jpsim

We learnt a lot about Swift introspection and interacting with Swift objects from the Objective-C runtime. We'll share our findings in some upcoming blog posts, so stay tuned!

[0]: https://github.com/realm/realm-cocoa/pull/549 [1]: http://realm.io/docs [2]: https://github.com/realm/realm-cocoa/tree/master/examples/sw...

I also feel that many of the points the author had aren't strictly related to the language, but rather its standard library. Which could be argued that you can't benefit from one without the other, but still. Most of his concerns seem to be easily fixable through a more versatile stdlib, but there are certainly cases to be made against that.

For example, I'm not sure I want a language's standard library to know about JSON and HTML parsing, features that seem to be a better fit for non-standard frameworks and libraries.

I'm talking about the space DigitalOcean and Linode now occupy. Hobbyists who need a quick, multipurpose machine might actually consider Amazon now.

Either that, or a new "hosting" company will slap a simpler UI on top of EC2 and reap the benefits.

Is this a revolutionary product idea? No. Is it a platform for Facebook to see what sticks and then apply to its core offering? You bet.

The video starts off with the basics but gets into some pretty obscure, and interesting, internals on how things work.

I'm currently in Silicon Valley from Canada on a 2.5 day trip, with 4 interviews in that timeframe, and it's quite fun yet intense.

I'd also say that if you're a self-taught programmer (I'm an EE), it's worthwhile to read a book like Intro to Algorithms[1] cover to cover before you start doing technical interviews. There are just too many CS101 concepts that you'll never run into even after years of programming.

[1]: http://www.amazon.com/Introduction-Algorithms-Thomas-H-Corme...

https://github.com/mathiasbynens/dotfiles

https://github.com/thoughtbot/laptop

http://boxen.github.com

https://github.com/jpsim/laptop

Actually, for the author's simple use case (REST API), writing per-platform would probably have taken as much code as the wrappers themselves. Not to mention improved maintainability and a slew of other factors.

Diving down to C++ for cross-platform libraries starts to make sense when there are 4-5+ platforms (certainly not 2), or if there are complex algorithms (certainly not just a REST API), or if there's a very wide range of functionality (i.e. 100+ API calls).

It's more than that, though. Learning business tips differs from learning about a technical topic.

Business advice does usually state something obvious, but underlines its importance. There are a million "obvious" things to do, and a lack of resources to do them all.

Contrast that to learning something technical, where statements are more likely to teach you something immediately upon hearing it, but offer much less depth individually.

  if probability == "59.369936" {
    probability = "?"
    gender = "unknown"
  }

If you look at the revisions, you'll see my 1st iteration was mostly identifying patterns, then with more and more cheating (and looking at this thread) to squeeze every point possible.

1. Native (iOS/Android)

2. Native (iOS/Android) with some content in webviews

3. PhoneGap (iOS & Android, cross platform, same app)

4. Xamarin (iOS)

5. RubyMotion (iOS)

I recommend 1 & 2 if you have the resources (time to learn native iOS/Android or an experienced developer available). A good approach is to write all the structure/navigation natively and individual content in webviews. LinkedIn's mobile team uses this technique exhaustively.

Xamarin and RubyMotion (4 & 5) are both great 2nd choices if you dislike the Objective-C / Java languages or your team is well versed in C#/ruby, but you'll still have to learn the SDKs. There isn't much you can't do in these frameworks that you could do "natively", since you're still hooking into the native runtimes (loosely speaking). Xamarin is a bit more stable than RubyMotion, imho.

I'd stay away from PhoneGap if possible. My main takeaway is that "write once, run everywhere, sdk agnostic" is a pipe dream. You'll be disappointed when you're investing tons of time in the last 10-20% of development, working with fringe cases on different platforms. If you find yourself considering PhoneGap, consider whether or not being on the App Store is necessary at all, or if you can get away with a standard web app through the browser.

True, just as writing in any language you're not familiar with will take longer.

For even a semi-experienced iOS/Android developer, it can be faster than writing an HTML/web app.

This way, even if the stored data is accessed, you'll have a hard time reconstructing the original fingerprint characteristics, and it'll be pretty much impossible to regenerate the fingerprint itself.

It's missing external dependencies which seems to be the goal of the included buildAspenProject.sh, but I can't get it to run 100%. I'll report back here when I can successfully build it.

EDIT: The git repo is missing the necessary patches to vendored code. i.e.:

  git am ../../patches/*.patch

Sure, those don't have support for NSNotifications, but I've found it's best to avoid those as much as possible anyway (essentially like a super GOTO).

[0] https://github.com/square/PonyDebugger [1] http://shopify.github.io/superdb/