Mostrando entradas con la etiqueta papers. Mostrar todas las entradas
Mostrando entradas con la etiqueta papers. Mostrar todas las entradas

viernes, 9 de septiembre de 2011

¿Cómo funcionan los navegadores?

Mi amigo y compañero de trabajo Charly Páez compartió el otro día este documento que me parece algo fundamental para todo desarrollador hoy día. Está en inglés, pero no podía dejar de compartirlo con ustedes.

How Browsers Work: Behind the Scenes of Modern Web Browsers”, es parte del portal HTML5 Rocks construido por Google, conteniendo introducciones, presentaciones y guías de referencia.

Como se explica en el prefacio, gran parte de este documento surge de la cuidadosa investigación de la desarrolladora israelí Tali Garsiel sobre las características internas y análisis del código de WebKit (Safari y Chrome)  y Gecko (Firefox) los motores de presentación de código abierto que hoy suman aproximadamente un 60% del uso de la web. Aunque Internet Explorer no puede ser analizado de la misma manera, los lineamientos generales de su arquitectura seguramente no difieren fundamentalmente de lo que este documento cubre.

El contenido completo cubre los siguientes procesos, basados en el flujo típico debajo (dejo muchos términos si traducir para evitar confusiones):

  • El motor de rendering
  • Parsing y construcción del DOM (HTML, CSS, Scripts)
  • Construcción del árbol de render
  • Layout (distribución de los elementos)
  • Painting (la aparición real de los elementos en pantalla)
  • Cambios dinámicos
  • Los hilos del motor de rendering
  • Modelo visual de CSS2

Todo comienza con la descripción de alto nivel de la estructura de los navegadores, resumida en el siguiente diagrama:

El trabajo es bastante extenso y detallado, pero nuevamente lo recomiendo muy especialmente. No importa aprender todo ese nivel de detalle, pero leerlo detenidamente nos permite retener al menos algunos conceptos generales que nos ayudarán a comprender más fácilmente situaciones comunes en el desarrollo web.

jueves, 18 de agosto de 2011

Scrum Guide 2011 en español (+ video en inglés)

Jeff Sutherland (arriba) y Ken Schwaber (abajo)Recientemente Scrum.org, la organización detrás de la difusión de la metodología, publicó la versión actualizada de la guía escrita originalmente por Jeff Sutherland y Ken Schwaber y revisada este año: Scrum Guide 2011.

En la misma página se encuentran disponible traducciones de la guía a muchos idiomas, incluyendo la versión en español (PDF, versión del 2010).

Para quienes no conocen más que lo anecdótico de Scrum, dejo un brevísimo resumen de este framework que se basa en tres pilares:

  • Transparencia
  • Inspección
  • Adaptación

El equipo de Scrum está compuesto por:

  • El Product Owner (PO, dueño del producto), que se ocupa de maximizar el valor del producto y el trabajo del equipo de desarrollo. Por eso es el responsable principal del Backlog de producto, y debe asegurarse que esta lista está siempre priorizada, de manera que nadie trabaje en lo que no es la máxima prioridad en cada momento.
  • El Equipo de Desarrollo es el grupo que se encarga de entregar incrementalmente un producto funcional al fin de cada Sprint (iteración). La guía agrega un poco más de detalle incluyendo la composición y tamaño.
  • El Scrum Master se encarga de que las reglas y principios de Scrum se mantengan y de que los bloqueos potenciales se eviten o eliminen cuanto antes. La guía detalla un poco más los servicios que el Scrum Master proporciona al PO, al Equipo de Desarrollo y a la Organización.

Los eventos de Scrum son:

  • El Sprint (o iteración) durante el que el compromiso asumido por el equipo y consensuado por el PO no debe cambiar, y se ejecuta manteniendo el orden de prioridad para el negocio, de manera de que al terminar el límite de tiempo impuesto (entre una semana y un mes) lo que quedó completo e incluido en el incremento de producto es siempre lo más importante. Dentro del Sprint se producen:
    • La planificación del Sprint, en el inicio, donde el Equipo y el PO acuerdan el compromiso para la iteración, tomando los ítems de máxima prioridad en el Backlog de Producto, en orden descendente, hasta donde el equipo estima que puede terminar dentro del límite de tiempo.
    • El Scrum Diario (o stand-up), donde el equipo se reúne (de pie, para evitar prolongar la reunión más de unos minutos) y cada miembro del equipo expone:
      • Qué terminó desde el último stand-up
      • Qué planifica terminar antes del próximo stand-up
      • Qué obstáculos puede llegar a tener (y que el Scrum Master deberá evitar que bloqueen al equipo)
    • El Sprint Review, en el que el equipo muestra el resultado del trabajo al PO y los interesados que éste considere apropiado para ayudarlo a continuar ajustando el Backlog de producto.
    • La retrospectiva en que el equipo reflexiona sobre la manera en que se desarrolló el trabajo, teniendo en cuenta relaciones, técnicas, herramientas y demás, y determina algunas medidas para mejorar en el siguiente Sprint.

