sábado, 31 de enero de 2009

Un viejo conocido: Comunicado del Jefe.

cadenas-correo ¿Se acuerdan de esto? Seguro que lo han visto alguna vez dando vueltas por su casilla de correo. Debe ser una de las primeras cadenas que recibí por mail… ¡y ahora vuelve para perseguirlos en forma de post!

De : PRESIDENTE
Para : GERENTE GENERAL
El lunes próximo a eso de las siete de la tarde el cometa Halley se hará
Visible. Es un acontecimiento que ocurre cada 78 años. Reúna a todo el
personal en el patio de la fábrica -todos usando casco de seguridad- que
allí les explicaremos el fenómeno. Si llueve, este raro espectáculo no podrá ser visto a ojo desnudo, en ese caso entraremos al comedor donde será exhibido un documental sobre ese mismo tema.

De : GERENTE GENERAL
Para : JEFE DE PRODUCCIÓN
Por orden del presidente el lunes a las siete aparecerá sobre la fábrica el
cometa Halley. Si llueve reúna a los empleados con cascos de seguridad y
llévelos al comedor, donde tendrá lugar un raro espectáculo, que sucede
cada 78 años a ojo desnudo.

De : JEFE DE PRODUCCIÓN
Para : SUPERVISOR
A pedido de nuestro gerente general, el científico Halley de 78 años
aparecerá desnudo en el comedor de la fábrica usando casco, porque va a ser presentado un documental sobre el problema de la seguridad en días de lluvia.

De : SUPERVISOR
Para : ASISTENTE
Todo el mundo desnudo -sin excepción- deberá estar en el patio el lunes a las siete, donde el famoso músico Halley mostrará el vídeo “Bailando bajo la lluvia”. El show se presenta cada 78 años.

De : ASISTENTE
Para : PERSONAL DE PLANTA
El jefe cumple 78 años el lunes y habrá una fiesta en el patio y el comedor con el famoso conjunto Bill Halley y sus cometas. Todo el que quiera puede ir en pelotas pero usando casco, porque se va a armar un flor de webeo aunque llueva.

Una anécdota sobre la percepción de seguridad.

La entrada Experto que acabo de sacar y el comentario que hizo en ella Senior Manager remarcando el término “percepción” me hicieron acordar de…

una anécdota: tenía… 19 o 20 años y trabajaba de “Ayudante de Sistemas de Control Operativo”. Básicamente era el que “sabía de computadoras” a la hora de elaborar informes ad-hoc y programar pequeños procesos de depuración o lo que hiciera falta.

Resulta que el gerente del que dependía ascendió en la estructura, y dedicó uno de sus últimos días a borrar sus cosas personales de la computadora y la red. En un momento me llamó –nos llevábamos bien, por suerte- y me dijo:

-¿Podrías grabarme los archivos que están en mi carpeta personal de la red –súper personal, súper secreta y privadísima del gerente- a un disco?

Se refería a un ZIP, o a algo igualmente obsoleto ahora, supongo.

-Ok –dije, di media vuelta y me fui sin más preguntas ni comentarios a hacer mi tarea... ¿Se entiende?

Y supongo que ésa fue la última vez que el tipo guardó un archivo con información privada o delicada en una red corporativa.

Saquen sus conclusiones. Yo usaría Google Apps.

viernes, 30 de enero de 2009

My precious treasure.

No es tanta la gracia del WTF como la genialidad de Alvy con los títulos...

Jeguitos de Viernes: The Fancy Pants Adventure.

The Fancy Pants Adventure es uno de los mejores juegos de aventuras en flash con los que me he cruzado hasta ahora. Muy en la onda del Run pero en un escenario caricaturesco, muy bien logrado.

fancypants

Después de unos instantes de torpeza inicial, se vuelve vertiginoso, y muy, MUY adictivo.

Experto.

Un buen disparador el post ¿Es Senior Manager un “experto”?,  por la anécdota y también por los comentarios (iba a meter el mío pero está todo dicho, especialmente en el de José Carlos Amo Pérez, el primero).

Son dos los temas que me quedan dando vueltas:

  1. ¿Escribir en un blog refuerza una percepción de “experticia” sobre nosotros de parte de la gente que nos rodea?
  2. ¿Cuándo puede considerarse uno un “experto”?

Para la primera tengo la sensación de que sí, definitivamente (buen momento para aclarar que estamos hablando de percepciones, no de realidades ni opiniones sobre mí mismo).

Sobre todo en un blog más bien tirando a “serio” como es el caso de Senior Manager. A mí, aunque a veces me dicen que escribo “lindo” (gracias) no me han señalado de experto muy seguido (por no decir nunca sin un par de copas encima). Supongo que entradas como ésta no ayudan.

Pero no es el hecho de escribir en un blog lo que refuerza la percepción de experticia sino el hecho de escribir, a secas.

Mucho tiene que ver (creo) el que muy pocas personas pueden producir texto de cierta calidad en términos de estructura, claridad, vocabulario, etc.

La mayoría de los profesionales puede escribir correctamente pero usualmente sólo produce texto orientado a lo laboral o a la coordinación más que a exponer un tema a una audiencia anónima y más o menos amplia. Escriben cartas, mails, informes…

Es decir, si bien pueden llegar un artículo o un comentario académico en general no lo hacen. O no con la frecuencia y el feedback suficiente (que da un blog, por ejemplo) como para aceitar el estilo.

Y un buen número de personas no puede expresar absolutamente nada coherente en palabras escritas, y esto es grave. Cualquiera que tenga un blog o guste de leerlos o navegar por los foros se ha topado con algún (usualmente) simpático hoygan, lo que nos da una idea de su número.

Así, no es tanto el ser más o menos experto sino el grado en el que lo que sabemos –mucho o poco- se demuestra, y escribir bien ayuda.

En cuanto a la segunda pregunta, “¿Cuándo puede considerarse uno un experto?” me ha gustado la definición de uno de los comentarios del post referenciado: “Ser un experto en algo significa haber cometido todos los errores posibles” (en esa disciplina).

Supongo que porque me permite afirmar que me dirijo a serlo a pasos acelerados… soy programador, nosotros tenemos ventaja en eso de cometer errores.

100px-Teclearhastalamuerte

jueves, 29 de enero de 2009

Frankenstein, el líder de proyecto (IV).

ATENCIÓN: ¡No sigas si no has leído la tercera parte! Y si no has leído nada empieza por el principio.


[Resumen: El Viernes a la noche, analizando los resultados de su espionaje, Frankenstein finalmente descubre la Matrix: las personas no hacen exactamente lo que dice la planificación y por eso los proyectos se atrasan. Internet. Música. Cuestiones personales. “El Lunes será otro día”.]

Es difícil que los desarrolladores asignados a los proyectos de Frankenstein olviden ese Lunes gris por la mañana, gris por la tarde y oscuro por la noche… y las semanas que le siguieron.

Lo primero que notaron ese Lunes ceniciento fue que los parlantes de sus computadoras habían sido retirados. Al iniciarlas se sorprendieron al ver que la conexión a internet no funcionaba y al enviar un mail a soporte una respuesta automática los notificó de que sólo podían enviar y recibir correo desde y hacia la casilla de Frankenstein. Algunos intentaron utilizar los auriculares de sus teléfonos en las computadoras, sólo para notar –ya sin demasiada sorpresa- que también habían sido deshabilitadas las placas de sonido. Los teléfonos de escritorio no tenían salida al exterior, los celulares de la empresa ya no funcionaban.

Las pantallas tenían reservadas un par de sorpresas más: en cada terminal se desplegó una ventana desde la barra de tareas anunciando una asignación (“Formulario de ingreso de facturas – cálculo del impuesto – AJK 453”) y un intervalo de tiempo (“2 horas”). Una barra de progreso avanzaba inexorablemente hacia su final (“resta 1 hora, 59 minutos, 20 segundos”) y abajo de la barra un botón rojo indicaba “detener”.

Era inevitable presionar el botón con urgencia, casi todos lo hicieron. Aparecía un formulario solicitando el ingreso del “motivo por el cual ha dejado de realizar esta tarea”, brindando una serie de opciones. Éstas iban desde “problemas en los requerimientos” hasta “uso de las instalaciones sanitarias”.

