En cierto modo es comprensible, siendo un país pobre, enfocamos todo lo que hacemos al lucro personal. Pero aún así, sorprende encontrar que el porcentaje de OS producido y consumido en RD está por debajo del 2% (y sinceramente creo que soy conservador).

No tenemos la voluntad, ni la disposición para crear y dar seguimiento a ningún tipo de software OS, lo cual es una lástima pues de allí han salido ideas estupendas.

Hablamos y nos regocijamos en el Open Source, nus lucramos enormemente del mismo, pero no tenemos la iniciativa para iniciar un proyecto con el fin de regresar un poco de lo que el OS nos ha brindado.

Ultimamente puede parecer que sólo critico a RD en mis posts, pero precisamente porque amo este país es que entiendo que debo hablar sobre lo que está mal pero que nadie habla.

Me gustaría conocer algunos proyectos Open Source nacidos en RD, si alguien tiene alguno para compartirlo, pueden dejarlo en los comentarios.

10. Comentarios que explican el “cómo” pero no el “porqué”

Esto es típico, estamos programando en el código de otro y nos encontramos con esto:

r = n / 2; // Set r to n divided by 2
// Loop while r - (n/r) is greater than t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

Y el principal problema con esto es que yo entiendo lo que hace el código, si estoy trabajando con tu código es porque sé cómo funciona un while(), lo que no entiendo (y necesito entender) es con qué objetivo usaste un while en esta parte del programa. A veces cuando comentamos no nos detenemos a pensar la relevancia del comentario, sino que como está comentado ya estamos cumpliendo, tomen por ejemplo el código anterior, cambiemos el comentario y veamos si entendemos algo.

// square root of n with Newton-Raphson approximation
r = n / 2;
 
while ( abs( r - (n/r) ) > t ) {
    r = 0.5 * ( r + (n/r) );
}

Ok, para muchos seguirá siendo incomplensible, pero para un programador al menos nos pone en el camino correcto de qué hace este bloque de código. Es una de las peores cosas de trabajar con el código de otro.

9. Interrupciones

Muy pocos programadores pueden ir de 0 a código en un instante. Por lo general un programador toma tiempo para introducirse en el código, pero una vez que lo hacemos podemos escribir miles y miles de líneas de código semánticas sin detenernos. Desafortunadamente es muy dificil entrar en la zona de programación cuando estamos siendo constantemente distraídos por clientes, compañeros de trabajo o jefes todo el tiempo, incluso otros programadores.

Algo que aprendí en mi trabajo en comuniQue es que lo mejor para programar definitivamente es desconectarse del resto del mundo.

Mientras programamos debemos manejar demasiada información en nuestra mente, es decir, antes de comenzar debemos tener una visión del objetivo final y luego separar ese objetivo en partes y trabajar en pequeñas porciones, pero cada porción debe ir de la mano con las demás para que mantengan concordancia. Esto es algo dificil de entender para la mayoría de los no-programadores. Las distracciones nos sacan de nuestra área y generalmente toma demasiado tiempo volver a ella.

8. Scope creep

Desde Wikipedia:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

No tengo mucho que decir de esto, solo pensarlo me pone los nervios de punta…pero miremos un ejemplo práctico que Kevin da:

• Versión 1: Mostrar un mapa de la ubicación
• Versión 2: Mostrar un mapa 3D de la ubicación
• Versión 3: Mostrar un mapa 3D de la ubicación en la que el usuario pueda navegar

Así de sencillo un requerimiento que en el primer planteamiento fue relativamente sencillo y de unas pocas horas de integración se convirtió en un total dolor de cabeza para cualquier programador. Este tipo de “adiciones” a un requerimiento generalmente ocurren durante el desarrollo y esto requiere reescribir, reestructurar y a veces votar porciones de código que previamente teníamos.

7. Gerencia que no entiende de programación

Resumiendo: Cuando la gerencia no conoce ni los conceptos básicos de nuestro trabajo, terminamos con Scope Creep, deadlines irrealistas y en general frustración de ambos lados de la mesa. Esta es una queja común entre programadores y la fuente de mucho enojo.

6. Documentar nuestras aplicaciones

