Jul 13

Seguir las reglas a ciegas

Veo esta duda en StackOverflow en la que preguntan si hay alguna forma de que los getter y setter en java se puedan generar automáticamente desde código, igual que muestra cómo se hace en Javascript. Mirando las respuestas, se llega por ejemplo a proyectos como Project Lombok, en el que poniendo anotaciones @Getter y @Setter en el atributo, los genera automáticamente.

Si vamos un poco más allá, también el lenguaje Groovy hace automáticamente estas cosas, pone en los bytecodes compilados métodos getter y setter para los atributos, de forma que podemos usarlos desde otros lenguajes como java.

Maravilloso, todos sabemos que hacer los atributos privados y poner setter y getter es una de las buenas costumbres de programación y es pecado no hacerlo, así que todas estas maravillosas herramientas lo hacen AUTOMATICAMENTE por nosotros, ahorrándonos escribir el tedioso código.

Pero creo que nos olvidamos del fondo. ¿Por qué es bueno hacer los atributos privados y poner getter y setter?. La respuesta todos la sabemos: encapsulación. Pero, ¿nos hemos parado a pensar realmente qué es eso?

Imagina un atributo privado "chisme" con su correspondiente getter y setter

private double chisme;
public void setChisme(double chisme) {
   this.chisme=chisme;
}
public double getChisme() {
   return this.chisme;
}

La ventaja de la encapsulación es que si más adelante decido que en vez "chismes" tengo "trvilorios" (todos sabemos que los "chismes" y los "trivilorios" son equivalentes y podemos obtener unos de otros) y que en vez de double, es un BigDecimal, podemos hacer esto

private BigDecimal trivilorio;
public void setChisme(double chisme) {
   this.trivilorio = getTrivilorioAPartirDeChisme(chisme);
}
public double getChisme() {
   return getChismeAPartirDeTrivilorio(this.trivilorio);
}

Y esta es la verdadera ventaja, hemos cambiado el atributo, pero mantenemos los setter y getter de chisme, haciendo las cuentas necesarias en esos métodos. De esta forma, todo el código que use nuestra clase seguirá usando setChisme() y getChisme() y seguirá trabajando con chismes y no con tirvilorios, no necesitamos cambiar nada, posiblemente ni siquiera recompilar ese otro código,  y todo seguirá funcionando.

Pero si usamos maravillosas herramientas que generan automáticamente los getter y setter, perdemos el encapsulamiento, que es precisamente el único motivo de la existencia de esos setter y getter. En el momento que cambie "chisme" por "trivilorio", aparecerán automáticamente getTrivilorio() y setTrivilorio(), pero desaparecerán, también automáticamente, getChisme() y setChisme(), por lo que todo el código que hay por ahí usando setChisme() y getChisme() se debe rehacer, recompilar…. y posiblemente hacer las conversiones de chisme a trivilorio y viceversa, o bien tocar el código que usaba chismes y ahora tiene que usar trivilorios.

Así que ojo con estas herramientas. Si queremos que el código que usa nuestra clase no tenga que cambiar y usamos estas herramientas, después de cambiar chisme  por trivilorio, debemos escribir manualmente los métodos getChisme() y setChisme() con su correspondiente conversión, manteniendo así la compatibilidad y la encapsulación. Por supuesto, setTrivilorio() y getTrivilorio() pueden y deben añadirse, automática o manualmente.

Mar 29

He leído “JavaScript, The Definitive Guide”

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.

Mar 14

Clean Code

clean codeMe 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.

Nov 11

Canción de la tabla periódica de los elementos

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

 

Sep 10

Sufriendo SAML/XACML

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.

Jan 14

¿Se deteriora Scrum?

scrumVeo 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.

Aug 20

Los Web Services y yo

web services 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.

Jun 29

.NET pende sobre mi cabeza

.netNuestros 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

Jun 28

Amortizando la web de bicicletas

bicicleta en el arbolLa 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.

Jun 17

Bicicletas a la carta

bici embarrada 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 €.