What kind of impact is Let's Encrypt going to have on the CA industry? I'm not that familiar with the current state of the CA companies, nor do I understand this industry well enough to know if this is going to be a major hit to them or not.
Is there any reason why a company would prefer a CA other than Let's Encrypt?
This is probably to late for your use, but there is a neat Mac utility called iExplorer that lets you browse your iDevice's filesystem and copy files off of it. I'm pretty sure you could have grabbed the files using a trial of iExplorer.
I'm curious to hear what you specifically like about Stitcher. I have tried, and own, almost all of the major podcast apps and it was my least favorite experience so far. Their whole business model seems to be to scrape other people's content, download it, compress it, serve it up from their own servers and slap additional ads on it.
Some things that turned me off of Stitcher:
* Includes it's own advertisements on top of the ads already in the podcasts themselves.
* Increasingly difficult to skip past the Stitcher ads and if you want to remove ads you have to pay a monthly fee.
* Can't browse the episodes of a podcast without actively listening to a podcast?
The UI just wasn't that intuitive for me. Part of the problem might have been that I was looking for a "podcast app" and this was more a "radio app" built out of my podcasts. Using something like PocketCasts or OverCast has been a much better experience to me:
* No additional ads.
* No extra monthly fees.
* Easier browsing/control of your podcast episodes.
What am I missing about Stitcher? I could see it being useful for podcast discovery, or for when someone is new to podcasts. I just struggle to understand it's insane popularity over other podcast apps.
I'm one of the people that bought Launcher when I first heard about it. I often switch between one of several bluetooth devices and adding a link that takes me straight to the bluetooth settings from the notification center was a huge speed boost for me.
With tools like these out there, what can we do to protect ourselves? Besides not downloading binaries over HTTP (which still wouldn't protect you if a CA has been compromised) what other steps can someone take? I hate how vulnerable and yet utterly essential our browsers have become.
The MUD that I played on in middle school and high school, Viking MUD, is still around. http://www.vikingmud.org
I think the directions to the main areas will be burned into my memory forever. On this MUD, when you reached level 20 (which took around a week) you had a choice to make your character "eternal" and continue adventuring or you could choose to make your character a "wizard" who could create new areas yourself and write scripted actions for your area. However, you could no longer take part in the actual game itself. Scripting the areas I had created was some of the first programming experience I ever had.
A big difference between most of the games today that I play and some of those old MUDs was that there were very serious consequences to dying. You lost a level and all your gear if you died and it was extremely easy to die in the game, both from NPCs or other players in certain zones. Dropping from say, level 28 to 27 represented a solid week of hard leveling effort that was lost. I remember I died 3 times in one evening and almost wanting to cry I was so upset. It did make the game that much more intense though because the stakes were so high.
I still login occasionally but it is rare to see more than a few players who aren't idle. I remember that the quality of the community was very high. I don't know if it was because there was a relatively high bar to join and interact with the game that self-selected those kinds of people or what. You had to have the technical chops to connect to the internet, download and install a MUD client and then connect to the appropriate server. Then to be successful at the game itself you had to have a lot of patience, have a good memory and be able to read and react quickly.
Thiago claims that one of Vim's biggest problems is its lack of testing infrastructure. It is difficult to refactor or make changes without the chance of introducing some possibly obscure regression. This is probably a big part of Bram's reluctance to merge large changesets from other developers.
I honestly thing if he can successfully pull off this "msgpack UI" and get a solid set of tests written (which the community seems eager to start work on) this project will be a huge success.
Here is his quote from the mailing list:
"This may not be so obvious, but vim's biggest problem has nothing to do with the lack of the above features. It's something much more basic: poor testing infrastructure.
While vim has some automated tests(about 200 counting with the ~100 tests embedded in test 49) those only catch the 'biggest' bugs, with many small ones being introduced by patches and only detected at a later time. It's a true maintenance hell, and here's a post on reddit that illustrates the problem(even though the author himself disagrees with neovim): http://www.reddit.com/r/programming/comments/1yjzez/neovim_a...
The problem is that in it's current state, vim cannot grow because there's no easy way to write automated tests for it. The current test suite is very hard to understand and those that submit patches probably won't write tests because it's too complicated. But patches need to be tested, especially bug fixes which must acompany a regression to ensure they won't be reintroduced. So it's easy to see why Bram is skeptical about merging patches, especially new features: He has no way of knowing if those patches will break existing code. In the example given by the reddit comment, Bram 'solved' the problem by simply picking the lesser of two evils.
This is one of the firsts issues neovim aims to fix: By writing a msgpack 'UI', we'll be able to write well-documented functional tests in a high-level language. Contributors reporting bugs will be able to reproduce them with a test cases and new features will be properly tested. As the test suite covers more code, neovim will be more 'protected' since there will be a bigger chance of catching bugs the minute a PR is sent(with travis). People need to understand that before posting issues regarding new features or new ideas, as neovim must be properly 'secured' against bugs first."
I think the fee could be applied only to unsolicited emails. If I have a particular email address whitelisted then it will get through my gateway with no fee attached. However, if it is an unsolicited email from someone not on my whitelist it will be required to have some small fee attached to get past my filter.
I've seen some suggestions that instead of using money you could use some proof-of-work computation. This is something we could scale the difficulty factor of as computing power increased. Something that takes, say, an average computer 30 seconds (or longer) to calculate. It will attach this proof-of-work to the email.
I'm writing an iPad app for Mediabrowser 3 (mediabrowser3.com) with another developer. Mediabrowser is in the same space as Plex and XBMC. If everything goes well we plan on launching later this month.
We have invested a lot of time and effort into making the app fast. Our mantra from the very beginning was that speed was going to be a keystone feature for our app. The fluidity of scrolling in our views was one of the main things we focused on. We wrote test code that continuously scrolls our views up and down while we profile it. We are utilizing Path's FastImageCache along with a lot of other caching to get the performance levels that we wanted.
We are considering writing a new backend for our client app so we can launch a similar app for XBMC as well.
I'm an iOS developer and I generally do what you suggest here. I create a bunch of subclasses of UIView and do my positioning via layoutSubviews, implement sizeThatFits when appropriate, etc.
Despite this I feel like Apple makes it very difficult to keep all UI code out of your view controllers. I'd go as far to say they actively encourage shoving UI code into your UIViewControllers. Take a look at the interface for UIViewController -- it is almost all view/presentation related [0]. Most of Apple's sample code and projects have view code sprinkled all over their UIViewControllers.
I feel like it is a constant fight to keep proper view/controller separation on the iOS platform.
This reminds me of feelSpace[1]. It is a belt which has vibrating motors all around it and a compass. I believe the point is to give you an extra "sense" which after you have worn it enough you incorporate with your other senses.
Early on in the project we ran Uncrustify across our entire-codebase before introducing the pre-commit hook. The major downside to this was that git-blame now pointed to this large commit for almost every line of our project. It became a pain to trace back changes before the mass style change. Luckily we did this fairly early in the project so that it hasn't really been a big problem.
However, because the entire code-base was cleaned up at once we now have no additional noise from Uncrustify being run on our commits. The only changes to style it will ever suggest are with your current changes you are attempting to commit since everything in the repo right now is "clean".
I set this up for my team using Uncrustify and a Git pre-commit hook. It will reject any commit which has files that don't adhere to our Uncrustify config file. If it rejects the commit it gives you a command to execute that will automatically fix your style issues.
