Si eres programador Java en Zaragoza estás de suerte

Hola,
Llueven las ofertas señores, allá donde miréis: infojobs, linkedin, jobandtalent… existen múltiples ofertas de trabajo para programadores y analistas Java principalmente, aunque también se aprecian ofertas para jefes de equipo y arquitectos (no muy común en Zaragoza).
Y la gente que cambia por qué lo hará? Es un tema puramente económico? Se está valorando también la proyección profesional y la formación? En qué medida? Tal vez el tipo de contrato? Realmente el proyecto en el que se va a trabajar es clave para el cambio? La marca realmente supone un peso?
Qué opinas tú? Mi opinión es que ahora mismo el estrés de demanda laboral que hay en Zaragoza en ciertos perfiles hace que la vertiente económica tome mucho peso, tanto que incluso que las personas que quieren cambiar por estar trabajando en un proyecto poco atractivo y que trasladen este motivo como su motivo principal del cambio no lo hagan sin ir de la mano de una subida salarial entre el 10 y 20%.
Lo dicho, suerte a todos, son tiempos curiosos.
Un saludo.
Miguel.

Patrón de Diseño: Memento

Me hace mucha gracia el nombre de este Patrón de Diseño, “Memento”, inavitablemente me recuerda siempre a la pelí­cula.
Memento nos ayuda por ejemplo a resolver la tí­pica problemática de máquina de estados, donde necesitamos almacenar cuáles han sido los diferentes estados que ha tenido un objeto a lo largo de un tiempo determinado.
Un ejemplo muy cercano a todos nosotros es el uso del “Undo / Deshacer” (CTRL+Z) del que disponen la mayorí­a de procesadores de texto, entornos de desarrollo… y que nos permite en un momento dado poder deshacer todos los íºltimos pasos que hemos llevado a cabo. Para hacer esto alguien se habrá tenido que acordar de lo que habí­amos hecho antes, y ese alguien es el Patrón Memento.
Os dejo link a la wikipedia
https://es.wikipedia.org/wiki/Memento_(patr%C3%B3n_de_dise%C3%B1o)
Y un link a un PDF donde tenéis una descripción más ampliada, además de un ejemplo de codificación en Java.
https://www.freewebz.com/amanecer/personal/papers/paper.memento.pdf
Un saludo.
Miguel.

Buenas Prácticas: La Importancia de los Comentarios

Poner comentarios en un código siempre se ha considerado por la mayorí­a como una labor aburrida, tediosa, poco motivante en general.
Luego está el otro extremo, los que se dedican a poner parrafadas de libro en cada lí­nea o en la descripción de los métodos.
Como siempre, los extremos no suelen ser las mejores soluciones. Lo recomendable es siempre comentar, pero a ser posible sin redactar el quijote por cada método o trozo de código. Los comentarios pueden resultar básicos para entender qué está haciendo un determinado algoritmo.
Es algo bastante natural, sobre todo para los programadores con poca experiencia, el tener la creencia de que se van a acordar de lo que hací­a el algoritmo, por lo que bajo esa premisa el uso del comentario pierde sentido para ellos. A medida que la experiencia va llegando se llegan a nuevas conclusiones:
1) Como me he encontrado código que no he hecho yo y no está comentado no tengo ni idea de lo que hace. Además, el compañero que lo ha hecho o está a tope y no me lo puede contar o justamente se ha ido una semana de vacaciones. Mira tíº por donde esto tiene que estar arreglado esta misma mañana por lo que me voy a tener que quedar comiendo delante del ordenador, así­ que, la próxima vez que programe algo que no es para mi, lo comentaré, y le diré a mi compañero que haga lo mismo.
2) Estoy solventando una incidencia y recuerdo perfectamente que el código lo hice yo, pero miro y remiro lo que hace y no me acuerdo para nada de por qué tomé esta solución. Es más, no sé ni qué hace o para que sirve esto. Será mejor que comentemos los métodos al crearlos, incluidos los parámetros que se la pasan, así­ nos evitaremos estos problemas.
3) Mira qué bien, el método está comentado, sé lo que hace por lo que voy a arreglar la incidencia en un momento. El problema viene cuando resulta que alguien cambió el comportamiento del método y no actualizó el comentario, entonces me estoy creyendo que hace lo que dice el comentario… ¿os imagináis el resultado, no? … Está bien, además de añadir un comentario al crear el método, cuando lo modifique también lo ajustaré.
Por ejemplo, trabajando con C# el añadir comentarios a método es muy cómodo, íºnicamente pulsad tres veces “/” justo en la linea de encima de la definición del método y os aparecerá la estructura xml que tenéis en el método de abajo (sin rellenar claro, la tendréis que rellenar vosotros).
/// <summary>
/// Inserta un nuevo coche
/// </summary>
/// <param name=”codigoCoche”>Identifica de forma íºnica el coche</param>
/// <param name=”nombreCoche”>nombre del coche</param>
/// <param name=”numeroPuertas”>níºmero de puertas del coche</param>
/// <param name=”codigoMarca”>identifica de forma íºnica la marca del coche</param>
public void Insert(int codigoCoche, string nombreCoche, int numeroPuertas, int codigoMarca)
{
 // código necesario para la inserción
}
La buení­sima noticia al respecto es que ahora cuando utilicéis el Intellisense de Visual Studio, al seleccionar el método os aparecerán los comentarios que habéis puesto, algo que aumentará vuestra productividad.
Para llevar a cabo la misma acción con VB.NET en lugar de usar “/” tenéis que usar “‘” (comilla simple).
Otra buení­sima noticia es que existen herramientas que a partir de los comentarios que añadais a vuestros métodos, clases, interfaces, propiedades generan documentación automáticamente. Los famosos JavaDoc en java son un ejemplo, los archivos .chm para .NET lo mismo.
Saludos.
Miguel.

