Max Villegas Viviendo en la era digital

De esto se trata el opensource y el movimiento del software libre dicho en español por el mismísimo Richard Stallman, aunque parezca que es la voz de Sam, el asistente chanta de MS Windows

Después de escucharlo un rato su discurso me parece demasiado anti Microsoft, cuando creo que debiera centrarse en las ventajas de desarrollo y económicas del software libre.

Pero en la medida que explica sus 4 libertades su discurso se hace coherente:

• La libertad cero es la libertad de ejecutar el programa como se desee, con cualquier propósito.
• La libertad uno es la libertad para estudiar el código fuente y modificarlo para que haga lo que tu deseas o necesitas que haga.
• La libertad dos es la libertad para ayudar a otras personas, es la libertad de hacer copias y distribuirlas a otros en cualquier momento.
• La libertad tres es la libertad para ayudar a la comunidad: la libertad de publicar o distribuir las versiones modificadas cuando tu quieras.

Visto en Tecnologías libres

En resumen, Prism es otra aproximación más a esto de las aplicaciones web como escritorio bajo el alero de la cloud-computing, es decir, es la apuesta de Firefox para competir contra Adobe Air y Silverlight.

En mi opinión, la ventaja que tiene Prism por sobre la otras alternativas es que al ser una especie de fork de Firefox ya está diponible en todos los Sistemas Operativos, vale decir, Windows, Mac  y Linux, tanto en versiones de 32 como de 64 bits.

Además, a diferencia de Air y Silverlight, Prism no pretende crear una web alternativa sino que intenta extraerla del navegador para llevarla mediante XUL a nuestro escritorio.

Esto significa que pueden desarrollarse aplicaciones web haciendo uso de tecnología y lenguajes conocidos: HTML, JavaScript, CSS, etc y que, en favor de la convergencia, más vale crear aplicaciones  minimalistas que realicen funciones específicas, puesto que pueden (re)utilizarse tanto en dispositivos móviles como en widgets de manera independiente de la plataforma y del Sistema Operativo, con una reducción de costos en tiempo y dinero que puede ser sustancial.

Más información

• https://wiki.mozilla.org/Prism#Web_Application_Script
• https://labs.mozilla.com/forum/?CategoryID=16
• http://es.wikipedia.org/wiki/Artilugio

Si dependiera de los internautas de todo el mundo Obama sería electo Presidente casi sin ninguna resistencia, es que Barack Obama ha usado Internet de manera excepcional tanto para comunicar su mensaje como para posicionar su nombre y su imagen como una marca imposible de olvidar…

Por eso no me gustaría ni pensar lo que pasaría si votara por McCain

Hace rato que uso la librería jQuery por lo que me resulta súper fácil manipular elementos HTML por su su clase, independiente de su tagName (a, div, span, etc). Por ejemplo en una breve y simple líena puedo darle display:none a todos los elementos con clase hide:

//lo simple es bello
$(‘.hide’).hide();

En Prototype (que no ocupo desde que comencé a usar jQuery), aunque era un poco más complejo y limitado, tampoco daba muchos dolores de cabeza:

//Sólo hay que dominar bien los selectores tipo CSS de Prototype
$$(‘div.hide’).invoke(‘hide’);

Incluso era posible de esta forma:

//iteramos sobre cada elemento
documetnt.getElementsByClassName(‘hide’).(Element.hide);

Pero resulta que la función getElementsByClassName() aún no es un estándar (lo que significa
que obviamente no funciona de froma nativa ni en IE6 ni en IE7, pero sí en Firefox3, Safari y Chrome), por
lo tanto, para que funcione en IE debe estar soportada por la librería que ocupemos.

En el caso que estemos trabajando sin ninguna librería o que no esté soportada (por ejemplo en las versiones nuevas de Prototype está obsoleta), la podemos implementar fácilmente con el siguiente código:

