There’s no question that GFS faces many challenges now. For one thing, the awkwardness of supporting an ever-growing fleet of user-facing, latency sensitive applications on top of a system initially designed for batch-system throughput is something that’s obvious to all. [...]

The guys who build Gmail went to a multihomed  model, so if one instance of your Gmail account got stuck, you would basically just get moved to another data center. Acutually, that capability was needed anyways just to ensure availability. Still, part of the motivation was that they wanted to hide the GFS problems.

Besides the fact, that this is nothing new, but an ongoing trend that started a couple of years ago, there are three observations I’l like to share:

1. The authors seem to be at home in the Java world, because XML was mentioned as the only feasible data format for Web services. If you are used to work with PHP and/or JavaScript, you probably prefer JSON over XML, because it’s more lightweight and it is the natural choice for Rich Internet Applications that use a JavaScript frontend. The only real advantage of XML is the possibility to use XSL to transform data. Therefore it sometimes makes sense to use XML for server-to-server communication, but probably not when communicating with mobile or JavaScript clients, that don’t use XSL.
2. The list of characteristics of a good service interface does not list API versioning, which is very important for mission critical applications that are mainly based on Web services. Otherwise these applications will break very often.
3. Also, the API should be “stateless”, according to the authors. In reality, you want to use some sort of state for sessions (a shared token is common) and for transactions (to bundle a couple of API calls and only permanently store the data, when everything was successful).

In my opinion, these are the most important results:

• Try to exclude candidates with a high general degree of optimism as well as optimism in the estimation process
• Split larger tasks into smaller ones, which can usually be estimated more precisely
• Communicate frequently with the client to obtain direct feedback
• Estimator experience is one of the most important factors in archiving development effort estimation accuracy, although it’s impractical to appoint the highest-qualified estimator on every project

• I can confirm that the picture quality is quite acceptable, for a phone.
• However the most prominent (negative) feature of the iPhone is the bigger size and weight compared to the iPod. Of course you can also get that, if you buy one of the predecessors of the 4S.
• Also I like the white color.  You don’t see the fingerprints so easily
• Free entertainment: It takes a while to understand how your privacy is compromised by iCloud (so many features to turn on and off)

What I want to say is: As strange as it seems how inferior people feel after they leave Google, get rejected or not even contacted by Google – at least people respect this company a lot and it would be way worse (from a PR standpoint), if nobody talks about them.

Anyhow: Using the GWT to build cool apps (not just intranet portals) doesn’t seem to be fun and it is a good reason to look for a job outside of Google. JavaScriptMVC is so much better!

This masterpiece can be admired at my condo, here in Berlin

I have to admit that I’m a bit disappointed because they didn’t re-tweet the link or reply to me… but hey, I guess they are too busy^^

After committing the second flot fix, I found out that you can only send ONE pull request per branch and I didn’t even know how to create new branches. Not to speak about how to move the commits to the right branches. Without the help of Alexandre Salomé from Sensio Labs I would have been totally lost! Here is what he did:

git status
git checkout origin/master -b fix-fonts
git remote
git remote -v
git checkout upstream/master -b tmp
git branch -D fix-fonts
git checkout -b fix-fonts
git branch -D tmp
git log
git cherry-pick 82583fc
git cherry-pick 082e991
git push origin fix-typos
git push origin fix-fonts
git checkout 40d886f9
git checkout -b fix-issue-520
git push origin fix-issue-520
git checkout origin/master
git checkout upstream/master
git branch -D master
git checkout -b master
git push -f origin master

Simple, isn’t it?

I really have to read (and understand) a book about git soon.

While passing by a second-hand bookstore in Evanston, IL I saw the book Psycho-Cybernetics in the window, which was published in 1960, 12 years after Cybernetics was published by Norbert Wiener. Apparently Cybernetics was a popular and well-known term at that time.

The flight back to Germany will give opportunity to read through this book, but the preface already looks promising:

Our present state of self-confidence and poise is the result of what we have “experienced” rather than what we have learned intellectually. [...] Actual, real-life experience can be a hard and ruthless teacher.

Some might say this is common sense, but many people don’t act like that and IMO our schools still don’t focus enough on creative experiencing but rather try to go the intellectual way of learning everything out of a book.

Just as a side note: As an outcome of the cold war, the Cybernetics hype was replaced by the Artificial Intelligence hype. At least this was mentioned in the Wikipedia article about AI, which is more than I expected:

In the 1940s and 1950s, a number of researchers explored the connection between neurology, information theory, and cybernetics. Some of them built machines that used electronic networks to exhibit rudimentary intelligence, such as W. Grey Walter‘s turtles and the Johns Hopkins Beast. Many of these researchers gathered for meetings of the Teleological Society at Princeton University and theRatio Club in England.^[21] By 1960, this approach was largely abandoned, although elements of it would be revived in the 1980s. (Wikipedia)

What they don’t write is that it was abandoned for political and financial rather than scientific reasons.

The von Neumann architecture could be replaced by new massive-parallel architectures built around the memristor, see one of my last posts and then, maybe we can finally transfer our minds into a computer

Anyhow, I just think it’s sad how much knowledge and context gets lost over time, despite the fact that we’re living in a knowledge-society and the Internet enabled us to get all the information we want. But people are (of course) interested in hypes and books written decades ago don’t seem to be relevant anymore.

I think every experienced JavaScript developers agrees with his statement:

Browser-based JavaScript development is much more complicated than it seems.

Except that I don’t like the word “complicated”. When developers say something is complicated, it means they are too lazy to think about it and/or that they want somebody else to implement a feature. Instead I would say:

Browser-based JavaScript development requires more attention to detail than usual server-side programming languages.

That sounds to good to be true.