In general, Dart is a well designed language, but there are some rough edges. Take for example the limited privacy options for class members: Dart only provides for private members where the boundary of privacy is the library.

While private members can get you a long way, often, what you are really looking for is a protected member, i.e. a private member that is still visible to sub-classes even if they are defined in different libraries.

I guess, the canonical example is a UI framework offering e.g. a Button class. When extending the base class to create your own FancyButton, access to 'private' implementation details is often required. Lack of protected access forces you to expose the implementation through public members.

Thankfully, there is a simple workaround. I will demonstrate with an example, leveraging the above-mentioned UI framework scenario. Let's start by defining a base Button class:

You cannot access the 'protected' members of FancyButton (or even Button's protected members, for that matter). As an added bonus, if you would like to side-step the protection (e.g. you are writing a unit-test and you would like to assert some implementation details) you can just instantiate the implementation class:

While this workaround is relatively straightforward, I really hope Dart's designers will introduce a @protected annotation in the future. An annotation that is statically asserted (e.g. by the IDE or dart-analyzer) would be an elegant and practical solution.

Apart from writing code for fun and profit, I have a thing about fonts. It's only natural then that programming fonts have a special place in my heart. Monospaced fonts are the defacto standard, but lately a radical idea came to my attention: using proportionally spaced fonts for code and leaving the actual typesetting to the editor.

While I am still not convinced, I have to admit that the proponents of the idea, came up with a beautiful family of programming fonts called 'Input'.

A lot about where we are today has similar characteristics. We have all of the ingredients for an information society in place: a global network that connects everyone, rapidly improving machine learning and automation, additive manufacturing and robotics (to name just a few key ingredients). We also have globalized many aspects of the economy with global corporations and supply chains.

Yet again the political leadership throughout the world is still largely thinking in industrial terms, including emphasizing the nation state as the geographic organizing principle (and playing up ethnic and religious differences). Once again we also have large groups of people who feel pushed around or left behind by the emerging information economy.

I am consistently surprised that people around me don't realize what is really happening in the world today. We live in dangerous times. You better expect (and prepare for) some disruptive changes within this decade. And I am not talking about Valey-style, hipster disruption here...

The representation of real numbers within computers leaves a lot to be desired. Every programmer is bitten at some point by floating point precision issues. Open a JavaScript console and type 0.1 + 0.2 for the canonical example. This fascinating paper frames the problem in whole new perspective and proposes a couple of innovative solutions. As the author says...

A well-articulated analysis, the following quote particularly resonated with me:

I don't think that Canonical is bad at what it does. It's just that they're rarely the best and being mediocre (or even second best) isn't good enough when the tournament effect is at work. The winner takes home the pot (e.g., becomes the new standard) and Canonical isn't winning.

Switching to Unity and competing on so many fronts was a mistake, Canonical is spread too thin. Still, the latest LTS release is pretty solid and pleasingly refined. I plan to stick with Ubuntu some more, these days my mantra is to be conservative with platform changes. If things don't work-out, there is always a safe fallback.

Still, I would prefer browser vendors to go after some low-hanging fruit first. I mean, emerging HTML5 technologies are cool and all, but how about concentrating on the actual HTML part first? How about implementing common forms controls (date/time pickers, rich text editors, improved validation and more)? How about fully implementing CSS Paged Media? How about implementing MathML? How about replacing .pdf with .html first and then focus on killing Flash?

And while we are at it, how about improving bookmark management in Chrome? The current interface leaves a lot to be desired (i.g. multiple categorization of bookmarks using tags and/or hierarchical folders, similar to the categorization available in Google Docs).

In short, I would like to see more pragmatic features sooner rather than later.

On the contrary, I thought that CSS can't handle vertical centering (at least in a cross-browser compatible way) and a quick Google session ended fruitless as well. Instead, I wrote a small script to programmatically center the div inside the window. It took a couple of revisions to support resizing, eliminate flickering, ensure cross-browser compatibility, etc. but eventually I got it right.

A few days ago, Joyent unveiled the public beta of their NodeJS-based platform-as-a-service contender. Well, this service rocks! From the great no.de domain name to the RESTful procurement/management API and the git-powered deployment, everything radiates coolness.

Even though I posted my hearts to the API end-point (/♥ !!), I haven't received any coupons in return. So there is no review for you. However, the elegant simplicity of the API (combined with the clean-slate design of the underlying NodeJS infrastructure) lights my geeky heart (pun intended).

I am not a NodeJS fan-boy. These days I am evaluating Java/GWT (so far I am positively surprised but I 'll reserve my final judgement for a future post). So, you understand, like everyone who feels overwhelmed by the complexity of the Java ecosystem, I can appreciate a refreshingly simple alternative.

Last year, Google released the Closure suite of tools for JavaScript development. It seemed too good to be true. A robust client-side JavaScript toolkit and UI framework was just what I missed in my stack.

I quickly downloaded the distribution and, like the rest of the world, was immediately disappointed: The source looked like Java, with long name spaces and getters/setters everywhere. The compiler looked interesting but difficult to setup and integrate in the build process. The templating engine looked ugly and required a compile step. I switched back to jQuery faster than you can say 'crap'.

The problem is I wasn't fond of jQuery either. It 's great for improving the interactivity of a page or adding special effects but leaves a lot to be desired when you are building a business-oriented Web application. As I am working on a series of Web applications for deployment through Google Apps Marketplace I decided to give Closure a second chance.

I followed a couple of online tutorials, browsed through the online API reference and the thoroughly commented source code and experimented with some demo apps. Eventually, the concepts of Closure started to sink in. But still, I had like hundreds of questions.

That's when I decided to buy the Closure, the definitive guide book, available as a Rough Cut from O'Reilly. What a great book! The author painstakingly discuses the design rationale behind the Closure tools and exposes the benefits of the suite. The Closure library is genetically engineered to work with the Closure compiler and the Google developers behind it are really obsessed with performance, memory consuption, compatibility and code safety/debugability. The whole system is optimized for bigger development teams, not quick Web page hacks.

Among other things, I learned that:

the powerful type system eliminates a large class of bugs

the compiler eliminates the long name spaces (and the corresponding run-time look ups)

getters/setters actually lead to better compression

you can split the client side code in multiple, independently loaded modules

the pseudoclassical pattern used for OOP is actually better than the functional pattern (when combined with the Closure compiler)

you can easily extend the Compiler with extra features...

...and so much more. I don't want to spoil your fun, just grab this great book. It's the only way to really get into Closure. Heck, I would recommend this book even if you are not interested in Closure, it will make you a better JavaScript programmer.

Don't get me wrong, no tool is really perfect. Closure still has some issues: no CommonJS compatibility (but then again, CommonJS seems kind of dead these days), limited support from Google (they seem to be pushing GWT instead) and a shallow community around the project. Still, Closure suits my needs better than other solutions.

Unless you 've been living in a cave for the last year, you know that server side (better: 'general purpose') JavaScript is all the rage. Everything started with CommonJS: the emerging standard spawned an ecosystem of compatible implementations competing against each other while advancing the JavaScript state of the art.

Then, NodeJS happened: An async only JavaScript platform, powered by V8, not really interested in CommonJS conformance. RY (the new DHH) managed to grab the attention of the developer community with cool marketing, leaving other implementations in the shadows. One such great implementation that deserves more attention is RingoJS.

Some time ago I switched from Narwhal to Ringo and never looked back. I strongly believe that Ringo is the preeminent CommonJS implementation. Here is why:

Ringo is quite possibly the most conformant CommonJS implementation, certainly more conformant than Narwhal and Node.

Ringo is fast. If you tried Narwhal/Rhino and found start up times lacking or module reloading unacceptably slow check out Ringo! You will be pleasantly surprised. And while v8 may be faster than Rhino, the JVM is still quite optimized for server side environments. (And btw, in a modern Web application, time spent running the server side script is a negligible percentage of the total request/response cycle. You should probably work on optimizing network issues, database interactions, client side rendering, etc).

Ringo is mature, stable and crash free. Ringo is the evolution of Helma, one of the first server side JavaScript platforms (more than 10 years in development). It's also based on the mature Java platform. Contrast this to reports of NodeJS crashes.

Access to the gazillion of Java libraries. There is no merit in reinventing the wheel, just reuse code from the Java ecosystem. The integration between Java and JavaScript is seamless.

Windows compatibility. OK, Windows sucks, but still, a lot of engineers use Windows as a development platform. Ringo apps work on Windows out of the box.

Support for synchronous and asynchronous APIs. Use what's best for your application.

Thanks to AppengineJS you can run your Ringo applications on Google's scalable infrastructure.

The lead developer is extremely talented and friendly.

Stop drinking the Kool-Aid! Engineer your application on top of a mature, conformant and compatible platform: RingoJS.

I 'm not in the mood for a long post, so here are some random thoughts in aggregate form:

f8

The new Facebook Social Plugins are FriendConnect done right. FriendConnect has so much potential yet the current implementation leaves a lot to be desired (to say the least). Moreover, the Graph API is a bold step forward towards the machine readable Web (Web 3.0 / Semantic Web if you will). The 'Like' button is an obvious (yet powerful) idea that Google should have implemented a long time ago.

π is wrong

I always thought that 'π' should be the number known as '2π'. Then 'π' would be the perimeter of the unit circle, angle measurements would be more intuitive (90 degrees == π/4, 180 degrees == π/2, 360 degrees = π, ie a full 'cycle' is π radians) and a lot of formulas would be simplified:

p = πr, i.e. scale the unit perimeter by the radius,
sin(x+π) = sin(x), i.e. the period of the trigonometric functions is π,

etc. At the moment π is the sum of the angles in a triangle and the perimeter of a circle of with a diameter equal to 1 (doesn't this look awkward to you?). Read π is wrong for a better treatment of the argument.

iPhoneOS TOS

The latest iPhoneOS TOS made a lot of developers angry. I don't agree. One of the problems in our profession is what I call a Babel situation: So many different languages and platforms hinder cooperation. Finding and integrating engineers into a software development team is a pain. Thus, having a single platform (iPhoneOS), a single system language (Objective C) and single scripting/application language (JavaScript) is refreshing.

Old time readers of my blog know that I regularly change the platform that I use. Lately, I was using Google's Blogger, but I wasn't happy with the layout. Before that, I used a lovely, custom-made, Ruby-based CMS. But since I am fed-up with Ruby (after 8 years, no less) it was difficult to maintain.

Therefore, I decided to utilise my AppengineJS and Nitro open source projects to create a new platform for my blog. This new version is implemented in JavaScript, the language of the Web, and one of the languages I dig these days (the other being Haskell). Even though I am relatively pleased with the result (and the clean code behind it), there is a lot of work to be done, when I find the time.

In the meantime, please subscribe to my feed and check this blog often for interesting content. Oh, and bug reports are always welcome ;-)

Update: This blog is not based on the blog-gae example source code. In fact, the blog-gae example is outdated and does not reflect the latest improvements in Nitro and AppengineJS. Perhaps, I will release the mini CMS behind this blog as an example if there is sufficient demand...

I had the pleasure of attending the first Open Coffee meeting, two years ago. From the humble beginning (10 geeks in a small cafe) the project went from strength to strength. Typically, around 300 people participate in the monthly event where aspiring entrepreneurs present their ideas.

I always thought that Open Coffee was just one part of the equation: surely, networking opportunities are important for bootstrapping an ecosystem of entrepreneurs. But a great idea doesn't guarantee a successful business. Neither does technical savvy.

A business needs funding, legal consulting, prudent accounting and strong management to flourish. The OpenFund is Open Coffee's long awaited take on this problem. Borrowing the concept of YCombinator and similar funds, OpenFund will hopefully spark a number of successful start-ups in the region.

The management team kindly accepted me as an adviser to the fund. I am fond of the idea of helping young people avoid the many mistakes I made in the last decade.