Frankenstein ya estaba allí analizando atentamente la escena. ¿Por qué no empezaban? Entendió que debería explicar un poco la situación.

Reunió a sus equipos. Presentó los resultados de su investigación con indisimulado entusiasmo. Alguien preguntó “¿Nos estuviste controlando sin avisarnos, todo el tiempo… espiándonos?”. “Por supuesto. –respondió Frankenstein con énfasis- Preanunciarles mis estudios hubiese puesto en duda la veracidad de los resultados”.

Preguntas similares obtuvieron respuestas similares, y cuando todos estuvieron convencidos de que más allá de cualquier duda -“con las que continuaré trabajando”, decía el líder- las decisiones estaban tomadas, volvieron a sus puestos. Alguien dijo “Esto es siniestro”.

Ese Viernes por la noche Frankenstein salió de la oficina con paso ansioso hacia su estudio, apurado por revisar por primera vez desde los cambios el avance del proyecto.

Notó cierto retraso. Analizando las causas descubrió un sinfín de pequeñas cuestiones no contempladas, algunas de ellas aleatorias: un integrante del equipo se quedó dormido y llegó media hora tarde. Otro se descompuso y se retiró… veamos… dos horas antes. Otro derramó café sobre su teclado y el reemplazo insumió… veinte minutos. Algunas tareas habían llevado tanto más de lo esperado y otras menos…

Trabajó todo el fin de semana ajustando el proyecto con la minuciosidad de un cirujano. Los datos recabados daban una visión microscópica a partir de la cual pudo calcular los tiempos de las tareas con una precisión de segundos y estimar los imprevistos asignándoles una probabilidad y costo mucho más exactos.

Llegó el Lunes y el Viernes siguiente. El desvío total, la sumatoria de todos los pequeños desvíos individuales con respecto a la planificación resultó de… 30 minutos.

Frankenstein respiró hondo y por primera vez en mucho tiempo sintió el cansancio. Ajustó el proyecto reservando una hora, 13 minutos y 23 segundos para una reunión en la que esperaba mostrar sus resultados. Y durmió. Durmió como un bebé todo el fin de semana.

El Lunes, en 1 hora, 3 minutos y 10 segundos presentó el avance en la reunión a la que invitó no sólo a los desarrolladores sino también a sus superiores y a jefes de otras áreas. Los saludos de rigor insumieron 5 minutos y 22 segundos. Desde que se dio por terminada la presentación hasta que todos llegaron a sus puestos de trabajo pasaron 6 minutos y 10 segundos. Total: 1 hora, 14 minutos, 42 segundos. Desvío: 1 minuto y 19 segundos.

… continuará. Actualización: capítulo V.

miércoles, 28 de enero de 2009

Chiche nuevo: Acer Aspire One.

black-aspire-one-acer

- ¿Hoy no hay post?

- No… ayer me compré la Acer Aspire One.

- Eso explica las ojeras también.

Buen tema de excusa para escribir un primer post desde mi nuevo chupete electrónico, no muy cómodamente sentado en mi cama (todavía no me acostumbro), con la red inalámbrica recién configurada.

La necesidad: bueh, necesidad… lo que se dice necesidad… ninguna. Pero el fin de semana pasado estaba enganchado escribiendo la serie Frankenstein y hacía un lindo día afuera… y eso es todo. Creo que me terminó convenciendo esa imagen: escribir en un bar un poco menos encerrado que en este oscuro nido de cables.

Para escribir, leer sobre todo y algún que otro jueguito en flash una netbook tiene una excelente relación costo / beneficio.

La elección: en principio mi único requerimiento no negociable era la memoria: 1Gb, ni más ni menos. Eso garantiza un poco más que un buen rendimiento. Con esa restricción y tomando el rango de precios más bajo sólo quedan dos competidores (por lo menos aquí en Argentina): la finalmente ganadora Acer Aspire One y la Asus Eee PC.

Noten que pongo los links a MercadoLibre. Las grandes casas de electrodomésticos no pueden ni siquiera competir en ofertas y precios, no se molesten en averiguar allí. Entiendo que se enfocan a un público que no tiene cultura de compra online o a través de sitios de compra/venta, pero ese público disminuye año a año, los precios están muy alejados y hay vendedores con una reputación indiscutible (quisiera saber si alguna de esas cadenas obtendría un 95% de positivos en sus últimos 18.000 clientes… ni siquiera hay una fuente confiable a mano para esas estadísticas). Eso sin contar los comentarios elogiosos de compradores del mismo producto. Yo compro en MC mucho más confiado que en cualquier gran cadena de electrodomésticos (podrían tirarme unas monedas por este párrafo).

Volviendo a la comparación, la diferencia fundamental es que la Acer tiene un disco rígido de 160Gb y la Asus 16Gb Flash. Extrañamente (para mí) la vida de las baterías (de 3 celdas) es idéntica en cada caso: alrededor de 3 horas (y ya les digo que bastante menos con el uso normal). Ya que sobre ambas podemos correr tanto versiones modificadas de Linux como Windows XP, no vi ninguna otra característica técnica que pueda hacerle una verdadera diferencia al usuario final medio.

Primera impresión: no sé cómo va a andar, pero es muy linda y liviana.

La instalación: nada que decir… “siguiente, siguiente, siguiente” y sin problemas. Eso sí: pasé un buen rato desinstalando las versiones de prueba de McaFee, Office, el Adobe Reader y demás. Consideren la siguiente lista:

Y sin mencionar la miríada de productos gratis de Google, de la propia Microsoft (ya les mencioné el Live Writer) o para usos más específicos. ¿Qué más se podría necesitar en una computadora de estas características?

Día dos: la red wifi. Un sinsentido tener una netbook enchufada a la red hogareña por el RJ45… aunque también usarla en casa, al lado de mi pc (ahora apagada) de teclado ergonómico y monitor de 19 pulgadas wide (¡pero quiero usarla!). Así que el día dos fue el de la compra del router wifi.

Hacía mucho que no configuraba una red hogareña… un par de años como mínimo. Quedé gratamente sorprendido por la simplicidad de lo que hasta no hace mucho era tarea obligada para “técnicos de pc” (especie asimilable a los mecánicos de automóviles, con perdón de unos y otros). Enchufar y listo.

Tal vez el único punto objetable es la configuración por defecto sin seguridad o con cifrado débil que seguramente está detrás de varias brechas de seguridad.

“Y eso es todo lo que puedo decir por estos dos días”, escribo estirado en el sofá (encontré el lugar y la posición justa). Un poco de dolor de espalda (la cama no es el mejor lugar para escribir, ya aprendí) y de muñecas (hay que acostumbrarse a tener los codos apoyados y bien lejos del cuerpo, una posición rara, pero menos dolorosa). La posición del cuello (otro de mis problemas crónicos) es perfecta, con la netbook sobre las piernas y la pantalla bien tirada hacia atrás.

Prometo actualizar en un par de semanas, con una opinión más formada por el uso cotidiano.

lunes, 26 de enero de 2009

Frankenstein, el líder de proyecto (III).

ATENCIÓN: ¡No sigas si no has leído la segunda parte! Y si no has leído nada empieza por el principio.


[Resumen: Frankenstein se siente al umbral de una revelación y adopta un comportamiento huraño. Ve Matrix y la revelación se completa. “El problema es las personas”. Comienza a espiar todas las actividades de los trabajadores de la oficina mientras en apariencia vuelve a ser el que era.]

La cordialidad y buen humor de Frankenstein desaparecían al abandonar la oficina. En una brusca transformación que tenía lugar al entrar en su estudio volvía a una actitud huraña y reconcentrada. Hacía días que no dormía, pero sólo sus familiares y amigos más cercanos (ninguno tenía contacto con su trabajo) notaban el cambio.

Pasaba las noches analizando el producto de su espionaje. Páginas. Correos. Conversaciones. Sobre noticias, chistes, tecnología, nuevas herramientas. Amoríos de oficina, tensiones internas, salidas de mitad de semana hasta altas horas de la madrugada, borracheras, falsas enfermedades, trámites personales, problemas en casa. Nada escapaba a su control.

