Burdjia

Etiqueta Ingeniería software, 7 entrada(s)

Feed Rss, Atom

Tener las herramientas adecuadas

Es algo que ya he mencionado anteriormente, aunque ahora no son las mismas circunstancias.

Ayer mismo terminé un ciclo en el proyecto Allegro.pas (¡por fin!).  En este último empujón me ha dado por pensar en lo importante que es tener herramientas adecuadas, y me he dado cuenta de cómo he perdido el tiempo debido a algunas carencias.

Por ejemplo, para solucionar la compatibilidad con Delphi en varias ocasiones he tenido que hacer un mismo cambio (o conjunto de cambios) en muchos archivos, como cambiar una variable de configuración de todos los archivos de proyecto o cambiar un tipo de dato en los ejemplos.  En el peor caso el proceso sería:

  1. Cargar archivo.
  2. Buscar el punto en el que hacer el cambio.
  3. Hacer el cambio.
  4. Guardar archivo.
  5. Repetir desde 1. hasta que todos los cambios estén hechos.

Sí, los editores de código e IDEs incluyen opciones de "Buscar y reemplazar" que pueden ayudar, incluso a través de varios archivos, pero en ocasiones no es tan simple como buscar y reemplazar:  a veces no son exactamente el mismo en todos los archivos sino que depende de ciertas condiciones.

Afortunadamente me di cuenta enseguida del problema, y vi que era una ocasión de poner a prueba BAScript.  Y dio el tipo, ¡vaya si lo dio!

Creé un programa que permitía ejecutar un guion a un grupo de archivos, y añadí multitud de funciones de búsqueda y manipulación de textos.  Empecé con guiones como el siguiente, que se asegura de que, en un archivo de proyecto, el nombre del proyecto y el del archivo principal coinciden, lo que me permitía copiar el archivo de proyecto sin tener que abrir Lazarus ni Delphi para crear y configurar uno nuevo casi exactamente igual a los anteriores:

; Actualiza el nombre del proyecto.

; Obtiene el nombre del archivo.
FileName			; Nombre con extensión.
Filename CALL:StrLen 5 -	; Posición del punto.
6				; Longitud extensión + punto
CALL:RemoveStr $FileName	; Elimina extensión.

'ex_audio_simple' FileName CALL:StrPos 0 > IF GOTO:end FI

:loop
'ex_audio_simple' 0 CALL:FindTextLine
DUP IF
; Se encontró.
  #Linea
  Linea CALL:GetTextLine
  'ex_audio_simple' FileName CALL:ReplaceStr
  Linea CALL:SetTextLine
  GOTO:loop
FI
DROP

:end

Este es de los guiones más simples que utilicé.  El más largo es otro que se asegura de que diversas variables de configuración de los proyectos tienen los valores adecuados, además de añadir algunas unidades a los mismos en caso de ser necesario.  No un simple "Buscar y reemplazar" como el que veis, sino otro que comprueba condiciones previas y toma decisiones de si hacerlo o no hacerlo. 80 líneas, más o menos.

Este programa me ha resultado tan útil que seguramente lo añada como ejemplo en la próxima versión de BAScript, que la habrá.

Pero antes, también me ha salvado un poco otro de mis proyectos:  mlsde, ahora mismo sólo una prueba de concepto que hice hace algunos años para probar algunas ideas para un IDE tras descubrir la existencia de Sublime Text con idea de añadir guiones (scripts) al estilo de los viejos Turbo de Borland.

Normalmente trabajo con Vim y me funciona bastante bien, pero escribiendo el tutorial de la web eché en falta una forma más simple de moverme entre diferentes archivos, aparte de que los scripts al estilo Turbo me hubieran venido de perlas también.  Decidí usar mlsde a ver qué tal, y aunque me hizo la navegación entre archivos más fácil, lamenté no tener terminado el motor de guiones.

En conclusión, tengo que hacerme con mejores herramientas de trabajo para ser más productivo.  Evidentemente hablo de mejorar mlsde, ¿o qué os creíais? :)

Etiquetas: Ingeniería software

Categorías: Herramientas, Opinión, Programación

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.

Etiquetas: Pascal, Delphi, Ingeniería software

Categorías: General, Noticias

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.

Etiquetas: Programación YAGNI, Ingeniería software, Programación KISS

Categorías: Artículos, Programación

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.

Etiquetas: Adobe flash, Ingeniería software

Categorías: Artículos, Programación, Web

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.

Etiquetas: Diseño, HTML, Ingeniería software

Categorías: Artículos, Herramientas, Opinión, Web