Idioma

En tots els projectes en que he participat, hem emprat el català en el codi. Això s'ha fet sense cap discussió, semblava que la opinió era unànime. Però, i si no haguera estat així? i si hi hagués hagut divisió d'opinions?

Suposo que tots els raonaments haurien estat fets a posteriori. Vull que es faci en català, quins arguments puc emprar? Desgraciadament sembla quasi impossible procedir d'altre forma en aquesta qüestió.

Pensant-ho fredament, quin idioma s'hauria d'emprar? o, millor: quins arguments hi pot haver per decantar-se per un idioma o un altre?

Una llengua, si intentem treure factors emocionals que l'enrevolten, és (en l'àmbit que ara ens interessa) una eina de comunicació, i com a tal l'hem d'analitzar en el nostre cas. Quin idioma complirà millor la tasca d'expressar el significat del nostre codi?

Descomposaria aquesta capacitat en dues propietats diferents: l'univers de persones que podrà llegir el nostre codi i la capacitat expressiva d'aquest idioma en l'àmbit que desenvolupam.

Anem al primer punt: qui podrà entendre el nostre codi. En aquest cas hi ha factors quantitatius evidents: el nombre de persones que podran treballar en el nostre codi serà molt major si ho fem en castellà, que si ho fem en català. Tots dos, per la seva banda, seran molt inferiors al que tendrem si emprem l'angles. En l'àmbit que treballem, aquestes diferències són pràcticament inexistents (gent de les illes), però se'ns poden ocórrer fàcilment motius per ampliar aquest àmbit. Per exemple, deixar l'aplicació a altres comunitats o fer-la codi lliure. Un altre exemple, accedir a serveis de consultoria externa. Si ho fem en angles podrem treballar més fàcilment amb els experts més qualificats en una determinada tecnologia.

I que hi ha de la capacitat expressiva que aconseguim amb l'idioma emprat? En principi un podria pensar que és gairebé equivalent en tots ells. O que només és pot veure afectat per el nivell que tenen els programadors (encara que no ho sembli, escric millor en català que en angles;-) ). Hi ha lògica en això. Però hi ha gent que pot objectar coses importants (bàsicament, els seguidors de l'anomenat Domain Driven Design). Aquesta gent diria que és un valor importantíssim desenvolupar un llenguatge comú entre desenvolupadors i clients que estigui present en tots els àmbits: comunicació directe, documentació, codi, taules, etc. Desenvolupar aquest llenguatge no es tant triar quina paraula emprarem per expressar cada concepte sinó esforçarnos per enraonar amb els mateixos conceptes. No dir habitació si els professionals del sector empren el terme "unitat d'allotjament". Però més que això, entendre per que el terme habitació no és exacte i s'empra l'altre.

Aquesta tasca serà molt més fàcil si emprem el mateix idioma en el que s'expresen els usuaris, la documentació oficial i les altres aplicacions que conviuran amb la nostra. En el nostre cas, aplicacions per la Conselleria d'Educació, el català és la llengua més adient. Si l'aplicació hagués de gestionar la docència a totes les comunitats, això canviaria.

Afegiria, però, que la solidesa d'aquest segon factor està condicionat a la importància que donem al model del domini. Si a l'hora de fer l'anàlisi, el criteri emprat és "basta per implementar els requeriments" poca importància té que hagem de traduir els termes emprats del català al castellà o l'angles.

tancat?

Sense portatil, crec que aquest bloc estara un temps aturat: -(

Robatori

Un mal dia.

M'han robat un parell de coses del cotxe quan estavem nedant a Alcanada. Una bossa on l'atlota tenia el passaport, la camara de fotos, targetes de banc i altres, i una altra bossa on duia dos portàtils, el que empro per treballar a casa i un antic on juga la nina.

Havia agafat el portàtil per acabar de preparar el curs de desenvolupament amb JBoss que comença dilluns.

Quasi tot ho tenia al subversion de la feina, però no havia pujat els projectes amb els exercicis, ni una darrera presentació.

Ara estic preparant a contrarellotge tot el que falta.  Espero poder arrivar amb alguna cosa presentable.

Que hi farem ...

Esborrats

Excelent article sobre l'esborrat d'entitats.

Vist via en Gavin King

Crec que falta comentar que quan ens plantejem un esborrat hi pot haver dues situacions al darrera:

• Una acció sobre l'entitat que identifiquem com a eliminació. El cas tractat a l'article.
• Desfer una creació incorrecte. És a dir, esborrem un producte per que ens hem equivocat a l'entrada. Aquest producte no ha existit mai. En aquest sentit, sí és correcte l'eliminació.

Què vols ser de major?

Recordo vagament que hem feien la pregunta quan era petit. No sé que contestava, futbolista, policia, bomber o alguna cosa que surtis per la tele, suposo. També jo demano això a la meva filla major. Ella me contesta metjesa. Ja veurem, la pregunta és més un joc que no una predicció.

Jo al final m'he fet programador, ara tinc 35 anys i a la feina torna a sortir la pregunta: i tú, que vols ser de major?

Buf, programador, suposo. Però per la reacció de l'interlocutor sembla que la resposta és igual de lògica que si a n'en Messi li demanen que vol fer als 50 anys i contesta seguir de davanter al Barça. Així que torna-m'hi. Que vull ser de major?

Com que sembla que t'expulsen de la feina de triada, has de mirar quines opcions te queden. En l'àmbit en el que estic hi ha dos camins típics: informàtic funcionari o professor a instituts. Cap de les dues opcions m'estira massa. Posats a triar, aniria a oposicions però sembla que a partir d'ara hi haurà poques places.

Sense entrar en el terreny de "mel i sucre" de treballar per l'administració, l'altre possibilitat que sol apareixer és la de convertir-te en cap. O sigui, entrar més en tasques de gestió. Vaig fer una llista de les deu qualitats principals d'un cap i vaig fallar en onze (una era posar nombres a les llistes per no descontar-me).

Fent l'exercici de retirar les opcions que m'agraden però sembla que no puc fer (programar), les que no m'agraden (funcionari, professor) o les que no valc (jefe, gigolo, futbolista, etc.), que triaria del que queda?

Per ara se m'ocorren dues coses que m'agradaria fer:

• treballar en un equip de test. És un tema que me interessa de fa temps i hi vaig fent lectures en "background". A més, me fa l'efecte que els problemes de la meva "vellesa" que m'impediran seguir programant no tindran tant d'efecte en les tasques de fer proves.
• donar classes a la universitat. Ja sé que he dit que no m'agrada la docència, però són els adolescents els que no m'agraden. Me fan por ;-). Crec que amb alumnes universitaris sí que m'agradaria. Pot ser una any d'aquests intenti entrar com a professor extern (ara no sé quin nom li donaven a això).
  

El que sí que temp clar que és que d'aquí a 15 anys no se programarà com avui així que el més important és llegir moltíssim i entendre el que està vinguent de nou. Al manco intentarem posar-lis difícil el retirar-mos.

Problemes, causes i solucions

Que van de bé a vegades les crítiques.

A un mateix no, que això molesta i som molt sensibles. Però sí als altres. En concret, al Java, que és al que em dedico.

La proliferació de nous entorns i llenguatges ha fet evidents alguns defectes molt importants del desenvolupament tradicional en Java. No té sentit negarlos, ja que són evidents. El que sí es pot debatre és si aquests defectes són inherents al propi llenguatge, i per tant, no hi ha solució possible, o bé si són per la forma actual de plantejar algunes coses.

Tot això ve a que trobo que el Java (entorn, no llenguatge) està responent bé als reptes plantejats.

Anem als problemes més comentats.

Cicle codificació - prova

Un dels defectes importants són els temps de desplegament per poder provar canvis en el nostre codi. L'altre dia parlava d'una forma de fer que el contenidor tingués accés als nostres canvis en fitxers JSPs o estàtics sense haver de redesplegar el context Web. Clar que això és una part petita.

Un pot argumentar, amb raó, que els canvis més freqüents són en el codi Java. Per això es pot fer servir una eina que, per ara, m'ha convençut plenament: el JRebel. En la nostra aplicació (EJBs, Servlets, més de 2500 classes ...) puc provar un canvi en una classe Java directament al JBoss en uns 2 o 3 segons!. Segur que altres entorns ho poden fer una mica més ràpid, però no molt més. Me falta poder augmentar la velocitat de prova d'un canvi a una classe de domini (o que afecti a Hibernate) però ja arribarà.

Tot això afegit a que el fet de que moltes coses es poden (i s'haurien) de provar amb proves unitàries, d'execució molt ràpida, fa que al llarg del dia les aturades de servidor o redesplegaments es puguin reduir a un nombre molt baix.

Complexitat

La complexitat de les tecnologies d'infrastructura estan en bon camí de la ma d'Spring. En cada versió es fa més fàcil resoldre coses com l'ús de les connexions, accessos a serveis remots etc.

Buf, molt curt i gens argumentat, però m'interessa anar als següents ;-)


Productivitat

Pel que fa a la productivitat, per aquí hi ha dos camins. Seguir el camí "dinàmic" amb "convention over configuration" o Groovy, Grails, Griffons i companyia o mantenir-se en la línia ortodoxa: tipat i fora "màgia". En aquest segon cas hi ha una eina que ens ajuda a tenir una versió funcionant en pocs minuts: Spring Roo. Aquesta eina ens genera tot el codi "pesat" i de "copy-paste" de cada projecte amb un parell de sentències.

La raó de emprar Spring Roo és atacar el problema de la productivitat amb èxit però disposar de tota la infrastructura Spring tradicional per poder afrontar aplicacions més complexes.

Aquest és un problema complexe. Per un costat tenim molt de codi idèntic. L'hem generat ràpid, però encara el tenim. Sabem dels problemes de les duplicitats. Necessitem moltíssim més codi per fer una interacció bàsica i típica que l'equivalent amb Grails. Ara bé, tot el que Grails no escriu es basa en convencions que fan que el nostre codi sigui una mica "màgic". Màgic en sentit negatiu: l'aplicació fa coses que no són explícites al codi. Clar que no s'ha de confondre màgic amb aleatòries, tot està ben definit, només que no en el nostre codi, sinó en l'entorn.

També hem de tractar aquesta qüestió quan emprant Spring, hem de decidir fins quin punt emprem les annotacions per retirar l'XML de configuració. Es pot arrivar a deixar un XML quasi buid però no sempre ens convé renunciar a la definició centralitzada que suposa l'application-context.

Llenguatge

Les crítiques més doloroses, en la meva opinió, són les que fan referència al propi llenguatge. En Java necessitem moltes volteres per implementar coses senzilles com "retorna la nota mitjana dels alumnes d'aquesta llista, considerant només els aprovats". Aquí sovint se identifica aquesta limitació per la naturalesa "tipada" del Java. De fet, es sol contrastar la "xapussaria" que ha de fer el Java amb solucions fetes en llenguatges dinàmics, que ho resolen de forma (molt) senzilla i (molt) elegant. "Lo cortés no quita lo valiente" ;-)

Estan sortint algunes llibreries que faciliten resoldre algun petit subconjunt d'aquests problemes. En particular, m'ha agradat molt el google-collections, però ja dic, no tracta ni de bon troç l'arrel del problema. Donat que el llenguatge ja té els seus anys i s'està mostrant conservador, cal cercar ajuda fora d'ell.

I fora d'ell trobam tot un conjunt de llenguatges com Groovy i Scala que aporten aire fresc a on abans només hi havia humitats. L'avantatge d'aquests llenguatges és que s'executen a la mateixa màquina virtual, oferint interoperabilitat amb el codi Java. És a dir, podem seguir desenvolupament en Java però fer un mòdul en Groovy si aquest llenguatge és més adient per les responsabilitats del mòdul.

Vull dir amb tot això que el Java aguantarà l'envestida que reb?. No. Ni idea del que passarà. Pot ser el Java hagui d'acabar dient alguna cosa com "Als que m'heu de matar: moltes gràcies"

Només dic que degut al que han proposat els llenguatges i entorns alternatius, avui desenvolupar en Java és molt millor que fa un parell d'anys.

Millorant la productivitat en aplicacions web J2EE

Una de les protestes més habituals que hi ha quan es desenvolupa en J2EE, és el temps que s'està per provar una cosa.

El cicle escriure, compilar, crear war (i/o ear), desplegar, provar i tornar a començar pot ser desesperant.

L'inconvenient és més notable si el que volem fer és canviar un simple html, o javascript o fins i tot un JSP.

Vaig a proporcionar un petit "truc" que vos pot ajudar si patiu el que hem dit abans.

Per començar heu de tenir, si no ho teniu, una estructura de directoris idèntica a la que queda al war. És a dir, un directori WEB-INF amb el web.xml, un directori classes i altres trastos per el contenidor, i a l'arrel els JSPs i continguts estàtics. A aquest directori poseu-li el nom que tendria el war, per exemple aplicacio.war.

Tot fet?, seguim.

La idea és indicar al servidor que aquest directori, l'aplicacio.war (sí, és estrany noms de directori amb extensió, però no hi faceu cas), ha de ser desplegat.

Per començar arrenquem el servidor JBoss de forma normal. Fet això ens situem amb la consola al directori bin del JBoss. Allà hi ha un script per enviar comandes al JBoss: el twiddle.

Bàsicament al twiddle podem enviar via la línia de comandes el que es pot fer via l'aplicació jmx-console. El que direm serà: desplega l'aplicació que està al directori X (on X és el nostre aplicacio.war). Au idò:

C:\java\jboss\jboss-3.2.7-caib1\bin>twiddle -s localhost invoke "jboss.system:service=MainDeployer" deploy "file:/C:/la_vostra_ruta/aplicacio.war/"

I això és tot. Als logs del JBoss hauria de sortir una cosa semblant a:

18:22:15,109 INFO [TomcatDeployer] deploy, ctxPath=/aplicacio, warUrl=file:/C:/la_vostra_ruta/aplicacio.war/

Anau amb el navegador a alguna pàgina de la vostra aplicació. Va bé?

Si vos ha fallat comprovau que heu posat la barra final. Si no la poseu JBoss no arrancarà el desplegament d'un directori sinó el de un fitxer war, que no és el cas.

Si vos falla amb el jboss-3.2.8-caib5, mala sort, aquesta versió no està soportada en aquest blog. Sincerament, vos aconsello que desenvolupeu en un altre JBoss i tengueu una màquina amb la versió jboss-3.2.8-caib5 per provar de tant en quant que tot funciona.

Seguim? Bé, suposo que tot vos ha anat bé. Ara ve l'efecte "uau". Amb el vostre editor modificau un fitxer jsp (o html, css etc.). Guardeu els canvis i refrescau el navegador. Xulo eh? Res de redesplegar aplicacions per veure els canvis en els fitxers modificats.

Si és a on feis feina habitualment, això ha de multiplicar la vostra productivitat. Fàcilment es passa d'un temps de 15 segons o un minut (en funció del tamany de l'aplicació) a un de 2 o 3 segons.

En cas de canviar el web.xml, o recompilar un servlet executem la comanda anterior però ara canviant el deploy per un redeploy:

C:\java\jboss\jboss-3.2.7-caib1\bin>twiddle -s localhost invoke "jboss.system:service=MainDeployer" redeploy "file:/C:/la_vostra_ruta/aplicacio.war/"

Encara en aquest cas hi hauria d'haver una millora important en el temps de prova degut a que no s'ha de empaquetar, moure i desempaquetar tot el contingut de la part web.

Aquesta estratègia es pot emprar encara que tingueu EJBs (eecs) o fins hi tot Hibernate (aaaah). Simplement els altres components els desplegau en artefactes separats (ears, jars o wars, segons el cas) i feis que la vostra aplicació web accedeixi a ells via JNDI.

Espero que vos sigui útil!