Finalmente, un par de semanas después -un viernes negro azabache que preanunciaba un fin de semana de tormenta- confirmó su teoría: las personas no trabajaban todo el tiempo. Y a veces trabajaban más despacio, y a veces se equivocaban, y a veces rehacían cosas que igual funcionaban, o se dedicaban más a unas tareas restándole tiempo asignado a otras.

El problema no era el proyecto, la planificación. El problema era que no se cumplía. ¡Por supuesto! No podía ser la planificación. Siempre había ajustado hasta el último detalle, hasta el último segundo y sin dejar nada al azar… fracasando una y otra vez en llegar justo a tiempo y en forma al final… por culpa de las personas.

El problema era, ¡claro! que no hacían lo que él escribía. Era obvio, tan obvio… Delante de esos ojos reconcentrados en la pantalla no siempre estaban las líneas de código que debían escribirse o el formulario que debía editarse sino… “GMail”, “Messenger”, “Microsiervos”. Detrás de esos ojos reconcentrados en la pantalla no siempre estaban los pasos intermedios para llegar a los resultados que él esperaba sino… música, aspiraciones, amoríos, problemas personales. Siniestro.

El Lunes –pensó-, el Lunes será otro día.”

…continuará. Actualización: capítulo IV.

domingo, 25 de enero de 2009

Generador de excusas para informáticos.

Una herramienta que no puede faltar en la cartera de la dama o el bolsillo del caballero informático. Tenemos aquí un generador de excusas para responder siempre y sin dudar a la pregunta más temida de todas: ¿Cuándo terminamos el proyecto?

excusas_informaticos

Y… “Apenas instalemos el último parche del recolector de basura de la base de datos”.

O… “En cuanto hayamos optimizado el código del gestor de peticiones del proxy inverso”.

Visto en Programador ASP.

sábado, 24 de enero de 2009

Leña del árbol caído: Maravilloso código.

Soy gran fanático de The Daily WTF. Desde hace un par de meses, casi todos los días paso de 10 a 15 minutos riéndome solo gracias a ese maravilloso basural de código.

Así y todo, en este tiempo no he encontrado un delirio cuya belleza y perfección superen las de este breve ejemplo que nos regala Diario de programación y que tengo… tengo que incluir aquí, en versión completa para mayor regocijo.

public byte[] getBytes (int valor) 
{
   byte [] a = new byte[1];
   switch (valor) 
   {
      case 0:
         a[0]=(byte)0;
         break;
      case 1:
         a[0]=(byte)1;
         break;
      case 2:
         a[0]=(byte)2;
         break;
      case 3:
         a[0]=(byte)3;
         break;
      case 4:
         a[0]=(byte)4;
         break;
      case 5:
         a[0]=(byte)5;
         break;
      case 6:
         a[0]=(byte)6;
         break;
      case 7:
         a[0]=(byte)7;
         break;
      case 8:
         a[0]=(byte)8;
         break;
      case 9:
         a[0]=(byte)9;
         break;
      case 10:
         a[0]=(byte)10;
         break;
      case 11:
         a[0]=(byte)11;
         break;
      case 12:
         a[0]=(byte)12;
         break;
      case 13:
         a[0]=(byte)13;
         break;
      case 14:
         a[0]=(byte)14;
         break;
      case 15:
         a[0]=(byte)15;
         break;
     default:
         a[0]=(byte)0;
   }
   return a;
}

No digan que no es una belleza… sobre todo si, por jugar, tratamos de hacer lo mismo con más fiaca para escribir y menos fuerza bruta:

public byte[] getBytes (int valor)
{ 
   return new byte[1] { 
      (byte)(valor >= 1 && valor <= 15 ? valor : 0)
   };
}

...eso suponiendo que sirva para algo hacer una función así.

El reino del revés. Primero tengo que ponderar a Microsoft por el Live Writer, ahora Google haciendo trastadas en FeedBurner.

Es así, así es la vida: todo gira, todo se panquequea.

Hace un tiempo criticaba a Microsoft mientras le decía adiós para siempre al IE. Hace apenas un par de entradas tuve que alabarlo por el excelentísimo Windows Live Writer.

Y ahora Google es quien me tiene la paciencia por el piso (por no decir las bolas) con su muy… desprolija -por decir lo menos- migración de plataforma en Feedburner, que combinada con Chrome es una experiencia frustrante (nunca pensé que escribiría esto de Google).

El tema es que luego de aceptar la migración sucedió lo más o menos esperable: estadísticas que no se actualizan, días perdidos, funcionalidades que no están (extraño el “Live Hits”, por algún motivo calmaba mi ansiedad), menos suscriptores (de todas maneras lo sospechaba un poco inflado, supongo que habrán ajustado los métodos)… pero bueno. Agua(ntarse) y ajo(derse).

La última, que colmó el vaso es: hago click en un ítem del feed de este blog, en el reader, me da un error (320) y luego el mismo cada vez que quiero acceder al blog, sea por el reader, sea directamente.

¿Mi blog inaccesible? Mfff… bueh, pasará. Pero por algún motivo, tal vez por instinto, para confirmar… abrí el Firefox y probé y… alivio, el blog funciona.

Ya más tranquilo, algunas pruebas. Conclusiones:

El problema se da con Chrome, sin importar el lector de feeds que estemos utilizando. Al hacer click en un ítem de un feed de Feedburner (solamente con los de Feedburner migrados), da un error (320) que impide llegar al sitio por cualquier vía hasta que vaciemos el caché del navegador (y las cookies, por las dudas).

¿Quejas exageradas? Bueno, son los estándares que Google mismo se ha impuesto, y que en general venía cumpliendo… la verdad que esta migración de FeedBurner me ha resultado una caja de sorpresas desagradables.

Veremos cómo queda en un par de semanas, cuando se estabilice la cosa.

viernes, 23 de enero de 2009

Jueguitos de Viernes: Double Wires.

En Double Wires tenemos que avanzar estilo spiderman por una suerte de laberinto psicodélico.

Simple y muy efectivo.

Frankenstein, el líder de proyecto (II).

ATENCIÓN: ¡No sigas si no has leído la primera parte!


[Resumen: Frankenstein tiene una revelación sobre los problemas en el resultado de sus proyectos. “El problema es las personas”, se dijo, y cayó rendido.]

No fue él mismo en esos días. En la oficina notaron el cambio pero nadie dijo nada. “Será la presión, algún problema”. Huraño y de mal humor, de vez en cuando emergía desde las profundidades de su planilla y recorría atropelladamente los pasillos, entrando a las oficinas de forma intempestiva para disecar a cada integrante del equipo con una mirada llena de recelo, dar media vuelta y salir.

Las personas, las personas… el problema… las personas”. Murmuraba constantemente.

Alguien -no un amigo pero sí un buen compañero- pensó que sería mejor distraerlo un poco. Sabedor de la renuencia de Frankenstein a todo lo que pudiera ser una pérdida de tiempo –todo menos trabajar y lo básico para vivir (es decir, para trabajar)- lo invitó con cualquier excusa, y de alguna manera logró sentarlo a ver una película, Matrix.

Frankenstein se acomodaba y reacomodaba, sintiéndose inútil y ansioso, pero prestaba atención. Hasta que Neo tomó su bendita pastilla y se despertó en la matrix. “Tengo que irme”, dijo y se fue sin más.

Entendió. La revelación estaba ahora completa.

Al otro día, al entrar en la oficina, se sintió envuelto en una atmósfera… no encontraba la palabra… ¿rara, gris, transparente, difusa? “Siniestra”, murmuró para sí. Nunca había utilizado esa palabra, y no creía conocer su significado, más allá de saber que era algo “malo”. Preguntó al aire “¿qué es siniestro?”. Uno de los programadores, sin levantar la vista de la pantalla, respondió: “cuando lo cotidiano se vuelve extraño”.

Sí, la revelación estaba completa. El problema es las personas.

Esa noche volvió a la oficina. Instaló un cliente silencioso de escritorio remoto en todas las máquinas, puso sniffers por toda la red, redirigió una copia de todo el correo a su máquina y se fue.

Por una semana todo volvió a ser como era. Estaba contento, descansado y de buen humor. “Lo de la película no funcionó, pero por lo menos los problemas pasaron”, se dijo aquel buen compañero de trabajo.

