justinvoss's comments

I've been using Feedbin for a few years and have been happy with it, especially since it syncs with my preferred iOS client, Reeder.

https://feedbin.com

https://www.reederapp.com

I think Cast does something like that? I haven't used it myself, so I'm not 100% sure what features they offer. But it sounds like they handle streaming audio between co-hosts, recording individual tracks, and doing the post-show editing. https://tryca.st

There's another explanation of Kalman filters here: http://www.bzarg.com/p/how-a-kalman-filter-works-in-pictures...

Honest question from someone who hasn't done C++ in a very long time: why is "header only" a good thing?

You could use this technique to examine the man page for a program and infer from that what valid command line arguments would be: some terminal shells (fish, for one, possibly zsh as well?) do something like this already to support autocomplete.

Because then the thumbnail where you see your own face behaves more like a real-world mirror, which is easier to reason about if you want to adjust your position.

Well, the iPad Mini has a pixel density somewhere in the middle: it's higher than an iPad 1 or 2, but lower than a Retina iPad or iPhone (in fact, it's density is exactly equal to the pre-Retina iPhones)

The overall size of the screens affects your perception, too, I think: a large iPad screen feels different than a pocket-size phone screen.

Retina for games may not be a big deal, but Retina for text definitely is: I notice the difference when reading on my iPad 2 vs my iPhone 4S. The distinction doesn't seem like much when you're in the middle of reading, but your eyes will definitely notice when you go from a screen that's Retina to one that isn't.

As someone who knows both Javascript and Objective-C, this is less readable than either.

Underscore.js may have some useful abstractions, but they'd be better exposed as Objective-C categories rather than trying to shoehorn everything into Javascript syntax.

Looks really similar to Coffeescript. Is it safe to say that this new Javascript feature is a direct result of Coffeescript's influence? I hope so: Javascript is full of little horrors like the 'this' keyword, and it seems like it took a whole new language to convince people that it needs fixing.

iOS and Mac apps are a lot of fun to write and work with, for two reasons:

1) Objective-C is a pretty decent language. It's not perfect, it has some baggage, but overall it's pretty neat and has enough flexibility to build a good platform.

2) Apple has built two good platforms, in AppKit (Mac) and UIKit (iOS). These frameworks are the real secret sauce, not the language. They're comprehensive and generally well-built, and make working on Apple platforms a joy. They actually take advantage of the unique features of Obj-C.

If someone could produce a web framework of the same caliber as UIKit, I think Objective-C would make a great server-side language. But building such a framework is not easy.

The basics are definitely easy. A lot of apps need more than the basics; even changing between landscape and portrait can be tricky and more complex that a simple autoresizing mask can handle (I would know, since I'm neck-deep in developing an iPad app that needs this kind of complex layout and needs to support all orientations).

I'm definitely aware of the autoresize tools, but like you said, as soon as you start to have variable sized data it all sort of falls down. Then you wind up having to switch to using a UIWebView, which means redoing a lot of work. It can also be a huge headache to support both portrait and landscape mode with only the autoresize tools.

The author may be overstating how rigid they are. iOS apps can be much less dynamic than web apps, mostly because you're working at a "lower" level in the GUI stack. Instead of having a layout engine that recalculates the positions of your UI elements for you (eg, HTML and the box model), you mostly have to manage the position and sizes of everything yourself.

You could create your own layout engine, but most developers choose not to, especially since the consistency of iOS hardware means they can predict screen sizes easily. Your other option is to make your app a thin wrapper around a Webkit view, but that tends to produce poor results (see the Netflix iOS app for an example).

I agree, but aren't these fundamentally hard problems? Take your calendar example. You could solve that problem with:

* Standardization. Difficult, but possible, if you can convince the entities involved that it's a good idea.

* Machine learning. Unreliable, since even a human might have trouble bridging the gap between the phone calendar's idea of an 'appointment' vs the desktop calendar's idea of an 'appointment.'

* Future Magic. Only works in Microsoft promo videos.

Neither of the two serious solutions seems very good. Is there a better way that I'm missing?

I've started to feel this way, too, but I guess I'm more selfish: the things I want to do and the products I use mesh together really well, and I've stopped caring about other people's problems.

I feel bad for people who have hopelessly broken setups, but not bad enough to want to help.

Great work; this looks way nicer than the competition.

Is Speaker Deck a for-profit idea, or is this a side project for Ordered List? I'd hate to see this turn into SlideShare: a hopeless mishmash of tacky ads.

I'm sure Apple will still use the UDID for provisioning. This change sounds like they're removing access to it from the device API.

That's very much a matter of opinion. Personally, I would rather write Objective-C/J than Javascript.