Los artefactos de Scrum son muy pocos:

  • El Backlog de Producto, que el PO se encarga de construir y mantener priorizado en base al valor para el negocio a través del tiempo.
  • El Backlog del Sprint, que el Equipo y el PO determinan al comienzo de cada Sprint y cuyo seguimiento determina el nivel de avance dentro del Sprint.
  • El Incremento de producto es la entrega que el equipo realiza a final de cada Sprint, y que debe ser funcional desde el inicio, de manera que esté potencialmente en condiciones de usarse y agregar valor.

En la guía terminan volviendo a la importancia de la definición de cuándo una tarea está “terminada”, lo que debe convertirse en un contrato entre el Equipo, el PO y la Organización, de manera de ajustar las expectativas y evitar discusiones y problemas al respecto.

La guía amplía un poco este resumen, pero sólo tiene 17 páginas, incluyendo algunas con índice, historia, agradecimientos, etc. El framework es muy sencillo de describir, lo que no implica que sea fácil de implementar. Suele decirse que se parece en eso a un deporte: las reglas son sencillas, pero ser un buen jugador es típicamente un gran desafío y el secreto está en la práctica y la dedicación.

Video

Como final, dejo este video de una charla de Schwaber en el 2006 dentro de las oficinas de Google, que me parece que explica bien muchos de los principios, y aunque está en inglés, vale la pena escuchar esto desde uno de sus iniciadores.

miércoles, 16 de marzo de 2011

En el jardín del buen y del mal JavaScript

Better JS Docs

Dos especialmente dedicados miembros de la comunidad de desarrolladores StackOverflow, Ivo Wetzel (23 años, trabajando en Zynga Alemania) y Yi Jiang (17 años, estudiante de Singapur) , han construido el sitio JavaScript Garden, dedicado a corregir errores de interpretación y mejorar el entendimiento sobre este fantástico lenguaje.

Además de ser un ejemplo de sobriedad y buen diseño (noten la fluidez de la navegación desde el menú a la derecha), me parece un gran trabajo de difusión, cubriendo por áreas las particularidades de JavaScript que suelen confundir a algunos programadores proveniendo de entornos bastante diferentes.

Algunos ejemplos que tomo del sitio:

Objetos y propiedades

En JS todo es u objeto, excepto null y endefined.

false.toString() // 'false'
[1, 2, 3].toString(); // '1,2,3'

function Foo(){}
Foo.bar = 1;
Foo.bar; // 1 

Es común pensar que los números literales no pueden tratarse como objetos porque no se puede acceder a sus miembros de la manera tradicional, pero esto es un defecto histórico del parser, que puede subsanarse fácilmente utilizando doble punto o espacios, como se muestra aquí:

2.toString(); // arroja SyntaxError

2..toString(); // el segundo punto hace que se interprete bien
2 .toString(); // o se puede dejar un espacio antes
(2).toString(); // o el uso de paréntesis también

En JS los objetos están implementados como hashmaps, o listas de elementos clave-valor, con lo que es posible crear objetos utilizando esta notación:

var foo = {}; //  objeto vacío (hereda de object.prototype)

// un nuevo objeto con la propiedad 'test' y valor 12
var bar = {test: 12}; 

Y las propiedades también pueden accederse como tales o como índices. Incluso al usar la notación con corchetes se pueden soportar propiedades que no serían posibles utilizando puntos, como en:

var foo = {name: 'Mafalda'}
foo.name; // Mafalda
foo['name']; // Mafalda

var get = 'name';
foo[get]; // Mafalda

foo.1234; // SyntaxError
foo['1234']; // funciona

Prototipos