…continuará. Actualización: capítulo III.

jueves, 22 de enero de 2009

6 preguntas que HAY que hacer en una entrevista de trabajo.

El tema de las entrevistas de trabajo está siempre al tope de las visitas que llegan por los buscadores. Las palabras clave denotan que se buscan sobre todo “las preguntas que hay que hacer” desde ambos lados del escritorio.

Tampoco es cuestión de sacar un cuestionario mientras estamos siendo entrevistados. Pero hay preguntas que revelan la situación en que se encuentra la organización y el estado del puesto vacante para las que deberíamos buscar una respuesta.

Tenemos que recordar que, más allá de nuestras propias necesidades –que pueden ser acuciantes- debemos intentar saber  intuir en dónde nos estaríamos metiendo.

Senior Manager propone una muy buena lista de 6 preguntas que debemos hacer, bajo el sugestivo título de Las seis preguntas más temidas por un entrevistador:

  1. ¿Cuáles son las prioridades que tendría que encarar de forma inmediata en el puesto que me ofrecen?
  2. ¿Cuánto tiempo duró en el puesto la persona a la que estoy sustituyendo?
  3. Me gustaría saber sobre el tipo o estilo de gerencia de esta empresa.
  4. ¿Qué tipo de personalidad buscan o necesitan en esta empresa?
  5. ¿Cómo definirían a su empleado modelo o ideal?
  6. ¿Cuánto tiempo llevas tú o lleváis vosotros trabajando aquí?

Así que les recomiendo leer el post completo.

miércoles, 21 de enero de 2009

Van Gogh no vendió ni un cuadro en vida.

Tal es el título del post del Sábado 17 de Plétora de Piñatas. Una buena excusa para recomendar este webcomic.

443

martes, 20 de enero de 2009

Jugando al Space Invaders… ¿con un edificio?

Pues va a ser que sí…

Francamente increíble. Visto en WTF? Microsiervos.

Frankenstein, el líder de proyecto (I).

Frankenstein era un joven y prometedor líder de proyecto. En su corta pero intensa carrera había demostrado siempre un genio especial. Pragmatismo y adicción a los resultados hacían de él un cumplidor nato.

Pero el desarrollo de software es un negocio voraz e injusto. Frankenstein notaba que, a pesar de su esfuerzo y capacidad (no se caracterizaba por su modestia) pocos proyectos prosperaban. Incluso los que lo hacían mostraban fuertes desvíos respecto de sus –en su opinión correctas- estimaciones iniciales.

Encerrado en su estudio y en estas cavilaciones, en el último piso de un oscuro edificio de Buenos Aires, al levantar la vista por sobre la pantalla brillante de rojo de su planilla de planificación y dirigirla hacia la ventana hacia un atardecer violeta y anaranjado rodeado en el horizonte por nubes de tormenta, tuvo una revelación.

“Son las personas”, murmuró. “El problema no es el proyecto, ni la planificación, ni los tiempos, ni los cambios. El problema –se dijo- es las personas”.

Como agitadas por un maremoto vinieron a él las caras de los integrantes de su equipo, y la planilla con los horarios de entrada y salida. Vinieron sus voces comentando las salidas del fin de semana. Vinieron los datos de consumo de ancho de banda, de tiempos de sesión, de páginas solicitadas y de sitios visitados. Vinieron los ecos de extraños y atemorizantes nombres escuchados al pasar: “GMail”, “Messenger”, “Microsiervos”. Vino la música ¿de dónde salía esa música?

Esa noche durmió mal y poco. Se sentía inquieto, incómodo. Sentía que había visto algo… algo que no podía siquiera entender, algo para lo que no encontraba palabras.

… continuaráActualización: capítulo II

lunes, 19 de enero de 2009

¿Por qué renuncian los que renuncian a Google?

Parecer ser que se ha colado a TechCrunch (Why Google Employees Quit) una serie de posts de un foro abierto por Google en 2008 para preguntar a ex-empleados por qué renunciaron a la compañía. Habrá que ver si no es un fake, pero si TechCrunch lo da por bueno ya es bastante…

Leyendo salteado (la verdad que después de un par se hace un poco repetitivo y hay como 330 comentarios) confirmo el delirante proceso de ingreso a Google, no sólo por las preguntas sino por su duración (más de 5 meses).

También confirmo parte de lo que imaginaba en A great place to work: si bien parece ser que todo lo que brilla en Google es oro (se confirma la buena comida, el buen ambiente -en general-, los beneficios y todo eso), ese oro no es lo esencial al momento de valorar positivamente un ambiente laboral.

Odio decir esto porque por orgulloso me cuesta recular (como resumía la frase de Larry Wall que referenciaba en este post), pero termino apreciando a la pequeña pyme amarreta, desagradecida, descontrolada, delirante a veces, un poco chanta siempre… pero en la cual, finalmente, uno termina sintiendo que gana en experiencia de la “vida real” y aporta algo sustancial, ya sea o no reconocido por los demás.

En definitiva, ya sea en Google o en NN S.A., lo importante es levantarse con ganas todos los días pero sin olvidarse de que no es un barco. No hay que tener reparos en irse de ningún lado.

Vía Google Blogoscoped.

2 consejos 2: Cómo saber si tu monito está picando código y cómo evadir las preguntas del vago.

Uno para el líder de proyecto desconfiado y otro para el programador huraño de Lunes a la mañana. El primero viene de Sinergia sin control

48

Primero lean…

Muy identificado con la 5: música épica para mantener el ritmo, usualmente Nightwish, y la 7: al alcanzar la concentración absoluta ni me doy cuenta de que se acabó la música y quedo con los auriculares puestos todo el día.

Y el segundo consejo viene a cuento del primero (un truco y una confesión, total ya sabe todo el mundo): ponerse los auriculares sin música es bueno para hacerse el sordo y evitar las típicas preguntas del vago (que yo también las hago a veces): ¿Cuál era el código de format para la hora en 24? ¿Cómo era para mostrar una excepción en javascript? ¿Cuáles son los códigos de los estados de…? ¿Cómo es la sintaxis de las restricciones en la declaración de genéricos? La uso intensivamente, porque tengo la mala suerte de saber de memoria ese tipo de cosas.

Las preguntas del vago son esas que uno hace por fiaca de buscar en la ayuda, o en otra porción de código parecido. Si uno no se hace el distraído probablemente el vago prefiera buscar la respuesta por sí mismo antes de gastar más energías en llamar la atención.

Lo divertido es que las respuestas –cuando aparecen- suelen ser igual de vagas… el que responde también lo hace de memoria, usualmente soltando una chorrada de código oral que es imposible de reproducir, como por ejemplo:

-DespuésdeladeclaracionwhereTdospuntosnombredelaclaseointerfaz
delaquetienequederivarnewostructsihaymásseparadosporcomas”.

-¿Qué?

-Está en la ayuda.

Medir la calidad de los requerimientos.

Los requerimientos cambian. Todo cambia.

La revolución de las metodologías ágiles no ha hecho más que establecer el factor cambio como inherente al desarrollo e integrarlo en el proceso (a través de ciclos cortos de desarrollo, reuniones periódicas, programación de a pares, programación orientada al test y un sinnúmero de otras técnicas) en vez de combatirlo (con planeamientos detallados, seguimientos rigurosos, requisitos enciclopédicos, etcétera).

Sin embargo, “eXtreme Programming es un arma peligrosa”:

[…] Se suele utilizar XP menos para desarrollar que para defender lo indefendible y justificar lo injustificable por la supuesta búsqueda de "agilidad" […]

Hablando de requerimientos, tengo la sensación de que muchas veces se esconden gruesos errores bajo una alfombra maloliente etiquetada “cambios en el negocio”. ¿Cuándo hubo un cambio en el negocio y cuándo un error al elaborar los requerimientos?

No estoy hablando aquí de errores de interpretación de un término o de la existencia de ciertas áreas grises en las definiciones, porque errores de ese tipo se van corrigiendo en la medida en que avanzan las iteraciones y el equipo toma conocimiento del negocio.

Estoy apuntando a cuando se producen repetidamente (casi diría sistemáticamente) errores de procedimiento o metodológicos al efectuar los relevamientos o al producir y comunicar los requerimientos. Es decir, errores que afectan a todos y cada uno de ellos porque son fallas de los procedimientos, de la metodología o de las personas involucradas en su producción.

