eelco

Check the logs. It is downloading another 3GB of stuff.

Framer is “just” HTML/CSS/JavaScript. This means you can also do things like embed (moving) GIFs, videos and use (almost) all browser APIs in Code Components.

It still works, Beamer uses a different part of the AirPlay protocol ‘suite’. We’ve tested with the betas to ensure it would. (I’m one of the developers.)

So, in the EU and US the average amount spent is above the average amount earned. I'd be more interested in more data on that than what OS was on their phones.

The partially unusable screen acts nicely as an easy to hit back button offering context about where you'll go back to. The spatial organization and animation showing the menu adds even more context, making this way of implementing a 'global' menu a pretty clever design all in all.

My only gripe with it that it might make it too easy to bring the complexity of big menus of the desktop to mobile device. As programmers we're (hopefully) all aware about the power and dangers of using globals.

That's not an option button on iOS. It leads to a menu of 'secondary' menu items, that are hierarchically on the same level as the other tabs.

For iOS/Mac development, Ole Begemann's http://oleb.net/ is invaluable, especially for the monthly link roundups.

I completely agree with you, but the user might have been trained by his iPhone to relate the speed of the spinner to the data transfer speed. (The spinner in the status bar of the iPhone indicating network activity has a different speed when you're on EDGE or GPRS versus when you're on 3G).

Utrecht, a whole city to buy your art supplies.

Steve Pavlina wrote a good article a while ago: http://www.stevepavlina.com/blog/2005/05/how-to-become-an-ea... Don't miss the links to more sleep experiments at the bottom.

iOS and all the apps are build for a specific _physical_ size. A larger screen would mean apps would need to scale (or run in an awkward smaller size) which would look terrible and be awkward to use (very large buttons). The alternative would be to ask developers to make another, slightly larger version of their apps. Not going to happen ;)

That was about three years ago, see http://www.economist.com/node/10328123

Either that, or you're still in school. (Not kidding, BB is very popular with teens, at least here in the Netherlands.)

No, Android phones are currently selling faster than iPhones (in the US). In terms of absolute numbers (and also counting iPods and iPads as iOS devices) it's think it's quite close (if you find trustworthy numbers, let me know).

But never mind Android, the dominant phone OS is still Symbian although nobody would say it is "leading the way".

The book the article links to in the end, Mindfullness in plain English is also freely available online (and as a download): http://www.urbandharma.org/udharma4/mpe.html

No, I had to compile my own kernels for several reasons.

1. My soundcard didn't work with any vanilla kernel (+ modules)

2. I owned a webcam that had a slightly different USB id than the ones supported by the driver that in fact also supported mine.

3. I owned a laptop with a touchscreen which involved having to compile some non-standard modules.

Anyways, things have gotten a lot better since I've "left", but Linux (on the desktop and Android, for that matter) will always be "very good the next release". Which is, of course, utter bull. If you don't have excellent polish as a priority from the start, you'll always be fixing things for the "next" version while simultaneously introducing 10 new half-baked "features".

Independent of what? Platforms, technology, customers? Don't kid yourself, there's always somebody who's your "boss".

His story reminded me a lot of the time I switched from Linux to OS X. There was a point where compiling my own kernels stopped being fun and I just wanted a computer that I could work with instead of work on.

The developers who got their app featured might disagree with you. It is a bit of a lottery, but not more so than, say, sending out press releases.

To be fair, the website says: "If you send any other three digit number that's not in that list, we'll return it too."

They seem to simply truncate the number. E.g., http://httpstat.us/39487394587394857349587 returns "394 Unknown status", but http://httpstat.us/200129038123 will return "200 OK"

I wonder where they used CouchDB and Cloudant for (listed at the bottom of the page).

Well, the faster the webserver, the more time is left for code to run while still having a very responsive website.

The article mentions the "pong" benchmark which seems to reside here: https://github.com/snoyberg/benchmarks. Looking at the code is doesn't do anything besides answering "pong" to any request so it's mostly about testing the overhead of the webserver, not its resilience against high loads.

Uh, in which part of the Netherlands do you live?

One of the reasons I enjoy programming for iPhone, you can let the engineer in you roam free to increase performance and not feel guilty ;)

The verification SMS took a long time to arrive and I couldn't find an easy way to get back to the page where the code had to be entered. Could find it using the back button though, but that wasn't really convenient.

Also, more importantly, making calls fails (trying to call my home number in NL) without any message about what went wrong.

Very often? Have you seen how many people are still using iPhone 3Gs (not 3GSs!) That's about two and a half years old.

Of course, Flash isn't patented at all. And H264 codecs always costs money.

I didn't know Google fanboyism existed.