Ok, desde siempre se nos ha dicho que debemos documentar todas nuestras aplicaciones, pero es un dolor en el @$$, miren todos los programas open source que hay en internet, qué es lo que normalmente buscan cuando alguien se ofrece a ayudar…”escribir la documentación”.

La causa de esto es simple, para cualquiera que esté en este trabajo es porque disfruta este trabajo. Siendo realistas, nadie escribiría 3786 lineas de código de no disfrutarlo. Documentar no es parte de nuestro trabajo, estamos a gusto escribiendo código que solo unos pocos entienden, pero la verdad carecemos de la capacidad de escribir una documentación que cualquiera pueda entender…a la hora de escribir documentación no podría hacerlo alguien más?

5. Aplicaciones sin documentación

Si, es una contradicción completa al punto anterior, estamos de acuerdo en que odiamos documentar, pero eso no significa que no la necesitemos.

4. Hardware

Es un error común el creer que solo porque somos programadores podemos reparar una computadora que no sube, una impresora que no imprime o una máquina que no tiene acceso al servidor. En muchos casos es cierto, pero en muchos otros no. Los no-programadores o en este caso no-informáticos en general tienden a creer que cualquiera que trabaje con algo relacionado a las computadoras debe saber repararlas, y esto no es cierto.

Un programador solo desea que las cosas funcionen  como deben de funcionar para que podamos seguir con nuestro trabajo. Esto pasa en compañías que tienen programadores pero no tienen nadie encargado de TI, así que en muchas ocasiones el programador debe dejar de programar y pararse a ayudar a un vendedor que no puede abrir una presentación de powerpoint en su pc, siendo que la presentación es para 2007 y la pc tiene 2003…y eso, eso es frustrante!

3. Vaguedad

Antes que todo si, la palabra existe.

Ahora al punto, “el website no funciona”, “no puedo loguearme”. Es un caos trabajar con requerimientos vagos. Es sorprendente ver como los no-programadores se ponen cuando se les pide que reproduzcan el error para el programador. Parecen no entender que “está dañado, repáralo” no es suficiente información para resolverlo.

Por eso muchas veces se dice “intenté reproducir el error y no logré hacerlo, por tanto, todo está funcionando correctamente“, esto no significa que el programador sea vago, significa que necesitamos saber el navegador, el sistema operativo, la velocidad de conexión, los datos que se estaban introduciendo, desde donde y hacia donde se dirigía cuando surgió el problema, si los CAPS Lock estaban activados o no, si el teclado es en inglés o en español…todo esto es necesario para poder encontrar y reparar un error.

2. Otros programadores

No comentarios en este punto…el título es muy obvio.

1. El código propio, 6 meses después

Para un no-programador puede ser dificil entender este punto, pero la base de un buen programador es la evolución constante. Un programador que no evolucione en 6 meses ya no puede llamarse a si mismo programador.

Lo cierto es que cada vez que tenemos que volver a trabajar en una aplicación que hicimos hace 6 meses o un año, muchas veces preferimos escribir el código desde 0. Esto no es malo, es solo que a un programador le cuesta mucho seguir las malas prácticas, la tecnología y la programación como tal evolucionan, la forma de hacer algo hoy es mucho más sencilla que la forma de hacer eso mismo hace 6 meses, por tanto es repulsivo tener que trabajar con un código no óptimo.

Les pongo un simple ejemplo, en cierto proyecto necesitaba mostrar una fecha en español desde la base de datos. Este fue el primer código que usé:

$fecha = explode(" ",$item['fecha']);
$date = explode("-",$fecha[0]);
$time = explode(":",$fecha[1]);
$dia = date("l", mktime($time[0], $time[1], $time[2], $date[1], $date[2], $date[0]));
$search = array("Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday");
$replace = array("Domingo","Lunes","Martes","Miércoles","Jueves","Viernes","Sábado");
$dia = str_replace($search,$replace,$dia);
$mes = date("M", mktime($time[0], $time[1], $time[2], $date[1], $date[2], $date[0]));
$search2 = array("Jan","Apr","Aug");
$replace2 = array("Ene","Abr","Ago");
$mes = str_replace($search2,$replace2,$mes);
$meridiano = date("a", mktime($time[0], $time[1], $time[2], $date[1], $date[2], $date[0]));