Me mencionaron alguna vez el caso de una empresa en la que los requerimientos llegaban en forma de gráficos perpetrados en un lenguaje pseudo-uml que ningún programador entendía. Finalmente, lo único útil del documento era el nombre del analista. Se fijaban quién era, lo llamaban y (si estaba disponible) le preguntaban qué había que hacer. Pero el problema era que esta charla informal no tenía ningún soporte ni revisión dentro del circuito de desarrollo, y usualmente los requerimientos se… digamos…. “modificaban” durante su transmisión. ¡Un fin de semana largo y su consecuente amnesia podía redefinir sustancialmente el proyecto!

Nótese que en presencia de este tipo de problemas las sucesivas iteraciones pueden alejarnos más y más de lo que el cliente quiere, porque el canal de comunicación entre él y el equipo de desarrollo está roto o tiene demasiado ruido. En nuestro ejemplo, ruido en la forma de dibujos incomprensibles pasados como requerimientos. Más valdría, por ejemplo, formalizar esas “charlas” como una instancia de elaboración de un documento simple y que todo el mundo entienda, tal vez directamente en idioma coloquial y con algunos dibujos hechos a mano.

Si tenemos contacto asiduo con el cliente (deberíamos), los problemas se notarán más temprano que tarde. Él mismo indicará claramente (muy) que no está recibiendo lo que pidió. Pero imaginemos que no sabemos nada del origen de esta discordancia. Puede venir por el lado de los requerimientos, pero no lo sabemos.

De alguna manera hay que medir, al menos aproximadamente, la calidad del proceso de relevamiento y la de los requerimientos mismos. Esto implica analizar, para alguna muestra relevante:

  • el ajuste con respecto a la solución finalmente implementada. ¿Estamos contactando a las personas correctas en el cliente?

  • el ajuste respecto a lo que el cliente o sus representantes expresaron. ¿Los clientes son bien interpretados?  

  • el grado de claridad o precisión que le asignan los desarrolladores (que son finalmente los consumidores de esos requerimientos). ¿Los requerimientos están bien redactados o presentados?

  • el grado de ajuste de la herramienta de soporte o metodología utilizada. ¿Es fácil producir un soporte estable para cada requerimiento? ¿Ese soporte los altera de alguna manera? Recordemos que por más ágiles que seamos, deberemos almacenar por lo menos los requerimientos en curso sin que sean modificados (involuntaria y/o inadvertidamente) de manera que alguien pueda consultarlos con seguridad ante alguna duda.

  • La calidad del análisis efectuado sobre cada uno. ¿Se detectaron interacciones con otras partes del sistema? ¿Se evaluó bien la coherencia del requerimiento?

El problema está en encontrar indicadores para estas mediciones, ya que me parecen bastante… sutiles.

Por ejemplo, es “normal” que algunas interacciones entre nuevos requerimientos y otras partes del sistema no sean detectadas, ya que el análisis análisis previo es breve y a grandes rasgos. Pero otras interacciones son obvias y que sean pasadas por alto es significativo.

Por otro lado si somos muy ágiles y prima la comunicación informal, medir algunas cuestiones implica “muy poco indirectamente” medir el desempeño. Necesariamente habrá que preguntar “¿Se entiende cuando ZZZ explica lo que hay que hacer?” y esto generaría una recelo excesivo.

Es todo cuestión de encontrar las preguntas… qué novedad.

domingo, 18 de enero de 2009

El infierno de la atención al cliente.

Magistralmente resumido por Sinergia sin control (¿cómo es que no le han dado el Nobel en comics a este tipo?).

48

Windows Live Writer

BlogPost_thumb1 Hace un par de semanas que vengo utilizando el Windows Live Writer de Microsoft. Por las dudas que no lo conozcan es un editor de texto / HTML liviano exclusivamente orientado a la publicación en blogs.

Es extremadamente simple y fácil de usar (no parece de Microsoft) e interactúa con las plataformas de blog más conocidas, por lo que se puede publicar directamente, editar entradas anteriores y guardar copias locales.

La vista previa nos muestra la entrada tal cual será publicada, previa “descarga del formato del blog” durante la instalación. Esta frase, que me sonó un poco ambigua, hizo que hiciera un backup de todo el blog antes de probarlo y buscara catástrofes relacionadas en google para asegurarme de que no hiciera desastres. Pero se simplemente publica un post de prueba, lo descarga y borra inmediatamente para utilizar la página generada como plantilla.

Lo anterior vale como muestra de mi desconfianza inicial. Así como señalo los errores de MS y no dudo en recomendar a todo mundo huir de alguno de sus productos, me pareció justo reconocerle este acierto.

sábado, 17 de enero de 2009

10 formas de decir “no sé”.

obs-024

Genial, fundamental, imperdible el aporte de 10 puntos... al desarrollo de software… ¡Qué digo al desarrollo de software! A la humanidad, a la posteridad, al tiempo por los siglos de los siglos.

Espero que, enarbolando estas 10 frases fundamentales, estos 10 bastiones de la lógica, la ciencia, el sentido común y de todo lo que es bueno, logremos por fin derrotar al oscurantismo, la fantasía y el wishful thinking.

Dejo aquí apenas tres ejemplos para que galardonen al autor con las visitas que se merece:

  • ¿Podría instruirme en el aspecto que acaba de mencionar?
  • Desconozco el término en cuestión.
  • Mis conocimientos no abarcan esa área determinada.

El resto aquí.

Las grandes empresas después de la crisis…

Fiasco

dell

Hay más en Business Pundit. Visto en Presión Blogosférica.

viernes, 16 de enero de 2009

Jueguitos de viernes: un poco de humor negro.

Karoshi Suicide Salaryman es un clásico juego de ingenio en el que tenemos que… suicidarnos. Morir no es tan fácil como parece.

suicide

Limitaciones de los modelos ágiles (y de todos los modelos).

Navegápolis nos refiere un muy interesante artículo de Bruno Collet: Limitations of Agile Software Development.

En él se describen y analizan algunas limitaciones percibidas en los modelos ágiles de desarrollo:

  1. Equipo de estrellas.
  2. Encaje con la cultura organizacional.
  3. Tamaño del equipo.
  4. Ubicación física del equipo.
  5. No hay apoyo de procesos.

Obviamente está en inglés, largo pero de fácil lectura. Vale la pena el esfuerzo.

Mi personalísima opinión –bastante en sintonía con el autor del artículo- es que ninguna metodología en estado puro (“de libro”) es aplicable en la vida real sin ajustes, y que por sobre cualquier otro criterio debe primar el pragmatismo, sin olvidar la precaución (no seguir las modas o novedades), y el gradualismo (las revoluciones son muy emocionantes, pero…)

Es importante recordar que el objetivo del desarrollo es crear software, por lo que la metodología es un medio que debe estar en línea con ese objetivo, no un fin en sí mismo.

La situación actual es siempre un punto de partida. Cada problema tiene origen en alguna debilidad del proceso, que de alguna manera permitió su aparición. Sobre esto escribía en Parches y soluciones:

[…] puede pensarse en un parche y una solución para cada problema […] El parche es la actividad que resuelve la situación puntual, mientras que la solución es un cambio en la metodología de trabajo o en el circuito administrativo dentro del equipo que torna imposible la situación que originó el error.

Siempre se parte de una realidad existente, no importa si es el primer proyecto independiente de dos amigos/socios o un proyecto de mantenimiento en una gran corporación. Durante la marcha (o en algún momento de evaluación) surgen dificultades, cuellos de botella, errores, omisiones o indefiniciones.

Son éstos problemas e ineficiencias concretas, nuestros problemas y nuestras ineficiencias las que se deben corregir. Y para ello está disponible no sólo la experiencia volcada en las metodologías ágiles sino en cualquier otra, incluso de diferentes ámbitos o industrias.

En resumen:

  • pragmatismo. trabajar sobre lo concreto: problemas concretos, soluciones concretas.
  • experiencia: referirse siempre a la experiencia. A la nuestra o a la ajena, pero no reinventar la rueda. Puede que un producto sea original, novedoso y único, pero créanme: los problemas en el proceso que lleva al desarrollo de ese producto no lo son. Antes de ponerse creativos es mejor hacer una búsqueda en google.

