Este tipo al que veis dando la charla “The Dungeon Master’s guide to Django’s ORM” en la pasada DjangoCon era Malcolm Tredinnick, uno de los principales desarrolladores de Django y responsable de la rama Queryset-Refactor. Y digo era porque Tredinnick ha fallecido este fin de semana.

Si bien es verdad que no era uno de esos programadores superconocidos del mundo del Software Libre (los Torvalds, Stallmans e Icazas son rara avis), creo que es justo rendir homenaje a una de esas personas que han dedicado su tiempo a hacer software para todos.

Desde el 2000 empezó a colaborar con Gnome, y fruto de esos parches acabó surgiendo ScrollKeeper. Pero si hay un proyecto que lleve su impronta, ése es Django, donde no ha dejado de colaborar desde 2006 hasta pocos días antes de su muerte.

Además, Tredinnick era asiduo orador en charlas sobre Python, Django, Behaviour Driven Development, Linux, etc, que podréis encontrar fácilmente en vuestros canales habituales. Y también ha sido objeto de entrevistas que buscaban pulsar el estado de Django y otros proyectos desde el punto de vista de uno de sus protagonistas.

Por último, como me gusta pensar que los programadores somos personas que nos dedicamos a juntar ideas, dejo aquí algunos tuits señalados que el propio @malcolmt lanzó al aire:

I wish people discussing performance would stop saying “memory leak” when they mean “memory usage” and “impact of recovering unused mem”.

— Malcolm Tredinnick (@malcolmt) 12 de febrero de 2013

Dear people writing resumes, github.com is not a version control system.

— Malcolm Tredinnick (@malcolmt) 4 de febrero de 2013

Been doing this programming thing for 30 years and still sit here paralysed at “what should I call this directory?” Every. Time.

— Malcolm Tredinnick (@malcolmt) 22 de agosto de 2012

New rule: you can’t write about responsive web design if all you’re talking about is working a few different Apple products.

— Malcolm Tredinnick (@malcolmt) 17 de agosto de 2012

Protip: do not enforce your password length rules in the login form. Only at reg/change time. Trust me.

— Malcolm Tredinnick (@malcolmt) 2 de agosto de 2012

Que la tierra te sea leve, Malcolm.

Vía | Django Project – Goodbye, Malcolm

Hace unos días veíamos un inspirador vídeo de gurús de la informática promoviendo un estudio temprano de la disciplina para no sentirse perdidos en un mundo cada vez más tecnológico.

Pero nosotros no nos contentamos con eso y queremos saber qué edad consideráis idónea para iniciarse en el estudio de la programación, o si realmente es necesario que todo el mundo aprenda informática del mismo modo que ahora se pretende que todos sepan inglés desde muy pequeños. Por eso, nuestra pregunta de la semana de Genbeta Dev no podía ser otra que:

¿Con qué edad se debe aprender a programar?

Como siempre, cerramos los comentarios en esta entrada para que nos los dejéis en la zona de respuestas y podáis ser elegidos como el mejor de la semana.

Y ahora recordamos la cuestión de la semana pasada, donde os preguntabamos cómo son vuestros ciclos de actualizaciones o de subidas a producción. Según la comunidad, la respuesta más completa fue la de davloperez, que nos hacía una comparación entre el antes y el después:

En mi anterior empresa, las subidas a Producción se llevaban a cabo con la “asiduidad que los jefes querían”. Es decir, cuando ellos consideraban que era un buen momento para haber terminado un desarrollo, ponían una fecha y punto. Tanto si caía en viernes como en sábado.

En cambio, en la empresa que estoy ahora, las subidas a producción se realizan sólo cuando hay cierta cantidad de funcionalidades terminadas en entornos de preproducción, y teniendo siempre la premisa de no realizar las subidas en viernes, ni siquiera a principios de mes (que es cuando más gente hace uso de la herramienta desarrollada).

No hace falta que indique cuál de ambas alternativas prefiero.

Muchas gracias a todos por vuestra participación, esperamos vuestras respuestas. Y recordad que Genbeta Dev Respuestas no sólo es un espacio para la pregunta de la semana, sino para que cualquiera de vosotros pueda plantear sus dudas y obtener las mejores respuestas de la propia comunidad.

En Genbeta Dev Respuestas | ¿Con qué edad se debe aprender a programar?
Imagen | Flickr – Computer class

