Todavía no sé si podré escaparme para asistir a la Conferencia Agile-Spain 2010, en Madrid los días 10 y 11 de Junio. Seguramente casi hasta a última hora no sabré si puedo ir. Pero sólo ojeando el programa, se ve una pinta estupenda: testing, scrum, integración continua, kanban...

La inscripción a la conferencia cuesta 95€ para los 2 días con desayunos, comidas y cafés incluídos. Eso sí, si se quiere asistir a algún taller, se tiene que pagar por separado, en la misma web del evento aparecen la duración y precio de los talleres.

Es una cita donde se encontrarán empresarios, desarrolladores, gerentes, investigadores, etc. Está enfocada principalmente a la industria de tecnologías de la información y consultoría tecnológica.

CAS2010 es una oportunidad para intercambiar experiencias y hacer contactos con otros profesionales del sector, además de examinar las últimas tendencias en el desarrollo del software ágil de mano de las figuras más representativas del panorama nacional.

Henrik Kniberg será el orador principal de la conferencia. Henrik es autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además de ser Certified Scrum Trainer, miembro de la junta directiva de la Agile Alliance, y uno de los máximos divulgadores de la aplicación práctica de las metodologías ágiles internacionalmente.

Y aparte de las sesiones y talleres, seguro que vale la pena ir también para charlar con ponentes y otros asistentes, que suele ser de lo mejor en la mayoría de los eventos ;)

Cuántas veces me habrá pasado por la cabeza hacer algo así XD

Como supongo que muchos ya sabréis, una especificación de HTML5 es Web SQL Database para persirtir datos en una base de datos relacional embebidos en el navegador web(la otra alternativa es Web Storage, para persistir datos como clave valor). Esto puede tener muchas aplicaciones, en mi caso lo he utilizado para implementar el sistema de favoritos de DNDzgz.

Cuando pretendamos sacar partido de las nuevas características de HTML5 debemos tener en cuenta que cada navegador puede soportar sólo algunas especificaciones, no es un todo o nada, por lo que lo primero que deberemos hacer es comprobar que soporta la especificación que queremos usar, por ejemplo:

function supports_local_database() {
return !!window.openDatabase;
}

Si existe openDatabase, crearemos la conexión a la base de datos:


db = openDatabase('dndzgz', '1.0', 'DNDzgz', 65536);

Una vez abierta la conexión, podremos ejecutar cualquier tipo de query SQL(compatible con SQLite), dentro de una transacción. Por ejemplo crear una tabla:

db.transaction(
function(transaction) {
transaction.executeSql(
'CREATE TABLE IF NOT EXISTS favorites ' +
' (id INTEGER NOT NULL, ' +
' service VARCHAR(255) NOT NULL, ' +
' date DATE NOT NULL,' +
' name VARCHAR(255) NOT NULL, ' +
' latitude REAL NOT NULL, ' +
' longitude REAL NOT NULL, ' +
' PRIMARY KEY (id,service));'
);
}
);

Insertar datos:

db.transaction(
function(transaction) {
transaction.executeSql(
'INSERT INTO favorites (id, service, date, name, latitude, longitude) VALUES (?, ?, ?, ?, ?, ?);',
[id, service, new Date(), name, latitude, longitude],
callBack,
errorCallBack
);
}
);

Eliminar datos:

db.transaction(
function(transaction) {
transaction.executeSql('DELETE FROM favorites WHERE id=? AND service=?;',
[id,service], null, errorCallBack);
}
);

Y por supuesto mostrarlos:

db.readTransaction(
function(transaction) {
transaction.executeSql(
'Select * from favorites;', [],
function(transaction, result){
for (var i=0; i < result.rows.length; i++) {
var row = result.rows.item(i);
alert(row.name);
alert(row.service);
}
},
errorCallBack
);
}
);