jueves, 15 de enero de 2009

El origen de la comunicación.

La comunicación dentro del desarrollo de software es un tema recurrente en este blog (artículos sobre comunicación). La principal razón de ello es, simplemente, que desarrollar software es comunicar (Del desarrollo de software como sistema de comunicación...).

Trabajamos en un mar de mensajes orales, escritos, gestuales. En castellano o inglés, expresados en diagramas y gráficos o como lenguajes de programación, y de diferentes fuentes (humanas, mecánicas, informáticas). Las acciones y decisiones que tomamos y percibimos son también mensajes.

Participar de la comunicación hace a cada integrante del equipo. No puede calificarse como tal quien no logre entender los objetivos. No se integra un equipo con estar ahí físicamente, hay que decodificar los estímulos que se reciben en ese ambiente en un sentido similar al de los otros integrantes.

Para un líder la comunicación es todo. Donde la coerción física es bastante infrecuente (digo bastante...) la comunicación hace al líder. No lo será el más fuerte ni el más capaz ni el más viejo ni el más sabio. Será aquél que transmita mensajes que lleven a los demás a seguirlo.

Usualmente vemos un gráfico parecido a éste:

comunicacion

Tomemos un elemento: el mensaje es “el conjunto de señales, signos o símbolos que son objeto de una comunicación”. Pero en la vida real, ¿quién dice qué estímulos son señales, signos o símbolos, y cuándo conforman un mensaje?

A la derecha del escritorio de X está el cubículo del líder de proyecto, al que puede ver ya que está definido por una separación transparente. Está visiblemente molesto mientras conversa con el líder técnico, y cada tanto levanta la vista en dirección a X. En un momento señala directamente a X, quien entiende que están hablando de él, a cerca de un grave incidente del fue responsable, y espera lo peor.

Se ha cerrado un circuito de comunicación: el líder de proyecto envía mensajes gestuales que X interpreta. ¿No?

El líder de proyecto está molesto porque han recortado casi un cuarto de su presupuesto. Descarga su furia conversando con el líder técnico, un viejo amigo. De vez en cuando levanta la vista y queda mirando al vacío al recrear los detalles de la reunión. El recuerdo lo enfurece. Apuntando hacia donde -en su recuerdo- se encuentra el gerente general, dice: “Es un verdadero imbécil”.

¿Esta última aclaración invalida la comunicación anterior? ¿El mensaje recibido por X no fue real? ¿Cómo puede X saber eso? ¿Y si no fue real, qué fue?

La decodificación de un mensaje y su interpretación es un fenómeno que hace al receptor, lo define. Somos receptores si -y sólo si- recibimos mensajes y lo somos sólo fugazmente durante el momento en que lo hacemos.

Pero por otro lado es el receptor quien decide qué es un mensaje y qué no. También decide si va dirigido a él y cómo se decodifica. En nuestro ejemplo X decidió que el gesto del líder iba dirigido hacia él, y decidió también su sentido al decodificarlo.

Así que nos convertimos en receptores a voluntad, incluso con independencia de la existencia real de un emisor con intención de dirigirse a nosotros. Basta con tomar cualquier estímulo e interpretarlo (¿o incluso el estímulo es innecesario?).

Pero este proceso de creación del mensaje que hace de una persona un receptor no es, habitualmente, aleatorio. Si así fuese la coordinación -si no la vida misma- sería imposible. Si no interpreto la luz roja del semáforo como un mensaje dirigido a mí que indica que no cruce la calle, probablemente no dure mucho en una ciudad moderna.

A través de un proceso (de aprendizaje, enseñanza, prueba y error) que comienza con nuestro nacimiento, filtramos estímulos y creamos mensajes cada vez más ajustados a la forma en la que necesitamos reaccionar para sobrevivir. Este proceso se vuelve tan automático que ni nos percatamos de ello.

Es decir, hemos aprendido a interpretar lo que nos rodea no de acuerdo a una realidad objetiva (si es que tal cosa existe), sino de acuerdo a nuestras necesidades de supervivencia (¡esto es duro de tragar!). 

Para sobrevivir necesitamos reaccionar especialmente a lo que un emisor intenta transmitirnos deliberadamente, y por ello somos muy buenos en detectar eso.

Pero de vez en cuando se produce un equívoco. El efecto de encontrarse con un malentendido (por ejemplo cuando X se entere de que no estaban hablando de él) es parecido al que nos provocan las ilusiones ópticas: nos revelan que nos movemos en un entorno que nosotros mismos estamos creando a partir de los estímulos que recibimos, y que nos podemos equivocar.

Pero volvamos a lo laboral. Lo anterior supone un problema, y uno grande. Desde el punto de vista de un líder, por ejemplo, es imprescindible asegurarse de que lo que dice se interprete en determinado sentido.

El lenguaje, los estudios y la experiencia compartida ayudan pero no aseguran. Si hay que transmitir la definición de un sistema administrativo un cursograma aportará un lenguaje preciso… dependiendo del grado de conocimiento de éste que tenga el receptor.

La única forma es el feedback (lo que puede pasar en su ausencia: Pedrito (el líder de proyecto) y el lobo: la importancia del feedback): el receptor devuelve el mensaje al emisor y éste lo confirma.

A mayor experiencia (más tiempo, conocimientos y vivencias compartidas) menor necesidad habrá de este tipo de “feedback de confirmación”.

Notemos que esto no soluciona nuestro ejemplo. ¿Cómo confirmar un mensaje que no se ha enviado? Si el emisor (el líder de proyecto) no es consciente de la interpretación de la que han sido objeto sus señales (por parte de X) no tiene forma de corregirla.

Este último caso es insalvable. Y todos lo sabemos. X tiene “cola de paja”. En la oficina está el paranoico que cree que lo van a echar. Y el que no sabe que está en la cuerda floja. Y el que se siente galán de la oficina. Y el jefe que se cree respetado y obedecido. Y el que cree que son todos haraganes. Todos “nos creemos” porque, finalmente, hemos construido nuestro mundo interpretando a nuestro antojo los estímulos que… ¿recibimos?

miércoles, 14 de enero de 2009

Dos opiniones sobre optimización de código…

Rules of Optimization:

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it yet.

-- M.A. Jackson

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity."

-- W.A. Wulf

Vía Coding Horror. ¿Les quedó claro?

Test sobre la salud de nuestra empresa u organización.

Directivo Pyme referenció este test de salud para la empresa, elaborado por tatum en base (según he entendido) al trabajo de análisis de Javier Fernández Aguado.

Completé el test (requiere una registración) y los resultados me parecieron por lo menos interesantes.

La única aclaración que quisiera hacer es que por la redacción del cuestionario dudo un poco de la capacidad de diagnóstico “objetivo” (lo “objetivo” va siempre entre comillas) de la herramienta. Es decir, creo que los resultados deben interpretarse más como un reflejo del momento personal dentro de la organización del que completa el cuestionario que como una descripción objetiva del estado de la organización en sí.

[Las dos frases siguientes NO son parte del cuestionario, sino un invento mío a modo de ejemplo] No es lo mismo preguntar “¿Las quejas han aumentado en comparación con el año anterior?” que “¿Se logra la satisfacción del cliente?”. La primera redacción apunta a un indicador mucho más “duro” que el segundo, que estará influenciado por lo que yo creo que es la satisfacción del cliente.

Si algún lector con experiencia en la elaboración de este tipo de herramientas completa el cuestionario agradecería su opinión al respecto.

Por otro lado los resultados obtenidos son acordes a las respuestas enviadas, aparte de claros, ordenados y en definitiva útiles teniendo en cuenta la aclaración anterior.

Éstos indicarán si la organización padece alguna de las enfermedades que se utilizan a modo de metáfora de los problemas organizacionales. Así, por ejemplo, el nivel de anemia dará

Un diagnóstico sobre el nivel de compromiso con las promesas internas. Y en este tema no es cuestión de quitarle “hierro” al asunto…, así la comunicación, motivación, retribución, reconocimiento son “vitales”.

