Burdjia

Etiqueta Ingeniería software, 6 entrada(s)

Feed Rss, Atom

Rosetta

Ha sido una de las noticias del año: el periplo final de la sonda espacial Rosetta a su encuentro con el cometa 67P/Churyumov–Gerasimenko.  Toda una odisea, pero no voy a comentar su importancia científica, sino otro tema.

Según leo en Glooscap Software y en Club Delphi, varias aplicaciones de control de la misión están desarrolladas con Delphi, es decir Object Pascal.  Sí, señores profesores españoles de programación e ingenieros españoles enamorados de C#, Go, Python y demás zarandajas:  Un proyecto de más de mil millones de €uros confía en un lenguaje de programación que, según ustedes, está muerto y enterrado desde hace décadas.

¿Y a qué viene esta gratuita descalificación?, se preguntará alguno.  Pues a que de vez en cuando, en algún foro, nos encontramos con alguien que tiene problemas, y resulta que el principal es que usa el Turbo Pascal 1.0 en lugar de cualquier compilador más moderno, por lo que termina (y con razón) renegando de él gracias al nefasto ejemplo que le ha dado el profesor.  No es un problema nuevo, ni de crisis, sino de no ver lo que hay, de cerrarse y creerse leyendas urbanas.

No lo vas a necesitar

Esto es algo que tengo en mente desde hace tiempo, pero hace poco lo he visto plasmado en un libro sobre programación, concretamente en Game Programming Patterns, que trata el tema de los patrones de programación.  Este es el texto concreto:

Some folks coined the term “YAGNI” — You aren’t gonna need it — as a mantra to use to fight this urge to speculate about what your future self may want.

Game Programming Patterns - Bob Nystrom

La verdad es que es muy simple.  Cuando trabajas en un proyecto, cualquiera, estás solucionando problemas, muchas veces futuros problemas que no te has encontrado.  Es en estos "futuros problemas" donde aparecen los ysis y los porsiacas, así que según vas diseñando y programando pasas una buena parte del tiempo analizándolos y buscando soluciones que no sabes si vas a necesitar algún día, porque no es lo que necesitas ahora.  Y la experiencia, no sólo mía sino la de miles de programadores en todo el Mundo, dicta que estos ysis y porsiacas rara vez se convierten en problemas reales.  Así que al final casi siempre terminas con una obra maestra que está plagada de funciones y estructuras que rara vez, si no nunca, van a ser utilizadas por alguien.

Aquí es donde aparece ese YAGNI (o NLVAN - No lo vas a necesitar).  Este mantra, como lo llama Nystrom, nos recuerda el párrafo anterior, y que por lo tanto la mayoría de las veces no merece la pena perder el tiempo en ello.  Si el problema es real, y lo necesitamos ya, entonces sí hay que programarlo, pero si no, pues no.

Precisamente los proyectos que tenemos ahora en marcha son lo suficientemente complejos como para ser caldo de cultivo ideal para ysis y porsiacas.  Es más, uno de ellos, xMAP, está siendo reescritos porque la complejidad creció más de lo necesario y me vi atrapado en mi propia creación sin poder hacer lo que realmente quería.  Por eso os recomiendo que vosotros también hagáis vuestro el YAGNI, no sólo en programación, sino en cualquier proyecto.

Ingenieros incomprensibles

Hay ocasiones que no entiendo muy bien qué pasa por la mente de los ingenieros informáticos.  A veces hacen cosas rarísimas, subterfugios incomprensibles, complicándose la vida a ellos y a los demás.  Supongo que serán los porsiacas, esos trozos de código que pones por si acaso lo necesitas, pero que en el 99'99% de las ocasiones no hacen otra cosa que ocupar espacio y complicar el código, porque nunca lo necesitas.  O tal vez sea el Si algo funciona, no lo toques aunque haya salido una versión más nueva y más mejor.  O quizá sólo sea que tienen una mente retorcida y aviesa.

Por ejemplo, el otro día estoy leyendo un artículo en una web, el cual tiene un vídeo inclustado.  Sin embargo, resulta que en vez del vídeo se ve un rectángulo negro.  Vaya.  Abro las propiedades de Gnash y me encuentro con esto:

¿Problemas con el vídeo?  No: Problemas con Flash.

Me encuentro con que usa la versión 2 de la máquina virtual de Flash.  Lo curioso del caso es que se trata de un vídeo de YouTube, y esos vídeos he podido verlos sin problemas siempre.  Así que copio el identificador del vídeo, voy a la página de YouTube, busco y encuentro el mismo vídeo, el cual puedo reproducir sin ningún problema.  Así que abro las propiedades para asegurarme de que se trata del mismo vídeo, y ver si existe algún parámetro diferente en ambos casos.  Esto es lo que me encuentro:

¿Problemas con el vídeo? No, ¿y con Flash?  Tampoco

Veamos, una persona ha escrito un programa en Flash para reproducir vídeos, y lo ha hecho de forma que que si se ejecuta dentro de la página de YouTube usa la versión 1 de la máquina virtual, mientras que si lo hace fuera de YouTube usa la versión 2.  ¿Por qué?  ¿Qué objetivo tiene ese comportamiento?  ¿Qué ventajas tiene?

Se me ocurren varias razones por las que suceda esto y ninguna me parece buena.  La más lógica es que haya dos reproductores diferentes, uno para usarlo dentro de YouTube y otro para usarlo fuera.  Esto me parece incluso lógico, para que dentro de YouTube pueda comunicarse con la web, pero aun así, ¿por qué uno usa una versión y el otro otra?

Lo dicho:  no entiendo muy bien lo que pasa dentro del cerebro de los ingenieros informáticos.

Busca las diferencias

Entre las muchas herramientas de ayuda al desarrollo de páginas y aplicaciones web, hay una que te muestra una representación tridimensional de la página.  Esta representación muestra las capas que existen en el diseño de la página, la estructura interna del documento HTML, los nodos y etiquetas.  Usando esta herramienta se puede ver más fácilmente algunos fallos de diseño, como etiquetas de cierre olvidados, y también problemas potenciales, como un exceso de capas que ralentizan tanto la carga como la visualización de la información.

Sirvan de ejemplo estas dos páginas, la de una conocida red social y la de una web amiga.  ¿Cuál creéis que será más propensa a tener problemas?

Webs 3D

Por cierto, si a alguien le interesa esta herramienta, se trata de una de las que vienen incluidas en la extensión Desarrollador Web de Firefox.

Usar la herramienta adecuada

Últimamente me estoy encontrando a menudo con la situación en la que puedo comparar lo que es trabajar con la herramienta adecuada y con la que no lo es.  En el mundo de la programación profesional nos encontramos demasiado a menudo con la situación de vernos obligados a usar una herramienta* inadecuada para el trabajo que has de realizar.  Lo mencioné de pasada en este artículo, por ejemplo, pero todos los que trabajamos en esto lo vivimos casi a diario.

Uno de los últimos ejemplos con los que me he encontrado tiene que ver con Google.  Como muchos sabréis, esta empresa está desmantelando la plataforma iG, y junto a ella a varias de las aplicaciones como su directorio de marcadores (o bookmarks) y su lector RSS.  Como usuario me he visto obligado a buscar alternativas, y la verdad es que he descubierto que no estaba usando la herramienta adecuada para consultar mis correos y enlaces RSS.  Usando iG no era raro el día en el que tardaba casi una hora en revisarlo todo (y eso revisándolo diariamente, imagináos después de unas vacaciones), pero ahora, usando un cliente de correos y noticias, con una extensión para obtener las actualizaciones RSS (concretamente Claws Mail) tardo menos de media hora siempre.

Por eso, cuando alguien me viene y me dice, por ejemplo, que para una web de noticias están pensando en cambiarse desde Spip a Wordpress y yo les digo que no es buena idea y me contestan que por qué no si es lo mismo y Wordpress es más fácil de usar y tiene menos errores, pues me pongo malo.  Menos mal que alguien con seso (que no soy yo) sugiere que quizá los errores se deben a una mala actualización y hace que regrese mi confianza en la humanidad, aunque sólo sea un poco.


* Aquí también vale lenguaje de programación.