Diario de Programación

Hace un mes aproximadamente terminé de leer "JavaScript, The Definitive Guide". Un libro sobre JavaScript y alrededores que me ha encantado. Aparte de JavaScript, trata bastante bien temas como JavaScript en un navegador web, una introducción a node.js y rhino en el lado del servidor, AJAX, jQuery, almacenamiento local en el navegador, Canvas de HTML5, …

Son un montón de páginas, 1100 nada menos, pero aproximadamente la segunda mitad son una guía de referencia de las funciones de JavaScript, por lo que de lectura es aproximadamente la mitad.

Comienza con los principios de programación en JavaScript desde cero, el típica capítulo de introducción al lenguaje que no aporta demasiado a casi nadie, demasiado rápido para el que no sabe nada de programación, pero demasiado trivial para el que sabe programar en otros lenguajes. Aun así, dentro de esta parte, he encontrado una pequeña joya para alguien como yo acostumbrado a otros lenguajes y es todo el tema de cómo se hacen conversiones de tipos automáticas, sobre todo en los condicionales, es decir, cuándo una variable independientemente de su tipo (string, numérico, un objeto,…) se considera que es true o false.

Sin embargo, luego empieza a meterse en profundidad en montones de temas variados de JavaScript y aquí es donde algún programador experto en otro lenguaje pero sin demasiado conocimiento de JavaScript, empieza a disfrutar del libro. Por supuesto, hay temas demasiado farragosos como para que sea agradable leerlos, pero hay otros que me han parecido geniales, tanto por lo que supone aprender cosas que no sabes, como por la forma de exponerlas.

Entre los primeros, los farragosos, está la parte de orientación a objetos en JavaScript, clases, herencias, polimorfismo a base de tipado tipo pato, También la parte de eventos en los navegadores web es pesadita, más que nada porque cada navegador es de su padre y de su madre y no hay acuerdo en los eventos que se producen, cómo se llaman y cuándo se producen. El libro no puede hacer mucho más que dar una lista con una breve descricpción de cada uno de ellos.

Sin embargo, entre las partes geniales, me ha encantado la forma de explicar las expresiones regulares, tanto, que he hecho mi propio tutorial de expresiones regulares en JavaScript siguiendo esa forma de explicación, por supuesto, donde esté el libro que se quite cualquier tontería que haya podido hacer yo. También me ha encantado la forma de explicar jQuery, todos sus apartados, desde los selectores para buscar y modificar elementos de nuestro HTML, como la parte de AJAX, efectos especiales como fadeIn() y fadeOut(), …

En fin, totalmente recomendado para aquel que ya ha empezado a programar cosas en JavaScript pero necesita profundizar y comprender más el tema.

Me acabo de casi terminar "Clean Code", de Robert C. Martin. Posiblemente lo he leído muy tarde, puesto que casi todo lo que se cuenta ya me sonaba de haberlo leído en otros libros o resúmenes, por lo que no me ha aportado nada especialmente nuevo.

Trata principalmente de cómo hacer un código legible para otros programadores, de forma que no necesiten gastar mucho tiempo navegando por él para entenderlo y puedan abordar fácilmente las posibles modificaciones o mejoras que tengan que implementar.

En los primeros capítulos nos cuenta las reglas más o menos conocidas por todas: nombres largos de clases, métodos y variables, lo suficientemente descriptivos, tratar de que no sean necesarios los comentarios por el código lo suficientemente claro y eliminarlos, evitar listas interminables de parámetros en los métodos prefiriendo realizar más métodos con nombres más descriptrivos pero con menos parámetros, etc, etc. Una regla si me ha llamado especialmente la atención y es la de tener las clases a distintos niveles de profundidad en la lógica del programa, es decir, debe haber clases de alto nivel con vocabulario muy cercano al usuario y clases de más bajo nivel con vocabulario muy cercano a los programadores pero, lo más importante, es no mezclar ambos vocabularios en una misma clase.