En fin, les recomiendo comenzar con el post referenciado. Aunque conociendo la ansiedad de algunos aquí está el enlace directo al cuestionario. Me cuentan qué les pareció.

martes, 13 de enero de 2009

Errores de HTTP.

Vía Un blog más me encontré con esta galería en flickr de imágenes graciosas para los errores de HTTP. Para muestra dos botones.

417 Expectation Failed 408 Request Timeout

417 Expectation Failed

408 Request Timeout

Para qué sirven Facebook, Twitter, LinkedIn, Xing y compañía.

¿Te quedó claro? La imagen es de Indexed.

lunes, 12 de enero de 2009

Errores de programación: los 25 más peligrosos.

Siguendo un twit de Matt Cutts (@mattcutts) me encontré con un interesantísimo documento, 2009 CWE/SANS Top 25 Most Dangerous Programming Errors.

Es una lista de los 25 errores de programación más peligrosos en términos de seguridad informática. Los errores están explicados tanto en forma breve y amigable como detallada y técnica y hay un montón de referencias para seguir.

Esta lista se obtuvo por consenso entre una serie de expertos de Estados Unidos y otros países (más información aquí). De acuerdo al documento, estos errores han sido los causantes de 1.5 millones de vulnerabilidades durante el 2008, que han posibilitado que muchas de las terminales utilizadas para visitar los sitios afectados se conviertan en zombis.

Algunos de estos errores son ampliamente conocidos, como los relacionados con la validación de datos ingresados por el usuario, que llevan a los ataques vía SQL-Injection o Cross-Site Scripting.

Otros son más sutiles o dependen de la actualización de los programadores involucrados en el proyecto, como por ejemplo el uso de algoritmos generadores de números pseudo-aleatorios débiles (o directamente la falta de uso, una de las claves que permitió a un grupo de investigadores y estudiantes de seguridad quebrar absolutamente la seguridad SSL hace menos de un mes).

Ésta es la lista de errores traducida (con mucho esfuerzo) por mí:

Interacción insegura entre componentes

Vulnerabilidades relacionadas con el envío y recepción de datos entre sistemas, componentes, módulos, programas, procesos o hilos separados.

  • Validación defectuosa de los datos de entrada.
  • Escape o codificación defectuosa de los datos de salida.
  • Defectos o fallas en la preservación de la estructura de las consultas SQL (SQL-Injection).
  • Fallas en la preservación de la estructura de las páginas web (Cross-site Scripting)
  • Fallas en la preservación de la estructura de comandos del sistema operativo (OS Command Injection)
  • Transmisión no encriptada de datos sensibles.
  • Falsificación de petición en sitios cruzados (Cross-Site Request Forgery)
  • Errores provocados por la interacción con el entorno de ejecución (Race Condition)
  • Información sensible volcada en mensajes de error.
Manejo de recursos

Vulnerabilidades relacionadas con manejos inapropiados durante la creación, uso, transferencia o destrucción de recursos del sistema.

  • Fallas al mantener una operación dentro de un determinado espacio de memoria.
  • Control externo del estado de la aplicación (por ejemplo al utilizar cookies para mantener el estado).
  • Control externo del nombre o la ruta a un archivo (por ejemplo al construirlo a partir de datos de entrada).
  • Ruta de ubicación de recursos no confiable (explotada por un atacante que logre que la aplicación apunte a una ubicación de recursos determinada).
  • Fallas en el control de la ejecución de código (por ejemplo el generado dinámicamente).
  • Descargas de código sin verificar.
  • Descarga o liberación defectuosa de recursos.
  • Inicialización defectuosa.
  • Cálculos incorrectos (por ejemplo fallas por desbordamiento inducidas).
Defensas porosas

Vulnerabilidades relacionados con técnicas defensivas mal o abusivamente utilizadas, o simplemente ignoradas.

  • Control de acceso impropio (autorización).
  • Uso de un algoritmo criptográfico quebrado (obsoleto).
  • Contraseñas establecidas en el código (hard-coded).
  • Errores en la asignación de permisos a los recursos.
  • Uso de valores pseudo-aleatorios predecibles.
  • Ejecución con privilegios innecesarios.
  • Seguridad implementada en el cliente (en vez de en el servidor).

Como les dije, hay mucha información en el anuncio, y en el detalle de estas vulnerabilidades. Vale la pena la lectura en profundidad.

Una relación entre innovación y estructura de la empresa.

“By me”, por supuesto. Que quede claro que ésta es una visión basada más en mi insomnio veraniego que en contenidos académicos.

La definición de la RAE nos indica que innovación es la

creación o modificación de un producto, y su introducción en un mercado.

Apoyándome en ésta definición es que quisiera someter a juicio una interpretación mía, a ver qué les parece.

En el centro de todo esto está la idea de que por definición innovar implica un rendimiento económico. Dice “producto” y “mercado”, indicando con esto un objetivo último: obtener o maximizar beneficios.

Así, Innovar = crear + producir + vender. No alcanza con crear algo nuevo, sino que hay que producirlo e introducirlo en un mercado (venderlo). Y hay que hacerlo por beneficios, no por amor al arte.

Las empresas, por definición, no intentan crear nuevos productos y servicios sino que intentan innovar (las que lo hacen, claro). La búsqueda del beneficio es lo que las define como tales y es lo que hace la diferencia. Esta búsqueda de beneficio no está presente en el término “creación” y sí lo está en “innovación”.

¿La letra dura nos dice, por ejemplo, que si estoy jugando con un nuevo lenguaje de programación no estoy innovando? Sí, creo que dice exactamente eso. Puedo estar aprendiendo o creando, pero no estoy innovando. No busco introducir un nuevo producto a un mercado para obtener un beneficio. Aún si lo estuviese intentando, innovar implica hacerlo con éxito, no intentarlo.

Entiendo que “jugar” es una parte importantísima e indispensable del proceso que nos lleva a la innovación (es la parte de creación) pero no es innovación per sé. Faltan los demás elementos. Y falta el éxito.

Se me ocurre que el fracaso en la innovación por parte de muchas empresas recae justamente en no entender ésta última ecuación.

Normalmente en la base de la pirámide los empleados no tienen incentivos para innovar (y algo más, ya llego).

Innovar implica la búsqueda de un beneficio económico derivado de la introducción al mercado del producto, y el empleado está excluido de la mayor parte de ese beneficio por definición. ¿Hay muchos empleados que se alegren sinceramente de que la empresa gana 1000k en vez de 500k? En todo caso yo creo que estamos más contentos cuando nuestro sueldo sube de 0,10 a 0,12k.

El empleado cobra un fijo que se mantiene mientras la empresa siga viva, innove o no. En todo caso, la motivación para innovar dependerá de qué tan convencido esté de que la innovación es vital para la empresa y, por tanto, para la continuidad de su trabajo.

En este nivel, por otro lado, la base del conocimientos es técnico, no de negocios. Así que la mayoría no está orientado a la innovación, por falta de visión y técnica de negocio (recordemos que innovar implica éxito por lo menos en lanzar el producto al mercado).

Incluso puesta en duda la vida de la empresa sin innovación, un empleado podría preferir irse antes que ponerse a pensar en cómo innovar. Esto implicaría ponerse a pensar en cómo obtener un beneficio económico… del que, de obtenerse, sólo le tocaría una mínima parte.

Los empleados de este nivel, en todo caso, crean. ¿Por qué? Por lo que decíamos en A great place to work y en Aprendizaje e Innovación: la creación es una actividad motivadora y representa un beneficio (el conocimiento) con el que el empleado sí se queda en su totalidad (por más que la empresa también se beneficie económicamente de ello).

Así que algunos crean porque la creación (no la innovación) y el aprendizaje los motiva. A otros no, y entonces simplemente hacen su trabajo por dinero. Es decir, simplemente producen. He aquí los dos motivadores de los que hablamos siempre: un buen entorno laboral (en todo sentido, incluyendo posibilidades de aprendizaje) y una buena paga.

Así que en esta visión, muy de empresa de sistemas, la base de la pirámide aporta la creación y la producción.

Faltan los negocios. Es en el medio de la pirámide donde el innovar se convierte en un objetivo laboral: un ejecutivo debe tomar la creación, seleccionarla y encauzarla con un sentido económico y dirigirla hacia los que producen para construir un producto concreto y rentable.

