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.

Paranoia en La bemol mayor and the answer to life the universe and everything

Estos dos artículos totalmente desconectados en Wikipedia me llevaron a escribir este post:

• El clave bien temperado.
• Answer to Life, the Universe and Everything.

En los links está bien marcada la parte que llamó mi atención, que no sé si referirme a ello como una suerte de paranoia simpática, estupidez o simplemente abundancia y exeso de tiempo libre. En el primer caso, un muchacho llamado Bradley Lehman -no se pierdan su sitio web, caripela por 10.000- asevera que Bach codificó el sistema temperado en la serie de rizos que decoraba el comienzo de una obra suya. Supongamos por un momento que esto es así, ya que la veracidad no está sujeta a nuestro análisis -nomeimportauncarajo.com-, el hecho es que este señor se puso muy minusciosamente a estudiar y a probar que en esos rizos decorativos -Bach no tenía Word- eran una codificación de un sistema de afinación. SEÑOR!!!!!!!!!!!!!!! VAMOS!!!!!!!!!! Yo estoy dispuesto a probar que una persona normal con trabajo, novia/esposa, una familia y amigos, en condiciones CNPT no haría algo así jamás.

Dejemos al señor Bradley en paz por un segundo, vayamos al segundo link. Acá la cosa se pone un poquito más grave, aquellos que no conozcan de qué se trata The Hitchhiker's Guide to the Galaxy tienen bastante que leer, o al menos vean la peli -donde actúa una linda señorita llamada Zooey Deschanel-. Volviendo al tema, en la historia el autor plantea que la respuesta a la vida, el universo y todo lo demás es el número 42, y según sus propias palabras lo eligió a un complejo sistema astroteocríptico (?) conocido como "le pintó", o como diría mi buen amigo César D. "Se lo sacó del Culo". Ahora bien, hay gente que no contenta con la explicación, empezó a buscar otras como se ve en el link de más arriba. Acá no hay "tu tía" (?) PEOPLE! GET A LIFE!!!

Todo bien con la CIA, la NSA, la NASA, la MOSAD, la AFIP -un saludo para todos los muchachos del palo de la inteligencia- dándonos motivos para inventar -o no tanto- teorías conspirativas; pero ya esto me parece un poco demasiado. No sé... me da cosa gastar tanta mente brillante (?) en buscar el significado del número 42 o de los garabatitos de Bach.

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!