La segunda parte del libro es muy farragosa. Pone código real de ejemplo sacado, por ejemplo, de Fitnesse, JUnit, … y se dedica a mostarnos, paso a paso y con detalle como se puede ir mejorando ese código a base de refactorizaciones pequeñas para dejarlo más entendible. Lo realmente importante de esta parte no son los pasos que se van dando en sí, aunque siempre se aprende algo de alguno, sino el hecho de que el código se deba refactorizar no sólo para evitar duplicidades en él o reorganizarlo de otra manera mejor, sino símplemente por el hecho de hacerlo más entendible. Como el autor dice, "el programador que da su código por finalizado cuando funciona no es  un buen programador. El buen programador dedica tiempo a arreglar su código para que sea entendible por otros". Y por entendible se entiende que otro programador pueda entender qué hace el código sin tener que andar entrando en todas y cada unade sus clases y métodos.

En cuanto a la tercera parte… me la he saltado. Tras el cansancio de la segunda y ver que empezaba a meterse con problemática concreta de determinados códigos (Threads en concreto), me dio la pereza y pasé a otro libro.

Cosas de ver la serie "Navy, investigación criminal"

Pues me ha tocado implementar web services seguros, y es requisito que se usen los protocolos SAML/XACML … y ahí empiezan los problemas.

Lo primero, buscar por google qué eso. Tras un rato de búsqueda acabas haciéndote una idea por encima de qué es.

Según SAML, cuando un cliente llama a un webservice debe añadir en el XML correspondientes a la llamada un token (un número de esos largos y crípticos) que luego el webservice es capaz de identificar como válido para permitir o no la llamada. Por supuesto, el cliente debe conseguir ese token de un gestor de identidades o algo parecido.

Con XACML el webservice consulta en un sitio si el cliente concreto que ha sido validado con SAML tiene o no permisos para acceder a determinados webservices, métodos de los mismos o incluso campos de datos.

Así que la idea básica está relativamente clara (con algunas dudas que me quedan todavía), pero hasta ahí el trabajo fácil. Llega el momento de implementarlo … y te encuentras con el caos.

Por un lado, hay dos mil librerías, frameworks y servidores varios que te ayudan a implementar todo esto de SAML/XACML. Unos a nivel bajo, otros soluciones más o menos completas. Googleando te pierdes en ellos, mirando su documentación, sus ejemplos y sin acabar de ver si te valen o no, si necesitas todo o solo parte o si falta algo. 

Al final te decides por uno y dices, vamos a probar. Y llega el segundo caos. Te montas un webservice básico y empiezas a descargarte la herramienta/libería. Luego las dependencias de esa herramienta/libería. Luego un servidor de no sé qué. Luego el plugin de no sé qué para el tomcat, luego borras una librería incompatible con la otra y buscas la alternativa … y después de un día de montar y desmontar tienes una "cosa" que al arrancar da excepciones por todos lados.

En fin, todas estas cosas tan avanzadas tienen un alto precio de aprendizaje. Y la información de google o bien es demasiado básica (conceptos generales), o bien demasiado detallada (referencias y documentos de centenares de páginas) o bien demasiado centrada en un aspecto concreto (pequeño tutorial de como usar una librería concreta de SAML con jax-ws presuponiendo que tienes montado todo lo demás).

Sigo en ello.

Veo que Scrum está dando fuerte. En nuestra empresa, aparte de nuestros intentos de hacer Scrum, hay otros departamentos que también lo están intentando. También conozco gente en otras empresas con las que colaboramos que están empezando a usarlo. Pero no solo es eso lo que me llama la atención ("frikis" los habemos en todos lados)

Por un lado, en la portada de nuestra intranet, que la empresa aprovecha para poner lo maravillosa que es, los proyectos que tiene y lo bien que va, apareció hace unos días un artículo en el que nuestra empresa y otra habían colaborado para la implantación de Scrum en los procesos de no sé qué.

Por otro, ha caído en mis manos (de forma completamente legal) una oferta técnica de otra empresa para el desarrollo de un sistema … y en él ponen que usarán redmine … y Scrum como metodología de desarrollo.

Todo esto tiene su parte buena … y su parte mala.

