985 karma · joined May 9, 2009
Is there any reason why a company would prefer a CA other than Let's Encrypt?
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 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.
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'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.
http://i.imgur.com/xCyfnjt.png
http://i.imgur.com/RNAUaNN.jpg
http://i.imgur.com/n3j11jI.png
http://i.imgur.com/mA4JTNu.png
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.
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.
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".
Edit: Here is an unnoficial torrent magnet link: http://mgnet.me/foUDd
However, one of the podcasts I was listening to said that a security company registered one of the random domains that Cryptolocker checks as its master control server so that they could measure the number of people who were infected. Their numbers showed around 15,000 unique IPs per week contacting their server. The ransom has been lowered to 0.5 BTC so if all 15k people paid the ransom this mean about $7.5 million dollars a week at current prices.
I'm not sure how much that would effect the price of bitcoin.