Rústico si, pero funcionó bastante bien. Luego perfeccioné ese código, en un nuevo proyecto descubrí que puedo lograr el mismo resultado con el siguiente código:

setlocale('es_ES');
strftime('%A %d de %b del %Y a las %X',strtotime($item['fecha']));

Cool eh? Acabo de convertir 12 líneas de código en 2…imagínen mi impresión cuando tuve que volver a trabajar con el primer proyecto y me encontré con ese código…qué creen que hice, lo dejé tal cual y resolví el asunto o lo cambié por el nuevo código? Por supuesto que lo cambié, si no lo hubiera hecho no habría podido dormir esa noche (si, así de grave es mi caso), en este caso no vale eso de que si no está roto no lo arregles, porque desde el punto de vista de un programador SI ESTA ROTO.

Estas son las 10 cosas que molestan a un programador según Kevin William Pang, ahora les expreso otras 6 cosas que molestan a un programador según Gustavo Villavizar.

6. La superposición del cliente

La superposición del cliente indica cuando un cliente solicita un nuevo feature a una aplicación, el contacto del cliente le dice “Ok”. Esa persona no hace preguntas, no sabe hacerlas, por tanto le queda al programador la tarea de realizar ese requerimiento sin importar si conviene o no, si es factible, si es posible, pero hay que hacerlo porque ya se le dijo al cliente que si.

5. Trabajar con el código de otro

Este caso indica una relación entre varios puntos que he mencionado antes…es dificil trabajar con el código de otro.

4. Demasiados nodos en la cadena

Esto es demasiado común. Cuando hay muchos intermediarios entre el cliente y el programador se hace mucho más dificil desarrollar los requerimientos del cliente. El cliente hace un requerimiento, tarda mucho tiempo en llegar al programador y si el programador lo rechaza tarda mucho en llegar de nuevo al cliente, en esta etapa el cliente entiende que al haber pasado tanto tiempo su requerimiento fue aceptado y que se está trabajando en eso, es problemático cuando se le cambia la idea al cliente con la respuesta del programador.

3. Gente que cree que sabe programar

Un ingeniero de sistemas graduado en 1993, un programador de Cobold, un programador de aplicaciones Win32 que creen que saben cómo programar para web…¡esto es fatal! Por favor entiéndelo, Windows y la Web no funcionan igual.No eres programador web así que deja de pensar que entiendes mi trabajo o pero aún, que sabes más que yo del mismo.

Esta es una de las principales razones por las cuales un programador independiente rechaza un proyecto luego de haberlo iniciado, no es por falta de responsabilidad, es que se vuelve imposible trabajar así.

2. Clientes que lidian con términos complejos de los cuales no entienden

A veces, cuando las estrellas se alínean, algún no-programador lee un post sobre programación o escucha una conferencia y aprende términos nuevos, y los quieren usar.

Cuando te piden un proyecto minimalista como el website de Apple, generalmente quieren una página con fondo blanco y muchas imágenes. Cuando te piden que el proyecto tenga la tendencia KISS pero que tenga 13 mil features, cuando te piden que la página sea fácil de usar pero que tenga comunicación de marca, etc.

1. Cuando creen que el programador también es diseñador y hasta copywriter

¿Alguien se siente identificado con esto? El cliente hace un requerimiento y el programador debe realizarlo, integrarlo con el diseño y escribir el texto correcto en el website…cuesta trabajo decirle a un cliente que somos programadores, no diseñadores ni copywriters, y peor aún es cuando se lo has dicho en los dos requerimientos anteriores y en este tienes que repetirselo.

Leyendo todo el post nuevamente parece una especie de rabieta, pero estoy seguro de que mis colegas programadores y algunos no-programadores se sentirán identificados con algunos de los puntos que expreso en esta entrada.

Si olvidé alguno, son bienvenidos a expresarlos en los comentarios.

Los chicos de Microsoft están haciendo esfuerzos para que todos los usuarios de su navegador actualicen a la última versión, para lo cual han implantando estrategia basada en actualizaciones mediante Windows Update.

A partir de la siguiente semana los usuarios de Windows Server 2008, 2003, Windows Vista y XP recibirán aviso automático de Windows Update para pasarse a la última versión del navegador, constando como una actualización de Alta Prioridad para los sistemas XP y Server 2003 y actualización Importante para Vista y Server 2008.