ASP.NET MVC Framework. Aplicando un MVC real con Visual Studio 2008.

En el anterior post vimos un artí­culo donde se mostraba cómo trabajar con MVC + ASP.NET en Visual Studio 2005.
Para los que habéis aplicado MVC en J2EE o en Ruby on Rails os parecerá una aplicación pobre del MVC, pero bueno era lo que tení­amos en su momento para ASP.NET, y los que querí­amos acercarnos a ese modelo no nos quedaba más remedio que aproximarnos lo más posible a él con las herramientas con las que contábamos.
Ahora, con Visual Studio 2008 la cosa ha cambiado, y tenemos un tipo de proyecto que explota explí­citamente el patrón MVC en ASP.NET.
He encontrado un artí­culo estupendo que habla de ello del cual os dejo el link más abajo, y que además da la puntilla dando unos toques de LINQ.
Por cierto, atención con el modelo de convenciones que utiliza el nuevo MVC para ASP.NET, para los que conozcáis Ruby on Rails os va a resultar ciertamente familiar. Es curioso como las buenas ideas se extienden como la pólvora por las diferentes herramientas de desarrollo.
Os dejo el link:
https://thinkingindotnet.wordpress.com/2007/11/18/aspnet-mvc-framework-primera-parte/
Un saludo.
Miguel.

Buenas Prácticas: Los servicios web no deberí­an devolver tipos especí­ficos de la tecnologí­a

Tí­pico ejemplo de esta situación es un servicio web hecho en .NET que devuelve un Dataset.
Si se nos garantiza que el consumidor del servicio va a ser siempre un cliente .NET aíºn la cosa se sostiene un poco. El problema es si por ejemplo intentamos consumir un servicio que da un Dataset por otra tecnologí­a que no es .NET.
Para los que tengáis experiencia trabajando con servicios sabréis que una vez que creas un servicio que devuelve un objeto o tiene por parámetro un objeto definido en el servicio, desde el cliente que consume el servicio tenemos visibilidad sobre la definición de dicho objeto. Si yo tengo un servicio que recibe por parámetro un objeto coche, yo desde el cliente puedo rellenar dicho objeto coche y pasárselo por parámetro al servicio. Lo mismo ocurre si el coche me lo devuelve el servicio, yo puedo conocer sus propiedades y extraer los valores de las mismas.
¿Pero qué ocurre con un dataset? ¿Ocurre lo mismo? Pues no.
El principal problema de un Dataset es que en tiempo de diseño no conocemos cuál es su contenido. Sólo lo sabemos en tiempo de ejecución. Ya “sólo” por este “pequeño” problema tenemos ya un agujero del tamaño de un tonel respecto a la protección de tipos en tiempo de diseño. Podemos pedirle lo que quiera al dataset, porque el compilador no va a darnos ningíºn tipo de alarma, nos vamos a enterar en tiempo de ejecución generando una excepción si la consulta sobre el dataset no era correcta.
Este problema se vuelve más complicado aíºn si consumimos el servicio desde por ejemplo un cliente java, ya que para interpretar el contenido del dataset en tiempo de ejecución no nos va a quedar más remedio que leer el mensaje xml que nos llega con el contenido, leerlo e interpretarlo a pelo.
¿Cual es entonces mi recomendación? No es difí­cil respuesta adivinarlo si leéis los artí­culos de esta web, por mi parte está claro, Data Transfers Objects 🙂 O Value Objects, que es lo mismo 🙂
Saludos!
Miguel.