Full Of Caffeine

The original title of this post was “Unifying the web with haXe”, however, after considering that haXe also outputs to C++, and that the other two platforms, PHP and Neko can be used beyond the web spectrum, I though I’d change it tot the current one.

Have you ever dreamed of ditching javascript, and or at least avoid the constant switching of languages when you are developing your next big web thing?

Well, the technology for that is here, and has been here for quite some time. Pre-processors, Generators and DSL’s are here to help (Take the Rails RJS engine, for example).

However, most of the solutions are either too complex or don’t offer enough flexibility/maintability.

Enter haXe.

haXe has been around for quite some time now, and has become a nice language/compiler. It generates code for many different languages, and allows you to keep one codebase and target different languages/platforms. haXe currently supports compiling for:

• The Flash Platform – compiles directly to bytecode;
• PHP – generates PHP sourcecode from haXe source;
• C++ – generates C++ sourcecode from haXe source;
• Neko – its brother, Neko, is a Virtual Machine and haXe generates bytcode for it;
• JS – generates JS code from your haXe source code;

The cross-platform compilation capabilities is what makes haXe special. Besides, it’s language is based on the ECMA-Script standard, and Nicolas Canasse, the creator, says it is a more well-though implementation of ECMA than ActionScript 3.

I never played around with haXe long enough, but this time I decided to at least try compiling a Hello World script to PHP, Flash and JS.

I leave the possibilities of such technology for you next brainstorm session!

Now, let’s get our hands dirty.

Firstly, we need swfmill. Swfmill processes xml and compiles them to swf. It can be used to construct simple swf animations or, on our case, build a swf as a library, to be used by haXe when we compile our
final SWF.

Now, get haXe. Go to www.haxe.com, and select the right installation package for your system. Installing haXe is easy, just click a button and wait a few moments.

Unzip the haxe_crowd.zip file somewhere in your filesystem, unzip it and you will see the following files:

• HelloWorld.hx – the super-powerful retro-style classical HelloWorld is back; This is the main haXe class;
• 3 build_flash.hxml – the build file for the flash version;
• build_js.hxml – the build file for the javascript version;
• build_php.hxml – the build file for the php version;

Note that the objective of the “application” is to display the haXe logo. As we are dealing with very different
platforms/technologies as output (js, flash, php) the way they do the very same thing (show the logo) varies and the API is different. Because of this, we need to use conditional compilation, and check if it is compiling for flash, php or js, and use the right code accordingly.

