Espero que mensajes como estos ayuden a mitigar las declaraciones de que tal lenguaje es absolutamente preferible a otro por tal o cual característica, sin tener en cuenta para qué problemas se va a aplicar. No estudien un lenguaje de programación porque las noticias hablan de él.

Supongo que a mediano plazo tendremos una batalla por el liderazgo en programación funcional y en programación concurrente. Estimo que los participantes podrían ser Haskell, F# y Erlang (que viene con ventaja en popularidad gracias al empuje de CouchDB).

Acerca de las modas, les dejo un párrafo del libro “Análisis y diseño orientado a objetos de sistemas”, de Bennett:

“Cualquier empresa resulta muy vulnerable [a las modas] si la mayoría de los directivos tiene poco conocimiento de las teconologías de la información y, por tanto, carecen de base racional para evaluar las afirmaciones exageradas que algunos fabricantes están dispuestos a realizar sobre sus productos más novedosos”.

PD: si buscan alguna intro a Go, está aquí.

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.

Este tipo de variables tiene algunos usos interesantes, siendo el ejemplo clásico el del contador de usuarios. Como la variable es compartida por todos los scripts, es muy fácil registrar la cantidad de hits de un sitio, o las sesiones creadas para intentar contabilizar los usuarios distintos.

En fin, hace unos días estoy desarrollando una extensión para PHP 5, justamente para tener este tipo de variables Application. Se trata de un módulo de PHP como cualquier otro. La magia de las variables compartidas se realiza con shared memory de la biblioteca libmm.

Actualmente tengo funcionando una versión prototipo en Debian Lenny, Apache 2.2.12 y PHP 5.3.0. Por funcionar con shared memory se precisa tener PHP como módulo de Apache (no CGI)  y a éste funcionando en modo worker (no prefork). Además, PHP debe haber sido compilado con –with-mm, lo que hace que no funcione en entornos thread safe si usamos además el módulo session…

En realidad este es un llamado a la solidaridad, para quienes estén más familiarizados con las distintas variedades MPM de Apache y también para realizar algo de testing en alguna plataforma Windows. ¿Interesados?

He llamado al módulo “appvar” y las funciones que provee esta ínfima versión 0.1 son:

• appvar_set(”mi_variable”,”mi_valor”);
• appvar_get(”otra_variable”); //se conserva en memoria, y visible por todos los scripts!
• appvar_unset(”cual_variable”);

Además cuenta con lock y unlock, todavía no implementado.

Si les interesa, estos son los números que muestran las palabras más utilizadas por este diario:

[gobierno] => 73
[gripe] => 53
[presidente] => 34
[policia] => 33
[ministro] => 29
[dialogo] => 29
[jefe] => 24
[clarin] => 21
[moreno] => 20
[cristina] => 19
[oposicion] => 19
[ciudad] => 18
[muertos] => 18
[indec] => 17
[honduras] => 17
[moyano] => 16

La cifra que se muestra es la cantidad de veces que se utilizó la palabra en los últimos 15 días, contando desde hoy. Se eliminaron las palabras comunes de nuestro idioma.

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!

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.

Actualizar desde versiones muy anteriores a la última es mucho más difícil que de una inmediata anterior. Habrá que acostumbrarse a hacerlo más seguido.

Acabo de testearlo y el sistema funciona. El listado de servicios de información disponibles puede encontrarse acá.

Todo es muy lindo y, al menos en mi caso y en este horario (prácticamente madrugada) fue muy expeditivo. Ahora viene el “pero”: pero, a pesar de esto, ¿tendrá este sistema una utilidad real más allá de la “sensación tecnológica”?

Después, los preciados namespaces. Con esto vamos a tener más libertad a la hora de nombrar clases (ya que se evitan los conflictos de nombres) y beneficiará a la programación con objetos toda.

Con el asunto de namespaces se vienen varias palabras reservadas nuevas, necesarias en el momento de tratar con las nuevas funcionalidades.

A la espera del release, lo único que tenemos por ahora son los snapshots dev.

En cuanto a sistemas e informática, en un país en el que no tenemos tradición de horario de verano, el asunto no deja de ser engorroso.

Para hacerlo bien, además de adelantar una hora el reloj de la PC, hay que cambiar la zona horaria a “GMT -2″. La pueden encontrar con varias denominaciones, siendo la más común “Atlántico Central” ó “Mid-Atlantic“. En Windows, al cambiar la zona horaria automáticamente se adelantará una hora el reloj. Todos estos cambios manuales no serían necesarios si la política de cambio horario fuese regular y la configuración para “Argentina” la contemplara. Es decir, que necesitamos una regularidad en la política :).

Si cambiamos sólo la hora, pero no la zona horaria, algunas aplicaciones mostrarán horas incorrectas, ya que se manejan por el tiempo GMT. Un ejemplo es Gmail. Si adelantamos la hora pero no modificamos nuestra zona horaria, es como si estuvieramos corriendo el horario GMT.

Espero haber sido claro… a cambiar los relojes!