Sí, ahora que estamos con la fiebre de la 2.0, de la web social, de facebook, de twitter y de todas esas cosas para las que todavía no he encontrado utilidad, resulta que ahora los usuarios de agroguía generan y suben su propio contenido a la web.
Nosotros frecuentemente subimos videos para tener a la gente interesada y “enganchada” en cierto modo. Hay uqe tener en cuenta que el target de usuarios de esta aplicación no soy muy dados a las nuevas tecnologías (aunque más de lo que se cree y me creía debo decir. Resulta que buscando un poco por youtube sobre sistemas similares me encuentro con que un cliente nuestro se ha grabado en video usando agroguía y lo ha subido… :).
Estyo terminando algunas de las nuevas features de agroguía, en unos días subiré unos videos mostrando como funcionan… eso siempre que sea capaz de hablar despacio, no hay nada peor que grabarse y comprobar que lo que te han repetido durante años es verdad, hablo a toda leche, me como palabras y me explico mal :).
Ya lo estoy viendo, de aquí a un año los agricultores subiendo sus parcelas, con sus tiempos, sus rendimientos, intentando estar en el top10 :)
Después de unas “largas” vacaciones sin tocar el pc (apenas recuerdo donde están las teclas :) apetece leerse algún buen artículo, como por ejemplo uno de clases transaccionales en python.
Interesante artículo por varios motivos:
- La propia clase, personalmente creo que puede ser bastante útil, luego pongo un ejemplo
- El uso de introspection (o reflexion o como quiera que se llame) en python. Simple y efectivo
- La explicación, paso a paso, y el código final con sus test unitarios.
Este es el típico ejemplo de pequeña clase que se complica y que termina siendo un verdadero infierno si no se tienen claros los contratos. Personalmente he tenido muy malas experiencias con clases en teoría simples, pero que dado su uso intensivo terminan por matar una aplicación. Por ejemplo, una clase tan simple como un vector, que en resumen no dejan de ser 4 métodos, es usada en todo el código, seguramente por varias personas que no tendrán ni idea de como está implementada (con razón), de la cual se pueden sacar unas cuantas “condiciones de contorno” que pueden hacer que la aplicación fracase estrepitosamente ya que cada persona puede decir: “es que yo pensé que funcionaba así”
En cuanto a la clase transaccional, se me ocurre un uso muy práctico. Estamos acostumbrados a ver diálogos wizards y configururaciones en todas las aplicaciones. El usuario cambia valores, toquetea y al final pulsa sobre ‘Ok’ o sobre ‘Cancel’. El planteamiento de la lógica del diálogo podría ser el siguiente:
- al comienzo del diálogo se hace una copia de los datos.
- se modifica la copia en función de los eventos de usuario
- si el usuario acepta, se vuelcan los cambios que están en la copia en los datos originales.
Queda mucho más elegante el siguiente funcionamiento:
- se modifican los datos (que implementan el modelo transacional) en función de los eventos de usuario.
- si el usuario cancela se hace rollback.
Pero es que además, con este modelo tenemos solucionado el típico undo que tantos quebraderos de cabeza da de forma “transparente” (de hecho implementa el típico patron memento). Si unes esto a una serialización como dios manda ya tienes solucionado medio modelo de datos de la aplicación :).
Eso sí, la clase tiene varios problemas, por lo menos dos que yo vea:
- si hay atributos muy pesados en 4 commits te has zumbado unos megas de ram y estos lenguajes dinámicos no son precisamente ahorradores en este aspecto
- a poco mal que hagas el modelo de datos habrá variables que no te interese, perdón, que no deban guardar el estado. Pasa exactamente lo mismo que con la serialización.
Lo bueno que tiene hacer de comercial es que a veces te encuentras con cosas curiosas. Resulta que el otro día fui a Barruelos del Valle (google maps) y curiosamente el agricultor interesado era el alcalde del pueblo. Charlando con él acerca de algunos temas técnicos, salió el tema de los aeorgeneradores aprovechando que al lado había un parque eólico y le pregunté para qué servían esas luces que tienen en la parte superior.
Resulta que cada molino tiene una luz que parpadea periódicamente y la verdad es que incluso a plena luz del día ya se veía con claridad. El chico me comentó que de noche era un verdadero infierno, que se hacía de día cada medio segundo… No me lo creía hasta que he podido comprobar que desde mi pueblo, a unos 50kms, (y más lejos) puedo ver las luces. Si pasas por la A-62 o la A-6 lo podrás ver desde bastante lejos.
Otra cosa que me llamó la atención es que las luces de los aerogeneradores están sincronizadas. Lógicamente nadie se gasta dinero en sincronizar las luces para nada. Según me comentaron, estas luces se usan como faros para loa aviones. Cada parque eolico tiene un periodo diferente, de forma que viendo los periodos es posible “triangular” y saber donde se está.
Una curiosidad técnica y un martirio para los habitantes cercanos al parque.
Java no me gusta y no me gusta por muchas cosas que ya he comentado, odio ese quiero pero no puedo, ni es totalmente dinámico ni totalmente dinámico, ni es multiplataforma ni deja de serlo… y es que java ahora mismo está a medio camino entre C++ y otros lenguajes de alto nivel como python, ruby o C#.
El caso es que llevo unos días trabajando con python para diferentes tareas de administración y automatización y te me doy cuenta que soy mucho más productivo y puedo dedicar el tiempo a otras cosas que no sean poner try catch, casts e interminables líneas para crear una simple lista.
A nadie que tenga cierta experiencia en programación se le escapa que las listas, maps, sets y demás son estructuras de datos básicas, que se usan para casi absolutamente todo y por tanto que el lenguaje los tenga “siempre a mano” y mantenga cierta simplicidad en su uso es vital. Por ejemplo, en java para filtrar una lista tienes lo siguiente:
void filter(List src) {
List li = new ArrayList();
for (Type t: src) {
if( t != null)
li.add(t);
}
}
Menudo coñazo, es que dan ganas de morir según lo tecleas… la misma cosa en python:
li = [t for t in src if t != None];
Una cosa tan simple se convierte en algo tedioso, cuando tienes que hacer bastantes operaciones con listas, maps, etc, ya es el súmun. Y no se trata de apelotonar todo en una línea, al final eso es una bomba de relojería para un proyecto, pero tampoco estamos hablando de un tema complejo, es una simple lista que usamos para absolutamente todo. Ya no digo nada cuando veo frameworks como ruby on rails, con el que recientemente he tenido algo más de contacto.
Mañana hace ya un año que entré a trabajar en Unkasoft. El resumen del año es muy positivo, he aprendido mucho, he conocido a gente muy buena, he cumplido uno de los sueños que tenía desde pequeño, trabajar en una empresa de videojuegos y un montón de cosas más.
Lo mejor de todo es que la cuerda no se acaba, todos los días sugen cosas nuevas que investigar y que desarrollar, algo que considero fundamental en una empresa y que tendré muy en cuenta a lo largo de mi vida profesional. Si de algo me ha servido este año es para darme cuenta de que es imprescindible tener retos y metas que sirvan como alimento diario, además de estar en un entorno que lo favorezca.
Nada, lo dicho, a jugar con el móvil se ha dicho… ehh!! que es gratis!!