La parte buena es que Scrum está ganando la suficiente fama de ser una buena metodología de desarrollo como para que las empresas empiecen a considerarlo como algo bueno, que merece la pena intentar. Lo ponen en su propaganda, en sus ofertas, …

Lo malo es lo de siempre, que se acaba desvirtuando el fondo real que hay detrás de la metodología. Al convertirse en algo "bonito" para poner en papel, se pondrá "usamos Scrum" por sistema, se use bien, se use mal o no se use en absoluto. El cliente no conseguirá siempre los resultados esperados de esta metodología y acabará perdiendo su fama.

La verdad es que estoy un poco hasta las narices de las mentiras empresariales, "vende-motos" y palabras rimbombantes. Conseguir un premio a "la excelencia empresarial" es muy fácil, sea lo que sea eso, pero todos los curritos sabemos que lo que hay detrás es cualquier cosa menos "excelencia". La "garantía de calidad", sea lo que sea eso, tres cuartos de lo mismo. Tener la "certificación ISO no sé qué", sea lo que sea eso, igual. Y dentro de nada, ser "Scrum certified" será algo (sea lo que sea) que no sabremos que es, pero que pagando se consigue.

 Sí, se que ando de vacaciones, pero por suerte para mí, soy de los que todavía les gusta su trabajo y, aunque no estoy trabajando, sí ando "revolviendo" en cosillas que me resultarán útiles más adelante. En concreto, en varios proyectos en los que es posible que participe se usan o se van a usar Web Services. A aprender me toca, sobre todo teniendo en cuenta que es posible que en uno de ellos sea yo el que tome la decisión de qué herramientas/tecnologías usar. Y en ello ando estos días, entre playa y terrazita, leyendo y jugueteando con los Web Services.

Aunque en el proyecto se nos aconseja el uso de .NET, yo soy más partidario de Java, básicamente por tres motivos:

• Es el lenguaje que conocemos todos los desarrolladores del grupo. De usar .NET, tendríamos un tiempo de aprendizaje mayor: los Web Services y el lenguaje.
• En Java casi todo es gratis, con el consiguiente ahorro de licencias, tanto de desarrollo como de los servidores.
• .NET nos limitaría a servidores Windows, mientras que Java nos permitiría desplegar en cualquier servidor, Windows, linux, solaris, …. Sé que está el proyecto MONO, pero no veo la necesidad de meter más complejidad al asunto.

En cualquier caso, no dudo que con .NET se puedan hacer perfectamente Web Services igual que en java, posiblemente más fácilmente integrados con otras cosas de Microsoft, pero no veo ninguna ventaja clara en lo que es estrictamente el lenguaje de uno sobre otro.

El siguiente tema es si SOAP o REST. En principio, por lo que he ido leyendo, me inclino por REST. Aparentemente es más simple y parece ser que es la nueva tendencia. Posiblemente me decida por REST, pero le veo/tengo un par de pegas/dudas.

• Al ser más nuevo, me da la impresión de que está menos soportado por los servidores/herramientas actuales. Muchas de las herramientas traen como coletilla "soporte para REST". Siempre es un riesgo meterse en algo reciente.
• De la misma forma, me da la impresión de que toca codificar más. En SOAP creas tu WSDL y aunque no he buscado con detalle, me da la impresión de que hay miles de herramientas que te generan el código tanto de la parte cliente como de la parte servidor para el uso del Web Service definido por ese WSDL. En REST posiblemente haya equivalentes, pero al ser más nuevo, seguro que hay menos o están menos desarrollados. Insisto, no he mirado en serio, es sólo la impresión que me ha dado en una búsqueda superficial.

Otra gran duda es el tipo de librerías a usar para el Web Service. He visto herramientas como Restlet, (es con la que estoy jugando), pero da la impresión de ser algo muy simple para aprendizaje, no tengo muy claro si puede servir para un servidor en producción con fuertes requisitos de seguridad. También hay cosas como JAX-WS o como Jersey, pero el verlos debajo de GlassFish y sobre todo el primero, debajo de Java EE, me da la impresión de que sería matar moscas a cañonazos. Nuestro proyecto sólo tendría unos pocos Web Services y con datos no muy complejos, aunque sí bastante trasiego.

