Software Artist

I’m a pure product of the Object-Oriented Programming generation. I’ve experimented several different paradigms when I was in engineering school, including formal programming in B, functional programming in OCaml, logical programming with PROLOG and Eclipse (the programming language, not the IDE). But when I started writing software in high school, it was with TurboPascal and then Delphi. And the main language I’ve been using during my studies was Java.

During all that time, I essentially worked on relatively simple problematics, and my end-of-study project was the first one where I started to look for better ways to handle a more complex environment, namely web applications and web services. The revelation came from AndroMDA, an Open-Source Model-Driven Architecture framework that has been my main specialty and domain of research during the past three years or so. As a professional IT consultant, I’ve used it and promoted it on at least 3 customer projects with rather great success.

But today, I think this time is over. I’ll move on to the next step, my next toy. And if you’ve read my previous entry about the limitations of OOP and its comments, you might guess what it is. I was looking for a better way to tackle today’s software issues and go further in my philosophical goal to make technology useful, and I found it. It’s called Language-Oriented Programming.

If you want to know more about it and wonder why I moved onto this so quickly, here are the articles that hit me as another revelation during the past couple of days:

• Language Oriented Programming, by Sergey Dimitriev
• Language Workbenches, by Martin Fowler
• The bridge between MDA and LOP, by Martin Fowler

Now I think I’ll have a much closer look at the practical side of things:

• Jetbrains take on LOP
• XMF

All of my personal projects, including MobiMap, will certainly benefit from this new enlightenment. And I sincerely hope that my day-to-day job will give me the opportunity to work with those concepts…

We needed a reusable mapping component for TagSpot development, and we wanted it to be Open Source so that everyone can reuse it and improve it for the general interest. There was no such library available on the environment we’re working on so… we made it!

And here comes MobiMap. MobiMap is a library that offers a reusable and customizable mapping component for several mobile platforms. Today, we’re releasing the first release candidate for version 1.0 of the JavaME version. We’re still working on porting this library to Windows Mobile and iPhone environments, and we’ll release the final version of all three libraries at the same time. Until then, we need feedback from mobile developers and we need help to improve the library.

The project website is on http://mobimap.epseelon.org
Out support forum is on http://groups.google.com/group/mobimap
Our issue tracker is here: http://bugs.epseelon.org
MobiMap’s Subversion repository is here: http://svn.epseelon.org/mobimap-javame

Special Thanks go to…

First I would like to thank developers of Pyx4Me and Microemulator, thanks to which we could develop this library on the Mac.

I would like to thank Romain Guy, Richard Bair and the whole SwingLabs Team: MobiMap component is heavily inspired from JXMapViewer Swing component.

Special thanks also go to Antoine Jacquet, aka Royale, whose blog article about tile providers really helped me a lot in understanding all the tile APIs.

And last but not least, thanks to the whole TagSpot team for their help and support.

Finally, if you want to see what MobiMap can do on your phone, you can type the following URL on your phone: http://mobimap.epseelon.org/mobimap.jad. Or if you’re just too lazy to type this URL and you know how to use a QRCode, you can use the one on the right.

Be careful though, as MobiMap will download quite a bit of map data over your mobile connection so…

As far as I can tell, there has been 3 major “revolutions” in software development since it all started:

1. From binary to assembly language
2. From assembly language to procedural languages
3. From procedural languages to Object-Oriented Programming

Of course I’m not even talking about marginal evolutions like functional programming, scripting or formal programming.

And behind a revolution, there’s always a massive “there’s gotta be a better way” feeling. For assembly language people probably thought, “since we’re working with registers and memory addresses and instructions, let’s have readable forms of these concepts rather than just hexadecimal code, obviously we’re going to be more productive”. And then it was probably the same with procedural vs. OOP: Objects, classes, fields and methods were just closer to the kind concepts we were manipulating at some point and we couldn’t just keep tinkering with old paradigms, even on steroids (read structures and things like that).