Esta es una de las facetas más "raras" para muchos programadores provenientes de una cultura de orientación a objetos "canónica. De hecho escuché varias veces el argumento de que "JavaScript no es orientado a objetos porque no tiene clases ni herencia". Esto es totalmente falaz: JS es orientado a objetos, sólo que tiene herencia por prototipos, y no por clases. En este sitio tienen estos buenos ejemplos de cómo mantener una jerarquía tradicional utilizando cadenas de prototipos.

Hay mucha más información y no es mi objetivo repetir todo el sitio, por lo que les recomiendo dedicarle una hora a leerlo y hacer algunas pruebas. No lleva mucho más que eso y para muchos ahorrará muchos dolores de cabeza, o les permitirá valorar JavaScript como el lenguaje merece.

martes, 22 de febrero de 2011

SADIO organiza la 40va edición de las JAIIO

SADIO

(luego de un receso vacacional, este blog vuelve a la carga)

En estos días me llegó el boletín de SADIO, la sociedad decana de nuestra área en Argentina, con más de 50 años de trayectoria. Me parece una buena ocasión para hacer eco de una de sus principales actividades.

40 JAIIO

Este año volverán como siempre las jornadas argentinas de informática. La edición número 40 (arrancaron en 1961) se llevará a cabo del 29 de agosto al 2 de septiembre en la UTN de Córdoba, Argentina.

La descripción de las jornadas, según los organizadores mismos, es:

En sesiones paralelas se presentan trabajos que se publican en Anales, se discuten resultados de investigaciones y actividades sobre diferentes topicos, desarrollandose también conferencias y reuniones con la asistencia de profesionales argentinos y extranjeros. Las JAIIOs se organizan como un conjunto de simposios separados, cada uno dedicado a un tema específico, de uno o dos días de duración, de tal forma de permitir la interacción de sus participantes.

Como siempre hay amplia variedad de simposios, incluyendo:

  • ASAI 2011 - Simposio Argentino de Inteligencia Artificial
  • ASSE 2011 - Simposio Argentino de Ingeniería de Software
  • AST 2011 - Simposio Argentino de Tecnología
  • CAI 2011 - Congreso Argentino de AgroInformática
  • CAIS 2011 - Congreso Argentino de Informática y Salud
  • HPC 2011 - High Performance Computing
  • JII 2011 - Jornadas de Informática Industrial
  • JSL 2011 - Jornadas Argentinas de Software Libre
  • JUI 2011 - Jornadas de Vinculación Universidad-Industria
  • SID 2011 - Simposio Argentino de Informática y Derecho
  • SIE 2011 - Simposio de Informática en el Estado
  • SIO 2011 - Simposio Argentino de Investigación Operativa
  • SSI 2011 - Simposio sobre la Sociedad de la Información
  • WSegI 2011 - Workshop de Seguridad Informática
  • EST 2011 - Concurso de Trabajos Estudiantiles

Para los interesados en proponer trabajos para cualquiera de estos simposios, ya está abierta la recepción, que cierra el 2 de mayo. Para comprender bien el proceso de presentación (necesario por el enorme volumen de presentaciones), lo ideal es seguir las instrucciones detalladas en la página de cada simposio (por ejemplo, la del de Ingeniería de Software). Implica crear primero credenciales individuales (si no se presentó un trabajo previamente en otras JAIIO), y luego hacer la presentación de la o las propuestas.

Dejo un breve video mostrando el mecanismo para la edición pasada, ya que el proceso sigue siendo igual.

 

 

martes, 2 de noviembre de 2010

Framework liviano de aseguramiento de calidad para PyMEs

Parte de la Presentación

Mis amigos Ariel Schapiro y Nicolás Páez presentaron en las últimas JAIIO este trabajo sobre un mecanismo de control de calidad de ejecución en equipos ágiles.

Pasó bastante tiempo desde la conferencia, pero recién hoy, a través del blog de Ariel me entero donde estaba publicado el paper, que quería compartir con ustedes, aunque está en inglés. Pueden ver también la presentación que hizo Nico al respecto recientemente en Dublin.

Lectura recomendable, y los interesados en discutir estos temas con los autores, recuerden que pueden llegar a encontrarlos en alguna de las reuniones mensuales en Buenos Aires del grupo Agiles (ver calendario para conocer cuándo y dónde son las próximas reuniones).