El ejecutivo medio es un empleado que es evaluado por su éxito en los negocios. No por la creación de un producto distinto a todos los demás sino por el éxito de ese producto en el mercado, por la innovación que produce medida en términos de ese objetivo que la caracteriza: el beneficio económico. Los productos exitosos no son los innovadores. Los productos exitosos son los que dan un buen beneficio. En el mundo de sistemas de hoy, ese beneficio se debe gran parte a la innovación. Pero no todo, que aplicaciones de nómina hay muchas.

La motivación de los empleados de nivel medio -los ejecutivos- para innovar es que su continuidad laboral depende de ello si el mercado lo exige, ya que a través de ello se lo evalúa. Usualmente aparece un extra a través de la participación (mayor que en la base pero de todas maneras mínima en cuanto al global) en los beneficios.

Si el mercado no lo exige no estarán motivados a innovar, para frustración de los “creativos” de la base, que se encontrarán estancados, y alegría de los “productores”, que en un ambiente estable estarán más tranquilos.

Volvamos a los empleados de la base. ¿Y aquellos que sí tengan una orientación de negocios?  Lo que sucede con ellos es muy común: ascienden para ocupar cargos ejecutivos. Si conjugan las dos orientaciones (visión técnica + de negocios) pueden innovar por ellos mismos, así que se van para trabajar en forma independiente. Esto aumenta la tendencia hacia lo puramente técnico del sector.

¿Y al tope de todo, en el ápice de la pirámide? Allí tampoco hay innovación, si es que pensamos en una junta de accionistas, por ejemplo. Allí sólo hay búsqueda de beneficio, inversión. No hay suficiente conocimiento técnico, hay una gran comprensión del negocio en su estado más abstracto y puro: el dinero, el capital, el interés, el plazo, el retorno de la inversión, el rendimiento.

domingo, 11 de enero de 2009

La vida del freelance.

Un video perfecto para el domingo a la noche. ¡Se acabó la joda (si es que la hubo)!

Visto en Pensamientos ágiles.

Seguridad: Ataque de “Man in The Middle”

ARP-man-in-middle-attack

Muy didáctica (aunque un poco viejita, vengo con retraso) la entrada El ataque del hombre en medio escenificado, en la que se describe y analiza la intercepción de un entrecot en una cena de empresa.

sábado, 10 de enero de 2009

Sábado a la noche en Esparta.

Siempre pensé que 300 era medio… así.

Visto en Multimaníaco 2.0

Google Chrome avanza.

Estaba leyendo otro artículo más sobre el constante y acelerado retroceso del IE y se me ocurrió chequear nuevamente en las visitas a este blog.

Por supuesto es un universo muy pequeño y muy sesgado. De todas maneras recuerdo que un par de semanas después del lanzamiento de Chrome éste se ubicaba en torno al 3%.

Ahí va:

navegadores

Un brutal 12% entre el 10 de diciembre y el 9 de enero. Tendría que hacer un análisis más profundo, pero a ojo de buen cubero creo que le ha mordido más a Firefox que al IE. ¿Es igual en sus blogs?

5 preguntas para hacer en una entrevista de trabajo.

ORP1

En 5 preguntas para entrevistas de trabajo a programadores proponía un breve cuestionario para el entrevistador, como para iniciar la charla.

Se ve que Enero es momento de recopilaciones (debería hacer algo…). Leyendo la de Pensamientos Ágiles me encuentro con  Cinco preguntas para tu próxima entrevista de trabajo si te gusta el software, de Mayo de 2008. Se proponen otras 5 preguntas, esta vez para hacer desde el otro lado del escritorio, como entrevistados (están orientadas a Java):

  1. ¿Qué framework de desarrollo utilizáis?
  2. ¿Qué metodología de desarrollo utilizáis?
  3. ¿Qué sistema de build utilizáis?
  4. ¿Qué entorno de desarrollo utilizáis?
  5. ¿Cómo se prueban las aplicaciones?

Creo que resume bastante bien los aspectos técnicos que uno debe evaluar antes de pegar el salto para no encontrarse con sorpresas desagradables. Vale leer el detalle y los comentarios sobre la interpretación de las diferentes respuestas en el post original.

viernes, 9 de enero de 2009

Jueguitos de Viernes: Run

run

Run es un juego que recuerda mucho al Parkour. Tenemos que recorrer la ciudad haciendo hasta lo imposible por recoger unas malditas bolsas. Los movimientos están muy bien logrados, aunque nuestro personaje es bastante difícil de controlar.

Un cierre con mis preferidos del 2008.

el-equipo-a2

En algún momento del 16 de Mayo me decidí a comenzar con este blog. Un día después publiqué la primera entrada, y aquí estamos.

Una evaluación seria depende en buena medida de la preexistencia de un plan o por lo menos de una serie de objetivos. Así que ésta no será una evaluación seria.

En un principio “publiqué” para darle un sentido a escribir, y escribí para publicar.

Siguió como un juego exploratorio: las herramientas, las costumbres, las manías, los lugares comunes, los lugares inesperados, los comúnmente inesperados y los inesperadamente comunes.

Y se convirtió en un pequeño mundo hecho a medida (los blogs que leo, los bloggers que conozco) pero que se expande rápida y descontroladamente (los blogs que leen los que me leen, los bloggers que conocen los que conozco).

No quiero mencionar especialmente a nadie. Son los que están por ahí, vinculados en las entradas o en los comentarios. También los que sólo leen pero empujan la cuenta de suscripciones al feed y los que pasan de vez en cuando o de casualidad y dejan su huella en las humildes pero siempre crecientes estadísticas. A todos gracias… totales (no pude evitarlo, tan seriecito que venía, casi poético).

Bueno, si sigo paso a la pavada. Éstos son mis artículos preferidos del año:

  1. No digas "programita".

  2. eXtreme Programming es un arma peligrosa.

  3. Panqueque System.

  4. Antipatrones de diseño.

  5. Reflexiones sobre el trabajo: la metáfora de la autopista y la metáfora del barco.

  6. La autopista del desarrollo.

  7. Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

  8. Asteroides.

  9. Simpleton (un post a cuatro manos).

  10. Eficacia vs. eficiencia del programador.

jueves, 8 de enero de 2009

202 frases célebres del mundo de la informática.

discurso

José M. Aguilar ha publicado en su blog un resumen con las entradas más leídas en 2008 (Top posts 2008 en Variable not found).

Las dos entradas más leídas han sido 101 citas célebres del mundo de la informática y Otras 101 citas célebres del mundo de la informática.

Imposible no referenciarlo, aunque el mismo post indique que ya se ha hecho hasta el hartazgo. Están categorizadas y hay para relamerse. Algunas de mis preferidas:

"Hay dos maneras de diseñar software: una es hacerlo tan simple que sea obvia su falta de deficiencias, y la otra es hacerlo tan complejo que no haya deficiencias obvias"

-- C.A.R. Hoare

"La mayoría de ustedes están familiarizados con las virtudes del programador. Son tres, por supusto: pereza, impaciencia y orgullo desmedido"

-- Larry Wall

"Primero resuelve el problema. Entonces, escribe el código"

-- John Johnson

"Obtener información de internet es como intentar beber agua de una boca de incendios"

     -- Mitchell Kapor

"Es importante destacar que ningún ingeniero software con ética consentiría escribir un procedimiento llamado DestruirBaghdad. Su ética le obligaría a escribir un procedimiento DestruirCiudad, al que se pasaría el parámetro Baghdad"

     -- Nathaniel S. Borenstein

Predicciones fallidas.

Qué mejor que mirar un poco hacia atrás en el tiempo para corroborar aquello de

"Somos dueños de nuestros silencios y esclavos de nuestras palabras."
  • “Nadie va a necesitar más de 640 Kb de memoria en su ordenador personal”, Bill Gates, en 1981.
  • “No hay necesidad de tener un ordenador en cada casa”, Ken Olsen, fundador de Digital Equipment, en 1977.
  • “La TV no durará porque la gente se cansará rápido de pasar todas las noches mirando una caja de madera”, Darryl Zanuck, productor de la 20th Century Fox, en 1946.
  • ...

El resto en 10 puntos...