kainosnoema

It's neither prior art (though it was started prior to the recent patent publicity), nor a re-implementation (as stated in the readme, it's just a wrapper around OS X's NSLinguisticTagger).

Why can't it just be a useful tool? I'm looking forward to using it while writing project documentation and will be working on editor plugins using the JSON formatted output (https://github.com/stephencelis/syn/commit/d2d36473f7295c6cf...).

Initially I had the same concern, but after digging a bit deeper, I don't believe this would be an immediate outcome. From the little I can gather, the ABC conjecture is really just a statement about the relationship between the operations of addition and multiplication on triples of coprime positive integers. While prime factors are involved in the conjecture, it doesn't seem that the proof of the conjecture would naturally lead to prime factorization in polynomial time. I'm not a mathematician though, and given how radical Mochizuki's proof sounds, I imagine it may (if it stands) eventually lead to more efficient factorization algorithms.

Advances in computing power seem to be a more worrisome threat to RSA, especially for RSA-1024 whose factorization is probably already feasible (http://www.cs.tau.ac.il/~tromer/papers/cbtwirl.pdf). And once advances in quantum computing become reality, quantum algorithms should be able to very quickly break even RSA-2048 (http://en.wikipedia.org/wiki/Shors_algorithm).

OAuth 2 + JSONP might be a good solution to the cross-origin issue.

The primary client for an API I'm currently working on is an iOS app, so for the web version of the client, it just made sense to build on top of the same OAuth-authenticated API. Instead of traditional sessions, we store the access token in a cookie and sign each authenticated request just as you would any third-party API.

This is interesting, but it looks like I have to learn another DSL, as well as figuring out how to describe my screens in CoffeeScript so the DSL can interact with them. I'm not even sure what the point of the intermediate layer is. Why not write the tests directly in CoffeeScript? Or even better (for those of us not infatuated by CS), why not just build a DSL expressive enough to interact with the screen directly?

For those not wanting to deal with yet another language/server, Square's KIF testing framework is really well done, integrates right with your project in Xcode 4, you can write your tests in the same language you write your code in, and you also get screenshots when tests fail: https://github.com/square/KIF

I can't say much since I'm still under NDA, but I can tell you that my co-founder and I got all the way through the MFI approval process, without any kind of "lawyering up". Apple was great through the entire process—very eager to help us get our small project started.

The MFI program isn't the easiest process in the world, but it isn't impossible. Definitely doable as a side project if you're motivated.

No. Keeping all your code in one file is a recipe for maintainability disaster. I've found that with Javascript, proper project organization is even more important than with some other languages.

It sounds like you haven't become familiar with Node's CommonJS compatible module system. Try starting there: http://nodejs.org/docs/latest/api/modules.html

Once you understand the basics of modules and requiring, I'd take a look at the ExpressJS example apps for organization ideas: https://github.com/visionmedia/express/tree/master/examples

This is definitely a big loss for Austin. There are still a few interesting startups in the area, but Gowalla was the one that made it a serious contender.

Nobody can say for sure yet, but I doubt it'll be around very much longer.

If you're looking for a check-in API, Foursquare's seems like the best bet at this point. The Venues (ie. places) Platform is especially good, with rate limits starting at 5,000/hr: https://developer.foursquare.com/overview/venues.html

Gowalla's been moving away from the check-in too, but even so, I imagine its mostly a talent acquisition. The source article mentions that the team will be working primarily on Facebook's new Timeline, which fits well with Gowalla's recent focus on "stories".

There's a reason the client libraries are lacking though.

In my experience with both OAuth 1.0 and 2.0 libraries for iOS, Node.js, and Ruby (among others), OAuth 1.0 is just a lot harder to implement. It's not fun in any way...

He's right. OAuth does suck. Thankfully OAuth2 sucks less... a lot less. We're working on an API now, and only plan to support OAuth2.

As far as the iOS side of things, the OAuth2Client library by nxtbgthng has worked amazingly well for us: https://github.com/nxtbgthng/OAuth2Client

Is there a particular reason why you decided to purchase 14 physical servers instead of spinning up virtual instances (or even co-located servers) for easy scaling? As you've discovered, it's hard to estimate what kind of load you'll need to handle, and the up-front cost is impossible to recover.

Also, I'd recommend spending some time looking at your architecture, as you should be able to handle 50,000 active users with a lot less metal. The extra infrastructure can often be more expensive than a well-designed architecture.

This is a duplicate of this post from a few hours ago: http://news.ycombinator.com/item?id=3115872

To be honest, this doesn't look like much of a web framework. The examples show views being built up using string concatenation... reminds of my pre-templating days building snippets for jQuery.

Really though, everything shown can be easily replicated with a bit of Connect middleware, and it'd be cleaner. I don't see the point?

MessagePack in Node isn't much more than bindings to the C++ library (https://github.com/pgriess/node-msgpack/blob/master/src/msgp...). For me the bottom line was "What's faster in Node, for my project, right now?", and the answer was JSON.

There are benefits to MessagePack that have already been mentioned here, namely not having to base64 binary data first (smaller size), but that's true for any binary message format. I'd love to see some other binary formats thrown into the ring and see how they compare to MessagePack in both size efficiency and encode/decode performance. BSON seems like an interesting option, but I don't know enough about it to comment...

Good point... a Node MQ project formerly based on msgpack recently switched to JSON and increased its performance by almost 200%: https://github.com/aikar/wormhole/issues/3

I've done several of my own benchmarks as well and can confirm that the current Node JSON implementation is much faster than MessagePack. Their benchmarks are most likely quite old.

Because JSON is around twice as fast to encode/decode in Node, which is where I really need the performance. MessagePack is just slow, complicated, and unnecessary.

In recent benchmarks, Node's JSON implementation is almost twice as fast as messagepack. I think I'd rather have the more universally used format anyway.

In my experience, it takes an incredible amount of effort and experience to solve a complex problem with simplicity and efficiency. It's well worth it, but there's definitely a cost, and not everyone is capable of it.

Congrats on the launch, guys! We've tried it and love it.