• Cuando, tras una gran actualización, pruebo la página web con IE.
• Cuando edito una porción de código que no he visto en 3 meses.
• Cuando, tras liberar una aplicación como beta, empiezan a llegar los informes de errores.
• Cuando reviso una porción de código que no comenté.

Porque no está mal saber reírnos tanto de unos como de nosotros mismos.

Página | the_coding_love();
Página | DevOps reactions

Para paletas más complejas, podemos ir escogiendo combinaciones de un color con su complementario, triadas con bajo contraste, o incluso combinaciones de cuatro colores muy diferentes pero que no duelan a la vista como suele ocurrir cuando los escogemos al azar. Luego, en la pestaña de ajuste del esquema, ya podemos variarlo hacia versiones con distinta palidez y contraste, ampliando enormemente las posibilidades.

Pero sin duda, desde el punto de vista del creador de una web o de una aplicación, lo más interesante es el poder comprobar in situ el resultado de dichas paletas de colores desde el punto de vista de una persona con daltonismo. De hecho, se muestran ocho variedades de ceguera al color, desde la deuteranomalía que afecta a 1 de cada 20 hombres y 1 de cada 250 mujeres, hasta la casi inexistente tritanomalía. Para todo aquel que quiera obtener un determinado nivel de accesibilidad, este paso debería ser obligatorio.

Y por último, decir que Color Scheme Designer nos lo pone muy fácil para utilizar la combinación de colores escogida, ya que se puede exportar a paletas de Gimp y Photoshop, muy útiles para diseñar los logos o el branding; a texto plano, a XML y, quizá la más útil para los programadores, a HTML+CSS:

/* Palette color codes */
/* Feel free to copy&paste color codes to your application */
.primary-1 { background-color: #9CC9EB }
.primary-2 { background-color: #849DB0 }
.primary-3 { background-color: #336C99 }
.primary-4 { background-color: #B7DAF5 }
.primary-5 { background-color: #C8E1F5 }
.complement-1 { background-color: #FFD8A3 }
.complement-2 { background-color: #BFA98C }
.complement-3 { background-color: #A67635 }
.complement-4 { background-color: #FFE2BA }
.complement-5 { background-color: #FFE9CD }
/* end */

Página | Color Scheme Designer 3
Vía | Meet the GIMP

Por eso, por contrapartida, siempre tenemos a alguien que intenta hacer más alegre nuestro entorno llamando a los servidores Neo, Trinity, Morfeo, Cifra… y a las ramas de desarrollo del proyecto Batman, Spiderman, Hulk… Las posibilidades son infinitas, y hoy tenemos curiosidad por conocer hasta dónde llega vuestra imaginación bautizando máquinas y proyectos:

¿Qué política de nombres usas para tus servidores, versiones de proyectos, branches…?

Como siempre, cerramos los comentarios en esta entrada para que nos los dejéis en la zona de respuestas y podáis ser elegidos como el mejor de la semana.

La semana pasada, os preguntamos si os interesa como desarrolladores probar los nuevos sistemas operativos para móviles y vimos que de forma prácticamente unánime todos ansiáis conocimiento y queréis probar uno tras otro. La respuesta más valorada fue la de nuestro compañero Pedro, que decía:

Yo estoy deseando probar Ubuntu on Phone, realmente el vídeo promocional enamora… y además las posibilidades de desarrollo pintan bastante bien.

Por otro lado Firefox OS aunque no se han pronunciado da la misma forma que el personal de Canonical (en Mozilla han hecho un par de vídeos un poco churros…) pinta muy bien, y si se consigue optimizar el renderizado de las aplicaciones web al máximo sin duda tendrá muy buen futuro.

Muchas gracias a todos por la participación, esperamos vuestras respuestas y nos leemos la semana que viene con la próxima pregunta.

Imagen | Software Libre Debian
En Genbeta Dev Respuestas | ¿Qué política de nombres usas para tus servidores, versiones de proyectos, branches…?

La biología, meteorología, sismología, medicina, psicología… requieren de la informática para tratar esas cantidades ingentes de datos atómicos y convertirlos en información, más o menos estructurada, de la que se pueda inferir un conocimiento, aplicable a dichas ciencias. Y de esa necesidad de tratar con datos surgieron los lenguajes de tratamiento estadístico, como R.

‘S’, el antepasado de R

En 1976, la mayor parte del análisis y computación estadísticos se realizaba por medio de subrutinas en Fortran, algo que era bastante tedioso. Por eso, John Chambers, Rick Becker y Allan Wilks, pertenecientes a Bell Labs, desarrollaron ‘S’ como un conjunto de bibliotecas de macros Fortran, que se convirtieron en su entorno de análisis estadístico interno.

Como eran rutinas de uso exclusivo dentro de Bell Labs, no le buscaron ningún nombre, y aunque barajaron unos cuantos, todos tenían en común lo mismo: la palabra “Statistical”. Como por aquella estaba de moda nombrar a los lenguajes con una única letra (con C como mejor ejemplo), se quedaron con la S inicial, por lo que en 1979 comenzó a conocerse como ‘S’, antes de salir por primera vez de los laboratorios Bell como un producto distribuible.

Nuevo S y S4

En 1988, se reescribió completamente S (la versión 3) en código C, siendo la primera versión parecida a lo que es hoy día. Además, se sustituyeron las macros por funciones y se modificó la sintaxis para hacerla más consistente, aunque también más estricta. También se añadieron las funciones de modelado estadístico, ausentes hasta entonces. John Chambers publicó el libro “Statistical Models in S” para documentar dicho análisis, el cual por su importancia es conocido como el libro blanco.

Diez años más tarde, en 1998 se liberó la cuarta versión, que actualmente es vigente, también denominada S4. Con un conjunto de características orientadas a objetos más avanzadas que las de S3, las clases propias del lenguaje también difieren mucho entre ambas versiones. Chambers también sacó un libro verde para documentar esta versión: “Programming with data”.

Ese mismo año, S ganó el prestigioso premio “Association for Computing Machinery’s Software System Award”, 15 años después que UNIX, 7 después que TCP/IP, 4 antes que Java u 11 años antes que VMWare, por poner ejemplos conocidos por todos.

S-Plus y los cambios de manos

En 1993, Bell Labs vendió a StatSci la licencia para la explotación comercial de S. StatSci se fusionó con MathSoft, para pasar a denominarse Data Analysis Products Division, y sacaron su versión comercial bajo el nombre S-Plus, haciendo referencia a las múltiples características que habían añadido a S (principalmente interfaz gráfica).

8 años más tarde, MathSoft se volvió a separar, rebautizándose como Insightful Corp. En 2004 adquirió la totalidad del lenguaje S y en 2008 fue comprada por Tibco, que es el propietario actual. Sin embargo, tras todos estos cambios de compañía, los fundamentos de S apenas han variado desde 1998, y sólo se han añadido nuevas capacidades.

R, el dialecto libre de S

Mientras S cambiaba de dueño y denominación, Ross Ihaka y Robert Gentleman, decidieron implementar su propio dialecto. Era 1991 cuando estos dos neozelandeses crearon R. Tardaron dos años en anunciarlo públicamente y otros dos años más en licenciarlo bajo GPL. Y posiblemente esta decisión sea la responsable de que a día de hoy R tenga cada vez más repercusión, y sea más fácil encontrar cursos y tutoriales para este lenguaje que para su predecesor.

Entre las ventajas de R, está su gran similitud sintáctica con S-Plus, lo que ha facilitado la migración de muchos usuarios, sus frecuentes versiones (es un lenguaje activo, con más de una liberación anual) y el hecho de que puede ejecutarse sobre cualquier sistema operativo convencional, e incluso en plataformas tan inverosímiles como puede ser una PlayStation 3.

Pero también tiene pegas: muy poco soporte para gráficos dinámicos o en 3D, funcionalidad basada en la demanda expresa de los consumidores (si necesitas algo, hazlo tú mismo o paga para que te lo hagan) y obligación de que todos los objetos se guarden en memoria física, con el problema que esto puede suponer a la hora de intentar cargar objetos de gran tamaño (aunque se están produciendo avances en este aspecto).

Resumiendo: R no es un lenguaje ideal para todas las situaciones, pero sin duda es uno de los más útiles a la hora de estructurar y manipular datos, especialmente grandes colecciones de ellos.

Y para que no todo sea historia y podáis ver un poco de código antes del próximo artículo de esta serie introductoria, os dejo con un hola mundo personalizado en R.

> print("Hola, Genbeta Dev")      # Hola mundo para nuestros lectores
[1]  "Hola, Genbeta Dev"

Página oficial | The R Project for Statistical Computing

Es el caso de HTML5 Boilerplate, que para su versión 5.0 propone retirar completamente el uso de clases condicionales para las versiones 6 y 7 del navegador de Microsoft. Su decisión, más allá del posible gusto de los committers por el trabajo sencillo, está basada en argumentos razonados de entre los que destaca el hecho de que Microsoft anunciase que Internet Explorer 10 no soportará comentarios condicionales.

Esto significa que habrá que adaptarse a los navegadores modernos y olvidar la poco ortodoxa detección del navegador (que se puede basar en prejuicios o gustos personales de quien desarrolla) y empezar a utilizar la detección de capacidades, que es lo que realmente importa a la hora de usar una u otra feature.

Para quien no los haya usado nunca, comentar que los comentarios condicionales son una estrategia utilizada por las distintas versiones de Internet Explorer para ofrecer código que sólo será interpretado por alguna versión. Dichos condicionales van incluidos dentro de comentarios HTML aparentemente normales, por lo que son completamente ignorados por cualquier otro navegador. Un ejemplo habitual de su uso es el siguiente, en el que se incluye una librería javascript que suple algunas de las funcionalidades carentes en la versión antigua.

<!—[if lt IE 7]>
<script src=“http://ie7-js.googlecode.com/svn/version/2.1(beta4)/IE7.js”></script>
<![endif]—>

Otro motivo para desechar la detección del navegador son los modos de compatibilidad de Internet Explorer, que hacen que por ejemplo su versión 9 se pueda comportar como tal, reconociendo los elementos de audio de HTML5, o pueda comportarse como IE5, renderizándolos como un elemento cualquiera. En ese caso, aunque el navegador real sea el mismo, es mejor preguntar directamente si existe la capacidad de reproducir ese audio:

function supportsAudio() 
{
   var o = document.createElement( 'audio' );
   return ( o.canPlay ); 
}

Si todos los desarrolladores web empezásemos a pensar de esta manera, podría suponer un nuevo avance para la guerra de navegadores, ya que dejaríamos de lado nuestras preferencias por uno u otro para centrarnos en nuestro problema: que la página haga lo que tiene que hacer. Y se agradece que desde plataformas de moda como Bootstrap o Boilerplate, se tomen iniciativas que intenten facilitar al desarrollador esta forma de trabajar.

Lista oficial de HTML5 Boilerplate | Remove IE conditional classes
Microsoft MSDN | About conditional comments
En Genbeta Dev | ie7.js y HTML5 BoilerPlate 4.0.0

Por eso conviene comprobar que hemos seguido todos los pasos de esta infografía que nos trae Blue Caribu, ya que aunque algunos pudieran resultar obvios, a menudo son olvidados. Desde la buena elección del nombre, icono, descripción y capturas de la aplicación, hasta la publicidad en medios y buscadores, pasando por la interacción del usuario, invitándole a valorar y compartir su opinión sobre tu aplicación.

Vía | Blue Caribu – Guía de Marketing para Aplicaciones

Google I/O 2012

El esperadísimo SDK para Android 4.1 fue uno de los caramelos que no por esperados tuvieron menos importancia. Más de 20 sesiones se dedicaron al sistema operativo del androide verde y a sus novedades: notificaciones interactivas, nuevas posibilidades en el uso de NFC, transiciones más rápidas mediante Vsync y una colección de nuevas APIs para mejorar la accesibilidad y navegabilidad de las aplicaciones.

También hubo nueva versión de Google App Engine, la 1.7.0, que nos trajo más espacio para nuestras cuentas, más velocidad, un cluster en Europa para mejorar el retardo en nuestras aplicaciones, geolocalización de documentos, SDK para Go…

Pero como no todo van a ser actualizaciones y nuevas versiones, Google también supo sorprendernos con uno de esos proyectos que prometen acercar la ciencia ficción al presente: Project Glass, las gafas de realidad aumentada que prometen convertirnos a todos en un Terminator capaz de analizar todo su entorno en cuestión de segundos y además comunicarse de forma sencilla con todo el mundo.

Seguro que a más de uno se os ocurre alguna aplicación que os apetece crear para Project Glass, incluso puede que alguna apta para todos los públicos (que ya me imagino en lo que estabais pensando).

Lanzamiento de Windows 8

Si un producto ha sabido acaparar buena parte de los titulares este año, ése ha sido Windows 8. Aunque nuestra bola de cristal nos hace sospechar un posible descalabro en 2013, lo cierto es que durante el año pasado dieron que hablar más que sus competidores, tanto para bien como para mal.

Es cierto, no sabemos qué grado de éxito o fracaso copará el nuevo producto de Microsoft, ya que eso dependerá de los usuarios, que son unos seres muy volubles, pero de momento la masa de desarrolladores ha decidido que ha llegado el momento de aprender a programar conforme al nuevo estilo metro modern de las aplicaciones Windows 8. Es por eso que, aparte de cubrir el lanzamiento de las versiones de escritorio y móvil, y de Visual Studio 2012, os hemos ofrecido una serie de artículos orientados a aprender a programar aplicaciones metro en Windows 8.

Y también es reseñable como evento concreto la Megathon organizada de forma simultánea en diversas ciudades españolas para crear en paralelo aplicaciones metro. También nosotros os invitamos por nuestra parte a formar parte del proceso de desarrollo de una aplicación de Genbeta Dev en Windows 8.

Estandarización de HTML5

Os hemos hablado de un congreso y de un lanzamiento, pero quizá el acontecimiento más importante de 2012 en el mundo del desarrollo ha sido el acuerdo tomado por parte de quienes parten el bacalao para agilizar la estandarización de HTML5.

Ha sido un año con muchísima actividad alrededor de HTML5 y CSS3, donde se ha intensificado de forma notable el uso e interés por el Responsive Design (nuestro compañero Pedro nos dejó una fantástica serie de artículos de introducción al diseño web adaptativo), grandes empresas como Facebook han abrazado y luego repudiado las aplicaciones web móviles (lo que sin duda servirá de acicate para su mejora) y algunas empresas más pequeñas han intentado demostrarle que es posible hacer aplicaciones HTML5 tan rápidas como las nativas.

Pero sin duda, más allá del creciente uso, la gran noticia ha sido el anuncio del acortamiento en 8 años de la estandarización de HTML5, ya que en lugar de tener que esperar hasta 2022 para que esté disponible como estándar del W3C, este mismo año se ha cerrado la definición 5.0 y se ha propuesto como candidate recommendation, con lo que en 2014 ya será un estándar perfectamente establecido.

Sin duda una gran noticia que convierte al mismo tiempo a HTML5 en lo más destacado de 2012 y lo más prometedor de 2013. Y es que en un mercado creciente, con cada vez más variabilidad de dispositivos, sistemas operativos, tamaños y densidades de pantalla, etc. nada viene mejor que un buen estándar para poder desarrollar conforme a él sin tener que preocuparse de decenas de lenguajes y sus correspondientes SDK.

Conclusión

Ésta es nuestra selección de los acontecimientos que más repercusión han tenido en la blogosfera del desarrollo en 2012, pero obviamente no son todos y seguramente a criterio de algunos tampoco los más importantes. De lo que no cabe duda es que estos tres temas han dado mucho que hablar y seguirán siendo tendencia en 2013.

La única ausencia que notamos es la de Apple, que este año no ha conseguido engancharnos con sus eventos. No cabe duda de que iOS sigue teniendo un gran tirón, pero no se puede decir que hayan anunciado muchas mejoras para los desarrolladores en 2012, sino que vive de las rentas de los años anteriores y de tener una gran plataforma de usuarios.

A ver si hay suerte y en 2013 nos sorprenden con nuevas capacidades que poder explotar y muchos eventos para desarrolladores en los que continuar nuestro aprendizaje en esta pasión nuestra que es la programación.

• Si un cambio hace que fallen programas de usuario, es un bug del kernel y nunca se echa la culpa a los programas. Linus lo denomina la “primera regla de mantenimiento del kernel”.
• Nunca se debe quebrar el espacio de usuario. Y particularmente, menos todavía para introducir mierda (perdón, cualquier otra traducción para crap sería un eufemismo).
• Y lo más importante: si no cumples las dos reglas anteriores, por lo menos procura haber usado correctamente las constantes y valores de retorno, ya que si no Linus puede hacer escarnio público de ti.

Como imaginaréis, eso es precisamente lo que hizo mal Mauro, usando la constante ENOENT (fichero o directorio no existente) como respuesta a una operación con drivers cuyos ficheros ya han sido abiertos correctamente. Eso, y culpar a las aplicaciones pulseaudio y tumbleweed de un error que probablemente había introducido él. De ahí el cabreo del dictador benevolente.

¿Quién dijo que en el Software Libre no había jefes y el trabajo es más agradable? Os aconsejo que leáis el mensaje completo para juzgar a qué hay que atenerse si tus aportaciones a Linux no cumplen los requisitos de calidad.

Mensaje original | gmane.linux.kernel