Now I’m starting to wonder whether we’ve not come to the same point with OOP. At least I have come to this point myself. Objects, packages, components, whatever the granularity I’m still stuck having to tinker with old stuff to realize higher level tasks at some point. Most of the time, I’m not thinking about adding a field or a method in an object, but instead I want to add a property to an entity in my domain, or expose a business operation via a webservice. That’s the kind of tasks that make my day-to-day work. And still, let’s say I want to add a property to an entity in my domain, then I have to add the corresponding field in a class, write a getter and a setter, update the DDL script for the database, add the mapping to the Hibernate mapping file, add a validation directive somewhere… there’s gotta be a better way.

Now I realize that’s the main reason I love AndroMDA so much: because I can do high-level modifications in my UML models and boom! The generator just takes it over from there and updates the code almost everywhere it needs to be, which improves my productivity by a tremendous factor. Others use other tricks for the very same purpose: some use annotations, others turn to active record implementations. But whatever the trick, I feel more and more like it’s a dead-end, like… there’s gotta be a better way.

The closer the tools I’m using are to the concepts I manipulate, the less work I have to do to implement those concepts, the better it is for the whole project:

• it reduces the probability for errors
• it improves time-to-market
• it frees up some time to focus on the real business at hand
• it gives me a better sense of achievement
• it dramatically improves return on investment since basically you’re doing more with less

Tonight I had a very interesting conversation with a very smart guy from the AndroMDA team, and it just appeared to me like magic: AndroMDA is just one way to cope with limitations of the underlying object-oriented paradigms, and we have to start thinking about how we can reach the same goals, but in a more native way. We need a brand new paradigm, a new way to build software closer to what we try to achieve everyday at a higher level.

What do you guys think? Have you heard of anything like that? Because I would be really interested in knowing about it. Otherwise, does anyone have any idea about what could be this new paradigm? And do you feel we need it? I’m really interested in your feedback on that one.

The tutorial I recently published on this blog about Flex, Spring and BlazeDS was really successful and attracted litterally thousands of people to this site where I had only a few tens of visits a day before that. So first of all, I’d like to thank all the people who gave me feedback and allowed me to improve this article, up to the point where I was contacted by James Ward to republish this article on the Adobe Developer Connection (which should finally happen very soon). This leads me to the main point of this new article.

The reason why I wrote this tutorial is because I am working on a personal project where I need to access a Spring backend with a rich web user interface in Flex. So I invested some time and effort in reading and understanding technologies I didn’t know. And obviously I would have had to invest much more energy into it if I hadn’t been helped by Velo and the amazing work he did on flex-mojos. So of course he invested a lot of time and effort in his Maven plugin too. And the chain can probably be very long. Yet this tutorial is free and under Creative Commons license, and I gave Adobe the right to republish it for free. And someone might be working on a product very similar to the one that forced me to investigate about Flex/Spring/BlazeDS, someone who can now reuse my work for free and maybe get the job done faster than me. Am I taking a risk by sharing this information and letting others benefit from my work without getting any money out of it? Some might think that. But for me, the answer is no.

Continue reading »

I love Apple. I confess I’m a pure fanboy, writing this post on a Macbook Pro I’m very proud of, and I really admire what Steve Jobs has managed to do with this company in just more than 10 years since he returned. But yesterday he did another of these annoying things I really hate: he denigrated a competitor. I mean, when you have great products like Apple does, you don’t need to do that sort of things, and if you do, it obviously means that you are afraid of them.

So when Steve Jobs says that “Flash is not suited for the iPhone“, I don’t hear “Flash will never be available on the iPhone” but “Flash will eventually adapt to the iPhone and when this day comes, we’ll have to deal with it.” The truth is that Adobe has been doing huge things with Flash lately, thanks to Flex. And I’m sure Steve is aware of that. And I see absolutely no coincidence in him spreading that kind of FUD on the same day he’s announcing the iPhone SDK.

