Hacker News new | past | comments | ask | show | jobs | submit | azza-bazoo's comments login

I love services for app notifications but despair that there are so many -- having a management layer on top of all of them sounds awesome!


Our thoughts too! Thanks. :)


This is such an awesome, anachronistic mix of the shiny new and the internet of yore.

It's a shame MUDs expect you to be constantly interacting, I keep being slow and having them time out on me (then having to ;;reset to revive the session ...)


Social MU*s usually have a keepalive option that does some silent character exchange in the background with the client every so often to keep the connection open.


Hmm, do you have a specific example? (Of the MUD and client?)


Parent is most likely referring to the telnet GOAHEAD character and its related SUPPRESS GOAHEAD protocol: https://tools.ietf.org/html/rfc858

I am the author of a MUD client for iOS[0] that, like most other clients, will capture and silently discard the GOAHEAD character. GOAHEAD is most common on MUSHes but I've seen them in a few MUDs as well.

[0] https://itunes.apple.com/us/app/mudrammer-a-modern-mud-clien...


I've been tempted to send a "look" or "inv(entory)" command to keep-alive a session. Hmm...


I hope they publish a post-mortem when all is resolved, it'd be an interesting read. I remember hearing that they had a fairly complex mix of MySQL, Riak, and Varnish caching, in what sounded like a reasonably well-thought-out design.

Also, there's probably a fail-whale joke in here somewhere :-)


> You still have the same email client you paid for, you weren't paying for future features.

Although I agree, if you look through the other Sparrow threads there's a strong theme of "I paid with the expectation of future improvements". And that doesn't seem entirely unreasonable, given how quickly they'd shipped improvements before.

It feels like there's some larger argument here around what exactly you're buying when you pay for software. After all, many small vendors say things like "pay us so we can continue our work", which certainly suggests you'll be getting more in future.


I wonder what the false-negative rate of this algorithm is. 99% (which I assume is the true-positive rate) is certainly impressive for such a simple test, though.

It would be all kinds of awesome if this turns into something that can be done reliably and routinely!

Edit: seems like 99% is only for later stages of Parkinson's, and the accuracy number is just off a 50-person sample. Less impressive, but still cool. http://www.forbes.com/sites/singularity/2012/07/03/new-softw...


How do you get 99% accuracy for a 50 person sample? Has to be 100% or 98% surely?


Wow. Hopefully this will give Gmail the kick in the pants it needs ... the interface really hasn't changed that much since the early days.

(Well, of course it's been prettified a bit, but besides a few things like Priority Inbox there have been scant few changes to the interaction. And I always liked that using Sparrow felt different to using the Gmail web interface.)


> the interface really hasn't changed that much since the early days.

And why should it? I haven't used Sparrow, but I have no problems with gmail. How is it different / better?


GMail has changed A LOT since its early days. What are you talking about?

Gmail is pretty much perfect and the Labs additions can basically give you a "Sparrow-like" window and viewing pane already.

APPLE needs these improvements, not google.


> Gmail is pretty much perfect

There isn't any room for improvement in Gmail? Really? It's still using the same basic design of every email client since forever (labels/mailboxes at the left, inbox shows a time-sorted list of messages, click through a message to read).

Meanwhile Sparrow showed what was possible if you sit down and at least tried to rethink the email interface -- with things like gestures, or by shifting towards streams rather than lists.


Google invented the entire notion of email streams. Did you forget that?

People weren't used to seeing emails that followed like IM conversations.


... which still doesn't excuse them not running with the idea and continuing to improve. Sparrow did; maybe I should have said "shifting further".

(And yes, Gmail popularized conversation view, but it was talked about at IBM Research and Microsoft Research years earlier. Of course, those guys are even worse at delivering innovative interfaces.)


"pretty much perfect"... Wow. In what of the 2^160 senses of 'perfect'?


I was hoping for less "here's how your commit message should be formatted", and more "here's what your message should say". Though at least the blog it links to[1] discusses the latter.

No guidance on how many changes should make up one good commit (versus several)? No rules on referencing the issue tracker, or changes made by other contributors? No suggestions for when to put useful information (like "always do x when calling y()") in the commit or in a wiki or something?

[1] http://who-t.blogspot.com.au/2009/12/on-commit-messages.html


I don't think it's a symptom of hype in the Valley. (The high rents in general, sure. But not the hacker hostels.) As others mentioned, the whole point of being in the Valley in the first place is to be around other people doing similar things, because it's more fun that way.

But if you just step off a plane at SFO and walk around, you're not guaranteed to find people doing startups, especially if you don't know which coffee shops they frequent. Speaking from experience, staying at somewhere like Chez JJ means an instant connection to a community of smart and similarly-inclined people. It really is great for folks new to the Valley ("on the bottom rung"), and I think the article got at least that point correct.


"a program is without value before it is used by an end user for something valuable"

Nice snippet of advice there. Also the rest of Trygve's original post is an excellent reminder (and in simple terms) of MVC as an idea, rather than MVC as a label to slap on the next bit of JS code you publish on github ... which is basically all the intro paragraph says.


Pattern not product? I agree.

I do believe that many nouvelle programmers in their rush to absorb and contribute to the art integrate too many things too quickly and try to fabricate the magic recipe they just learned about into a hammer they can pound on everything regardless of whether the particular problem is a nail or not.


I would say the same thing about over-using and integrating frameworks. Backbone, NodeJS Mustache and coffee script. For what? If all a programmer has ever done is use frameworks they will never understand tacitly the problem its trying to solve.

I'm a strong advocate for using no framework, then building your own, then and only then introducing a library or framework because they can do it better.

This allows you to understand the pain of its absence, understand how to fundamentally solve the problem through abstraction or organization, and then fully leverage and reap the benefits of a well designed framework.

Some would say you don't need to walk 100 miles to understand the value of a car. But thats from the product side. I would say you need to understand the weaknesses of a car to build the next generation vehicle.


I agree with the last paragraph in the article -- it's pretty crazy to see Google anointing this software update as special and rushing it out so much faster than normal Android updates.

I mean, I get it, this is a headline-grabbing issue and they need to act to keep a flagship phone on the market, and it's Google writing this patch rather than the phone manufacturer. But if it's okay to fast-track and skip some of the process for this patch, why not others?


There are two possible reasons for this. This most probably is a small patch. just disabling a feature and not removing it completely from the phone; as such, it would not affect drivers and such like other Android updates. The second reason is that it may be just an app update for Search if they have that well separated from the OS, which would mean that it would not change any of the bloatware carries and hardware makers put in.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: