lunes, 22 de noviembre de 2010

Programar en tiempos revueltos

Recientemente varios amigos, de diferentes ámbitos, me han hecho la misma pregunta:
“escucha, si yo quisiera dedicarme a la programación, así en serio, como lo haces tú, ¿qué debería estudiar? ¿qué libros me compro?”

Obviamente son gente que, sin ser geeks, más o menos se manejan con la informática.
“os contesto por email” les he dicho a todos. Pero he pensado que mejor lo publico en mi blog, que para eso lo tengo :-), y que lo lean ahí.
Tengo que matizar que cuando mencionan lo de ser programadores, se refieren en concreto a programadores de software de gestión en entornos web. No es que ellos lo mencionaran expresamente, pero entiendo que nadie se plantea de la noche a la mañana “voy a programar motores de renderizado 3D” o "voy a desarrollar un compilador de Java alternativo al de Oracle". Primero porque es complicadísimo y antes que aprender a programar bien tienes que aprender mucho de otras disciplinas (generalmente matemáticas). Y segundo porque no hay tanta demanda.

Hoy día la gran mayoría de los puestos de programador que se solicitan son programadores J2EE o .Net. Programadores de aplicaciones web, vaya. Y se solicitan muchos. Lógico es que mucha gente decida reenfocar su carrera profesional hacia donde brilla el sol. En este caso el mundo del desarrollo web.
El resto de este (Email)Post es bastante subjetivo; no pretendo lo contrario.
Yo veo, en el mundo del desarrollo web, tres divisiones, en lo que lenguajes de programación para el servidor se refiere:
- La primera y más importante, donde juegan las estrellas, es la de Java y .Net. Prácticamente todas las grandes aplicaciones que se inician hoy día, se hacen en Java (J2EE) o en .Net. Me refiero a aplicaciones como las que usan los bancos, las petroleras, las aseguradoras... Bases de datos gigantes, decenas de servidores, con decenas o incluso miles de programadores. Estas aplicaciones son sobre todo aplicaciones de gestión, llenas de CRUDs y de informes.
- La segunda, es la que yo llamo del PHP. Aquí está toda la gente que hace páginas web, más que aplicaciones web. Suele haber mucha página estática, diseños gráficos rompedores, algún panel de control, y puede que algo de gestión. Suelen ser aplicaciones que van todas en un único servidor, a menudo incluso la base de datos, que suele ser MySQL, también está en la misma máquina que el servidor web (que suele ser Apache).
Ya estoy oyendo a los PHPeros decir: “esos es mentira, en PHP hay aplicaciones gigantes, incluso para bancos”. Lo siento amigos PHPeros, si creéis que PHP juega en primera división, es que nunca habéis jugado en primera división.
Y no dudo que se puedan hacer grandes cosas en PHP, pero, por circunstancias que más adelante explico, PHP no es una opción para hacer algo grande de verdad.
En esta división entrarían otros lenguajes que, aunque en su día pudieron llegar a hacer sombra al PHP, hoy se han quedado en el camino, como son Perl, Ruby, Phyton… Son lenguajes que no tienen nada que envidiar a PHP, pero PHP les ha ganado la batalla. Y eso que se podría decir que detrás de Phyton está Google, y que Ruby, con su framework Rails (Ruby On Rails) puso de moda este concepto de On Rails, que viene a significar que las tareas más comunes con las que se encuentran los programadores están simplificadas al máximo y se programa a toda velocidad. Y Perl es un lenguaje que por su especial habilidad para manejar cadenas de texto, es el lenguaje preferido por los administradores de sistemas Unix/Linux.
Y la tercera división, es el resto de lenguajes. Todavía he visto a gente haciendo cosas para la web en C o C++. Incluso lenguajes raros, residuales. No voy a perder el tiempo con esta división.
Alguien estará diciendo… ¿y donde esta Groovy/Grails? Pues, hasta que no lo compró SpringSource (ahora VM Ware), diría que era un lenguaje de segunda o tercera división. Pero ahora diría que es un lenguaje de primera división. Hay que recordar que Groovy es uno de esos lenguajes que en realidad su código luego se traduce a Java, por lo que puede correr perfectamente en un entorno de servidores de aplicaciones Java.
Groovy tiene su framework On Rails, llamado Grails, y que ciertamente es una maravilla. Ríete del PHP. Además Grails (por que al final casi todo el que usa Groovy acaba usando Grails) se integra perfectamente con Spring. Pero incluso con los proyectos más avanzados de Spring como Integration, o Batch. Así que puedes abordar un proyecto gigante con Grails, y donde se te quede corto, pues usas Java puro. Al final se va a instalar todo en un Tomcat o un WebSphere.

Quiero volver a recordar que esta es una opinión y como tal es subjetiva. Si alguien cree que PHP es mejor que Java, que escriba su blog y rabie ahí todo lo que quiera.

¿Por qué estas tres divisiones? No lo tengo claro del todo, pero supongo que es por la cantidad y calidad de herramientas existentes para las diferentes etapas del ciclo de vida de una gran aplicación. En ese sentido, Java es el lenguaje que más librerías y frameworks tiene; el que dispone de los mejores entornos de desarrollo con centenares de plugins; el que más servidores de aplicaciones tiene en su menú. Por no mencionar otras herramientas para la explotación, integración continua, test de estrés, etc. Sin todas herramientas no puedes plantearte programar algo como pueda ser un banco online, por pequeño que sea. Y cuando digo programar un banco online no me refiero solo al front office, que ya sé que hay alguno hecho en PHP. Me refiero a todo lo que conlleva un banco, con sus centenares de módulos. Incluso Java y .Net siguen madurando día a día para poder gestionar mejor las macroaplicaciones que el mundo moderno va necesitando.

Basta de charla, a ver, entonces qué estudio para ser programador de primera ¿java? ¿Me compro un libro de Java?
No quisiera desanimar a mis amigos, pero aprender java sólo es el primer paso de cientos. Porque programar aplicaciones web, abarca muchas disciplinas. Bueno, básicamente se reducen a tres:
Programación, Administración y Diseño. Sí amigo, si quieres ser un buen programador web de primera, tienes que saber algo de administración y algo de diseño. Tienes que saber un poco sobre como funciona un servidor de aplicaciones y un servidor de base de datos por lo menos. Y tienes que saber algo de diseño. No diseño gráfico, sino HTML, hojas de estilo CSS, bien de Javascript, algo de usabilidad y sobre todo saber qué se puede y qué no se puede meter en un interfaz web.

Así que voy a empezar a escupir la retahíla de siglas que recomiendo para cada uno de estos tres pilares. Insisto en que yo soy del mundo Java así que todas las recomendaciones que voy a dar son para convertirse en un Javero de pro. Vamos primero con el más básico, el que menos tienes que saber:

Administración.
Básicamente dos conceptos: Servidor de Aplicaciones y Servidor de Bases de datos. Tienes que ser capaz de instalar estos dos servidores. Y saber por lo menos donde se guardan los logs, y donde los ficheros de configuración. Servidores de aplicaciones Java hay muchos, pero os diría que para empezar, con el Tomcat es suficiente. Si os gusta este tema, podéis avanzar hacia JBoss o GlashFish. Y en cuanto al servidor de base de datos, aquí sí que no hay duda: PostgreSQL. Olvídate de MySQL. Son igual de fácil/difícil de manejar pero Postgres es más potente y robusto. Y punto. ¡Que no! Que MySQL no le hace sombra a Postgres. Pesaos estos del MySQL...
Con el postgres viene un pequeño cliente, el pgAdmin, pero si vas a hacer cosas en serio te recomiendo el Navicat o el EMS Pgsql Manager. No son gratis pero son mucho cómodos para moverse por las tablas, indices, triggers, etc.
Estoy dando por supuesto que al menos sabes lo que es un índice de base de datos. Te perdono que no sepas lo que es un trigger, pero si no sabes lo que es un índice, deja de leer ahora mismo y échate un vistazo a yonkis.com; le sacarás más provecho :-)
No es una casualidad que casi todos los "nombres propios" que he mencionado hasta ahora son open source. Soy un gran fan de open source. No un fanático, pero si un fan. Y como estoy dando por hecho que no vas a pagar por nada mientras te estés formando, todas las recomendaciones que voy a hacer serán open source, salvo que indique lo contrario.

De la administración no os cuento más, dando por supuesto que también se tienen conocimientos avanzados del sistema operativo sobre el que vas a trabajar.

Diseño.
Voy a hablar del pilar del diseño antes que la programación, porque entraña menos complejidad. Vuelvo a aclarar que por diseño no me refiero al diseño gráfico. Por supuesto es un plus dominar el photoshop o ser muy creativo con el CorelDraw, pero aquí nos referimos en esencia al HTML y a las hojas de estilo CSS. Las hojas de estilo son fundamentales. Ya no se usa la etiqueta <table> para definir layouts y plantillas. Ahora son todo <div> con sus correspondientes estilos. Y si quieres hacer interfaces decentes tendrás que usar mucho javascript. ¿Qué pasa con el javascript? pues que es un dolor de lo malo que es... hasta que llegaron Prototype primero y JQuery después. Son frameworks para la manipulación del Ajax, los estilos, el DOM, y hacer todas esas virguerías que antes sólo se podían hacer con flash. Sin duda hoy día JQuery y su hermano JQuery UI (para armonizar el interfaz) son la opción más segura. Además programar con JQuery o incluso extenderlo es muy sencillo. Tanto es así, que ahora, hasta me mola programar en Javascript, cosa que siempre he odiado. Aunque lo cierto, es que yo diría que programo en JQuery más que en Javascript. Creo que no uso ni un sólo método nativo de javascript. Y mejor así.
El javascript tiene un pequeño problema. Y es que como se ejecuta en el navegador, el ordenador que ejecuta ese navegador tiene que ser mínimamente potente. JQuery consume mucho procesador. Así que si te lías a meter efectos y "verbenas" es posible que la página se ejecute muy lenta si tu ordenador tiene más de 5 años.

¿Pero la tendencia no era hacer clientes muy finos y tontos y que sea el servidor el que ejecute toda la lógica?Pues sí. Así es. Podríamos pensar que, por error, nos estamos llevando la lógica (cosas como la validación, la ordenación, agregar o eliminar contenido, etc.) al cliente, o sea, al javascript que se ejecuta en el navegador.
Sin embargo, y esto tenedlo muy presente, dentro de poco, el cliente (navegador) con sus sistema operativo incluido se va a ir al servidor. Los que leísteis mi post anterior ya lo sabéis. Dentro de poco, tu sistema operativo completo se va a ejecutar en un servidor remoto (alguna especie de Terminal Server para los que sepáis lo que es) así que no habrá más problemas con que tu ordenador se quede obsoleto, porque sencillamente, no hay ordenador. Tu "ordenador virtual" siempre será lo suficientemente potente para ejecutar lo que haga falta. Lógicamente, cuanto más pagues más potencia tendrás...

A ver, que me lío. Javascript. Con JQuery. A saco. Y no dejéis de echar un vistazo a los increíbles plugins basados en JQuery como JQgrid, o JTree. Y hay centenares más, algunos muy útiles.
Y del diseño no os cuento más. Si os divierte la fotoedición, siempre viene bien saber crear tus propios iconos, patrones, y cosas así con el Photoshop o con el Gimp que es gratis. También hay programas más específicos para la iconografía, y creación de pequeñas imágenes pensadas para integrarse en un entorno web.

Programación.
Aquí está el turrón. Aquí está el porqué te van a pagar más de 48.000 euros al año -cuando domines todas estas siglas y palabrotas, claro está.
Una vez más doy por hecho que algo de programación sabes. Al menos lo que es un bucle, un condicional, etc. Así que lo primero es aprender la sintaxis y la estructura básica. En un libro de esos gordos de Java te enseñan eso y más. Porque suelen enseñar también programación orientada a objetos. Y si el libro es muy gordo, seguro que también te enseña patrones de diseño. Los patrones son soluciones perfectas a problemas comunes. Conocer los principales patrones de diseño hoy día es fundamental. Y no porque los vayas a usar mucho, sino porque los vas a ver mucho. A menudo te encontrarás implementando interfaces o clases abstractas que no has hecho tú, o que se llaman algo así como nosequeFacade o nosecualTemplate, y es importante que sepas lo que es una Fachada (Facade) o una Plantilla (Template). Para aprender bien patrones de diseño, cuando te manejes más o menos con el Java, te recomiendo el libro Head First Design Patterns.

Cuando ya te manejes con Java y hayas hecho unas cuantas cosas chulas (no basta con el “Hola mundo”) habrá llegado el momento de hacer tu primera página web dinámica. Me refiero a un servlet. Pero antes de meterte a hacer servlet y JSPs, tendrás que leer algún libro sobre J2EE, bueno ahora lo llaman JEE, donde explican todas las librerías que puedas necesitar para hacer aplicaciones web. Aprenderás sobre todo Servlets y JSP. No pierdas demasiado tiempo con los servlets. Y de los JSP… lo más interesante es el JSTL un lenguaje muy básico para meter entre el HTML. Un lenguaje de plantillas que se suele llamar, y se usa sobre todo para hacer bucles y condicionales sin tener que recurrir a meter Java puro entre medias del HTML (que es lo que hace JSP). Hay más lenguajes de plantillas para Java, como Velocity o Framemaker, pero te diría que por ahora con JSTL es suficiente.

Y tendrás que aprender a hacer tus propias Tags, que son atajos para no escribir mucho HTML.
Cuando ya hayas tocado todos los palos del JEE, y sepas hacer conexiones con bases de datos vía JDBC, y sepas serializar objetos a XML y viceversa, tendrás que ponerte con JPA. Las conexiones y accesos a la bases de datos suelen dar mucha guerra. Cuando lo tienes mascado, una configuración simple se hace muy deprisa, pero siempre acabas encontrándote con algún problema de persistencia. Siempre. JPA lo que hace darte una serie de herramientas (funciones y librerías) para que tu propio código genere la base de datos, y cada vez que añadas un objeto nuevo se cree una tabla nueva en tu base de datos. Y si añades un atributo al objeto, pues se añade un campo en la tabla de base de datos. Además te independiza de la base de datos. Da igual cual uses. JPA se encarga de traducir el SQL al de la base de datos subyacente.
Para ser preciso, no es JPA quien lo hace, ya que JPA sólo es un API, un interfaz. Hay que usar una implementación concreta de ese interfaz. Yo recomiendo usar Hibernate, aunque últimamente coge fuerza una alternativa llamada Eclipse-Link. El caso es que no tienes que aprender apenas Hibernate, sino JPA y su lenguaje JPQL que es muy similar al SQL. Cuando le pides algo a la base de datos vía JPA, en realidad lo va a ejecutar Hibernate, que es quien finalmente genera el SQL adaptado a la base de datos que uses. Hibernate soporta las principales bases de datos del mercado, entre ellas claro está, Postgresql que es la que vas a usar.
Si se te ha dado bien, y le has dedicado varias horas al día, puede que sólo hayan pasado 4 meses desde que empezaste. Lógicamente lo único que habrás conseguido es una capa de barniz Java. Currando el día a día es como se consiguen más y más capas de barniz hasta que eres un experto.

Pero no hemos terminado ¿eh? Queda un paso más: Spring. Si vas a hacer aplicaciones web hoy día, usa Spring. Es una macrolibrería o framework con módulos para simplificarte la vida en casi todos los ámbitos de la aplicación: capa de datos, capa de negocio, y capa de presentación.
Mediante la configuración de la aplicación con ficheros XML y/o anotaciones en el código, te evita cientos o miles de líneas de código. Es importante que hayas aprendido bien lo que es un servlet, una llamada Http y todas esas cosas, porque luego, con Spring, no las vas a usar pero vas a saber que está pasando por detrás. Porque si no, te va a parecer que Spring hace magía. Sobre todo en la capa vista.
Spring lo vas a acabar usando y tires por Java puro o por Grails. Pero si Java con Spring te puede llegar a parecer magia, Grails con Spring ni te cuento. Por eso insisto en tener unos conocimientos mínimos sobre como funciona un servidor web, y el protocolo HTTP.

Si no te gusta la capa vista, diseñar interfaces, el HTML, programar en Javascript, no pasa nada. También hay un hueco importante para los programadores que sólo hacen módulos que luego necesitan comunicarse porque generalmente están en distintas máquinas. Para esto suelen usarse los web services. Hasta hace poco se hacía todo con web services XML, y el paradigma SOAP. Pero es tan complicado que mucha gente lo está abandonando a favor de otra forma más sencilla: web services REST. Es mucho más sencillo, y para la mayoría de los casos es suficiente.
Por supuesto Spring tiene módulos tanto para los servicios web XML, como para REST. Ya os digo que cuando empiezas a usar Spring, todo se simplifica. Pero no funciona el atajo de empezar directamente con Spring. Si haces eso, cuando te encuentres un problema de esos raros (que te lo encontrarás seguro) no vas a tener ni idea de qué está pasando, ni siquiera aunque leas con lupa el Stack Trace del error.
Tu kung-fu con la programación será óptimo, cuando, al producirse cualquier error, puedas mirar el Stack Trace (la descripción del error según Java) y saber al instante qué está pasando. Los mensajes de error de Java, a pesar de ser infinitamente más inteligibles que lo que había el siglo pasado, siguen siendo un poco crípticos a veces. Y a menudo te dicen que falla algo con lo que tú no estabas lidiando en ese momento, o que ni sabías que existía. Sin un kung-fu óptimo, pasarás más de la mitad del tiempo resolviendo errores que no sabes por qué se provocan.
Y cuando ya creas que sabes mucho Java entonces te lees el libro Effective Java de Joshua Bloch, el arquitecto Java jefe de Google, y descubrirás que todavía eres un novato.

A todo esto hay que sumarle dos cosas, diría que imprescindibles: UML y el idioma inglés.
UML es un “lenguaje” para analistas. Más bien, por decirlo de forma simple, es una notación para hacer diagramas. Diagramas de estado, diagramas de flujo, diagramas de componentes, diagramas de secuencia, y sobre todo, como programador, diagramas de clases. El UML es muy importante no sólo para preparar lo que vas a hacer y comentarlo con los stakeholders o participantes en el proyecto. También es una muy importante herramienta de documentación. Lo normal es que haces primero todos los diagramas UML y cuando te dan el OK empiezas a programar, siguiendo las pautas de lo que hay en el UML (a veces el UML lo hacen otros). Yo para todo lo relativo al UML uso el Visual Paradigm, que es de lo mejorcito que hay.

El UML es el único gran consenso en lo que a documentación se refiere. Porque aunque mucha gente programa siguiendo muchas pautas (como los patrones de diseño o los patrones de análisis), a la hora de documentar… la norma parece ser que cada cachorro se lama su pito :-). Hay como unos grandes trazos, que te recomiendan que dividas la documentación en visión global, documentación funcional, documentación de análisis, documentación para el programador y documentación para el usuario.
El UML se usa para la documentación de análisis y la documentación para el programador.
Y como decía, la otra cosa imprescindible es que te manejes bien con el inglés. Mantenerte en la cresta de la ola implica lidiar con últimas versiones o incluso versiones beta o alfa. Y como cabe esperar, la documentación de todos estos frameworks o lenguajes está inicialmente en inglés. Y siempre pasa algún tiempo antes de que empieces a encontrar gente que en sus blog en castellano pone ejemplos, traduce partes del manual, o escriben y responden en los foros. No sólo es importante, si no que es casi una condición sin-ecua-non. Pues ir avanzando si sólo lo chapurreas, pero llegará un momento en que notarás como el no saber bien inglés te frena.

Pues ala, a empezar. Si ya sabes inglés, algo de HTML y programas bien en algún otro lenguaje (aunque sea de segunda), en cosa de un año, con una dedicación constante, puedes estar preparado para jugar en primera.

El mundo de la programación hoy día tiene una ventaja: no importa que lleves toda tu vida siendo, qué se yo, embalsamador de moscas, que si te lo tomas en serio, en dos o tres años estudiando lo último de lo último en informática, te puedes hacer con un buen puesto de trabajo bien pagado. Sin embargo es un arma de doble filo, porque si das ese paso, ya no puedes parar. En cuanto dejes de estudiar y mantenerte al día, verás como caché cae empicado. Y si te quedas anclado a una tecnología que se va deprecando, cuando quieras dar el salto verás que tu el mercado laboral no te valora tanto como esperas.

En definitiva, si das el paso de meterte en esta profesión, prepárate para afrontar actualizaciones frecuentes en tu entorno trabajo. Formación continua. En este mundillo, la máxima que tienen los budistas de que lo único constante es el cambio, es especialmente cierta.