Como podéis ver, a executeSql se le pasa primero la query, seguidamente un array con los valores de los argumentos de la query, y finalmente una función de callback y otra de callback para el caso de que existan errores. Y existen dos tipos de transacciones: transaction y readTransaction, la primera es de lectura-escritura, mientras que la segunda es de sólo lectura.

En fin, supongo que a otros también os pasará lo mismo, resulta bastante raro estar tirando queries SQL desde javascript. Pero puede resultar útil para muchos casos, empezando por descargar de responsabilidades y carga al lado servidor.

Lo prometido es deuda, tenía pendiente escribir un poco acerca de la parte técnica del fin de semana del desafío AbreDatos y de DNDzgz. A grosso modo las tecnologías utilizadas fueron Google App Engine(GAE) y Python del lado servidor; del lado cliente fueron Javascript con jQuery, la versión 3 del API de Google Maps, algunas de las novedades de HTML5, unas gotas de CSS3 y jQTouch para ayudarnos para que tuviera pinta de aplicación nativa iPhone. Usamos Git como repositorio de código, el repositorio está concretamente en github; para los documentos, diseños, fotos, etc. utilizamos dropbox(antes del fin de semana yo no tenía ni cuenta :P).

La elección de GAE fue casi instantánea cuando empezamos a hablar con gimenete acerca de presentarnos al AbreDatos, las razones: hosting gratis y capacidad de escalar mucho sin tener que gastarnos ni un euro, despreocuparnos de la parte de sistemas, ningún problema con las limitaciones por correr sobre la plataforma de Google.

Que usáramos Python, aún siendo más javeros que otra cosa, fue por que ninguno de los 2 teníamos experiencia con GAE en Java(okok, yo había hecho un pequeño experimento, pero muy poca cosa para llegar a ninguna conclusión). Por eso preferimos aprovechar su experiencia desarrollando la primera versión de debug_mode=ON con Python+GAE; mientras que varias semanas antes yo me ojeé un par de manuales de inicio rápido, retomé el ebook Python para todos que tenía a medio leer(hace muuuucho :P) y un par de días antes, me hice en poco rato el proyecto de ejemplo de GAE. Para extraer los datos utilizamos tanto Beautiful Soup como expresiones regulares para hacer scraping de HTML o Javascript de Tuzsa y Bizi, y simplejson para cargar los datos JSON de datos.zaragoza.es.

Que utilizáramos jQuery como framework Javascript, fue una elección posterior a jQTouch(que está basado en jQuery) pero de todas formas, seguramente lo hubiéramos elegido. Google Maps es la elección "por defecto" para todo el que quiere hacer algo con mapas :P. Gimenete es quien estuvo peleando con esto, teníamos problemas con la fluidez en la navegación de los mapas, que al final consiguió mejorar... Eso sí, fuera del navegador Safari del iPhone no conseguimos que los mapas funcionaran correctamente, ni en terminales con distintas versiones de Android y ni si quiera en el Safari de Mac(tenemos que ver que pasa exactamente, tras algunas pruebas, el sospechoso principal es jQTouch).

Gracias a que iPhone(y las últimas versiones de Android) soportan parte de HTML5, se ponían a nuestra disposición algunas de esas novedades que molan tanto (Flash, tiemblaaa!! ;)):

• La posibilidad de geolocalizar al usuario por medio del GPS del terminal (no es exactamente HTML5, pero parece que la mayoría lo ponemos en el mismo saco) muy fácilmente utilizando navigator.geolocation.
• Para implementar los favoritos/acceso rápido estuvimos usando Web SQL Database, lo que supone guardar los datos en una base de datos embebida al navegador web(actualmente parece que en todos es SQLite, o al menos parece ser la implementación de referencia), que finalmente se quedó fuera por falta de 3/4 horas :S.

En fin, que debemos molar, porque nuestro proyecto es una pequeña colección de buzzwords: Cloud Computing vía Google App Engine, HTML5, iPhone... XD

Basado en los datos de Who Has the Most Web Servers? de Data Center Knowledge

Vía @javahispano