Hace unos días, investigando sobre programación concurrente, sistemas operativos de tiempo real y sistemas de alta confiabilidad, me encontré con este supuesto white paper: Linux in Defense: An Urgent Threat to National Security.

Para extraer rápidamente las ideas más importantes:

• Linux es un sistema operativo que jóvenes delincuentes (algo así como crackers) hackean en su tiempo libre.
• Si eso pueden hacerlo unos adolescentes aburridos, imagínense lo que pueden hacer organizaciones de gobierno enemigas o terroristas.
• Siempre hay una lista de vulnerabilidades pendientes, porque el sistema siempre tiene errores.
• Gente mal intencionada puede insertar troyanos en el código fuente de Linux ya que es de código abierto.
• La CIA insertó troyanos en software que luego utilizaron los soviéticos, así que bien pueden nuestros enemigos estar insertando troyanos en estos sistemas de desarrollo colaborativo y open source.
• La solución es utilizar el sistema operativo de esta compañía, closed source, seguro y que nunca fallará.

Mis anotaciones al supuesto white paper:

• No es un white paper: es una publinota. El artículo está escrito por el CEO de la empresa que lo publica, fabricante del sistema operativo Integrity.
• Linux no es hackeado por adolescentes rusos en su tiempo libre, ese es Microsoft Windows, sistema closed source. Y por adolescentes americanos también, entre otros muchos países.
• Si en los sistemas colaborativos se pueden insertar troyanos, ¿por qué no en el closed source? Con más razón un troyano insertado en software closed source será más difícil, o imposible, de detectar. El mismo ejemplo que pone el autor acerca de la CIA lo demuestra.
• La solución no es desconfiar del software open source, sino controlarlo de cerca, al igual que se haría con una solución closed source de un contratista privado y nacional. Incluso controlar la seguridad de un sistema open source será más sencilla, ya que muchos problemas habrán sido descubiertos por la comunidad de desarrollo.
• Si siempre hay una lista de vulnerabilidades es porque el sistema evoluciona constantemente. Para hacer decrecer la lista se debe detener la incorporación de nuevas características. Esto sucede en el mundo open source y en cualquier otro, nada más que resulta visible en mayor o menor medida para el público.
• Todo sistema tendrá fallas y nunca será perfecto. Nunca existirá un sistema 100% seguro, y esto es algo que sabe casi todo el mundo, por lo que no se puede proponer una solución porque es perfecta.

Está bien demostrado que lo mejor que se puede hacer por la seguridad y estabilidad de una pieza de software es la utilización del esquema open source.

Dos cerebros suelen pensar más que uno. No digo mejor sino más, y eso es esencial para descubrir problemas en el software, donde se deben descubrir problemas en lugar de las soluciones.

¿Cómo se puede sostener, por ejemplo, que un compilador de C desarrollado por 20 programadores es mejor que GCC, desarrollado por miles? Suponiendo que se parten de los mismos objetivos, siempre será mejor que el código sea visto/desarrollado/revisado por la mayor cantidad de programadores posible.

Esta nueva entrega de mi lenguaje de scripting favorito tiene un soporte rudimentario de “goto”.

No quiero imaginarme las malas ideas que mucha gente va a tener con esto.

En la otra hand, llegaron los namespaces prometidos para la versión 6. ¡Enhorabuena!

Hace mucho tiempo que trabajo en web y un poco más que mi vida tiene que ver con la programación. Los últimos años han sido los años de popularización de WAMP, a tal nivel que está casi estandarizada la forma de aprender a programar para web. Esto es por el paso del tiempo y porque cierta arquitectura de aplicaciones se afirmó como la más confiable, esto es, PHP y MySQL.

Me da la sensación, hace un tiempo más bien corto, de que mucha gente está volviendo a preguntarse las cuestiones iniciales y estamos repensando las cosas que dábamos por absolutamente definidas. Adobe Air le dio un interesante empuje a SQLite, librería que existe hace bastante tiempo, pero que es más bien desconocida. Lo mismo con YAML, una interesantísimo formato como alternativa a XML.

Tenemos que volver a las bases, agarrar la navaja de Occam y replantearnos el diseño de las aplicaciones. De aquí el título de este artículo. Me parece importantísimo que en las facultades, donde se enseña a producir software, se sigan tocando los temas esenciales a la computación: los bytes y los ciclos de máquina.

Incluso desde el punto de vista del ahorro de energía: tenemos miles, sino millones, de sitios web trabajando con motores de bases de datos preparados para soportar cantidades inimaginables de información, cuando una pequeñísima librería como SQLite  sería más que suficiente. Estamos desperdiciando CPU y complicándola innecesariamente.

La popularización del desarrollo agile, en detrimento del RUP, está abriendo paso a una nueva forma de pensar.

Ayer llegó un mail a la lista de PHP announce. Se trataba del aviso de disponibilidad de una nueva versión en las ramas 4 y 5. ¿Qué loco no? Digo, que una pieza (grande) de software con tantos años de desarrollo siga teniendo avances y mejoras.

