Cambio laboral

Vaya! esto está que como muy tranquilo.
El motivo es que estoy de cambio laboral, y antes de él me he tomado unos días de asueto (que vienen genial para desintoxicar el coco y arrancar con fuerza).

Y supongo que lo seguirá estando por un tiempo... o al menos supongo no podré actualizar muy frecuentemente. Tengo que ponerme las pilas con bastantes cosas.

Por lo demas, con expectativas, pero también con inquietud. Supongo que se me exigirá bastante y hay que dar el callo. Hay 'level' por aqui, por lo que he podido ver... Se intentará no defraudar :p. Por otro lado, tengo el handicap del Inglés (idioma oficial de curro). Vamos... que lo estoy desoxidando a marchas forzadas... :pp

Y por de pronto mas nada... Decir que estoy en un proyecto interesante y en una empresa totalmete atípica para lo que es el mercado IT español; concepto de empresa americana a tope... (con sus pros y contras).

pyCitas

Tengo la impresión de que Java fue diseñado para hacer que fuera difícil escribir mal código, mientras que Python está diseñado para hacer que sea sencillo escribir buen código.

-- Magnus Lycka

A falta de un nombre mejor lo llamaré la paradoja Python: si una compañía decide escribir su software en un lenguaje poco utilizado comparativamente, serán capaces de contratar a mejores programadores, porque atraerán sólo a aquellos que se molestaron en aprenderlo…
Hasta ahora sólo unas pocas compañías han sido suficientemente inteligentes para darse cuenta de esto. Pero hay una especie de selección natural trabajando: son exactamente las mismas compañías en las que a los programadores les gustaría trabajar. Google, por ejemplo. Cuando ofertan puestos para programar en Java, también piden experiencia con Python.

-- Paul Graham

Vía eFerro de aquí.

Spring Python

Hoy me pasaba JJ un enlace, sobre Spring Python.
No sabía de su existencia...
He estado leyendo un poco. Se trata de una migración del framework Spring de Java a Python.
Por lo visto Spring fue ha sido un revulsivo en la comunidad Java, ya que puede servir como alternativa a los EJBs.

Así como las cosas mas interesantes que incorpora son AOP, IoC y MVC.
Esto me ha dado pie a empezar la mañana a leer alguna cosilla sobre AOP y IoC. Para refrescar.
En la web de Spring Python hay información,
Continuando y recordado una duda de la semana pasada he indagado un poquillo algunas cosas.
La semana pasada me preguntaron por los Arquitecture Patterns. Y tirando de memoria, tras un ejemplo, logré sacar de la manga el Pipeline. Es lo que tiene el mentar en el CV el tema de los patterns. Luego hay que apechugar...
El tema de los patrones es interesante, pero ya está muy asumido. Cuando apareción era un concepto novedoso y ahora los usas casi sin darte cuenta. Incluso que implementas las cosas usando patrone de una manera natural.
De todas formas no estaría mal, volver a echar una lectur al libro de la GoF. El problema es el de siempre, la falta de tiempo, ya hay que priorizar.

Relacionado con la Application Arquitecture tendríamos la Enterprise Arquitecture [martinfowler]. Es interesante la lectura del link anterior. Las pegas que indica de la Enterprise Arquitecture, lo he visto con mis propios ojos.... Montarte una paja mental para intentar extenderla por la compañia. Es realmente complicado.

¿Que pasa cuando estas centrado en el día a día, implementando tus movidas? Pues que es fácil irte olvidando de algunos conceptos.
Por ejemplo, ¿cuantos me podríais definir claramente lo que es un Programming Paradigm? ¿Y una methodology? ¿Y software design? ¿Y que define que un lenguaje sea OOP?
¿Lo tendrías claro en una entrevista? Deberías.
Ya para nota, ¿sabrías lo que es SoC (Separation of Concerns)?

Para cerrar el tema con lo mismo que he empezado esta divagación, enlazo un post: The case of AOP in python.
Y un par de enlaces relacionados con IoC: DI y DIP.

WebServices en .NET - curso .net (III)

Ayer estuvimos trasteando con los webservices.
Supersencillo! Pero bueno... como todas las cosas... que todo va bien mientras va bien.

Te creas un projecto del tipo servicio web, y ya VS (Visual Studio) te crea una template, con ya una operación 'hola mundo'. Lo adaptas y ya tienes tu propio servicio. Los métodos que son servicios (puedes tener en la clase, métodos que no lo sean) están etiquetados.

Posteriormente te creas otro proyecto (que puede ser una aplicación windows normal) y estableces la referencia web con el servicio y eso es todoo.

El servicio llegará un momento en que tendrás que desplegarlo en un IIS, pero VS te monta un servidor en local, donde corre el servicio.

Las dos cosas que me llamaron la atención fueron:

• Si usas clases en el servicio, en él puedes usarlas normalmente, pero desde fuera de el sólo puedes acceder a atributos y propiedades públicos (y el único constructor válido es el de por defecto; que lógicamente tendrá que tener).
• No vi ningun fichero XSD por ningún lado. Con ASP.NET, se genera un fichero .asmx, que de hecho si acceder a él en el servidor, te da información sobre los diferentes servicios y el formato de los datos intercambiados. Hay otro tipo de archivo, que se mencionó en el curso, el .aspx, que se corresponderían con los WebForms. El .wsdl ((guisdel) si que se genera. En contraposición, cuando he manejado webservices sobre java, aparte del wsdl se generaba el xsd.
  

Curso de .net (II)

Tengo pendiente algun post sobre el tema de .net. Pero antes va un minipost.

Hoy tenemos una minipractica. Va a ser interesante el volver a diseñar una miniapp con windows. Desde los tiempos en que estaba en Meta4 y desarrollabamos con VB no habia vuelto a tocar los forms de windows.

Hacer apps con C# en windows está tirado la verdad. Con la ventaja de que C# es un lenguaje muchisimo mejor que el VB que usabamos entonces...
Lo que no puedo comparar es el entorno de M$ con los de Java, ya que no he desarrollado aplicaciones gráficas en Java.

Otra cosilla que quería comentar es que con C# se puede ser muy productivo. No ya por el lenguaje. En este caso la productividad te la da el entorno.
Python es un lenguaje muy productivo por el mismo. C# puede serlo menos, pero el entorno que tienes de desarrollo hace que realmente puedas serlo.
Habría que ver cuanto mas podrías mejorar en la productividad con python con un buen entorno. No lo se, ya que no lo he hecho. Estoy acostumbrado a hacer las cosas a manubrio. Todavía aro mis campos con burro :p.

Pensando sobre lo que hizo M$ con .net, está claro que la jugada fue realmente buena. Imaginaros que no hubieran creado C# y .net... ¿Que seguirían, con VC++ y VB? Estaba claro que tenían que sacar algo... y como no pudieron adaptar Java [autonota: indagar mas esto], tuvieron que crear su propio entorno y crearon un nuevo lenguaje.

Lo único triste de todo esto es que quien esté detras sea M$, y no le interese abrir mas las cosas, y si quieres desarrollar en .Net y C# tengas que hacerlo sólo (practicamente) para Windows.
Yo ni me plantearía desarrollar para Mono, hoy por hoy.
Pero M$ no puede tener otra postura que la que tiene; de otra forma Linux le comería mas pastel.
Lo que si que gana ahora con .net es una mayor compatibilidad entre versiones de windows. Es lo que tiene el programar contra una maquina virtual.

Nota: el profe al final ya no se fue tanto por las ramas... mejor! cuando se iba la liaba parda!

Corrigiendo nif/cif/nie en django

Abrí un ticket sobre este tema, pero me lo marcaron como dup, ya que existía otro, el 10204.
El 10204 tiene un parche, pero es erroneo. Como estoy metido en estos fregaos y la corrección es trivial he subido otro parche.

Ha sido mas coñazo montarse el tema para corregirlo que realmente hacer la corrección.
Para ello hay que bajarse el código del repositorio.

Como las pruebas las voy a lanzar con los tests de regresión es necesario preparar para ello el entorno. Aquí de dicen como.
Como fichero de settings, me hice una copia de .../conf/global_settings.py modificandolo según indican aquí (usé la primera entrada).

Una vez creado el fichero, me creé las siguientes variables de entorno:

export PYTHONPATH = $HOME/.../django/trunk
export DJANGO_SETTINGS_MODULE=tests.cesar_settings

Según lo anterior, el fichero cesar_settings.py lo metí en .../django/trunk/tests.

Para ejecutar los tests de mi interés hice:

runtests.py -v 2 forms

Que ejecuta muchos tests, a pesar de que a mi sólo me interesaba trunk/tests/regressiontests/forms/localflavor/es.py.
Tengo que indagar como ejecutar sólo eso si es que se puede....

Ya para acabar, indicar que algo mas de curro se puede hacer sobre lo que hay en django/contrib/localflavor/es.

Validación nif/nie y cif

Tenía que implementar un algoritmo para localizar nif/nie y cifs en texto, y de paso comprobar que eran validos.
Como tengo costumbre pasaba de reinventar la rueda, pero la única implementación que encontré era erronea.
Pregunté en la lista de python-es.
En el hilo podeis ver una implementación que hice, y lo que me pasó Jesus y la implementación de django.
Tanto la implementación de Jesus como la de django son mas pythoneras que la mia, pero la mia funciona :p.

En django actualmente hay un ticket abierto para corregir la implementacion, el 10204.

En la wikipedia está muy bien cubierto el tema. Lo único que no comentan es sobre el caso de un NIE que empiza con la letra T. Lo único que he encontrado es:

"La ley establece que el NIF, en caso de personas físicas extranjeras con documentación del pais de origen podrá sustituirse por el número de identidad válido en su país de origen, precedido por una T. Por tanto y de cara a la validación: TODO NIF QUE COMIENCE POR T ES VÁLIDO, dado que el resto del NIF se rige de acuerdo a la legislación propia de cada país"

Se podría considerar que un NIE que empieza con T podría ser valido si sus 8 caracteres siguientes están en el set [A-Z0-9], pero no lo podriamos validar, ya que el algoritmo de validación lo desconoceriamos. No creo que esto ahora mismo se use...
Yo no los aceptaría, en principio, a no ser que realmente hoy en dia, todavía se de el caso.

Una implementación que he visto muy copiada es la de bulma. Lo mas interesante de la misma es la codificación del valor de retorno. Si el valor es <=0 estamos ante un cif/nif/nie invalido.
En caso contrario es válido y ademas nos indica ante cual de ellos estamos por el valor (0,1 o 2).

Va a estar divertido el curso de .net

No por el curso de .net, que será un truño, sino por las tertulias que vamos a mantener con el profe. Lo estoy viendo...
Antes de entrar en el tema, linkeo un post relacionado de Sergio Montoro.

Estaba muy desconectado del mundo Microsoft, pero ya me voy enterando, que si codeplex, team system, estado de mono, sharepoint, silverlight, ...

Bueno... volvamos al tema del curso.
El curso nos lo da un formador interno, teoricamente arquitecto o consultor en tecnologías .net.
Pues bien el susodicho puede que controle de .net, que ya lo iremos viendo... pero ha demostrado un desconocimiento del mundo del Open Source, y tener unas ideas sobre el desarrollo del software en general, que me hacen sospechar que tiene los pies de barro... Ya iremos viendolo, que puede estar divertido. Fijo, porque este es un taliban de Microsoft.

Ha tenido dos perlas hoy: la primera cuando mentó que desarrollar con Visual Studio era gratis. No puedes hacer afirmaciones como esa. Es gratis usando la versión express. Pero son versiones limitadas. Ni que fuera un comercial.

La segunda perla es cuando comentó las desventajas de usar open source frente al tener el respaldo del soporte de Microsort. Chanante! Ya nos metimos en una tertulia que duró hasta que me fuí del curso que tenía que salir un poco antes....
¿Pero como puedes hacer una afirmación como esta? Claro que está de PM el tener soporte (pero hay que pagarlo), pero el tener un soporte no te va a garantizar nada. Puede que incluso que hayas encontrado un bug ¿y que? ¿Te lo van a arreglar?
El tio comentaba una mala experiencia con una cosa que pillaron para fusilarlo en un proyecto y que luego les petaba.

• Punto 1: tu eres responsable de lo que pillas
• Punto 2: hay que saber lo que se coge. Y si coges algo que no sabes como está, pues se supone que vas a saber valorar su estado. Si coges algo como libxml2, puedes estar tranquilo que es a prueba de bombas. Sin dudarlo mejor que cualquiera de los parsers de microsoft, porque seguro que ha sido hecho con mas cariño, lo han revisado mas ojos, y está superprobado (si lo usas correctamente).
  
• Punto 3: fusilar algo que es gnu, pues ya tiene delito. Ajo y agua.
• Punto 4: de todas formas si pillas algo que no está hiperprobado, pues oye, eso que te ahorras. Da gracias. Si luego falla, pues oye, ¿no somos desarrolladores?
• Punto 5: tienes el código. Quien no ha estado pillado por los huevos y no poder hacer nada, a no ser que pagues por que quien te tenga pillado te haga un desarrollo, que sabes que se puede hacer, pero no sabes como ni está documentado. Yo si.
• Podiamos seguir... pero creo que es sufiente.

Ojo! reconozco que los productos de desarrollo de Microsoft son buenos, pero eso no quita para menosprecies el desarrollo Open Source.
Ojo! que no es oro todo lo que reluce. El Open Source tiene sus carencias: documentación, falta de soporte, ... Pero ya somos mayorcitos para saber donde nos metemos. Un poquito de por favor...

Ya para acabando, indicar que en una ppt indicaba que era multiplataforma. ¿Como puedes afirmar esto así categoricamente? Mencionaba que corría en Symbian. OK, pero seguro que es una versión limitada.
Y lo de mono tampoco sirve. Lo primero porque microsoft no está detrás. Con lo cual chungo.
Tienen implementado lo estandarizado (ECMA-334 y ECMA-335) y están intentando soportar parte de los paquetes que Microsoft no ha estandarizado: Windows.Forms, ASP.NET, ADO.NET, ...

En cuanto al tema de mono, comentar que he estado indagando y realmente hay pocas aplicaciones que lo usen. No se yo si es una tecnología para confiar. Yo según están las cosas no apostaría un duro por ello. Mas cuando la gente de gnome han creado un lenguaje, como alternativa: vala. Además hay temas chungos de licencias por medio.

Acabo este post comentado que hay un proyecto de gnu dotGNU, donde está Portable.NET.
Este proyecto está centrado en implementar las especificaciones ECMA en multiples plataformas.
Este si que me parece un proyecto interesante (si es que realmente el framework merece la pena...) y no mono. Bueno... es mi opinión.