document.getElementsByClassName = function(cl) {
var retnode = [];
var myclass = new RegExp(‘\\b’+cl+’\\b’);
var elem = this.getElementsByTagName(‘*’);
for (var i = 0; i < elem.length; i++) {
var classes = elem[i].className;
if (myclass.test(classes)) retnode.push(elem[i]);
}
return retnode;
};

Referencias:

• http://www.prototypejs.org/api/utility/getElementsByClassName
• http://www.anieto2k.com/2007/05/29/ultimate-getelementsbyclassname-mejorada/
• http://edusanver.wordpress.com/2007/10/03/getelementsbyclassname-javascript/
• http://www.anieto2k.com/2007/02/03/firefox-3-integrara-getelementbyclassname/

Tengo mucho código para postear, pero me aguantaré unos días para hacerlo detalladamente en blogandia. Ahora sólo quiero sacrame un poco las ganas de hablar de JSON.

Algunas de las razones porque vale la pena trabajar con este tipo de notación son:

1-. Por sobre todo: orden. Trabajar javascript con JSON es por lejos más ordenado y simple que hacerlo de la forma clásica. A este orden “visual/mental” hay que agregar un punto tan o más importante que mi manía personal por el código elegante y ordenado: los nombres de las variables y funciones dificilmente interfieren con los nombres de variables y funciones de otras aplicaciones javascript que coexisten generalmente en un sitio web.

Por ejemplo, es perfectamente posible el siguiente escenario:

var aplicacion_uno = {
cargando : function(){
//código de esta funcion;
},
hide : function(){
$$(‘ul[class=hide]‘).map(function(s){$(s.id).hide();});
}
}

var aplicacion_dos = {
cargando : function(){
//código de esta funcion;
},
hide : “se traduce como esconder”
}

2-. Para trabajar con gran cantidad de datos dinámicos de forma asincrónica es mucho más rápido que hacerlo con XML, en pruebas preliminares con firebug, para la siguiente consulta el tiempo de respuesta es de 164ms.

[{"modelo_generico":"Chevrolet Corsa","t1":"25.800","t2":"21.900","t3":"17.955","t4":"15.750",
"zonal":"RENT A CAR ANTOFAGASTA","patente":"WV-9955","fecha_inicio":"2007-12-05",
"fecha_termino":"2007-12-15"},
{"modelo_generico":"Chevrolet Corsa","t1":"25.800","t2":"21.900","t3":"17.955","t4":"15.750",
"zonal":"RENT A CAR ANTOFAGASTA ","patente":"WV-9960","fecha_inicio":"2007-12-15",
"fecha_termino":"2007-12-20"}]

Mientras que para una cantidad evidentemente menor de datos en xml la respuesta menor que he obtenido es de 544ms.

<xml>
<contenido>
<status>ok</status>
<precio>45000</precio>
<pasajeros>1</pasajeros>
<dolar470</dolar>
</contenido>
</xml>

3-. Si bien la forma de pasar los datos de un lado a otro es básicamente la misma para JSON y XML (Ajax.Request o $j.ajax con prototype y jquery respectivamente), la disponibilidad de ellos es radicalmente distinta. Mientras que con XML hay que parsear los datos según las etiquetas:

xmlparse : function(responseXMLCli){
var xml=responseXMLCli.responseXML.documentElement;
var item=xml.getElementsByTagName(‘contenido’)[0];
var pasajero=item.getElementsByTagName(‘pasajero’)[0].firstChild.data;
alert(pasajero)
}

con json quedan disponibles de inmediato

jsonready : function(data){
alert(data.pasajero)
}

Un DTD especifica los tipos de elementos y atributos que podemos utilizar en una página web; define, de acuerdo a la especificación del lenguage de marcado, las reglas de cómo podemos usar estos elementos juntos y, también, declara cuáles juegos de caracteres debemos usar.

Los validadores comprueban que una página web esté correctamente escrita de acuerdo al DTD especificado en la declaración DOCTYPE, utilizando el identificador del sistema o, implicitamente, usando el identificador público. Sin embargo, los navegadores actualmente usan intérpretes que no validan y no leen el DTD.

