Bitácora del Desarrollador: septiembre 2007

miércoles 26 de septiembre de 2007

Las leyes de máxima fatalidad

A fin de inaugurar una nueva etiqueta "El programador es prácticamente un ser humano" reuní unas cuantas máximas relacionada a nuestro trabajo que siempre aplican, y aquí están;

  • Puedes hacer que tu software sea a prueba de errores, pero no podrás hacerlo a prueba de idiotas.
  • Los proyectos con objetivos difusos, van bien para evitar el compromiso de tener que estimar los costos. (Primera ley de Golub sobre la informática)
  • Un proyecto planificado sin precisión tarda tres veces más en acabarse de lo que se espera, un proyecto planificado cuidadosamente tarda el doble de lo previsto. (Segunda ley de Golub sobre la informática)
  • El esfuerzo requerido para corregir el curso de un proyecto se incrementa geométricamente en función del tiempo transcurrido. (Tercera ley de Golub sobre la informática)
  • Los equipos de proyectos, odian hacer informes semanales sobre la evolución del proyecto porque padecen claramente de la falta de avances. (Cuarta ley de Golub sobre la informática)
  • Cualquier problema sencillo se convierte en insalvable, si se hacen las suficientes reuniones para discutirlo. (Ley de Mitchell sobre las comisiones)
  • Cualquier programa, cuando funciona, es obsoleto. (Primera ley de la programación)
  • Todos los programas cuestan más y tardan más tiempo de lo esperado. (Segunda Ley de la programación)
  • Añadir más mano de obra a un proyecto de software que va retrasado, lo retrasa todavía más. (Ley de Brook)
  • Si tu proyecto no funciona, revisa la parte que te parecía que no era importante. (Ley de Biondi)
  • Cualquier idea simple puede ser redactada de la manera más complicada. (Ley de Malek)
  • No hay ningún trabajo tan sencillo, que no se pueda hacer mal. (Ley de Perrusell)
  • Los gastos crecen siempre hasta alcanzar los ingresos. (segunda ley de Parkinson)
  • Las excepciones confirman la regla... y desarman el presupuesto. (Ley de Milles)
  • El progreso se lleva a término un viernes sí, otro no. (Primera ley de Weinberg)
  • Nunca sabes quién tiene razón, siempre sabes quien manda. (Ley de Whistler)