For months, Apple has been telling us that we didn’t need any SDK for the iPhone, because we could just write standard AJAX web applications, which is nothing more than a transitional form of rich internet application. Now that the SDK is out (and it really amazes me by the way, but that’s another topic), the web application way of doing things looks really poor in comparison, both more complex to use and less integrated than its heavyweight client alternative. But what if Adobe comes up with a Flash runtime for the iPhone supporting Flash 9 and Tamarin? Then we will have Flex applications on the iPhone, in other words easy-to-develop apps, with no need to go through the App Store. And if Adobe does things right and uses the full power of the iPhone APIs, maybe we could have some special capabilities to integrate multi-touch and other advanced features into our rich mobile applications.

Wouldn’t it be great?!

Now the question is, if Adobe comes with such an adapted Flash support, will Apple accept this alternative and pre-install it on all new iPhones?

I really hope so… But what do you think?

When I was in college, we had a very talented physics professor coming directly from Scotland. And as I was in a French engineering school, I was more used to the French way of teaching science, with a lot of theories, demonstrations and proofs. So when I first saw this guy with all his experiments and observations, I thought the man was crazy but in the end, a fact was a fact, and I didn’t really care about why a specific equation applied. I just needed to be convinced it was true… until someone proves us wrong. That’s what science is all about.

Yet, some French scientists tend to be distrustful with the whole empirical stuff, probably because they can’t help thinking that it’s not because you observe something a 999 times that it’s going to repeat itself  a thousandth. So the best alternative we have is to prove it by theory, using mathematics and a lot of tools like theorems, matrices, integrals, etc., even though it’s far more difficult. And once it’s proven with theory, we can more or less take it for granted (provided our reasoning is valid).

Now what if I want to assert something about a piece of software? I can either create an experiment to show that it repeats itself: that’s a unit test! Or we can prove it theoretically using mathematics… Yes, there are formal languages that allow you to prove your programs. They’re very complex to use but hey, reliability has a price!

Fortunately for us, the metaphor stops where the specificity of our case begins, because with software, we have a third option. I won’t say the dirty word right now because I know you’ll run away. Let’s just consider that there are basically three types of testable code:

• code that is very simple to write but you’re testing it because you want to make sure that no one can break it with a wrong copy-paste or something like that
• business code which is a bit more complex, for which you have to write equally complex test code, with the risk of having correct code tested by wrong test
• all the rest, which in my experience is not as much as we think usually.

Based on my experience, I would tend to do the following:

• I write regular unit tests for ALL the rest.
• I don’t test complex business code, I do code review on it.
• For simple code, I shouldn’t even have to write it in the first place. If it’s so simple, then it can certainly be generated automatically by a generator I trust (that’s it! I said it!)

What’s your position really? Set aside the “testing-is-good vs. not-testing-is-bad” dichotomy, what would be your testing strategy? Do you use code generators to avoid testing boilerplate code?

Whenever I talk about Flex and other Adobe stuff with colleagues and geeks I know, sometimes I get the annoyed answer like “Adobe is evil, it’s proprietary code, there’s a governance issue.” Of course the implicit assumption is that Sun Microsystems does it so much better. Well, let me tell you a story about Sun Microsystems’ tremendous governance.

At this time, I’m trying to put together a prototype for a mobile service of mine, using Java Mobile Edition and several of its optional API’s. One of those API’s is core to my application since it is what I use to connect to my backend server: JSR172, aka Web Services API. When I started this prototype, I knew that using optional API’s is risky, because not all cell phones out there support all of them. But it’s a prototype, I just want to make sure it works on my own super-phone (Nokia N95 8GB), and I’ll try to find a solution later for other phones.

So I ordered my very expensive phone and while I was waiting for it, I started working on my J2ME application. I tested it under Sun’s reference implementation Wireless ToolKit and everything worked just great. Then I downloaded the Nokia toolkit and there I had an issue, something cryptic like “(1) Missing end tag for body or envelope”. I thought it had to be an issue related to the beta version of the toolkit, so when I got my phone, I deployed it there and boom: same error. No way to connect to my backend server! Then I started to get nervous. I left a message on forum.nokia.com, and nobody seems to be able to give me serious options.