¿Cuales son las diferencias entre los DTD?

Por ejemplo, para el HTML 4.01 existen 3 tipos de DTD:

• Strict, el DTD “HTML 4.01 Strict” hace énfasis en la separación del contenido de la presentación y el comportamiento. Este DTD es el que la W3C recomienda para todos las páginas web actuales. Este DTD es recomendado por sobre el HTML Transitional y Frameset.
• Transitional, el DTD “HTML 4.01 Transitional” significa que puede ser usado transicionalmente para convertir un documento de las versiones anteriores de HTML 4.01 en uno más moderno, no es recomendable para nuevas páginas web. Este tipo incluye 11 tipos de elementos que estás obsoletos pero que se pueden usar.
• Frameset, el DTD “HTML 4.01 Frameset” se utiliza para página que usan marcos. debes tener en cuenta que los marcos son obsoletos fueron descotinuados por la W3C, se recomienda que en este caso se utilice algún scritp del lado del servidor para reemplazar los marcos.

En el caso del XHTML 1.0 se deifnen los siguientes tipos:

• Strict, se usa cuando se desea un lenguaje de marcado limpio y se usa en conjunto con las hojas de estilo CSS.
• Transitional, se usa cuando se necesita de ciertas características del HTM y cuando se quiere dar soporte a navegadores que no entienden las Hojas de Estilo.
• Frameset, se usa cuando se necesitan los framset de HTML para dividir el nagvegador en dos o mas recuadros.

¿Cuál DOCTYPE debo utilizar?

Hasta donde sé, no hay una recomendación oficia,l o al menos no la pude encontrar en la W3C. No obstante, al ser el XHTML la evolución natural del HTML4, y por su tendencia a ser un lenguaje de marcado más semántico que su antecesor, es recomendable usar el DTD XHTML 1.0 Strict.

Sin embargo, actualmente se está a la espectativa de lo que sucederá con XHTML2 y el HTML5, debido a que Tim Berners-lee escribió un post donde asumiendo el fracaso en cambiar a la gente al XML y anuncia la formación de un nuevo grupo de trabajo encargado de mejorar el HTML, lo que ha generado debate entre los desarrolladores y especialistas.

vía

Lo anuncian en Ajaxian: HTML5 incorporaría un API para bases de datos del lado del cliente. Esto significa que las aplicaciones web podrán almacenar datos estrcturados de forma local usando el ya familiar SQL.

La API es asincrónica y usa funciones del tipo callback para cargar los resultados de las querys.

Un ejemplo:

var database = openDatabase(“Database Name”, “Database Version”);

database.executeSql(“SELECT * FROM test”, function(result1) {

// do something with the results
database.executeSql(“DROP TABLE test”, function(result2) {

// do some more stuff
alert(“My second database query finished executing!”);
});
});

Puedes leer más información en webkit

Las solapas o pestañas son muy utilizadas en prácticamente todos los sitios que se ven hoy en día. Jacob Nielsen (para el que no lo conoce para muchos el “guru” de la usabilidad web) ha escrito 13 reglas para hacer las solapas usables.

1. Utiliza las solapas para moverte dentro del mismo contexto y no para navegar por áreas diferentes

2. Utiliza de manera lógica porciones de contenido para que los usuarios puedan predecir fácilmente que encontraran cuando selecciones una solapa.

3. En línea general los usuarios no tienen que ver de forma simultanea el contenido de múltiples solapas. Si la gente realmente tiene que comprar la información entre diferentes pestañas la necesidad de ir hacia delante y hacia atrás pone un carga extra en su memoria a corto plazo y de esa forma baja la utilidad comparada con un diseño que pone todo en una sola página grande.

4. Las pestañas son paralelas por naturaleza, al menos para los usuario de los Estados Unidos (Para los usuarios internacionales sería mejor tener una pestaña para “Norteamérica” o “América” para un mejor paralelo con “Europa” y “Asia”)

