After 6 years doing Flex, am I moving to HTML5?

Short answer: no. But I’m investing in HTML5.
(really) Long answer: see below.

After coming back from the Flex Summit, many people have contacted me asking what was going to happen with Flex and if I was going to “migrate” our projects (like http://airgile.com ) and services to HTML5. After plenty of exchanged emails and dozens of long talks, I decided to write down and share some notes of my first steps in the HTML5 world regarding the development of Enterprise RIAs (or not). These notes are not organized, they have typos, and, as I said above – they are only my first steps so more experienced people might (and will) prove me wrong in some topics.

Background

I founded Webfuel in 2004 and since then we’ve specialized in building long-term (> 6 months) enterprise-grade RIAs that had to scale well and be prepared for constantly changing requirements with a low cost in maintainability, while simultaneously providing a top-notch user experience. We’ve managed to offer our services comfortably with a very limited number of resources and small development teams (3-5 persons per project), much thanks to the way we leveraged existing knowledge on Software Engineering and applied it to our platform of choice – Adobe Flex (now fortunately called Apache Flex).
Our decision was purely technical and we have never regretted our choice, until it got badly affected by the bad PR around the Flash platform.

Worse PR ever in November 2011

The Flash platform was already in bad shape, much thanks to one year of chaotic PR and there were already some inconsistent signs from Adobe. While disappointed, I was not very surprised when all hell broke loose in November 2011 with Adobe destroying the very last credibility that Flash still had, directly affecting Flex, our businesses and careers. Long story short, Adobe wasn’t able to monetize the Flash Platform and the top managers who don’t really care or understand its power simply decided to put the money where their mouth was: HTML5. I happen to strongly agree with the move on investing in HTML5, but they could and should have done it without destroying (the perception of) Flash. Especially because in the meanwhile it had turned into the platform of choice for Enterprise Development.

In December ’11 Adobe has donated Flex to Apache. While this might end up in being the best thing that could happen to Flex, the initial reaction from the Enterprise was that Adobe was getting rid of Flex. Like someone said during the Flex Summit – “it seems to me that Adobe has built the best platform for enterprise-grade application by accident”. Adobe understands design; creativity; marketing; publishing; Adobe doesn’t seem to understand Enterprise. Example #1: Zero Support = the biggest complaint about Adobe I heard for years on the Enterprise. Example #2: the pricing of LCDS.

Did Adobe kill Flex? No! A technology doesn’t have a heart attack and drops dead on the floor. Flex is still alive and the reasons why we chose it are still perfectly valid. Flex didn’t get worse suddenly – it’s still the same robust platform for enterprise RIA development.
What Adobe destroyed was perception of the Flash Platform. And the perception is what matters on business. You can have the best product of the world, but if people believe it’s bad they won’t buy it (and they’ll even be happy on telling everyone how much your product – that they never used – sucks). But if they think it’s good – even if it actually sucks – they’ll probably buy it (and complain later). Perception. That’s what sells. Perception.

Will the perception around Apache Flex ( http://incubator.apache.org/flex/ ) improve? Most likely, yes. In 9 days, there were more than 1.4 thousand emails exchanged on the Flex Mailing List ( http://incubator.apache.org/flex/mailing-lists.html ) ! It’s pretty impressive the number of people that are now involved in pushing Flex forward and this number will most likely keep rising. But Apache Flex still relies (or, at least for now) on the Flash Platform and I’m not seeing the bad perception on the Flash Player changing in a near future. Of course there’s still AIR, but what concerns me are browser applications.

We are desktop-developers-working-on-the-web

An important side note, is that I see Webfuel as a team of desktop developers working on the web. In other words, we use desktop development paradigms, best-practices and design patterns borrowed from the JAVA world and we’ve applied them to build applications that happen to run inside the browser. Our work consists normally in building at least two loosely coupled applications, connected by an RPC API: a client application (running inside the web-browser) and a server application that only exposes services and is not aware of the client application.

Most Flex developers out there think on themselves as web-developers, but in most cases the mindset of a Flex developer is closer to a desktop developer than to a web developer. IMHO, this is the most single-most-important reason on why we, Flex developers, dislike so much the “normal” web development approaches.
We work with “views”, web developers work with “documents”. We do old-school MVC, DI, loosely coupled approaches, dependency management, RPC, code coverage, continuous integration [...], and when we’re forced to do web-development these are the first concepts that we try to investigate and replicate… before we get frustrated and enter in “denial”.
To be good at typical web-development, we have to change our mindset.

Is “HTML5″ ready?

According to Twitter, online magazines, blogs, Apple, Microsoft and even Adobe, HTML5 is the silver-bullet for everything. It can be used to build websites, webapps, games, software, mobile applications, doing laundry and cooking. The focus is all on HTML5 right now. Is it the right moment to use it?

From the point of view of a web-developer – of course it is!!! For a typical web-developer, HTML5 means more tools, more power and much better cross-browser compatibility than what they had before. If you’re working on the web, HTML5 and the storm of JS frameworks is simply the best thing that has happened to the web since…. humm… Flash. ) Bottom line, HTML5 is for sure a giant step forward.

From the point of view of desktop-developer-working-on-the-web – hell no! WTF? We work on the enterprise and enterprise means stability. We can’t afford to have too many moving pieces all the time. We can’t afford to deal with un-structured languages. If you’ve used Flash or Flex for the last 5 years, you’ll feel that in HTML5 there’s nothing new or better than what you already have. Worse, you’ll feel that there still are hundreds of needed capabilities and tools missing. Exception to the rule, happens if you’re targeting the browser of Mobile devices, where HTML5 is king.
It’s quite understandable that a Flex developer feels frustrated. You feel you’re going backwards 4 or 5 years. It happens that, as Ted Patrick stated ( http://tedpatrick.com/2011/11/12/living-in-the-future/ ) , we were living in the future…

Ignore the shit storm. Ignore fanboys. Choose the right tools. Ask the right questions to the right developers

People like to take sides. If I like and use something, for sure it’s because it’s the best thing ever, and all the rest sucks or is dead. That’s how it works for most fanboys.
Newsflash: if 10.000 persons say that something sucks, it doesn’t really mean that it really sucks. It means that they believe it sucks. Like believing in a religion. The irony is that developers should be pragmatic people, but we often see them becoming fanatic about their technology choices. “Infidel, infidel”, they yell with their pitchforks in the air when you say the name of a “competitor” technology. WTF?

For me, technologies are just tools. Obviously I would like to have as many good tools as possible so I can be able to choose the right one for each task. Be it Flex, HTML5, Javascript, Actionscript, JAVA, PHP, whatever.

Bottom line: ignore the shit storm and the bad PR. Ignore fanboys. Choose your tools based on logic. You wouldn’t choose a hammer to cut wood, would you?

Last year, when I started digging seriously into Javascript, I had many questions. I took for granted that someone who defends a technology with so much conviction, probably understands it pretty well. So I placed several questions to these guys expecting to learn new stuff and understand their best practices. It happens that I haven’t learnt shit. It was like if me and they were from different planets, speaking different languages. Even similar words have different meanings (their MVC is not our MVC. their dependency management is not our dependency management… etc).

I’ve sent a couple of emails to mailing lists of HTML5 and JS development asking people what they were using for MVC, IoC, Unit Testing, Code Coverage, Compiling, Continuous Integration, etc, etc. The answers were like “WTF dude, IoC? What are you talking about?”. I now know that I was doing the wrong questions, as you’ll see below.

Since I couldn’t get (or understand) answers from the gurus of the JS world, I started trying to find people who were doing both large-scale Actionscript and Javascript. They would understand me. ) It happens that there aren’t many and most of them were more or less at the same point I was. The best single advice I got was: “accept web dev for what it is and don’t try to change it. Don’t do RIAs. Do simple web development. Then improve.”. Good advice!.

Redefining our focus

As I said above, technology-wise, Flex is still perfectly valid. But it’s perception is at its lowest level and clients are quite confused and started asking us to use HTML5 to build the same type of solutions we were building with Flex.

So we had to rethink our business, and considering our desktop-developers-working-on-the-web mindset, we’ve decided to:

1- return to our roots: desktop development. That’s what we’re good at and we can still keep using Flex to build AIR applications, either for the desktop or mobile. Since we can embed the AIR runtime, those applications will be future-proof to any other crazy-game-changing decisions made by Adobe.
2- increas our investment in developing (simple) HTML(5) webapps, while accepting the web for what it is: broken. In another words, we have to be humble about what we can provide on the web. It’s too hard and expensive to build the same type of applications we were building, so we’re starting with just simple webapps.

We won’t be accepting huge enterprise-grade projects if they’re meant to be built in HTML(5). This is actually the hardest problem to manage. There are expectations from clients. They’ve gotten used to our beautiful RIA applications, with almost no waiting times, with beautiful and pixel-perfect interactive user interfaces. And now they want the same, but in HTML5, because Flash is “dead” and HTML5 will also run on their Mobile devices (all of them), faster and without consuming battery. At least, it’s what they heard…. The solution for this problem is to say “No, we are not ready to develop it in HTML5″. We’ll be restricting our development to simpler web-apps, until we feel that we (and the web) are ready.

First steps in JS and HTML5

During 2011, I’ve read A LOT about JS frameworks, libraries, approaches, etc. Sometimes, after finishing reading something, it was already outdated and a better library was available.

My first impression was that most docs were “meh”: in most cases you have an excellent “Getting Started” guide, but as soon you start getting your hands dirty in more complicated scenarios, things start falling apart and you’ll see no or outdated advanced documentation.

Another trend that I hated in my readings was the lack of objectivity: instead of the typical docs saying “this framework does A,B,C,D” , I saw a lot of “THIS IS THA MOTHA-FUCKA FRAMEWORK THAT WILL SAVE UR LIFE!”, “MEGA-HYPA-SHIZZLA-FRAMEWORK”. Feels awkward.

I’ve also seen several frameworks being dropped in favor of others, which was actually what scared me the most. I felt insecure choosing the “right” libs and frameworks, so most choices I did at start were the safe ones, as you’ll see below.

Another irony was that most of the JS frameworks exist to overcome the limitations of the web development (normally, the crossbrowser issues). Coming from an environment where a framework tries to abstract application concepts, it felt weird to me to use frameworks to abstract technical limitations. Today, I’ve learnt to enjoy and welcome these frameworks. Accept them for what they are, because the technical limitations actually exist and without those frameworks you’re screwed.

Knockout.js

Despite having read about Backbone, Spine and other complicated frameworks, I’ve decided to start small and simple with Knockout.JS . I just wanted simple data-binding to start with, so I could get some separation between the data model and the view. Later, when we were more experienced, I would re-evaluate the choice of the framework and choose between Backbone, Spine, or another.

My choice has proven to be worthy since Knockout is actually quite simple – but far more complicated and intrusive than the ultra-easy and powerful binding we’re used to in Flex.

The documentation of Knockout is quite good, with plenty of tutorials available. On Google you won’t find as many resources on Knockout as you would like, but fortunately the website covers most of the important topics. The mailing list is pretty good, despite not being as active as the MLs I’m used to in the Flex world with dozens or hundreds of experts. Anyway, in the Knockout ML, there were always one or two people kind enough to point you in the right direction, which is great.

jQuery

I had already a good impression on jQuery, but even still it turned up to be even better than what I expected. jQuery not only hides a lot of the crossbrowser issues – not all -, but also boosts up a lot your productivity with dozens of shortcut functions to most of the stuff people normally need to do on the web. Use it (can you live without it?).

SaaS

Managing CSS can easily turn into a pain especially if you need to do many changes to an existing stylesheet with hundreds of CSS declarations. When Googling for best practices, I met SaaS. SaaS is actually pretty simple: it lets you define CSS stylesheets with declaration hierarchy, variables and mathematic expressions, saving them on a scss file. Then you start a command line task that listens to changes to your scss file and converts it to a CSS file on the fly.

I haven’t looked at Less, so I don’t really know which one is better.

Lab.JS

I also discovered (the hard way) the pain that it can be to manage dependencies in Javascript. I was used to having all class definitions packaged for me in a single SWF and the Flash VM would take care of embedding and managing dependencies for me (pretty most like all bytecode VMs do). In the Javascript world, there’s nothing taking care of this for you. You start by setting in the HTML file the location of the scripts needed, but then you cannot control the order they are loaded and run. So you can be calling a function myFunction() in fileB.js that was defined in fileA.js that was not loaded yet – resulting in errors.

I’ve chosen Lab.JS to solve the issue of loading dependencies on the right order. I’m also making sure that any initialization code only runs AFTER all the needed files are loaded.

I’ve found a problem with Lab.JS: if your code throws exceptions, they will be swallowed by the library and nothing happens. My workaround (read: ugly hack) was to do a ” setTimeout(initialize, 1); ” after the scripts are loaded. This way exceptions are now caught by the browser, as you would expect.

IDEs

This was one of the biggest disappointments in the beginning. The biggest problem of JS is that due to its dynamic nature it’s hard to be tooled around. For building large scale complex systems, especially in a team environment, I needed good refactoring capabilities. It happens that refactoring doesn’t exist in the IDEs I tried.
Ok, there is something called “rename” in WebStorm but it works for very simple cases and I’ve seen it resulting in unexpected results (so I always use the “preview”).

Flash Builder is a complete beast (in a good sense). I’ve seen many people ranting on Flash Builder and even I had some disappointments a couple of years ago. But after FB 4 it just got awesome, with its serious refactoring capabilities, find usages, metadata completion, autocomplete, inline docs, content assist, etc. Most of the best tricks from the JAVA world are available on FB. If you expect to find those in JS editors, I have bad news for you.

I’ve started with Aptana. It’s free. It’s based on Eclipse, so I felt at home at least with the shortcuts and the structure of the IDE, but with a black editor (wtf? is this the “fashion-color” for supa-dupa-web-developers?). Anyway, after two months I got tired of it. I couldn’t do refactoring. I couldn’t jump properly to a function definition with CTRL+click (and this was REALLY annoying). It didn’t have decent auto-complete. I’ve tried making the debugging work but it only worked properly 15% of the time.

Then I’ve decided to give PHPStorm a try – which is the same as WebStorm, but also supports PHP. At first, I was scared: I couldn’t find half of the stuff I needed. After one day, I was pretty comfortable with it and now I feel it’s actually pretty well built. Ok, it’s NOT Eclipse, but even still it’s quite powerful. What those guys did was to implement really well the things you use most while developing and packaged all of them in a clean and objective interface. Kudos to JetBrains ( http://www.jetbrains.com/ )!
In PHPStorm, refactoring “sorta” works in simple scenarios. If you complicate too much (like when you try to mimic packaging for your objects), it won’t work. Click and jump to a function definition works. Debugging… works!! Autocomplete works a lot better than I expected. Actually, it works quite well. The catch: comparing to Aptana, it’s not free.
Coming from Flash Builder, will you be happy with PHPStorm? No. But currently it seems to me that it is probably the best IDE for Web development.

Debugging

I feel ashamed to say that I couldn’t debug properly during the first two to three weeks. Every tool I tried didn’t work as expected. It happens I was using the wrong tools, browsers and approaches.
I ended up using the debugging capabilities of both Firebug (in Firefox!) and PHPStorm. Firebug is also pretty helpful to inspect the DOM of the document, something you’ll be doing every 5 minutes. Both Firebug and PHPStorm allow you to place a breakpoint in JS code and then run your code step by step, as expected. PHPStorm looks more comfortable to me, also because it’s where I’m writing my code.
Bottom line: If your debugging is not working, don’t blame JS: you’re simply using the wrong tools.

Javascript

This was probably my biggest pain point. I’ll start with the conclusions: accept Javascript for what it is and don’t try to mimic your common OOP techniques and classes. There.are.no.real.classes.in.javascript.
Of course, you can try to mimic them – I’ve read half of a book teaching how to do that. But I’ve come to the conclusion that the complexity that you’re adding to get you closer to your comfort zone ends up not being comfortable at all…
You have objects in Javascript. Some might argue that they’re not “real objects”, but wtf, they are what they are and bitching around all the time won’t turn them into real objects. They are objects. It’s the definition of “real” that is subjective )

The problems with JS:

- Silent errors. They happen. Get ready for them.
- Hard coupling everywhere. It’s pretty hard to do loosely coupled architectures. It’s quite easy to end up with a web of dependencies between different objects. I’ve read there are techniques to avoid hard-coupling, but I haven’t had time to dig up more, so this might be my fault.
- Ugliness. I’m used to a HUGE-ULTRA-CLEAN separation between classes, libraries, modules, components and applications. In the webdev world, get ready to see PHP spitting HTML with JS that spits more HTML… Or function a() that creates another function in object b, that knows about object c and changes how c behaves. Things like that. In many known js libraries.
- It’s not built for team work. At Webfuel we normally don’t need to talk much with each other about development. Half a dozen guys can be working together for half a year on the same project, committing code every 5 minutes to the same SVN, without breaking the code of others. This was quite easy to achieve much thanks to the structured nature of Actionscript, on top of some very simple practices borrowed from the JAVA world. Enter Javascript and you’ll see your code breaking the code of someone else. While developing JS in a team, it’s normal that developers need to talk a lot about what each one is doing, warning the other to be careful about X or Y, or asking the other “where did you put the code for…”. Actionscript makes teamwork a joy almost since moment zero – there’s no rocket science for a healthy teamwork environment. In Javascript, the trick is to put people working in very different unrelated parts of the projects and use techniques to encapsulate their code – I have yet to learn them, but I will soon. I’ve asked some JS developers about this but the ones I know are all lone-wolves so they didn’t understand what I was talking about (apart from the reaction “SVN?? WTF?? Use GIT!”.. hum… that wasn’t my question…)
- Unpredictable. In AS3, the “this” refers to the instance where the method is defined. In JS, “this” can mean pretty much anything (remember AS2?). This was one of my biggest pain-points at first. Another problem is guessing by looking at the code the properties and functions of an Object. You can’t. A function in an object can be defined pretty most anywhere. It’s up to you (and your team; and your partners; and your library-providers) to make sure that you keep your house clean with everything organized in the right place.
- Code practices. These are completely different from everything you know. I taught everyone here at Webfuel to not be afraid of writing many lines of code. I want them to write self-explanatory code, like if they were writing English. Enter Javascript. And cry. By some weird reason, people like to write as much code as possible in a single line, making it not only very hard to read, but also very hard to maintain. I’ve got used to seeing the #(‘huge’).line({of: code, that: function() { looks() }).like(‘a’).train(); . And this practice is everywhere, pretty most all examples, libraries and worse: in books! One of the books I read had one line that took me around 5 minutes to understand! The fun part is that I had the book with me in San Francisco on the Flex Summit and I showed that line of code to several people just to scare the shit out of them. It worked!

Bottom line: if you’re a OOP purist, with many years of experience on software engineering on Flex and/or JAVA, you’re going to be scared. The mindset is different. The problems are different. The solutions are different. Even the slang is different. The good part: no compiling times. Which is actually a very good part…

There’s so many people betting in JS, shouldn’t it be good?

This is actually the question that confuses me the most. I simply don’t have an answer… Some people seem to be able to pretty much do anything they need. But at the same time the language certainly has its fundamental problems that can scare the shit out of you if you’re doing a one-year-project.
One thing is for sure: it’s being pushed forward and you can’t deny that.

CoffeeScript

I haven’t tried yet CoffeeScript. After reading a bit about CoffeeScript, I’ve learnt that you still need to be comfortable with Javascript to use CoffeeScript properly. And that’s what I’m doing. On the next project I might give CS (or other language that cross-compiles) a try.

Layouting and the DOM

This was actually my biggest disappointment. Flex (>4) is amazingly simple and powerful concerning pixel perfect skinning and layouting. You have pretty much no constraints in Flex regarding layouting, giving you immense freedom in creating perfectionist user-experiences. You don’t think “how am I going to implement this?” because there’s not much to know about Spark skinning: it’s really powerful and simple.
The HTML world is different. You have to be aware of the constraints before creating the design and setting the user experience. I wasn’t aware of these constraints so we had to change the designs of the product we’re building a couple of times on the middle of the project to turn them into something possible/easier to achieve in HTML. I really hate constraints that end up affecting the user experience.

You have also to be prepared to accept small (and big) cross-browser rendering differences. They will happen. A lot. But that’s another topic…

Optimizations/Preloading content

Coming from the Flash world I was used to have to build one single application (the SWF) that has all (static) assets embedded. This results in pretty small files (yes, a SWF is smaller than it’s HTML+JS+CSS+Assets equivalent, even after minimization and gzip, and etc), only one request to the server (which results in a very low load on the server), and the assumption that all the content you need is available at runtime since moment 0. If you want to achieve a similar result in JS, you have to do it by hand – there’s nothing taking care of that for you. You have to join and minify Javascript and CSS files and resort to image sprites to reduce the number of requests to the server and the user perceived speed.

An image sprite is simply one PNG file with all the images and icons you use in your webapp. Then you simply apply that image as the background image of your UI component, using CSS to set a translation so it shows the icon/image you need. It’s quite simple, but make sure you load this image before your content appears on screen. The same applies to other content, in case you don’t want the user to see “glitches” on the layout while things load.

During loading I am hiding most divs (display: none) in the DOM, showing a preloader and after all content is ready (JS files through Lab.JS, Image Sprite, etc), I’m using jQuery to show stuff. It’s quite simple, actually, but of course, Flex did take care of all that for you… BTW, I saw this today, but I haven’t tried it yet: https://github.com/thinkpixellab/PxLoader

I’ve started today looking for a Javascript minifier. I need something that can automatically watch a folder with several JS files and merge them in a single minified file. If possible, assigning a revision number to the generated file. I haven’t yet found anything, but I’ll update this post if I have positive results.

HTML(5), JS and Mobile

If you think you’re going to build something in HTML(5)+JS that will work seamlessly and without problems in desktop AND mobile browsers, think again. Document based websites usually work without problems on both types of environments. But if you’re doing a more or less advanced user experience that relies in some CSS and JS magic, then be prepared to be disappointed when you open your content in your Mobile device. Not that the mobile browsers are bad – they’re actually pretty good. The problem is that the Mobile experience needs to be thought from the start – people will be using their huge clumsy fingers to interact, the screen will be smaller and the hardware resources are more limited. So at the end, you have to implement at least two different user experiences and switch between them according to the device capabilities using Media Queries. I haven’t yet tried Media Queries, so there’s not much I can say about this. I just mentioned this topic because I’ve seen several people migrating their Flash applications to HTML expecting them to work right away on iOS – without thinking that it’s probably cheaper to keep the Flash version on the desktop and building a dedicated version for iOS.

UI Components

DateChooser, NumericStepper, TextInput, DropDownList, RadioButton, Panels, Accordions, HGroup, Charts, Lists with Renderers, DataGrid, etc, etc, etc, almost all types of components you can imagine are available in Flex. And they are extendable and completely skinnable. You have great control in your hands. In the HTML world, either you go with the limited browser components – that are not extendable and are hard to skin but they integrate with the browser and the device -, or you have to choose a component library like jQuery UI, ExtJS or zkoss, among other – that are more or less powerful, but don’t integrate with the browser or device.

After exploring dozens of options, all of them with their cons and cons, I felt unsecure on choosing one option, spending time and money learning it and teaching it to my team, to later conclude that I might have chosen the wrong one. So I’ve decided NOT to try any component library – apart from the limited jQuery UI -, simply because there are too many things changing right now and it’s very hard to predict which libraries will succeed and which ones will not. I’m going to be lazy (also because I can’t study thousands of stuff at the same time) and wait to see what other Flex developers will choose. In the meantime, as I said above I won’t be using HTML(5) to build RIAs, but only simple webapps. And for that, jQuery UI is up to the task (with some quirks here and there).

Crossbrowser issues

Heck, this is my biggest nightmare. I tremble everytime someone says the world “web browser”. Ok, I’m exaggerating a bit. Crossbrowser issues exist, they are a PITA and they will consume at least 30% of your time in a project. But to be honest, at first I was expecting it would be a lot worse. Don’t take me wrong here, crossbrowser issues are a nightmare. Simply, they’re not as scary as I thought. If you follow me on twitter ( https://twitter.com/#!/joaosaleiro ) you’ve probably seen me cursing some web-browsers (hint: has two letters, starts with an I, ends with an E). Get ready to having to test something in several browsers and to change plans in the middle of the project because your approach doesn’t work as expected in one or two major browsers – especially if you’re building edge-cases and using HTML5 stuff.

You can’t miss this article: http://www.joelonsoftware.com/items/2008/03/17.html

We had one crossbrowser issue this week that almost killed our current project. We needed to override the browser URL while the user was navigating the application and we couldn’t rely in simple URL hashes. We were hoping that history.pushState was up the task, but it happens that it is not. Erratic behavior in Safari, doesn’t work in IE, worked in Android until 2.3.3 and stopped working in 3.0 and 4.0 (WTF?)… Fortunately, I’ve found History.js which was built exactly to fix our problem and reduce (not fix) the cross-browser issues. See, the good thing is that crossbrowser issues happen to everyone, so you’ll likely find a workaround on the web.

If you’re doing HTML5 you probably know about http://caniuse.com/ . If you don’t, go there.

Productivity

Our productivity is pretty bad right now – but we are getting better! We’ve spent 11 weeks of two resources to build something in HTML(5)+JS that we would have built in 3 weeks with the same resources in Flex, without any stress at all. Of course, I take a big part of the guilt here: we’re still learning and during the first weeks there were a lot of readings, plan changes, tests and bumps on the road.
The real issue is how tight the relation between productivity and your experience with the tech is: the bumps on the road are there, they happen to everyone and you won’t be able to predict them, so the only solution is be experienced and be aware of those issues. They will simply happen, you’ll curse them, search the internet for hours, fix/hack them and the next time you’ll meet them, THEN, you’ll be ready and productive.
You’ll end up implementing workarounds and hacks (on top of other hacks) constantly. Coming from the Flex world, you’ll feel ashamed of your hack – don’t be. It’s normal. Most of the times, you won’t have another choice but to accept the hack and move on.
Coming from a rapid development environment as Flex, productivity in JS and HTML can be quite frustrating until you get used to the bumps on the road. After you’re experienced, it will get better, but I don’t expect it to come any close to Flex development in a near future.

Conclusions

The first conclusion is that we’ll keep using Flex in long-term enterprise RIAs projects. Neither the open-standards nor us are ready to build the same type of experiences that our clients expect us to.

At the same time, we’ll be accepting smaller webapps. At this point, after three months, we’re already pretty comfortable building web experiences, so it’s a matter of raising the bar slowly, webapp after webapp. But I don’t think we’ll be able to do the same type of RIAs we were doing with Flex at least not in the next two years. Also, maintainability and its cost scare the shit out of me. And all the moving parts of HTML5 – new libraries appearing, others disappearing, browsers dropping support of features, etc. There are lots of “ands”.

I know I’ve missed half a dozen topics above and I know I’ll have dozens of other to write about in a couple of months. Actually, there are no real conclusions here – only open subjects. There’s much to be investigated and learned. I’m sure I’m not completely right in some of the above topics and I would love to get your feedback, pointing me in the right directions where I got it wrong. I can only hope that most of the stuff I pointed above won’t look as bad in a couple of months as it looks now. Or that browser vendors shake hands and decide to stop fragmenting the web. Maybe they could all be friends and adopt the same rendering engine and VM (_giggles_). For example, Google Dart. (_yeah, right_…)

Original post: https://plus.google.com/109047477151984864676/posts/CVGJKLMMehs (please try to keep comments on the original post, of possible)

No dia 31 de Dezembro, o Flex foi finalmente aceite pela Apache Foundation e está agora em processo de incubação (um género de “processo de passagem da Adobe para o Apache”).

As Mailing Lists oficiais do Apache Flex foram criadas no dia 3 de Janeiro e entretanto já foram trocados 349 emails (em 2 ou 3 dias!) – o que demonstra o elevado interesse da comunidade, com um nível de participação muito acima do esperado. Os arquivos da mailing list estão disponíveis aqui: http://mail-archives.apache.org/mod_mbox/incubator-flex-dev/

Para se inscreverem na mailing list do Apache Flex podem fazê-lo com as instruções disponíveis em http://incubator.apache.org/flex/mailing-lists.html

As discussões  têm sido extremamente interessantes, mas quem não tiver paciência para ler os 349 emails pode sempre visitar este URL para ver um resumo dos tópicos discutidos: http://blog.teotigraphix.com/2012/01/05/apache-flex-flex-dev-summaries/ .

Uma página temporária para o Apache Flex foi criada aqui: http://incubator.apache.org/flex/ . Ainda não tem muita informação, mas irá evoluir ao longo do tempo.

O SVN do Flex SDK está a ser migrado da Adobe para a Apache, tal como o JIRA. Este é um processo que deverá demorar entre uma a duas semanas (digo/espero eu).

Continua em aberto a minha sugestão de se realizar um evento de Q&A para vos elucidar (ou às vossas empresas/”chefes”) em quaisquer questões que tenham, mas como há a possibilidade da (antiga) Flex Team vir a Portugal, esta sugestão fica on hold durante mais alguns dias.

Entretanto podem enviar questões que tenham relativas ao processo de transição e ao futuro do Flex para a Mailing List do riapt

O gestor de projecto irá usufruir do conforto do Airgile para gerir e acompanhar a evolução dos projectos, delegando tarefas aos consultores e programadores. Estes receberão as tarefas directamente no Eclipse, a sua ferramenta de trabalho de eleição. À medida que completam as tarefas, os consultores podem fechá-las directamente no Eclipse, que irá sincronizar com o Airgile (automaticamente), actualizando os indicadores e notificando o gestor de projecto.

Este é o workflow de gestão que usamos na Webfuel, ligando o Eclipse antigamente ao Trac e actualmente com o Airgile – que é mais rápido e confortável. É relativamente fácil configurar a ligação, estando as instruções disponíveis aqui.

No vídeo abaixo, a partir dos 5:45 é possível ver o conector em acção.

O evento contará com as seguintes sessões:

Aplicações Offline

Descrição: A capacidade de aplicações web poderem ser corridas offline é uma das principais funcionalidades disponíveis na nova especificação HTML5. Esta apresentação foca-se em como fazer uma aplicação offline usando: application cache, local storage e webSQL (agora deprecated). Ao longo da apresentação será construída uma aplicação móvel que pode correr em múltiplos ambientes.

Bio do Orador: Vasco Andrade e Silva é CEO na Byclosure, uma startup portuguesa que trabalha no desenvolvimento de aplicações HTML5 sobre diferentes plataformas e dispositivos. Detém um mestrado em Engenharia Informática e de Computadores pelo Instituto Superior Técnico de Lisboa. Na área de gestão de projectos ageis detém os certificados de Certified Scrum Master e Certified Product Owner. Trabalha de perto com tecnologias web como o GWT e Ruby On Rails e sobre diferentes diferentes dispositivos iPhone, iPad, Android, PC. Para além do acompanhamento de todo o lifecicle da venda, desenvolvimento e manutenção de aplicações web tem especial interesse na automação de testes unitários e de aceitação. Fora do trabalho gosta de jogar Basket e foi treinador de equipas sub-16 e sub-18 em diferentes clubes.

Novas APi’s no HTML5

Descrição: A nova versão do HTML5 introduz um conjunto de novas API’s que até agora estavam apenas disponíveis através de plugins. Nesta sessão será feita uma introdução e veremos demonstrações das API’s WebSockets, File e Media capture conforme a especificação do W3C.

Bio do Orador: Tiago Andrade e Silva é Developer Evangelist na Microsoft. Nos últimos 14 anos tem focado a sua actividade profissional na área do desenvolvimento de soluções Web. Esteve em empresas como Fullsix, Tinta Invisível, Neoris e Oni. Detém um mestrado em Engenharia Informática pela Universidade Nova de Lisboa e tem-se especializado na área de gestão de projectos, com foco nos métodos Ágeis. É Project Management Professional (PMP), Certified Scrum Professional, Certified Scrum Master, Certified Product Owner e foi o fundador da Comunidade Portuguesa de Scrum.

Local do Evento

Edifício Qualidade, C1 – C2
Av. Prof. Doutor Aníbal Cavaco Silva
Tagus Park
2744-010 Porto Salvo

Mais informações sobre o evento podem ser vistas aqui: http://html5pt.org/

As inscrições estão abertas em http://html5pt.eventbrite.com/

A segunda edição da Agile Portugal terá lugar em 20-22 Junho, no Porto, novamente perto do S.João, a maior festa da cidade. O objectivo da conferência mantém-se o mesmo, promover um ambiente de inovação, discussão, e networking com outros agilistas nacionais e internacionais, juntando sob o mesmo tecto liders, praticantes e formadores.

Um evento a não perder! Existe um número limitado de lugares, por isso não é de deixar o registo para os últimos momentos.

O Programa deste ano conta já com um conjunto muito bom de palestrantes de renome internacional, como:

• Allen Wirfs-Brock
• Dave Thomas
• Joseph Yoder
• Mike Beedle
• Mitch Lacey
• Rebecca Wirfs-Brock

No website da conferência é possível encontrar as últimas notícias e actualizações ao programa. Visite o website do evento – http://2011.agilept.org/ - para mais informações.

Aproveito ainda para informar que, numa parceria entre a Webfuel e a Agile Portugal 2011, temos um código promocional de 20€ para o Airgile, uma plataforma de gestão de projectos. O código é válido até dia 23 de Junho de 2011, e para o utilizar basta preencher “agilept2011″ no campo “código promocional” durante o registo no Airgile.

O orador será o Igor Costa, CEO da RIACycle.

“Com 6 anos de experiência com Flex, Igor se tornou conhecido na comunidade Flex por evangelizar o produto para empresas e faculdades espalhadas pelo Brasil. Sendo o primeiro instrutor de Flex no Brasil. Sente-se feliz de ter formado mais de 900 pessoas quando trabalhava na ENG DTP. Já palestrou em vários eventos nacionais como o Just Java, internacionais como o OSFlash Conference, e também cria eventos como o Flex Mania. Traz consigo uma experiência de 11 anos de desenvolvimento de software e compartilha com todos os mesmo sonho que informação precisa ser barata e rápida. Dedica-se a criar, compartilhar e explorar os valores de cada solução RIA para seus alunos.”

No final da palestra será sorteada uma bolsa de estudos no valor integral do curso de Flex Mobile da RIACycle. O curso é transmitido via Internet, assim, caso o vencedor resida na Europa poderá participar no curso.

URL para detalhes sobre o evento: http://flexduck.groups.adobe.com/index.cfm?event=post.display&postid=36363

URL para acesso a palestra: http://experts.adobeconnect.com/flexduck-flexsmartphones/

URL para conhecer a bolsa oferecida: http://riacycle.com/flexmobile/

(Conteúdos fornecidos pelo Stefan Horochovec)

O aumento de produtividade no Flash Builder destaca-se através de várias pequenas mas extremamente úteis funcionalidades para simplificar a vida do programador enquanto escreve código, tais como:

Code templates – o Flash Builder traz cerca de uma centena de code templates, mas estes são configuráveis pelo programadorsendo fácil adicionar novos. Para activar um code template, basta, por exemplo, escrever “fori”, carregar CTRL+Space, e o Flash Builder escreverá automaticamente “for (var i:Number = 0 …. etc”.

Code completion para Metadata – basta escrever [B (Ctrl+Space) e o FB preenche o resto

Live error Highlighting - ao escrever código o Flash Builder agora aponta os erros sem ser necessário compilar. De notar que isto funciona com grande parte dos erros, mas não com todos.

Melhorias no IDE - a performance do IDE foi melhorada, tal como a velocidade de compilação. O design mode agora consegue fazer o rendering de views mais complexas

Quick-assist - na realidade esta não é uma, mas sim dezenas de funcionalidades. O Quick-assist é um atalho (CTRL+1) que quando é chamado abre um menu com várias opções, de acordo com o contexto, como por exemplo:

• Geração de event handlers
• Organização dos imports
• Criação de métodos automática
• Declaração de variáveis
• Promoção de variáveis locais para propriedades da classe
• [... outras ...]

Neste vídeo do Serge, é possível ver algumas destas funcionalidades em acção:

Relativamente ao desenvolvimento para dispositivos móveis, o Flash Builder é agora um ambiente extremamente confortável para desenvolver para smartphones e tablets Android, iOS e BlackBerry (Playbook).

A versão que foi disponibilizada ainda só exporta aplicações para Android, mas muito em breve será lançado um update que permite exportar a mesma aplicação com o mesmo código para iOS.

O Flex SDK possui agora um conjunto de componentes “light” especialmente optimizados para telemóveis e ainda uma framework que simplifica o desenvolvimento  ao gerir pelo programador a navegação entre as views, a “cache” dos dados em cada view, etc. No desenvolvimento para Mobile é importante ter em conta as diferentes resoluções e densidades de cada smartphone – o Flash Builder possui ferramentas para gerir confortavelmente o desenvolvimento para diferentes ecrãs (multi-screen development).

Neste vídeo do Serge podemos ver mais sobre o desenvolvimento para Mobile:

Este é também um vídeo interessante que mostra os Charting components a correr no iPad, iPhone, Android e BlackBerry Playbook:

Para quem pretende explorar mais o desenvolvimento para Mobile usando Adobe Air, deixo aqui este recurso (embora não seja completamente orientado ao Flex):

Esta é, na minha opinião, a melhor release do Flash Builder até à data. Ou pelo menos, é a mais sólida e que eleva o desenvolvimento em Flex para outro patamar, muito próximo da experiência de desenvolvimento típica no mundo JAVA.

Eu, o Rui Silva e o João Fernandes acompanhamos esta release desde o início e tivemos a oportunidade de contribuir para a evolução da mesma. Orgulhosamente temos agora dois nomes portugueses nos créditos do Flash Builder, se bem que o João Fernandes também merecia. E não queria deixar de mandar um abraço para o Carlos Rovira ali na vizinha Espanha.

Não se esqueçam que podem sempre utilizar a Mailing List para partilhar as vossas experiências ou colocar questões ao resto da comunidade.

O Airgile sincroniza automaticamente as alterações às tarefas entre todos os elementos da equipa automaticamente, o que permite que as equipas trabalhem a todo o gás e que os gestores de projecto acompanhem as evoluções ao projecto em tempo real através de um dashboard intuitivo. Pesquisas e filtragens a milhares de tarefas demoram menos de meio segundo, tal como adicionar ou editar tarefas – através do Quick-Add e Quick-edit.

Feito a pensar em equipas espalhadas em redor do mundo, suporta multi-linguagem (por agora em Português e Inglês) e lida automaticamente com o fuso horário. Isto é,  uma tarefa introduzida a uma determinada hora em Portugal, aparece com a hora correcta para os elementos da equipa localizados no Brasil sem qualquer configuração necessária.

Além da informação detalhada que é possível colocar numa tarefa – como o tipo, estado, importância, data de início, fim, orçamento, entre outras -, é ainda possível anexar múltiplos ficheiros de uma só vez sem que tenha que esperar que o envio termine para continuar a trabalhar. Isto é, a aplicação não bloqueia em tarefas assíncronas, tudo com o objectivo de aumentar a produtividade! O sistema de preview inline permite visualizar imagens e ficheiros de texto dentro da aplicação, sem ter que os descarregar para o seu computador.

O sistema de comentários associado a cada tarefa reforça a comunicação entre os elementos da equipa – ou mesmo com o cliente -, incentivando a troca de ideias ou pedidos de esclarecimento.

O Airgile encarrega-se de enviar automaticamente emails a todos os utilizadores ligados a um projecto sempre que há alterações  (nova tarefa, tarefa editada, novo comentário, etc), podendo o gestor de conta activar a opção de subscrição por tarefa, permitindo que cada pessoa opte individualmente por receber mails só nas alterações das tarefas que escolher.

O sistema de permissões permite ligar utilizadores a projectos, sendo definido projecto a projecto se determinado utilizador pode somente consultar, inserir tarefas, e deixar comentários; se pode aceder às tarefas confidenciais; ou ainda se terá permissões de gestor de projectos que lhe permitem manipular todas as tarefas.

Como cada projecto e negócio é diferente, o Airgile permite-lhe configurar projecto a projecto os tipos, estados e níveis de importância das tarefas. Isto é, é fácil adaptar os projectos a áreas completamente distintas, como a consultoria em IT, ou a advocacia.

Os pormenores de usabilidade do Airgile são deliciosos, com vista não só a aumentar largamente a produtividade da equipa e assegurar o cumprimento de prazos, como também a permitir a utilização por diferentes pessoas com níveis de conhecimentos informáticos completamente díspares: a sua simplicidade tornam o Airgile na ferramenta de gestão de projectos ideal tanto para utilizadores experientes, como para utilizadores inexperientes.

Estando alojado numa Cloud, a plataforma está acessível a partir de qualquer computador em qualquer local do mundo com ligação à Internet, sendo compatível com todos os sistemas operativos e web-browsers usando o Flash Player 10.2. Não existem incompatibilidades entre web-browsers e sistemas operativos, sendo o desempenho e robustez da aplicação sempre ao mais alto nível.

O Airgile está disponível no modelo Software-as-a-service, isto é, mediante o pagamento de uma mensalidade muito baixa (a começar nos 6€/mês!), mas possui também uma conta gratuíta limitada a um projecto. Ao longo do tempo, o Airgile continuará a crescer com novas funcionalidades sempre com vista a aumentar a produtividade dos utilizadores.

O site do Airgile está disponível em http://airgile.com e possui não só vários vídeos de demonstração, como lhe permite testar uma conta de demonstração com dados fictícios antes de poder criar a sua conta.

A aplicação foi desenvolvida pela Webfuel, sendo completamente nacional. Assenta na Cloud, e corre em qualquer browser, tendo sido implementada em Flex usando o Adobe Flash Builder 4.5.  Planeamos lançar uma versão instalável com suporte a OCC (trabalhar offline) e uma versão para Android e iOS através de Air 2.6.

Experimentem o Airgile, forneçam-nos feedback usando o fórum e ajudem-nos a divulgar este produto de origem nacional!

Comecei recentemente a dar os primeiros passos na aprendizagem de Maven, e apesar de ainda ser um novato achei por bem partilhar as razões pelas quais esta tecnologia é tão interessante.

Apesar de utilizarmos Maven há já algum tempo nos nossos projectos na Webfuel e de conhecer os seus benefícios, nunca tinha investido tempo na sua aprendizagem visto que a configuração dos projectos com Maven estava a cargo de uma empresa nossa parceira (Web-Responsive). Sou, portanto, tenrinho no assunto, mas sinto-me compelido a partilhar as razões pelas quais vale a pena aprender Maven.

Este post não é um tutorial a explicar como se usa, mas sim uma descrição de alguns dos problemas (use cases) que o Maven resolve em projectos complexos. De notar ainda que o Maven não é específico ao desenvolvimento de RIAs, mas sim aplicável ao desenvolvimento em qualquer tecnologia que tenha um plugin para Maven. Para Flex existe o flex-mojos que cobre grande parte dos tópicos referidos neste post, mas não todos (ainda). Diria que no mundo J2EE, aí sim, o Maven se porta brilhantemente – por exemplo, na configuração de um JAVA + Spring + Hibernate + BlazeDS + Springflex + montes.de.outras.libs.

O que é o Maven?

O Maven é uma ferramenta poderosa para gestão de projectos, gestão de dependências, gestão de versões, automatização do processo de build (compilação, unit tests, reporting, etc), configuração de ambientes de desenvolvimento, entre outras. É uma ferramenta com cerca de 3 megas que se utiliza através da linha de comandos (ou através de alguns plugins para Eclipse, como o m2eclipse), para executar diversas tarefas sobre um (ou vários) projecto(s), regra geral associadas à sua compilação, mas sobretudo manutenção. Bem, o ideal é mesmo ver os exemplos mais abaixo…

(Mais prólogo) Esqueçamos o modelo de projectos gigantes…

É importante compreender que existe uma maneira “à-la-Maven” para a estruturação de um projecto. Um “projecto físico” deve ser separado em vários sub-projectos/componentes/bibliotecas (artefactos), com dependências entre eles. A noção de um projecto, com Maven, pode resultar em 10 ou mesmo 100 “projectos Eclipse”.  Por outras palavras, o projecto “my-huge-crm-application” quando criado “à-la-Maven” deve ser dividido em “my-crm-users”, “my-crm-reports”, “my-crm-costumers”, “my-crm-commons”, “my-crm-config”, “my-company-lib”, “my-3rdparty-lib”, etc – podendo-se atingir com facilidade 10 ou 20 projectos diferentes, com dependências uns dos outros (isto é, o my-crm-commons.jar é usado pelo my-crm-costumers, etc).

À primeira vista, pode parecer mais confuso, mas na realidade resulta numa maior simplicidade – graças à elegância do Maven, como veremos adiante.

O Maven lida com uma simplicidade extrema com as dependências entre projectos e com o processo de build – por exemplo, ao compilar um projecto que depende de outro, o Maven irá descarregar o outro projecto de um repositório onde possa estar instalado, ou se não o encontrar, mas tiver “acesso” ao código fonte, compilar o outro projecto -, e graças a esta arquitectura de gestão de dependências, torna-se relativamente fácil acoplar, desacoplar e substituir projectos/módulos/dependências num projecto.

(Ainda mais prólogo) Algumas notas prévias

Caso 1: Configurar um projecto do zero é demorado e aborrecido

O Maven resolve essa tarefa em dois segundos com um único comando, recorrendo a algo conhecido por “archetypes”. Como? Escrevendo:

mvn archetype:generate

O Maven irá fazer algumas perguntas (tipo de projecto, package, etc) e irá então criar uma estrutura de directorias base com alguns ficheiros necessários (ou dummy) tipicamente necessários nesse tipo de projectos, utilizando uma estrutura de pacotes pré-definida, e criará um ficheiro pom.xml de base. A estrutura de directorias usada pelo Maven obedece a uma *convenção*, normalmente muito bem definida, que torna permite que developers que estejam a analisar um projecto  pela primeira vez entendam rapidamente a sua estrutura, e onde encontrar todos os recursos. Além disso, a convenção usada pelo Maven reduz em *muito* a complexidade dos arquivos pom.xml do Maven (especialmente quando comparando ao Ant), pois não é necessário adicionar configurações extra ao pom.xml – O Maven irá “automaticamente” encontrar os recursos necessários nos locais correctos, se as convenções forem seguidas – mas, claro, os developers podem fazer override às convenções, embora não seja recomendável.

Outro dos desconfortos na criação de um projecto a partir do zero, é a configuração do projecto no Eclipse. Descarregar as dependências, adicioná-las à classpath no Eclipse, etc…, e depois fazer isto novamente em cada um dos postos de trabalho de uma equipa. Porém, graças ao maven-eclipse-plugin, basta um comando para gerar estas configurações. Fazendo:

maven eclipse:clean eclipse:eclipse

serão criados automaticamente os ficheiros de configuração do Eclipse (.project, e restantes), de acordo com as dependências e tipo de projecto definidos no pom.xml. A partir daí, basta que em cada posto de trabalho se faça um “Import Eclipse Project” no Eclipse, onde regra geral fica tudo maravilhosamente configurado. Graças ao pom.xml o Maven saberá o suficiente para criar correctamente os ficheiros de configuração do Eclipse. Claro que existem centenas de diferentes tipos de projectos no eclipse com configurações diferentes, e o maven-eclipse-plugin não conhece todas. Mas para JAVA, tem-se portado suficientemente bem para 90% dos meus casos. Os outros 10% são resolvidos facilmente adicionando algumas configurações adicionais no pom.xml.

Em resumo, a utilização de archetypes permite criar a estrutura e configuração de projectos a partir do zero, e o maven-eclipse-plugin permite criar e *actualizar* os ficheiros de configuração do Eclipse, sem ser necessário configurar projecto a projecto cada um dos projectos em cada um dos postos de trabalho à mão (isto, para JAVA, regra geral).

Caso 2: O meu projecto tem 20 dependências, e cada dependência também tem 10 outras dependências… Além de ser confuso, perco imenso tempo à procura das bibliotecas, a descarregá-las e configurá-las

Com o maven, é bastante simples. No pom.xml basta adicionar o seguinte XML para especificar que o projecto tem uma dependência do spring-flex, por exemplo:

         <dependency>
             <groupId> org.springframework.flex </groupId>
             <artifactId> spring-flex-core </artifactId>
             <version> 1.5.0.BUILD-SNAPSHOT </version>
         </dependency>

E aí basta correr:

mvn install

O Maven irá automaticamente encontrar a dependência (chamada de “artifact”) – pesquisando num conjunto de repositórios de dependências -, fazendo o download da mesma e “instalando-a” no seu repositório local. Irá fazer o mesmo para todas as dependências de cada dependência recursivamente, pelo que não temos que perder tempo com isso. E a partir daí, sempre que compilar com Maven, este irá adicionar cada uma das dependências ao classpath do compilador automaticamente.

A integração com o Eclipse também é incrível – ao executar:

mvn eclipse:clean eclipse:eclipse

o maven irá actualizar (na verdade, irá recriar) os ficheiros de configuração do Eclipse e adicionar as dependências correctamente ao classpath do projecto. Por outras palavras, algo que regra geral pode ser um autêntico pesadelo (definir as dezenas de dependências de um projecto, descarregá-las da internet, configurá-las, e por sua vez fazer o mesmo para as dependências de cada dependência…), é resolvido elegantemente em poucos segundos!

Esta simplicidade na gestão das dependências não só facilita a configuração das bibliotecas externas necessárias aos nossos projectos, como fomenta a separação dos nossos projectos em dezenas de módulos e bibliotecas, visto que com Maven se torna relativamente simples organizar todas as relações entre projectos.

Caso 3: Build através da linha de comandos

Com Maven, iremos utilizá-lo inevitavelmente para compilar.  A compilação é feita através de plagins, que invocam os compiladores com as directrizes de compilação apropriadas, de acordo com o pom.xml. Isto é, não definimos os argumentos dos compiladores; definimos sim a configuração do projecto, e o maven trata de definir os argumentos, regra geral automaticamente! Além da compilação, o Maven irá utilizar o resultado desta para executar tarefas adicionais, como a execução de unit-testing, geração de relatórios, envio de emails quando ocorrem erros de compilação, etc.

Algo extremamente elegante no Maven, é a forma como ele compila vários projectos em “simultâneo”, recursivamente de acordo com a ordem das dependências. Algo que iremos ver posteriormente

Caso 4: É difícil gerir diferentes versões dos meus projectos/bibliotecas e das suas dependências

Artefactos (módulos, bibliotecas, etc) possuem sempre um número de versão que lhes é inerente. Isto é, a biblioteca log4j poderá existir na versão 1.1, 1.2, etc. Isto significa que se o nosso projecto precisar do log4j 1.3, basta abrir o pom.xml, localizar a zona onde a dependência é definida (ver o caso 2), e mudar a versão para 1.3. O Maven irá descarregar automaticamente a versão 1.3 e actualizar as definições do projecto. Posteriormente, ao correr mvn eclipse:clean eclipse:eclipse, o Maven vai ainda reconfigurar o Eclipse com a nova versão da dependência. Agora imagine-se que por alguma razão é preciso voltar à versão 1.1 do log4j. Simples. Basta mudar no pom.xml a versão da dependência para 1.1, e o Maven trata do resto.

Mas o que acontece com suas próprias bibliotecas (aliás artefactos) – como são geridas as versões? Sempre que é executado o “mvn install”, o maven faz o build ao projecto, vai criar o package correspondente (i.e. Jar, War) e vai usar o número da versão definido no pom.xml para instalar o artefacto compilado no repositório local (ou online). Um repositório não é mais que um género de “base de dados” de bibliotecas gerida automaticamente pelo Maven.

Imagine-se que estamos a implementar o projecto A v1.0, que depende do projecto B v0.5. Temos ainda o projecto C v0.2 que também depende do Projecto B v0.5. Quando se faz o build install do projecto A v1.0, como este depende de B v0.5, o Maven vai primeiro fazer build, (package), e instalar o projecto B v0.5 e só depois o mesmo ao projecto A. Por sua vez, ao fazer build install ao projecto C v0.2, como o artefacto B v0.5 já existe e está instalado, o Maven não recompila o projecto B (excepto se houverem mudanças no código), usando a versão do projecto B v0.5 instalada no repositório.

Agora imaginemos que evoluimos o projecto B, actualizamos a versão para v0.6 no pom.xml. Estas alterações são necessárias ao projecto A, pelo que mudamos também o versão na dependência definida no pom.xml do projecto A. Porém, o projecto C ainda depende da versão v0.5 do projecto B, e não quer as novas alterações. O maven gere isto confortavelmente, pois irá simplesmente usar a versão do artefacto necessária, já previamente instalada no repositório.

Ou seja, elegantemente conseguimos ir evoluindo as versões das nossas bibliotecas “sem termos que nos preocupar” com quebrar a compatibilidade com projectos que dependem das mesmas, visto que o número de versão toma aqui um papel muito importante, facilmente gerido pelo Maven. Na realidade, é tão fácil, que quase nos esquecemos de porque é que era tão complicado lidar com diferentes versões das bibliotecas…!

Caso 5: O meu projecto consiste em 20 projectos de Eclipse, dependendo uns dos outros e é preciso compilá-los na ordem correcta para que tudo funcione

Esta é uma tarefa aborrecida no Eclipse, para a qual normalmente usamos o Ant. Mas que o Maven gere de uma forma muito simples, e confortável. Relembrando, cada projecto tem um ficheiro  pom.xml. Os projectos podem ser organizados em níveis. Por exemplo:

Cada um dos (artefactos) acima possui um pom.xml. Nos pom.xml “parent”, adiciona-se:

 <modules>
      <module>ProjectA-server</module>
      <module>ProjectA-flex-client</module>
  </modules>

Quando o maven é executado no projecto base, irá analisar a configuração dos módulos, e tentar executar primeiro o build em cada um dos módulos definidos, e por sua vez, em cada um dos sub-módulos, recursivamente na ordem correcta de dependência, “instalando-os” no repositório local. Mas claro, é sempre possível indicar ao Maven que queremos compilar só um projecto.

Caso 6: O projecto está a ser implementado numa equipa, mas é penoso configurar todos os projectos no Eclipse um a um em cada um dos postos de trabalho

Os ficheiros de projecto (.project) do Eclipse são específicos da máquina em que estão (i.e. um .project configurado no meu computador provavelmente não funcionará no computador do lado), e portanto não é boa prática colocá-los no SCM para partilhar com a equipa. Isto quer dizer que normalmente todos os elementos da equipa têm que criar à mão um novo projecto no Eclipse, configurar as dependências, definir a build path, etc, etc. Por vezes, estas configurações são até um pouco complicadas e demoradas, e algo corre mal, pelo que alguém tem que andar a saltar de estação em estação a ajudar a configurar o ambiente de desenvolvimento. E o pesadelo repete-se sempre que há uma alteração à configuração (novas dependências, novas versões, etc).

Com o Maven, como já foi referido anteriormente, queremos evitar de mexer com nas configurações de projecto do Eclipse. Por outras palavras, o Maven irá, regra geral, tratar desta tarefa automaticamente por nós. Quando escrevemos:

mvn eclipse:eclipse

O Maven irá ler o pom.xml, e usá-lo para criar os ficheiros de configuração do Eclipse para esse projecto, e para todos os sub-módulos desse projecto (ver Caso 5). Depois basta fazer um “Import > Eclipse project” no Eclipse, e já está, pronto a trabalhar. Naturalmente, já tinha referido isto no caso 1, mas voltei a repeti-lo aqui para reforçar o quão útil é este comportamento no desenvolvimento em equipa, especialmente na configuração inicial do ambiente de desenvolvimento de um novo projecto.

Mais possibilidades

Este post podia alongar-se em muitas mais páginas. Como ainda estou a estudar maven, este é o ponto a que já cheguei:

Mas ainda me falta:

Em resumo…

Resumindo, qualquer pessoa numa equipa pode executar um único comando que irá:

Interessa também realçar que os ficheiros pom.xml acabam por se tornar em manuais/guias valiosos para novos developers entenderem muito rapidamente a organização de um sistema complexo. Outro facto de realce, é que o plugin m2Eclipse possui um interface gráfico para editar e gerir os ficheiros pom.xml, simplificando em muito a vida na fase de configuração do projecto.

João Saleiro (Webfuel)

O video abaixo exemplifica alguns dos nossos trabalhos:

Aproveito para agradecer a todos os que nos têm apoiado ao longo destes anos. Esperamos continuar a inovar, a elevar a fasquia no desenvolvimento de RIAs no nosso país, e a partilhar conhecimento com a comunidade.  Obrigado a todos e espero que gostem do site.