¿Qué se puede hacer dentro de Facebook? En sentido general lo que lograremos es una aplicación integrada con el flujo social de información de la plataforma. Uno de los objetivos principales suele ser lograr la “viralización”, es decir, que un contenido se “propague” entre los contactos de distintas personas para ser difundido y comunicado con eficacia. Para lograr esto, las aplicaciones buscan generar contenido interesante para el usuario y que éste lo publique o recomiende. Esto se logra integrando estas acciones del usuario con lo que los demás ven sobre su actividad (el news feed, o muro).

Desde el punto de vista del desarrollo web, las aplicaciones para Facebook son, básicamente, aplicaciones web, pero que funcionan dentro de un ámbito particular y conviviendo con otros desarrollos de Facebook. Nos estamos refiriendo a las aplicaciones tipo Canvas. Este Canvas no es más que un iframe que queda contenido dentro de la interfaz de Facebook.

Pero las cosas no son tan sencillas o, dicho de otro modo, las cosas son mucho más profundas y poderosas. Además del flujo de información (o sea, HTTP, web) entre el navegador del usuario y Facebook, tendremos comunicación entre nuestro servidor (donde hosteo mi aplicación) y los servidores de Facebook, para lo cual necesitamos conocer desde mecanismos de seguridad (HTTPS, desafíos, algoritmos de hash) hasta la forma de dialogar con Facebook (las Facebook APIs).

El acceso a la información social del usuario, además, está mediada por el sistema de permisos (OAuth) y autorizaciones, de manera que tenemos un acceso limitado según las preferencias de cada persona. Este sistema de permisos es bastante complejo y tiene una evolución rápida en el tiempo, por lo que es necesario comprender las bases conceptuales para poder actualizarnos rápidamente.

En esta oportunidad, comparto con ustedes el material utilizado en la clase 3, referido al sistema de autorización de aplicaciones. ¡Espero que les sea de utilidad!

Aplicaciones para Facebook, material clase 3: autorización de aplicaciones

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.