5. La pestaña que se encuentra seleccionada tiene que estar destacada. Puedes destacarla por su color, por un tipo de fuente distinta o bien haciendo aparecer esta solapa delante de las demás.

6. Las solapas que no están seleccionadas deben estar claramente visibles, un color que se confunde con el fondo puede lograr que el usuario nunca pulse en ellas y por lo tanto nunca conozca su contenido.

7. La solapa común y corriente esta conectada con el área que posee el contenido, de igual manera que miramos en las tarjetas de un índice físico. Esta conexión ayuda al usuario a visualizar las solapas activas y reforzar la conexión entre el contenido y su solapa.

8. Las solapas deben contener texto corto y con un lenguaje simple. Las solapas en general deben contener una o dos palabras. Las solapas cortas son mas “escaneables” si necesitas solapas más grandes esto es un signó que las opciones son demasiados complicadas para este tipo de control.

9. Mantener siempre un mismo estilo de capitalización. En este punto Nielsen no recomienda poner todas las letras en mayúscula cuando definimos el texto de cada solapa puesto que dificulta la legibilidad.

10. Utilizar solo una fila de solapas. Muchas filas destruyen la memoria espacial y hace imposible a los usuarios recordar que etiquetas ya han visitado. También muchas filas de solapas son un síntoma de complejidad excesiva. Si necesitas más de una fila de solapas tiene que simplificar tu diseño.

11. Las filas de solapas deben estar arriba del panel y no sobre los costados ni abajo, lugares en donde seguro pasaran desapercibidas.

12. El alcance de uso de las pestañas o el área que controlan debe estar claramente definidos en el aspecto visual.

13. Velocidad de respuesta. Al presionar sobre una etiqueta el contenido deberá ser desplegado de manera instantánea, probablemente se logre esto con Ajax, no obstante la tecnología no es lo importante, sino mas bien el resultado. Es aconsejable que el tiempo de respuesta sea menor a 0.1 seg.

En Denken Über me entero de un post de Marc Andreessen sobre las plataformas de internet. Andreessen definde el concepto de plataforma de manera muy simple:

A “platform” is a system that can be programmed and therefore customized by outside developers — users — and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate.

En definitiva, si el sistema es programable por otros desarrolladores y usuarios es una plataforma, de lo contario, no lo es”.

Además distibgue 3 tipos de plataformas:

1- API de acceso a datos: donde solamente podés tomar datos y armar algun tipo de mashup o visualización de los mismos. Ej: Flickr, eBay, Paypal
2- Plugin API: la que te permite crear nuevas funciones o extender las ya existentes a través de código “montado” sobre la plataforma (inyectado) Ej: Facebook F8
3- Runtime Enviroment: es la plataforma donde el código creado por los desarrolladores externos core DENTRO de la plataforma. Ej: Second Life, Ning, Salesforce

Es un post muy intersante sólo habla desde lo técnico sino que además manifiesta que la tendencia en Internet será utilizar las plataformas Runtime Enviroment.

Volviendo un poco sobre mi post 5 errores en los contenidos de un sitio web me encuentro hoy un post en Linux Today sobre un formato público, abierto y estándar para los contenidos de noticias online.

The News Industry Text Format is an XML-based format used by the news industry to encode and share the content of news articles. PEAR’s XML_NITF package provides an extensible API to read and parse NITF-formatted files, making it easy to extract bibliographical information and article content for use in any PHP application.

Me pregunto si en La Tercera o en LUN sabrán de esto… ¿Qué creen?

Es interesante ver cómo de un lado del mundo se discute sobre el futuro del periodismo (vía jbarahona) y se entiende que Internet juega un papel vital en su construcción; mientras por acá parece que nos quedamos pegados en la era de la fotocopiadora.

Si quieres saber más sobre NITF:

• Read News Industry Text Format (NITF) files with PHP
• NITF Website
• NITF tutorial
• NITF specification