Localdatabase released

I'm pleased to announce the availability of localdatabase. Localdatabase is a database abstraction layer that provides fluent interfaces for more readable code. It now supports Google Gears database. Recently, I spent 20 caffeine-fueled days building offline support for an existing enterprise J2EE monolithic application for a pharmaceutical company based in Barcelona. The magic of this Javascript framework is that it suits any kinds of legacy applications provided that you use Google Gears. I learned a lot over the course of those 30 days and even more after launching the functionality and hoped to share this production with other developers looking to work with Gears. It's now released on Google Code. You can download it here. What lies beneath is a clean support of Web Storage and Web Database APIs. It is in progress and I will update you. It will be the logical progression from Google Gears. Upgrading localdatabse for full HTML5 Web database support will not affect the API interface. It is just a matter of adding a simple wrapper of this asynchronous API. For Google gears, i implemented a simple wrapper of the Google Gears Database API. Currently, there are tons of Javascript framework that provides an abstraction layer such as gears-db-lib or sqljs. So what 's localdatabase good for ? Well, from a developer perspective, it helps writing readable code and it is undoubtedly essential for any applications. I kept as much as possible the SQL semantics. Passing in the wrong parameters won 't happen. The core aspect of localdatabase is the use of method-chaining pattern and the end result is quite interesting. Here's the code to select the 12-year-old kids living in Paris ordered by name:

_db.from("PERSON").where({age:12,location:"PARIS"}).order({name:"ASC"}).each(function(kid) { alert('Hey my name is ' + kid.name); });

Its use is simple. Instead of using a callback you now using Localdatabase chaining to execute all the methods that you need. What 's more is that it eases common database tasks like data exports or drop-creating. For instance, to export your data in a JSON format with Jquery: var lines = _db.from("ORDER_LINE").list();

var orders = _db.from("ORDERS").list(); var export_data = $.toJSON([{"lines":lines},{"orders":orders}]); // you can send it now

If you have any request, please do not hesitate contacting me. Contributors are welcome!

Running Python on Google App engine in 5 minutes

The title might be misleading. We're just going to run a simple Hello world Google app with the developpement environment. I'll be concise and write this item in 3 steps. The "Getting started guide" is self-explanatory. So if you merely want to start with a hello world app in 5 minutes here are some instructions I tested. 5 min. No more no less. Let's start! VERSIONS USED : Google App Engine 1.3.0 Python 2.5 Linux STEP 1 : Installing Google App engine SDK for Python You develop and upload Python applications for Google App Engine using the App Engine Python software development kit (SDK). It contains everything you need to start, run and test your google app on your local machine. By failing fast on your local machine, you avoid surprises on Google app engine. First, download the Google App engine SDK for Python here On your project directory "mysite", execute the following command: ln -s /path/to/google_appengine .google_appengine (in case : chmod u+x -R /path/to/google_appengine/*.py ) STEP2 : Starting with the Hello World app Go to .google_appengine and you'll find simplistic demos. Hum.. let's take the "Hello world" sample app. Copy the directory helloworld and paste its content inside mysite directory. STEP3 : Testing the Hello World app Launch you app : path/to/google_appengine/dev_appserver.py path/to/mysite/ Do you see the Hello world message ? Next time we'll run Django 1.0.2 on Google app engine.

Erlang/OTP must be in your toolbox