Finalmente, está el tema de elegir servidor, hay cosas como Spring Web Services, Apache Axis 2 o cosas más tradicionales como Jetty, Tomcat o servidores más "bestias" como Glassfish o JBoss. Por un lado, las ganas de aprender me tiran a Spring, pero el irme a algo conocido me tira por Tomcat. Como he comentado, Glassfish o JBoss me parecen excesivos para lo que pretendemos.

En fin, sigo investigando y haciendo pruebas, pero cualquier sugerencia de gente con experiencia por estos lares, es bienvenida.

Nuestros proyectos suelen ser de larga duración (dos años los que menos) y cuando empezó la crisis a nuestro departamento no le afectó mucho, teníamos proyectos y trabajo para alrededor de dos años. Pero dos años después empezamos a sufrirla, los proyectos están terminándose y durante este período no se han contratado más. Así que andamos buscando trabajo en otros departamentos de la empresa y van cayendo algunas cosas, y proyectos que no son "como siempre".

El banco automático de pruebas que me cayó en su día es uno de esos proyectos de otros departamentos. Su duración prevista era de unos tres meses y debo tenerlo terminado en Julio. Mi parte de software va bastante bien, pero el banco lleva mucho hardware (instrumentación electrónica, conectores, cables, aparatos variados, incluso un "armario" para montarlo todo) y creo (sé seguro) que todo eso van a retrasarse. Supongo que tengo trabajo de integración con todo ese hardware al menos hasta Septiembre. El lenguaje de programación para el banco lo elegí yo y pensé en LabWindows/LabView, pero visto el corto plazo y que el protocolo SCPI de control de instrumentación es bastante simple, decidí hacerlo en java.

Y pasado Septiembre … ya me tienen buscado otro proyecto. Este es en .NET, así que me toca aprender un lenguaje nuevo. Espero sólo un par de cosillas:

• Que me metan en el proyecto a un nivel de "currito", de forma que pueda programar y aprender .NET. No sé qué me han comentado de requisitos y zarandajas varias, así que me veo más con el Word que con el .NET. Bueno, en ambos casos es Microsoft.
• Que el proyecto dure lo suficiente (fecha prevista Septiembre de 2011) como para aprender bien .NET. Supongo que podré hacer cosas en .NET en cuestión de semanas, pero sé por experiencia que pueden pasar años hasta que aprendes a hacer las cosas correctamente y ni aún así, siempre estás aprendiendo. De hecho, esta frase "
  Sigo pensando todo de nuevo mil veces y todavia encuentro mejores maneras de hacer lo mismo. Creo que ya tenemos todas las soluciones al igual que lo creia 8 años atras" del blog de Lucas Ontivero creo que refleja perfectamente lo que quiero decir.

Ya me veo añadiendo un apartado en algún sitio de esta web sobre .NET

La aplicación de bicis a la carta que le estoy haciendo al de la tienda de bicis todavía no está en marcha, falta básicamente subir un catálogo de piezas y clasificarlas (depende más de él que de mí), aparte de arreglillos/añadidos que vaya haciendo. De todas formas, ya he empezado a amortizarla.

El otro día se me ocurrió dejarle la bici a mi hija de 13 años y se ve que se le cruzó un árbol en el camino y se dio contra él. Un rasguño en el brazo, uno de los cables del freno a la porra, tirita a la niña y la bici a la tienda.

Pues nada, le ha cambiado el cable del freno, la probó, le cambió también los cables de los cambios, un buen engrase, la ha tratado con cariño y me ha hecho un buen descuento: no me ha cobrado. Voy a tener que ir poniendo alguna cosa más en la web.

 Soy aficionado a salir en bicicleta los domingos y llevo varios años haciéndolo. Pero a diferencia de otros muchos aficionados, no soy en absoluto aficionado a la bicicleta en sí misma. Cuando llego de uno de mis paseos, la cuelgo en la terraza y me olvido de ella hasta el siguiente Domingo. No la engraso, ni la limpio, ni la miro. En cuanto tengo cualquier problema más allá de un pinchazo, suelo llevarla a una tienda de bicis de barrio. El dueño es muy amable y se ha ganado mi confianza desde la primera vez que fui por la tienda, después de llevarme un cabreo con los del Decathlon.

