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.