Ahora bien, estos de Microsoft siempre dan una de cal y otra de arena. No entiendo por qué, a la vez que sacan esta estrategia, también presentan un pequeño programa para que quien quiera pueda bloquear la instalación de IE8. Creo que es hora de que todos los usuarios se actualicen sin condición, si no corremos el peligro de lo que hemos vivido hasta la fecha: muchos usuarios funcionando aún con la arcaica versión 6 de Internet Explorer.

Esperemos que esto surta efecto y la gran mayoría se pase a Internet Explorer 8, la última versión y por lo tanto la más “fina” y a la que se le dará soporte de fallos, seguridad etc.

Fuente: Bitelia

No puedo decir más que ojalá y esto sirva para reducir la quota de mercado de IE6. De nuestra parte solo nos queda, ayudar a Microsoft con esta medida.

Bien, para empezar. La iniciativa se llama NOIE6Day y consiste en que a partir de un día en específico (por ahora el 18 de Octubre del 2009) los sitios que sigan la iniciativa se motrarán sin estilos CSS a los visitantes que entren con Internet Explorer 6.

¿Porqué una iniciativa para descontinuar IE6, si yo lo uso y funciona?

Pues es relativamente simple, IE6 es la pesadilla de los desarrolladores.  Los avances tecnológicos son muy buenos pero los usuarios de IE6 nos frenan en nuestro avance, pues por mucho que querramos usar nuevas y mejores tecnologías debemos detenernos y perder horas, días o hasta semanas de tiempo para poder hacer nuestros trabajos compatibles con ese explorador.

Si hoy en día la mayoría de las páginas de internet funcionan en IE6 es por la dedicación de muchos desarrolladores al sentarse días y días a hacer que sus aplicaciones funcionen también en IE6 (es decir, hay que dedicar tiempo extra sólo para que la página funcione también en IE6).

Pero incluso no este el principal motivo, sino que muchas veces para lograr buena integración debemos restringir ciertas acciones o efectos a los usuarios de IE6, así que en muchos casos al navegar con IE6 se pierden detalles de un website, que si bien no son vitales, no está en la idea de un desarrollador que cierto grupo de sus usuarios no puedan ver algo que pensamos e ideamos y desarrollamos para ellos.

¿Y porqué no desarrollan para IE6?

Porque nos limita y nos atraza. IE6 no se actualiza desde el año 2004. No es culpa de los desarrolladores que IE6 sea un atrazo tecnológico, sino de los usuarios que aún lo usan. Es como andar en caballo en estos días.

¿Y qué hago si quiero cambiarme?

Hay muchas mejores alternativas en internet completamente gratis, más rápidas y seguras.

De parte de Microsoft tenemos: Internet Explorer 8

De parte de Apple tenemos: Safari

De parte de Google tenemos: Google Chrome

De parte de Mozilla tenemos: Firefox

Y hay más en internet. Alternativas hay cientos.

¿Cómo sigo la iniciativa?

En el siguiente enláce encontrarán toda la información necesaria.

Por mi parte seguiré la iniciativa, a partir del 18 de octubre ninguno de los sites que haga tendrán hojas de estilo en IE6.

¿Alguién se une a la iniciativa?

Por muy avanzado y por mucho que trate de adaptarse a los estándares de Internet, la nueva versión 8 del navegador de Microsoft todavía tiene mucho camino que recorrer para arreglar lo que una vez rompió.

Oficialmente, Microsoft dice que su versión candidata a la final, la RC1, no es compatible con más de 2.400 sitios importantes, o sea, de gran tráfico.

Del total de la lista, los sitios incompatibles más conocidos son:

• microsoft.com
• google.com
• yahoo.com
• msn.com.cn
• live.com
• youtube.com
• thepiratebay.org
• wikipedia.org
• flickr.com
• wordpress.com
• sony.com
• adobe.com
• facebook.com
• imdb.com
• dell.com
• nytimes.com
• apple.com

Me parece increíble, incluso me atrevo a decir que con IE8 han dado pasos hacia atrás con respecto a la versión 7 (que al menos había adoptado algunos estándares).

Y lo más curioso de todo es, explíquenme, cómo puede cualquier browser ser no compatible con google.com!?

Vía: FayerWayer