En cierta ocasión vi que la tienda tenía una página web, así que en una de mis visitas se lo comenté. El dueño me dijo que no andaba muy contento con los que se la habían hecho y que si yo sabía algo de eso, que le hiciera un presupuesto para llevarle yo la página web. Bueno, no es lo mío, sólo llevo la mía por hobby, tampoco soy autónomo así que no podría darle factura y encima soy vago. Una cosa es "jugar" con mi página web cuando tengo ganas y otra es comprometerme a algo. Así que lo dejé correr. De esto debe hacer ya cerca de dos años.

Pero hace poco volví a visitar la web y vi cosas que no me gustaron nada. Enlaces internos rotos, fotos que no salen y la página muy parada, en dos años apenas había nada nuevo. Así que le envíe un correo al dueño diciéndole que podía arreglarle la página y que siempre que fueran cosas puntuales y sin mucho trabajo, no le cobraría. Me conformaría con algún descuento/regalo en los arreglos que me fuera haciendo en la bici. Vaya, un trueque. Así que quedamos para un café … y me llamaron la atención varias cosas.

Lo primero es "hacer negocios" con gente de un negocio totalmente distinto al tuyo. Si le pregunto con quién tiene contratado el dominio y el hosting o cómo accede al panel de control, pues pone la misma cara que cuando él me comenta a mí que en una bici a medida se seleccionan unos treinta tipos de piezas y que la junta de la trócola no forma parte de ellas.

Y por otro lado, yo iba con mi idea de arreglarle un poco la página, ponerle un os-commerce para que tuviera un carrito de la compra o incluso un foro en el que la gente pudiera preguntarle on-line si tiene tal o cual pieza, cuánto tardaría en conseguirla o el precio. Pues bien, no tiene tiempo para atender el foro adecuadamente y lo del os-commerce le da igual porque casi todas las tiendas de bicis tienen y el que compra on-line al final se va al más barato, que suele ser alguna gran superficie. El lo que quería es algo que muy pocas tiendas de bicis tienen y es que un cliente pueda hacerse una bicicleta a medida, eligiendo las piezas del catálogo y hacer el pedido sobre ello. Es más, tampoco quiere que esa aplicación esté abierta al público en general, sino que sólo puedan acceder ciertos usuarios a los que él dé de alta y que hayan pasado previamente por la tienda, es decir, clientes conocidos.

Así que me pareció entretenido y a ello me he puesto. Llevo ya un par de semanas a ratos libres desempolvando mi php y me he creado un proyecto de bicis a la carta en GitHub, donde he subido una primera versión, más o menos funcional, pero todavía con faltantes y algunos ideas pendientes. A la vuelta del verano le llevaré mi bici para que le haga una revisión general por debajo del barro que tiene acumulado desde el invierno.

Por cierto, entiendo que sólo le interesen esos pocos clientes conocidos que "suelen" comprarle bicis a medida. Jugando con la aplicación y un catálogo real, haciendo bicis de forma aleatoria, no me ha bajado ningún precio de los 2000 €.

 Una pequeña estupidez. Cuando empezamos a teclear algo en google para buscarlo, se nos abre un desplegable con las frases que más hay en la web, de forma que si vamos a buscar lo "normal", lo tenemos más fácil. Pues bien, si vamos tecleando "tengo 1….", vemos que las preocupaciones de la gente de diez años para arriba van todas por el mismo lado

Lo que me gustaría saber es si realmente hay tanta gente que busca "tengo 13 años y mi papa me pego porque me arrestaron por borracha stoy muy molesta". Creo que google a veces se lía un poco con tanto dato.

Visto en Emezetablog.