I would like to convince you that there's no one-size-fits-all language. Building a concurrent application for thousands users should always be designed with grains of salt. Developers are now required to know more than one language because one doesn't fit all your requirements. Many languages emerge (Go, Clojure etc..). Some of them are mature but they are not yet mainstream language like Java (Haskell, Lisp ). They are not newsworthy but they deserve being better known. This diversity of language is a chance. I'd a like to convince you that Erlang is a great language. Let's get down to the nifty-gritty reasons why it is worth considering it. Imperative vs declarative When you build an application, you have 2 options: imperative language and/or functional programming language. I think the right option is when you write the What instead of the How. Using an imperative language enforces you to write expressions that more or less accurately indicate how you manage memory. In an object oriented language, encapsulating the behaviour and state in an object doesn't get rid off race conditions unless it is immutable or its state is shared with synchronization. A common strategy in imperative language is synchronization of threads. However, this often leads to deadlocks because two threads are locking resources that depend on each other. Instead of the What, you spend most of your time writing the How. In a declarative language, you can express complex logic with powerful declarative syntax. Pattern matching is a syntactic sugar that provides an excellent alternative to imperative test/cast paradigm. Passing an anonymous function as a parameter to another function is also a great way to combine logic. Function is the first-class component of a functional programming language. For example, parsing an XML tree with combinators using the high-order function construct makes your code much more concise and elegant. But there is more than constructs that makes your life easier. There is immutability. In functional programming, processes are non-blocking because they don't share memories. Erlang process don't share memories unlike threads. It has a concurrent structure. Building concurrent applications in Erlang is fitted like glove because you have concurrency without synchronization. Erlang vs other declarative languages Erlang without OPT is like Java without J2EE or Ruby without Rails. It would be a great language. However it would lack a robust container. Without OTP and its callback structure, you might have to spawn, register, send or recieve. OTP comes to the rescue. Just focus on the callback that is your business feature in a pure sequential code. OTP framework might, for example, take care of making the application fault tolerant or scalable, whereas the behavorial callback concentrates on the specific aspects of the problem. For you, OTP handles concurrency out of the box. For a month, i've been searching the killer language that I could use to build a scalable, fault-tolerant and fast chat system. At first, I prefered Scala and the Lift web framework. It sounds to me a tough option as Scala relies on a mature JVM and provides a nice concurrency model: actors. When David Pollak, the Lift founder decided to refactor the Scala actor and to develop from its own Lift actor to make Lift more stable I suddenly became skeptical. Is the Scala lightweight actor less stable than Erlang process? Scala is a nice hybrid language relying on long-live process : the Java threads. However, if I wanted to build a reliable chat system, the question is not whether I should use system process or Erlang runtime process but how many of them can I run on my host? How to solve the C10K problem? As the Erlang process are emulated in the Erlang runtime, you get a loose coupling with the OS capacity. The Yaws HTTP server in Erlang performs pretty well against the existing servers (Apache and Nginx). One can have up to 35 000 process as the other one is limited to 5000 sockets in a 32 bit UNIX machine. Furthermore Erlang programs can have linear speed up when they run on multicore computer. There are many real large scale system in Erlang such as RabbitMQ, Ejabberd just to mention a few. Amazon implemented its storage system "SimpleDB" in Erlang; a cluster of Ejabberd nodes daily serves millions of messages for the Facebook chat users. OTP is used in the telecom infrastructure of Ericsson ( see the case study of Motorola too. Some pretty fast-moving startups in the financial world have latched onto Erlang; for example, the Swedish www.kreditor.se. Conclusion Being a declarative language empowered by a battle-tested platform, Erlang is an excellent option to build distributed system and concurrent applications. I didn't digg into the features of OTP (reliability, fault-tolerance, hot code swapping etc..) because an item would not be enough. I didn't cover the drawbacks: crappy record syntax, string being a list. Anyway, the Web requirements for more interactive and scalable system make Erlang an outstanding language. Nowadays a lot of web framework in Erlang are emerging (Nitrogen, Chicago, ErlyWeb, MochiWeb). I'm looking forward to seeing how Erlang will be adopted in the coming years.

Tornado released

Facebook acquired FriendFeed and we all knew all that came with it. The brains and the technology plus the possibility on leveraging a very useful service online. Days ago Facebook announced something I wasn’t expecting it to for quite some time to come; Open sourcing a part of it. The Social Network released Tornado, a real time framework for Python. The framework will be able to handle traffic simultaneously with its support for the many tough tasks associated to Web Development. These include localization, user authentication like Facebook Connect, etc. This would improve the quality of service at a high performance rate. Tornado provides me a way to leverage the long polling technique for my video chat...

Git Hosting

Lately I started up a personal project (the one that will make rich). There is a control system I wanted to explore: Git. A bunch of free git hosting exist on the net but you basically have to open source your codes. So I searched around the net for some private hosting, which allows to hide the codes from public access. It might be helpful for you guys. Here’s the list. 1. http://www.gitcentral.com 2. http://www.projectlocker.com 3. http://gitfarm.appspot.com I chose the gitcentral option. It works like a charm. Here's how to create a repository :

$ cd (project-directory) $ git init $ (add some files) $ git add . $ git commit -m 'Initial commit'

You basically create a new account and project in gitCentral. It's quite straighforward. DOn't forget to add your SSH keys. It must be your public RSA key (usually id_rsa.pub in ~/.ssh/). Wait for a minute In the "Repositories" tab you'll found out the push url of your project.

$git remote add origin git@www.gitcentral.com:2dqhbXXXXXvm2z/mainline.git (the push url) $git push origin master

Then after a commit, I just need to push this way :

$git push

Just play with Git now for free!

I don’t know how I could ever go back to Java

I've been developing scripts in Python to handle replication issues against a cluster of Subversion repositories. It was fun. Python is definitely my favourite scripting language because it's a high-level language and helps writing concise programs. Then I went back to Java. I've been developing in PHP recently. I built an entreprise application on top of Cake PHP stack, a Ruby on Rails like framework quite popular in the PHP community (like its clone: Symphony). Cake provides every feature you need out of the box. I figured out how dynamic language is straightforward when it comes to Web development. "Convention over configuration" + Dynamic language is the right combination to Keep It Simple Stupid. Wait! I could KISS with GWT too. Bruce Johnson, the creator of GWT, managed to compile Java source into javascript. Nice job! Bruce introduced overlay types that are JSNI behind the scene. It is not a new comer for those who developed with JNI a decade ago. There ain't nothing new under the sun right? But deferred binding in GWT is truly a reification of an abstract concept in compilation theory. Deferred Binding is a fully generic mechanism for handling features that vary according to some context ( browser ;) ). This concrete application of deferred binding has made GWT a cross-browser framework and smoothed RIA development. Its hosted mode speeded up my learning curve with a very short edit-compile-test cycle, just like Cake PHP. I went back to Java with GWT. Beyond GWT, there 's something interesting from the HR recruiter perspective. There are millions of legacy code lines written in Java in the world, good ones and bad ones. Entropy makes it harder and harder to maintain production systems and commercial softwares. That's why Java was and will still be in the job market. When a recruiter wants to hire a developer, buzzwords help identifying candidates' development skills. I completely disagree with this simplistic approach however it's the way it is in most organizations. Now, to develop Web applications or to maintain legacy codes, organizations will still hire Java developers instead of polyglot developers who knows HTML and CSS. Why? Because finding a Java programmer in the job market is cheaper, faster and easier. A Java developer can learn easily GWT without having to learn HTML, CSS and Javascript according to a company recruiter. The spring founder Rod Johnson (another Johnson :0 ) said once : "If you think Java developer are monkeys they will be monkeys." in reaction against the EJB. I do think that the real monkeys were those employers or employees who considered Java as a unique way out. Beyond the intrinsic aspect of Java, its predominance in the job market has delayed the adoption of a new language. Inside my company, there is an active community of PHP programmers. Many of them argue that Java is dead while saying : "Well, in PHP we don't have NullPointer Exception" or "PHP is so fast, Java is too slow". Alright. As for me, they don't make the point. Java is fast, almost as fast as C. If you get NullPointer exception or memory leaks it has something to do with Java skills. Whatever the language, there will still be monkeys writing error-prone programs, reinventing the wheel, with preconceived ideas like "Thread-safety ? Who care? I'm using sessionBean" when they don't know Servlet is not thread-safe. So far, I always went back to JVM. What I like in Java is its JVM. It makes Java portable, fast and extensible. I wanted to try out a dynamic language running against the JVM like Groovy. And once I read "Beginning Scala" by David Pollack. I just had the feeling that I didn't know anything about programming when I read his book. I felt the same as James Strachan did when he said : I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy. I will explain in my next posts why "I don’t know how I could ever go back to Java". It's not a break. Just a continuation. Scala is my new JVM partner.

Google's window killer, coming soon

In the second half of 2010, Google plans to launch the Google Chrome OS, an operating system designed from the ground up to run the Chrome web browser. According to the official Google Blog, Chrome OS will be a lightweight, easy to use and secure open source OS platform meant to “power computers ranging from small netbooks to full-zize desktop systems,” with the goal being a practically instant-on system that takes you right into the web. Chrome OS will be running on x86 and ARM chips, which means 32-bit computers, including Intel Atom machines, along with mobile platforms. Anyone exited? Humm wait a minute! What's behind this OS? I remember when Google, months ago, launched its atomic bomb : Native client. Another lightweight, simple, secure open-source OS (I should say OS like runtime) for running x86 native code in web applications. Google was caressing its sweet dream : launching a Window killer. From an OS like runtime running in a browser to a browser running on top of an OS, there was merely one step, wasn't it?

If we read between the lines, we see that the new OS was a mixture of ARM, X86 and 3D technology. I can't be more accurate since no technical details have been unveiled so far. But I bet without taking too much risk that it will lean on these 3 "Web compatible" technologies.