Farewell EcmaScript 4, Adobe are you in deep pain?

According to this email from Brendan Eich the discussions on EcmaScript 4 are over, finalized, ended, dead, buried - you get the picture. Everyone will have to move on and continue to work on EcmaScript 3.1.

For those of you who haven't been following this soap opera here's a quick review: version 4 of the standard was mainly backed by Adobe who wanted to have a proper standard behind its product ActionScript, remember that the language is the main workhorse behind Flash, Flex and threrefore a wealth of derived products. 

But who cares about standards anyway? mostly everyone. Picture a world where TCP is not backed by RFC 793 and to browse the web you don't use HTTP but a protocol developed by, say, AT&T that might be open, well documented and whatever else, but there will never be an official consensus about its use. 

You might say, well there is no standard behind MS Word .doc file format for instance and you would be right, but here we are talking about mindblowingly massive stuff, and that's what Adobe was aiming for, remember the latest addition to the family, AIR that takes ActionScript programming out of the browser cage and into the world of desktop programming.

So now Adobe ended up with a language that's a bit compliant with EcmaScript 3, with some extensions - so it _does no comply_ - after all the effort...

Aaaaanyway, this was supposed to be merely an informative post, much more info about the background of the issue can be found in this blog.

Cuadradito, puntito, rayita, cuadradito, cuadradito

Están apareciendo en Buenos Aires carteles en blanco y negro con esta forma:



Pero se "olvidaron" de enseñarle a la gente cómo se usa. Claro, me van a decir que seguramente es una estrategia de marketing ya que apuntan a un mercado que conoce lo último en tecnología, etc, bla, bla. Para mi la pifiaron, es algo que _puede llegar_ a ser muy útil o puede denigrarse tanto como "mandá un sms al 666 con la palabra PONERLA y te mandamos una lista de chicas en tu zona después de responder una trivia de 223 preguntas".

Acá pueden ver un video promocional de ScanLife que más o menos te da una idea de qué se trata:



Para los más geekitos acá les va una implementación en J2ME http://sebastien-arbogast.com/2008/07/06/mobimap-10-rc2/

Hack me babe! I implement Hackeable

Recién tuve que escupir un mail tratando de convencer a alguien de que _no use_ EJB, acá va:

Hi guys,

I'd like to take the conversation one step further and give you my opinion on "why I think we should go REST". Exchanging information online among apps is all about exchanging bits over a socket. The ways I've done this before are EJB, some sort of RPC implementation (i.e. spring rpc), WebServices (Axis) and simple custom HTTP calls. With the advent of "Web 2.0" completely different websites (apps) need to communicate with each other, besides screen scraping (for non-cooperative external apps), simple HTTP calls are great. Why should I have to implement a whole set of things just to get simple info from another app? As happens with EJB and WebServices (to a lesser extent), and that what happens with *ClientName* apps most of the time. Also, as we are using Javascript and JSON extensively we can leverage that knowledge to use JSON as a transport and not XML, which is waaaay better for these matters.

For the particular case Sofía mentions, a couple of cooperative servlets in each app would do for now. In the big picture, IHMO we should think in terms of exporting all the functionalities in, say *AppA*, as simple REST services that any other app can use with simple HTTP calls. We've already done this in a way with *AppB*, you can go an talk JSON to it through the Jabsorb bridge.

Well, this is a long email, we can discuss the topic further over the phone if you want.

Cheers,
Juan 

La idea que quiero transmitir en realidad, más allá de si se implementa REST, RPC o whatever, es la de hacer una aplicación hackeable o hacker friendly. Cuando estás codeando esa fina capa de aplicación/servicios está bueno pensar en cómo vas a proveer esos servicios a todo el resto del mundo, que nadie piense siquiera en hacerte screen scraping, un buen ejemplo son los WebServices de Amazon. La sigo en otro post porque ahí viene el próximo entrevistado.

Java vs. C(++) vs. Lisp (?) vs. [Put your geek addiction here]

First of all, you should know that I get paid for putting Java code together and trying to get into production. Those of you that have a similar job need no further explanation.

I don't really think Java is neither the best nor the worst thing out there, its just a fair language with a lot of effort, money, marketing and open source code under the hood.

So, what is this post for? You see, where I work we _try_ to follow Evans' DDD most of the time, and there is this guy who joined our team a couple of months ago... he's a nice person, but he also is what you would expect to find if you crack open an Oracle DB: He loves stored procedures, JDBC (no ORM trash), hates overpatternized (?wtf) business code... you get the picture. So you could imagine, Banks here in Argentina have been using stored-procedure-only access to the DB to provide extra performance and security, Mainframe is still kicking most J2EE apps asses and so; explaining why we should use DDD to this guy wasn't a task for the weak.

After a while, all the talking with this gut got me thinking about a topic I had buried some time ago, the same thing that made me go and try Rails and friends: How come the Mainframe is still the best darn thing out there to do Client-Server apps? Most Java Enterprise editions are development/deployment/configuration nightmares, so I usually fantasize about something simpler.

From a development point of view, you could have hundreds of Junior devs coding EJB2 interfaces with well defined DTOs and everyone should be happy if the specs are good enough, you'll end up with a big, well priced, working product. This scenario is considered BAD, EVIL, NASTY. Everyone wants to code Spring supported DDD code (xml/annotations nightmare?). I also know small teams coding in Smalltalk (niiiice, though not nice enough :(). The thing is that it is hard to get complex -in some ways- with objects, so this guy I was talking about wants to do as much as he can inside the DB and then having just one layer that does a bit of business logic and puts everything in the response. I don't really like it, but I can't say I don't!! It rings so many bells, including Paul Graham's! The guy would even hack lisp code in a running production server, it doesn't get much more agile than that!

So, summing up a little bit. I want your opinions, thoughts, feelings, about non traditional architectures such as: Paul Graham's ViaWeb (lisp hacking), Google's Map Reduce architecture, and so on. What have I been researching?

Facts:

• Rails (sadly) sucks for important -this depends on you- things.


• *ails also have a tendency to suck.


• JRuby runs better that Ruby itself. Thanks guys coding JVMs! And JRuby team too.


• ('nuff said 'bout ruby)


• I don't care about a language "easyness", I want effectiveness and efficiency.


• The Gmail team is hiring software engineers that know a lot about C++ and TCP/IP (Python is just a plus).


• A really big etc.

I've just realized that this list is too large and will defer it to a later post.

So, I want to know if YOU could make something better than J2EE (and the like), not easier, not nicer, not lighter, not heavier, not rocker(?), not fancier, but just better.

Cheers!