[http://www.calidoscopio.com/calidoscopio/principal36.htm]

lunes 17 de septiembre de 2007

Compramos dominio

Sacamos el cocodrilo del bolsillo y compramos dominio !!!
La Bitácora del Desarrollador tiene dominio propio, por lo que a partir de hoy http://desarrollador.org/ estará asociado a este blog.

Saludos.
[Bitácora del Desarrollador]

jueves 13 de septiembre de 2007

robots.txt en blogger.com

Verificando el blog, encuentro que ahora blogger incluye un robots.txt con las lineas:

User-agent: *
Disallow: /search

Esto significa que los amigos de blogger.com impiden que los buscadores indexen todo el contenido bajo la ruta http://tudominio.com/search.
En otras palabras, los buscadores no indexaran tus etiquetas (labels).

Parece que blogger no duda en ser autoritario, ya que ni siquiera tienes la opción de modificar dicho archivo.

Realmente no entiendo cual es la justificación de implementar esta restricción, sin siquiera consultar a los autores.
Parece algo poco inteligente, porque el contenido que archivo si pude indexarse.
Se supone que si clasifico en categorías, es porque será de más utilidad para el lector, ¿no?

Dado a que tu blog es propiedad de blogger.com y este no permite modificar la mencionada restricción, podríamos interpretar la acción de blogger como; al que no le guste que se vaya

Al Sr. responsable de dicho Disallow; bien igual

martes 4 de septiembre de 2007

X Jornadas Estudiantiles - Facultad Ingeniería - ORT

El 19 de setiembre se realizarán las décimas Jornadas Estudiantiles de la Facultad de Ingeniería (JEFI).
"Las JEFI son un espacio en el que año a año, estudiantes de las diferentes carreras de la facultad presentan trabajos y proyectos que por sus características son de interés general"

Entre presentación de proyectos y trabajos, se realizará el concurso de programación y el concurso de programación robótica. El concurso de programación seleccionará a los equipos que representarán a ORT en la Final Sudamericana del Concurso Internacional de Programación de ACM.

Creo que es un evento al que vale la pena asistir, por lo que dejo aquí un link a la descripción provista por los autores de las charlas para que puedas comprobarlo.

[Programa Matutino-Vespertino]
[Programa Nocturno]
[http://athenea.ort.edu.uy/publicaciones/JEFIS/jefis2007/]

lunes 3 de septiembre de 2007

Ajax, límites en conexiones concurrentes

Como todos ya sabemos, AJAX es acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML). Dicha asincronía consiste en la comunicación asincrona con el servidor en segundo plano. Pero esta comunicación tiene limitaciones en cuanto al numero de conexiones simultaneas.
En el caso de HTTP 1.1; por defecto los browsers limitan a dos conexiones simultaneas a un mismo servidor o proxy según recomendaciones de la especificación de HTTP 1.1 (RFC2616).
En el caso de HTTP 1.0, por defecto son cuatro conexiones.

Por lo tanto, cuando usamos las técnicas AJAX, estamos sujetos a estas limitaciones porque usamos como base el browser, no importando si usamos una librería que nos ayude a hacer peticiones tales como XMLHttpRequest, Ajax.NET, AjaxPro, etc. porque la limitante es el browser.
He leído en muchos blogs de personas que hablan de concurrencia y muestra ejemplos, pero ninguno de ellos contempla esta situación. ¿Será que hasta ahora muy poca gente se habrá dado cuenta de este problema?

En condiciones normales, al disparar varias Calls de forma asincrónica, se ejecutará las dos primeras y las restantes quedaran en standBy hasta que una de las dos finalice.

Veamos la siguiente imagen para explicarlo de una forma más gráfica.


Lamentablemente esto es así, pueden probarlo. Lo que no está claro, por que la especificación HTTP recomienda estas limitaciones, siendo que esto afecta toda la navegación, inclusive imagenes y demás elementos.

¿Entonces que podemos hacer para solucionar el problema de concurrencia cuando implementamos Ajax en nuestra aplicación Web?

Para dar solución al límite de request simultáneos desde un mismo cliente, optaremos entre dos soluciones poco felices;

  • Modificar la registry del cliente.

  • Podemos hacer invocaciones a diferentes servidores o mismo servidor con diferente DNS.

Modificar la registry en el cliente normalmente es una soluciones poco viables -valida para soluciones en Intranet o ambientes controlados-.
Para ello es necesario agregar los siguientes registros en la registry del cliente;
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

MaxConnectionsPerServer REG_DWORD (configuración predeterminada 2) Establece el número de solicitudes simultáneas en un Single servidor HTTP 1.1

MaxConnectionsPer1_0Server REG_DWORD (configuración predeterminada 4) Establece el número de solicitudes simultáneas en un Single servidor HTTP 1.0

Nota: Modificar el numero de solicitudes simultanea a un servidor impactará para todo el contenido navegado dentro del browser. Estos valores se contienen para un usuario concreto y no tendrán efecto en otros usuarios que inician una sesión en el equipo.


Por otra parte, la solución mas viable sería hostear las páginas que se consultarán de forma asincrónica en otro servidor, o en otro WebSite dentro del mismo server. Para ello debemos contar con varios DNS tipo A.
Es decir que con dos DNS tipo A, podemos hacer hasta cuatro invocaciones simultaneas de forma asincrónica (HTTP 1.1).

Aquí puedes descargar un ejemplo donde se hacen invocaciones asincrónicas utilizando XMLHttpRequest, donde podrás evaluar los tiempos de respuesta de cuatro Calls lanzados simultaneamente.

Implementando una de las dos soluciones anteriormente mencionadas, la ejecución de Calls será de la siguiente manera;




Autores: Sebastián Dopico, Diego Osores, Neri Custodio.

[http://support.microsoft.com/kb/183110]
[http://www.ajaxtoolbox.com/request/examples.php]

sábado 1 de septiembre de 2007

Libro: Ajax Design Patterns

Esta semana comencé a leer el libro [Ajax Design Patterns]. Como su nombre lo dice trata patrones de diseño utilizados en técnicas Ajax de un modo general.
El libro tiene un nivel de dificultad medio. Está muy bien diagramado, permitiendo que el lector logre una lectura ágil, dinámica y clara, sobre temas precisos y cotidianos.
Un libro en el que se puede encontrar la información buscada fácilmente y de forma claramente estructurada.

Muy recomendable; principalmente para aquellos que suelen esperar a que ajax.net -o similar- publique un nuevo control en el toolkit que solucione sus problemas, comiencen a descubrir como realmente funciona esta técnica...

[Ajax Design Patterns]