Automáticamente recuerdo a nuestro querido profesor Argibay diciendo esto mismo, que el ciclo de vida de un software no se acababa con el release de una versión, porque era evidente que luego habría que solucionar cosas que habían quedado mal hechas (con o sin intención, claro, tampoco vamos a alardear de programar sin cometer errores que no imaginamos) o “peor aún”, los requerimientos iban a cambiar, o dicho de otra manera, el cliente ya no quiere algo de la forma inicialmente planeada o se fueron ocurriendo cosas en el camino. ¿Y qué tal si la competencia de repente hizo algo mejor? Véase Gmail, Yahoo, el viejo y obsoleto Hotmail…

Y esto me recuerda otra cosa, cuando, hace algo así como dos años, preparé un sistema de gestión contable para una pequeña empresa. En mi cabeza el proyecto quedó cerrado cuando les entregué lo que para mí era la versión final, funcional. Pero claro, amplio error el mio: obviamente tenía errores de código, tuvimos que afrontar un cambio en el motor de base de datos, una reestructuración de toda la red, nuevas exigencias contables. ¿Versión final dije? Qué idiota. Qué inexperto.

Conclusión, mía: el ciclo de vida de una pieza de software sólo finaliza cuando ese software deja de estar productivo.

Después de algunos meses de desarrollo, y de semanas cada vez más intensas, y días cada vez más llenos de programación, llegó el momento de presentar en sociedad a nuesto primer hijo oficial: www.dimehoteles.com

En este caso rehicimos el sitio desde cero, from scratch, para un cliente -me atrevo a decir devenido amigo- español.

No sólo se mejoró mucho la interfaz, la usabilidad y la navegabilidad (cosas que pueden verse) sino que por detrás corre toda una aplicación que arrancó bien arquitecturada desde el principio, una base que se la re banca, y toda una estructura de páginas y componentes que son realmente objetos, sumado a una concepción totalmente traducible a otros idiomas y un sitio realmente google-friendly. Me atrevo a decir, un casi framework.
En fin, un verdadero chiche!!!! Estoy muy contento con el proyecto: con lo que se hizo, con lo que se está haciendo, y con todo lo que está por hacer!!

Felicitaciones a la Tana, por tanto trabajo para lograr esto, y bienvenido nuevo DimeHoteles! :)

Entre otras, la programación en PHP (como en casi todos los otros lenguajes de programación de ordenadores) [perdón, necesitaba densidad de keywords jajaja] puede encararse desde objetos o desde procedimientos.

Como dije, hay otros “enfoques“, pero los dos modelos dominantes son esos. Bueno, al menos para mí, está bien, no todo el mundo es como yo, ya lo recordé.

En fin, mi experiencia es que trabajando con procedimientos uno codea el 40% del tiempo, y debuggea el resto. Con objetos, los números son distintos: codeo el 95% del tiempo y debuggeo el 5%.

Es abismal la diferencia, y es muy placentero trabajar con objetos. Además de las ventajas teóricas que plantea, claro. No es un quick development porque algo mal hecho al principio puede arruinar todo (peor que en procedimientos, donde el fenómeno también existe, claro) y eso hace que se tenga que razonar y arquitecturar mucho al inicio, pero el desarrollo se acelera mucho una vez que se tienen la bases, y además, se pasa más tiempo programando -que es lo que nos gusta, lo que me gusta- y menos resolviendo problemas -que es lo que nos termina irritando, a todos.

Objetos, por ahora los amamos. He dicho.

El otro día vi un microcontrolador de Rabbit Semiconductor que corría el µC/OS-II.

Este es un sistema operativo microkernel, de tiempo real, diseñado por Jean Labrosse. Entre sus características se encuentra el manejo de semáforos, mailboxes, preemption, multitasking de hasta 64 aplicaciones, y más.

La verdad que me dejó impresionado. Hace rato que sabemos que los microcontroladores tienen una potencia increible, y un costo muy bajo, pero esto realmente no lo sabía. Poder correr un s.o. ahí adentro es increible. Además, fue certificado por la FAA (US Federal Aviation Administration) para misiones críticas. Wow!
No sé realmente hace cuánto que este tipo de cosas están disponibles en el mercado, pero yo me acabo de desayunar.

Descripción del principal libro, con referencia a algunas características del µC/OS-II.

Página en Rabbit Semiconductor.

La FAA en yankilandia.

Les dejo unos links para que puedan descubrir tres lenguajes de scripting “no tradicionales”. No son únicamente para scripting web, pero ese es mi punto de interés hoy.

Ocaml, Lasso, REALbasic

Acaba de salir el nuevo Google Maps for Mobile, el sueño del pibe de tener un mapita live por si te perdés en la ciudad, y que te diga para dónde salís disparando si te sentís en peligro.

En fin, un nuevo ejemplo que demuestra la alta integración de todos los servicios de Google que, más allá de haber ido construyéndose con retazos de empresas, compradas a discreción, supieron integrar y estandarizar.

El gigante, una vez más, nos demuestra por qué es el más grande.