Protected members in Dart classes


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:

library ui.button;

// 'Public' API
abstract class Button {
  factory Button({HtmlElement host}) = ButtonImpl; // Redirecting constructor
  void click();

// 'Protected' implementation
abstract class ButtonImpl implements Button {

  int state = 0; // 'protected' implementation detail.

  void click() {
    this.state = 1;

In your application, namespaced in another library, you define a custom button:

library; // notice, this is another library

abstract class FancyButton extends Button {
  factory FancyButton({String title, HtmlElement host}) = FancyButtonImpl;

class FancyButtonImpl extends ButtonImpl implements FancyButton {
  String title; // voila, a protected property

  ButtonImpl({this.title, HtmlElement host}) : super(host: host);

You can use it like this:

final button = new FancyButton(title: "Cancel", host: element);

button.title // => cannot access!
button.state // => cannot access!

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:

final button = new FancyButtonImpl(title: "Cancel", host: element);

expect(button.title, equals("Cancel")); // => true

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.

Cool retro terminal


I dig command line terminals, I dig retro computing, I dig cool stuff. And I absolutely love this mind-blowing combination:

Amber flavor

Green flavor


Input font system


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'.

Input font gallery

What can I say, it's my new favorite :)



So old-school, yet so modern. I especially like the music!

Were are we today?


Is it 1880 or 1914?

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...

Right-size precision


The need to right-size precision to save energy, bandwidth, storage, and electrical power

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...

Let’s make computer math much smarter than what it was in 1914!

No Juju for you!


Ubuntu's Not Invented Here syndrome

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.

The evolution of browsers


A new month, a new version of Chrome is released. Don't get me wrong, Web Audio is interesting (one more nail in the coffin for Flash) and Native Client may be a solution to the primary roadblock in the evolution of the Web towards an application platform (namely JavaScript).

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.

Nasty Java catch


Some time ago, I wrote about a nasty JavaScript catch. Well, it seems that no language is immune from nasty surprises, so here comes one for Java:

BigDecimal value = new BigDecimal("0.31");
BigDecimal oldValue = new BigDecimal("0.34");
BigDecimal ratio = value.divide(oldValue);


java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.

Funky, huh? Let me offer a quick fix:

BigDecimal ratio = value.divide(oldValue, BigDecimal.ROUND_HALF_EVEN);

For some intuition (in Khan's parlance), have a look here.

Ultra geeky holiday e-Card


This came to my attention and I had to share it:

Center a div horizontally and vertically using CSS


A few days ago, I needed to center a mini site horizontally and vertically (don't you just love client requests?). It 's easy to tackle the horizontal axis using CSS:

.hcenter {
  margin: auto;
  width: 320px;
  height: 240px;
<div class="hcenter">Horizontally centered text</div>

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.

Today though, I re-discovered an old trick:

.center {
  position: absolute;
  width: 320px;
  height: 240px;
  top: 50%;
  left: 50%;
  margin-top: -120px;
  margin-left: -160px;
<div class="center">Horizontal and vertical centered text is possible.</div>


Update, 24 Oct 2010: Oh, there is a better way:

line-height: ${height}px;

where ${height} is equal to the height of the container.

Update, 31 Aug 2014: HTML5 rocks! You can do this easily now, using CSS flexbox layout.

I ♥


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 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.

We are what we repeatedly do


We are what we repeatedly do. Excellence, then, is not an act, but a habit.

Aristotle, 384-322 BC

Closure: The world's most misunderstood JavaScript library


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:

...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.

The verdict? Buy Bolin's excellent book and give Closure a try!

RingoJS vs NodeJS


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:

Update: Removed a controversial link.



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


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.

The Web is the new UNIX


The Web is the new UNIX, UNIX is the new BIOS.

George Moschovitis, 2010

New blog platform


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...

The Open Fund


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.

Read older posts in the archive, or subscribe to the feed.