So now I’m stuck with an application that works great on Sun’s reference implementation, but nobody uses their implementation on their phones. It could be that Nokia did a bad job reimplementing the specification. But if Sun had done things right, there would be a comprehensive compatibility test that would enforce all the implementations to work the same. Or at least, there would be the option to replace the phone implementation with theirs. But wait, outside of the WTK, the WSA page has not been updated since June 2005! Come on!

No wonder why Google Android and Nokia Qtopia are working on alternatives…

In my humble opinion, Adobe has done a great job in encouraging developers to consider AIR as a desktop application development platform. Applications are sexy, you can leverage your HTML/Ajax/CSS skills, and now with Flex Builder 3 and AIR Introspector in the pipeline, we have everything we need… well, ALMOST everything we need.

But of course, having everything that we need to build AIR applications is not enough, because we’re not the only people involved. We have other actors to convince, mainly our bosses and our users. Our bosses because when you’re building a product for a company, adding new technologies like Flex, ActionScript and AIR, has consequences in terms of maintainability, in terms of the number of resources you can find on the job market, in terms of the budget that has to be assigned to training. For that of course, the reference argument is very efficient, and Adobe has done a great job on that too. When you can tell your boss that NASDAQ, eBay, Google and many other big companies they’re admiring are using such technologies, it helps a lot in convincing them.

But I think that there is one target that is still to be addressed: users. Of course, when the application you’re building is targetted at corporate users within the company, once your manager is convinced, it’s almost done. It’s just a matter of adding the AIR runtime to the next company-wide software update. But what if your users are normal people who don’t care about installing a runtime, who are even afraid of installing new stuff when it’s not smileys or search bar addons?  When you build a product for those people, natural penetration rate is vital. And from the last figures we got, “only” half-a-million people have already installed the beta AIR runtime. And something needs to be done to encourage people to install the final version, to improve this penetration rate.

I asked the question to James Ward and Serge Jespers, and their answer was basically “it’s free, we’re talking with Sony and for the rest, if you want it in Windows or MacOSX, mail Bill or Steve and ask them”. And that’s an annoying answer. Because I can’t believe that those companies don’t talk to each other, especially Apple and Adobe. But it looks like when they do, they’re ashamed of it, because they are competitors. It’s like partnerships and synergies are a shame.

Well, let’s hope that all those shiny applications will encourage people to get the runtime and it can be even more interesting to develop new shiny applications, and so goes the virtuous circle.

What do you think? What could be done to spread the AIR runtime?

PS: If you’re like me and you really want to have EVERYTHING to build Flex and AIR applications, you can’t vote for the JIRA issue because it’s been deferred. But James told us that you can file a new issue referencing this one and they will add a vote to it. And who knows? Maybe they will get it done before Flex 4 ;o)

That’s official: SpringSource has just acquired Covalent. Or as I explained it to one of my colleagues, “the company behind our IoC framework has bought the one behind our application server”.

My first reaction was satisfaction, because it’s another step forward in the direction of corporate Open Source adoption. It’s always amazed me to see how big companies can be afraid of Open Source. And the fact that there is now one bigger support service offer behind two of the most popular Open Source technologies in the enterprise will certainly reassure some skepticals.

The second “kiss cool effect” was undoubtedly about something I’ve really been playing with lately, since Javapolis: OSGi. The fact that componentization-related JSR’s are so fragmented and so alpha, plus the recent works of Spring Dynamic Modules for OSGi, added to Peter Kriens’ presentation at Javapolis, all of that really got my attention. And now I’m dreaming of building a collaboration platform using Flex for the front-end and OSGi, Spring and Hibernate JPA for the back-end. The only component that’s missing in my big picture is a deployment target platform, i.e. an OSGi application server. Of course, JOnAS is working on that but there’s no documentation on their 5.0 server whatsoever. And I’ve heard Websphere and Weblogic are using OSGi too, but hey, I’m talking about Open Source here! Now have a look at the documentation of both Tomcat and Spring. They’re probably amongst the best Open Source documentations on the planet. Now imagine that quality of documentation for a brand new Tomcat 7 server using OSGi as a core deployment mechanism, and integrating Spring DM libraries to ease the development of web application bundles.

Yummy!