However, it is possible to abstract (and I’m sure it has been done already) in a way that the API is the same for different platforms (i.e, one method call would show the image for the three different platforms and the details of the conditional compilation would be hidden in the implementation of such class/library.

The point is that we have only one codebase that can target many different platforms. Of course, it takes a good developer that knows OO and haXe very well to abstract it in a way that we have minimal difference between the platforms.

However, there’s another benefit of using a technology like haXe. The remoting development is smooth. For any of you who have worked with Flash Remoting, you know that it is a pain to map the classes in the
backend, and sometimes you end up with simpler data-structures (in the case of AMFPHP).

haXe remoting solves this problem. As both platforms share the same class definition, the server/client side deal with the very same data-structure. Neat!

Ok, now go back to where you have uncompressed the zip file, and type:

$ swfmill simple assets.xml assets.swf

Now you have the assets.swf, which include the haXe logo in its library, exported for AS and with id equals “photo”.

Now, open up the build_flash.hxml in your favorite editor. Here’s what you will see:


-main HelloWorld
-swf-version 8
-swf hello_world.swf
-swf-lib assets.swf


• The -main directive specifies the class with the entry-point method;
• The swf-version specifies which Flash Player version you’d like to target;
• The swf is the actual name of the output swf
• swf-lib specifies an swf with assets that may be used by the final swf (image, sounds, other clips);

We’ve got everything we need, the assets.swf, the source code and the params for haXe to compile it. Now jump into the command-line again and type:

$ haxe flash_build.hxml

You should then see the output swf, called HelloWorld.swf. Open it through the hello_world_flash.html document.

Now, you can also compile for the php and js targets:

$ haxe php_build.hxml

For JS, you’ll need to install DomReady using haxelib (equivalent to rubygems in the Ruby world):

Firstly, setup haxelib, for a quickier setup, just press to accept the default path:

$ haxelib setup

Then, install the DomReady library:

$ haxelib install DomReady

Now, you are ready to compile the JS version of our amazing app:

$ haxe js_build.hxml.

The flash and js builds are the ones that have more code. Flash needs the assets swf, and js needs an additional library called DomReady (used to run the code only when the whol DOM tree has been loaded).

You can see that in all the builds, lots of infra-structure code is generated, this is the way haXe abstracts its standard API across all the platforms, and some support code is needed.

For the JS versio, open the hello_world_js.html file. This file includes the hello_world.js we just compiled. The code just selects a DOM node and replaces its innerHTML with an tag with its src attribute pointing to the haxe_logo.jpg file.

For the php version, you can either setup your current webserver to browse it or just use the command-line php interpreter like this:

[php/]$ php index.php

You’ll see that the tag output in the console.

There’s also support for a virtual-machine called Neko and C++. There are even some iphone apps that have been developed with it.

haXe, despite existing for 4 years already, hasn’t grown “mainstream”, it is still a niche, albeit with a very active and exciting community. The idea behind it is amazing and has great business potential too (reuse your knowledge for multiple technolgoies, keep the same language despite of the technology).

I’m hoping that soon it get more support from more developers and companies, but that, my
friend, also depends on you too! So, grab a copy of haXe and start playing with it today!

Resources:

• Support files for this tutorial: hxllo_world.zip
• Official haXe website
• Swfmill official website

Ouch…

After 3 years using emacs, I never thought I’d start using TextMate, but I must admit the temptation is big…

Emacs is a lifetime investment, you can reach mastery but you will always learn something new. The mastering of keystroke combos is only the beginning.

Then, you start wanting to learn elisp, and after you are used to it, start implementing all sorts of cool stuff into the editor (or should I say OS?). The problem is: elisp is not an easy language to learn, and mastering it takes quite some time (I don’t even consider myself an intermediate elisp programmer yet).

Emacs is marvelous. It is lightweight, it couldn’t be more extensible, it has excellent text-editing features and works well.

I’m still an Emacs type of personality, and I think I will always be.

However, Textmate looks like its worth trying. I’ve download the 30-day trial and I am playing with it. What I liked so far? Well, here it goes:

• It integrates very well with Snow Leopard (emacs 23 also has a great level of integration, though)
• The Graphics User Interface is slick and simple;
• It has a great project browser, which comes in handy when you don’t know the folder/files structure (emacs has ecb, but honestly it is ugly)
• It has great editing capabilities

The “go to file” feature doesn’t impress me that much, however. Emacs has an extension called gpicker which is, in my opinion, the evolution of Textmate’s “go to file”. The one from TextMate only searches through files, while gpicker takes into account directories and substrig across all the paths, which makes it a snap to find files with the
same name but which are in different directories.

The problem is, gpicker requires gtk+, and I haven’t managed to compile gtk+ on Snow Leaopard yet.

The veredict: I will never stop using Emacs, it will be always be there, be as a platform for my wiki, PIM, or whatever. However, I will try Textmate for Ruby/Rails/Web (js/html/css) development for the next two weeks and see how it goes.

Wish me luck!

Something I’ve noticed throughout the years I’ve been working with OO languages, is that, you end up under-estimating OOP. Why?

Well, my path was something like this:

• Delphi (Object Pascal)->PHP->ActionScript2->Pyhton->Ruby.

(I have touched Java and C# for quite some time, but I don’t consider them part of my portfolio since I haven’t dug into them as I did with the languages above — I didn’t like them either).

When I started with Delphi, everything looked so amazing. From the book by Marco Cantù, I have learned the fundamentals of OOP, and very well. Delphi is a language that implements OOP efficiently.

At that time, my *mindset* was totally absorbed by OOP, for every single computing issue I had to solve, I had to create a class, inherit another one, delegate methods to a composite object (composition) and so on.

Then I started with AS2 and Flash. Oh, what a beautiful time it was. Flash is a really amazing technology. At that time, the Flash Platform term was starting to be coined, as Flash was in the transition from being a simple player to a full-fledged application platform (with Flex 2 sticking on very hard later on). I used to read all kinds of books about design patterns, send mailing-lists messages asking about the best way to implement a certain design pattern, and obsessing about member visibility encapsulation, when programming ActionScript 2.

When you get to dynamic language like Python and leave the world of statically-typed languages, you start to enter a more pragmatic culture. The hidden message from the communities of Python and Ruby is: Be Pragmatic. In other words, time is more valuable than perfect architectures, and, it’s better to have legibility and flexbility than an over-engineered OO architecture.

The materialization of all this is in the Rails framework.

Although Rails is becoming more and more OO as time goes by, the main values behind it are:

• Keep it Simple, Sir
• Don’t Repeat Yourself
• Test,Test,Test; and later on Test-first,Test-first,Test-first
• Convention Over Configuration
• Stop spending all your time programming and get a life!

It’s true that Rails has enough OOD, but it certainly is not as OO as Wicket or any other Java framework for that matter.

Ruby is OO, it supports inheritance, member visibility, composition, polymorphism. It is even more OO than Java, since everything is an object.

The point is that the community valued more these values than over-engineering an OO architecture.

However, and I think here’s where the main problem lies, the hype comes with its distortions of reality. The Rails hype is no exception!

If you showed Rails to any well-versed software engineer at that time it was still a pet project from DHH, I think the default reaction would be laughter.

When DHH wrote Rails, it was essentially a request based (web) MVC framework that had sensible defaults. I bet that if he started it over again right now, he would do almost everything differently, architecture-wise.

However, Rails is more than technology, it is a way of life. It communicates what DHH believed about life. It should be simple.

Nowadays, Rails is becoming more and more complex, other design patterns have been adapted, there are more layers (rack) and the plugin system is becoming more strict (Rails 3, following Merb’s approach to plugins).

I think that’s the result of years of evolution, and that the community decied that Rails would be the killer framework for Ruby, just as Hibernate and other highly-configurable frameworks are for Java.

The philosophy behind Rails is still there and for me, is the most valuable thing I’ve learned since I entered the community. The philosphy is also what led me to “get back to the inner-game” and focus on Ruby, instead of Rails, as well as choosing Sinatra for the rebuid of this website (less is more).

Rails heavily marketed the use of TDD. Before Rails, Web Development and TDD for me were like water and oil for me — they didn’t match. However, as I learned more and more about Ruby and Rails, I saw the importance of TDD.

The tendency? Well, I think Rails is going to be more and more OO, as time goes by — more abstractions will be implemented, maybe we will be able to have a component-based Rails framework. That’s good, that’s choice, that means Rails, the eco-system, is growing.

Despite all the bad-press that OO got because of over-engineered OOD,
design patterns and stuff related, let’s remember that Object Orientation, when used wisely in its context, does help a lot to keep things clearer and more maintanable.

So, don’t under-estimate OO, get more into it, study more on how it applies to Ruby or whatever language you happen to spend more time with. OO is “Java-agnostic”, so, don’t transfer all the bad-press from Java to it. OO is also design-pattern agnostic, hence, don’t transfer all the bad press from design-patterns to it.

PS: I’m planning to write a series of articles comparing classic OO (C++,Java,AS2/3) with “new-age” OO (Ruby), it should come in the next few weeks.