Jun 14

Google indiscreto

 Una pequeña estupidez. Cuando empezamos a teclear algo en google para buscarlo, se nos abre un desplegable con las frases que más hay en la web, de forma que si vamos a buscar lo "normal", lo tenemos más fácil. Pues bien, si vamos tecleando "tengo 1….", vemos que las preocupaciones de la gente de diez años para arriba van todas por el mismo lado

google indiscreto

Lo que me gustaría saber es si realmente hay tanta gente que busca "tengo 13 años y mi papa me pego porque me arrestaron por borracha stoy muy molesta". Creo que google a veces se lía un poco con tanto dato.

Visto en Emezetablog.

Jun 03

El maligno

CORREGIDO: Bueno, al final lo que comento aquí es cierto, me ha pasado, pero ha sido culpa mía. Los <form> que comento tienen un <select> con varias <option> y se me había olvidado cerrar los <select>. Corregido eso, todo funciona correctamente. Así que me castigaré a mi mismo a usar internet explorer durante un mes.

el maligno No recuerdo dónde leí a alguien que le daba este nombre, "el maligno" a internet explorer. Cualquiera que se haya peleado un poco con CSS y se haya preocupado de que su página web se vea bien en los distintos exploradores, estará de acuerdo en lo apropiado del nombre. De todos es conocida la manía de Microsoft de saltarse los estándares y de interpretarlos libremente, por decirlo de forma fina.

Pues no solo con CSS es el problema. Estoy haciendo una paginilla web para un amiguete y me he encontrado otro problema con los formularios <form>. No sé muy bien el motivo (aunque lo intuyo) y desde luego no funciona bien con internet explorer, pero sí con chrome y fifefox.

El problema es el siguiente. En una misma página index.php tengo varios formularios <form>, cada uno con campos distintos y cada uno con su propio botón de submit. Todos ellos hacen submit a la msma página index.php, menos el último de ellos que hace submit a otra página pedir.php

La primera diferencia de internet explorer ( versión 8 ) con los otros navegadores es que cuando pulso submit, la página receptora tiene acceso a todos los campos de todos los formularios en $_POST (uso method="post"), mientras que en firefox o chrome sólo tengo acceso a los datos del formulario sobre el que he pulsado el botón submit. Bueno, no me representa un especial problema porque como he comentado, todos los campos de los formularios son distintos, pero intuyo que puede ser un problema si hubiera campos con el mismo nombre en distintos formularios.

Y la segunda diferencia, esta sí más puñetera, es que el botón submit del último formulario, el que supuestamente reenvía a una página pedir.php, no lo hace. Ese submit en internet explorer envía a la misma página que todos los demás, index.php. En firefox y chrome funciona bien, cada submit envía a su página. Esto posiblemente está relacionado con el problema anterior. Es posible que si internet explorer considera los varios formularios <form> como un único mega-formulario, quizás no admita que varios <form> tengan atributos action distintos. No he probado a poner el action en cada submit concreto.

Este último problema lo he solucionarlo usando un poco de javascript

<input type="submit" onclick="this.form.action=’pedir.php’;this.form.submit()" …

que básicamente es decir cual es el action con javascript y no dejarle al internet explorer que lo interprete a su peculiar forma.

 

Sep 06

Travian y las micro-esperas

 

Hace unos días descubrí Travian, un jueguecito de estrategia on-line. En el juego hay romanos, galos y germanos. Cuando te das de alta, te permiten elegir que pueblo quieres y te dan una aldea de ese pueblo. Tu misión, como en todos los juegos de estrategia, es gestionar los escasos recursos para producir más recursos, edificios y tropas. Por supuesto, puedes dedicarte al comercio y a atacar/defenderte de todo bicho viviente que esté en las cercanias. El objetivo final no lo tengo muy claro, pero creo que es hacer una alianza con otros jugadores y entre todos construir una maravilla.

Aunque el juego es entretenido, tiene una pequeña pega que te hace pasarte la tarde entera sin hacer nada: las micro-esperas. Cuando constuyes algo, debes esperar diez minutos a que esté hecho. Te dan recursos poco a poco, de forma que puedes tardar una o dos horas en conseguir los recursos para construir algo. Cuando mandas tropas a algún sitio, tardan un mínimo de diez minutos en ir y otro tanto en volver. Una partida completa creo que dura del orden de 13 meses.

En fin, que haces una cosa y esperas un cuarto de hora, haces otra y esperas otro cuarto de hora y así sucesivamente. Y claro, entre cuarto de hora y cuarto de hora, no te vas a poner a hacer algo de otro tema (un tutorial, descargar un programa para probar, probar algo). Bueno, sí, entre cuarto de hora y cuarto de hora, escribo este post….

A ver lo que me dura la afición por el jueguecito este. Por cierto, si alguien juega estoy en el server 2 como chuidiang. Y si alguien quiere apuntarse, me hace un favor haciéndolo a través de este enlace http://www.travian.net/?uc=net2_18520&signup

Jul 01

Ser o no ser héroes

 

Imagínate que caes en un equipo de desarrollo con gente competente, que saben lo que hacen y lo hacen bien. Tienes además la suerte de que el jefe de proyecto para el que trabajas también es un buen jefe de proyecto. Sabe lo que quiere, se lo cuenta al equipo con claridad y trata de resolver todos los problemas que se presenten. ¿Qué pasa en esta situación?. Lo normal. El proyecto va bien, sin problemas graves, llega a tiempo a sus fechas de entrega con unas incidencias razonables y sin fallos graves.

Suponte ahora lo contrario. Un proyecto en el que el jefe de proyecto no tiene claro lo que quiere, no te especifica nada, no te dice como lo quiere, pero sí te dice cuando ya los has hecho que así no lo quería. Además, el grupo de desarrolladores es más bien de la media para abajo, el poco código que sale está lleno de errores y si funciona, es de casualidad. ¿Qué pasa en esta situación? Pues lo normal, que el proyecto va mal, que no llega en fechas, que cuando se pasan las pruebas con cliente todo es un "efecto demo" gigante.

Entre los dos proyectos hay además una consecuencia interesante. En el primer caso, los jefes del jefe de proyecto apenas saben que existe ese proyecto. Es un proyecto que no da pegas, que no gasta más dinero de la cuenta, que no se retrasa y que no recibe quejas del cliente, así que la cosa "no sube" hacia arriba, así que para ellos no es más que una cifra bonita en alguna tabla de Excel.

En el segundo caso, empiezan a dispararse las alarmas, los jefes del jefe empiezan a recibir los problemas de dinero, fechas y quejas del cliente. Empiezan a saber que ese proyecto existe y empiezan a hacerle un seguimiento exhaustivo día a día. Se empieza a hacer presión y los desarrolladores y jefe de proyecto empiezan a echar horas como locos y se olvidan de que tienen casa.

En el primer proyecto, el buen jefe de proyecto y los buenos desarrolladores han hecho estupendamente su trabajo, pero no se les ha notado ni los jefes los van a valorar en lo que merecen. En resumen, "no son héroes".

En el segundo proyecto, si después de echar muchos fines de semana y horas a tope se consigue que el proyecto pase como se pueda, con un listado interminable de incidencias y cosas pendientes, con el cliente descontento, pero pasa, entonces los que han participado en él son la leche, han hecho un esfuerzo sobrehumano y han conseguido sacar adelante un proyecto que era un caos. Gracias a esto, los jefes de proyecto ya conocen las caras de los desarrolladores y del jefe de proyecto. Por supuesto, se han creído todas las excusas que el jefe de proyecto y los desarrolladores les han dado para justificar que el proyecto va mal. En resumen, "Sí son héroes".

Desgraciadamente, es la realidad. Se valora más al desarrollador que echa horas y horas resolviendo problemas en un proyecto caótico, que al desarrollador que no resuelve problemas a horas intempestivas de la noche, símplemente porque no ha generado esos problemas.

Jun 27

Tipos de debugger

 

Cuando queremos depurar nuestro código, hay tres tipos de debugger, que de menos evolucionado a más evolucionado son:

  1. Poner prints, compilar, ejecutar y mirar la traza. Ponemos más prints, volvemos a ejecutar y volvemos a mirar la traza. Así, por aproximaciones sucesivas, vamos aislando el problema hasta que damos con él.
  2. Usar un debugger propiamente dicho, el que venga con el compilador o el de nuestro IDE favorito. Ponemos breakpoints, watches, inspects y similares. Ejecutamos el códido y vamos dándole a "step over", "step into" y demás variantes. De esta forma, llegamos más lentos que en el paso anterior al error, ya que tenemos que aprender a usar el debugger y si apenas sabemos programar, es pedir demasiado.
  3. La opción buena. Cogemos nuestro proyecto y lo metemos un un zip. Hacemos un copy-paste del error/excepción que nos sale y lo subimos todo a varios foros junto con una explicación más o menos elaborada, pero sobre todo misteriosa (estilo "lo tengo todo bien pero no funciona"). Esta es la forma más cómoda, con un poco de suerte, el bug se soluciona solo y además usamos las metodologías más avanzadas (el internet) y compartimos conocimientos (otros pueden aprender de nuestros errores).

Lo siento. A veces me espanto con lo que veo en los foros …

Jun 11

¿La programación es una carrera que llena tu vida?

 

Leo en DosIdeas el siguiente post : ¿La programación es una carrera que llena tu vida ?. Precisamente eso es algo en lo que estaba reflexionando en días anteriores y ahí van los porqués.

En el curro me dedico o intento dedicarme a programar. Siempre he huído despavorido de ser jefe de proyecto, de un grupo o de cualquier otra cosa. ¿Por qué?. Por que pienso que todas las relaciones con clientes y en general con gente en ambiente de trabajo siempre acaba llevando a tener roces. Al principio con el cliente todo son buenas palabras, pero cuando los plazos empiezan a echarse encima y log bugs del sistema empiezan a aparecer y ser complejos de resolver, la relación con el cliente puede volverse tensa. Con los compañeros de trabajo, habiendo buen rollo, no suele haber problemas. Pero al llegar a las etapas finales de proyecto, la presión, los bugs y las muchas horas de más pueden llevar también a roces y discusiones. "Mi parte funciona, el bug es tuyo". "Y unas narices". Si ya entre compañeros puede llegar a ser tensa, no te digo entre jefe y curritos. Además, en momentos de presión, un jefe debe ser malo, debe conseguir que la gente se quede a echar horas y terminen a tiempo. Los jefes inútiles lo hacen amenazando, regañando, chillando e imponiéndose. Los jefes astutos (y esos son los peores), lo consiguen sin necesidad siquiera de pedirlo. Todavía recuerdo un Domingo que me quedé hasta las dos de la madrugada para un proyecto que pasaba pruebas el Lunes y lo peor es que la jefa de proyecto… ¡ ni siquiera me pidió que fuera el fin de semana !, consiguió que yo lo hiciera voluntariamente.

Sin embargo, cuando me dedico a programar es cuando realmente estoy en mi salsa. Puedo pasar horas entretenido, sin darme cuenta del tiempo que pasa. Y cuando consigo acabar algo o resuelvo algún bug especialmente complejo, es cuando más satisfecho me voy a casa. De hecho, cuando llego a casa, suelo encender el ordenador y ponerme a hacer/aprender cosas de programación o relacionas. Además de mi trabajo, es también mi hobby.

Sí, entiendo que si quisiese ser jefe de la forma tradicional, cogiera proyectos como jefe de proyecto, me dedicara con mi traje y corbata a aguantar y engañar al cliente y me importara tres pepinos "explotar" a mis compañeros, posiblemente cobraría más y estaría mejor considerado en la empresa, pero… a mi, por lo menos, no me merece la pena. Prefiero tener la conciencia tranquila y dedicarme a algo que realmente me gusta. Irme a mi hora a casa (salvo agún Domingo excepcional), llevarme bien con la gente y aprender cosas nuevas todos los días.

May 27

Un barrapunto

 

Hace un mes largo alguien me puso en barrapunto. Las visitas subieron de golpe ese día (me enteré rápido porque hubo muchos más comentarios de lo habitual al post de turno). Ahí va el gráfico de turno, las visitas se multiplicaron por diez y luego fueron bajando poco a poco, durante dos semanas, hasta llegar a su tónica habitual.

visitas despues de barrapunto

Apr 30

Test FourSight

 

Un poco jugando, un compañero mío ha propuesto que realicemos el test FourSight para ver el perfil de cada uno de nosotros. Yo, por supuesto, me he escaqueado hábilmente, por aquello de que no me gusta exhibir mis vergüenzas en público. Eso sí, lo he hecho luego, tranquilamente, en mi casa (supongo que el Lunes seré honesto con mis compañeros y lo llevaré para que lo vean).

Este test trata de ver tus puntos fuertes y débiles a la hora de afrontar problemas. Hay cuatro pasos a la hora de resolver un problema y según en qué pasos eres más fuerte (o tienes más gusto por dar), así es tu perfil. Esos cuatro pasos son:

  1. Análisis del problema. Una persona a la que sólo gusta este aspecto es un Clarificador.
  2. Generar ideas para resolver un problema. Este tipo de persona es Ideador.
  3. Analizar esas ideas para ver cual es mejor y planificar cómo llevarla a cabo. Este tipo de persona es Desarrollador.
  4. Solucionar el problema. Este es implementador.

Para ver tu perfil realizas un test en que contestas, poniendo crucecitas, en unas treinta y tantas preguntas. Luego sumas puntos y ves el resultado. Por supuesto, hay perfiles mixtos, en el que algunos de los puntos anteriores pueden ser más fuertes y otros más flojos. Cada uno de estos perfiles mixtos tiene un nombre, estilo "Acelerador" que es el que destaca en el análisis del problema y en solucionarlo, es decir, analizo el problema y me pongo inmediatamente a implementar la primera solución que se me ocurre, sin evaluar alternativas ni sopesar pros y contras de cada una de ellas. Otro es el "Conductor", que no analiza el problema, se le ocurren muchas ideas para solucionarlo, no mira pros y contras de cada una de ellas y rápidamente se pone a implementar una de ellas, o todas a la vez.

¿Qué me ha salido a mí?

Pues soy un "corredor de ideas". Según el test, me salen valores altos en 1,2 y 4, pero muy bajo en 3. Es decir, me gusta entender el problema, se me ocurren muchas posibles soluciones, no analizo los pros y contras de cada una de ellas, sino que elijo la que intuitivamente más me gusta, y me lanzo a implementarla.

¿Cual es el objetivo del test?

Bueno, como he comentado, lo hemos (lo han) hecho un poco jugando, pero la idea de este test es doble:

  1. Por un lado, que cada uno conozca sus puntos flacos para intentar reforzarlos. Me aplicaré el cuento, tengo que analizar un poco las ideas que se me ocurran para ver cual es mejor antes de lanzarme a hacer cosas.
  2. Por otro lado, en un grupo de trabajo, conviene poner junta a gente que se complemente. En mi caso, se supone que trabajaría bien con alquien que tenga fuerte el tercer punto, en el que yo flaqueo. Alguien que sea capaz de ver los pros y contras de las ideas que se generen y sepa elegir la mejor y planificar cómo llevarla a cabo.

 

Feb 24

Es imposible hacer buen software

 

Parece un poco radical, pero es la conclusión a la que estoy llegando, al menos para el 99% de las empresas que hacen software.

El problema principal es que un programador que se queda de programador mucho tiempo es considerado como un fracasado. Y el programador, viendo que le consideran un fracasado, acaba sintiéndose como tal. En cuanto lleva un poco de tiempo, tienden y tiende a subir de categoría, ser jefe de algo y dejar de programar.

Sin embargo, ya lo dice el refrán, sabe más el diablo por viejo que por diablo. Hay montones de pequeñas tonterías de programación que se aprenden con la experiencia. Y son muchas pequeñas cosas. Se puede hacer un listado de ellas y dárselas a los que empiezan a programar, pero lo verán como un rollo, no entenderán el porqué de esas cosas y no pondrán en práctica la mayoría de ellas. Tampoco se las puedes explicar una a una ni perseguir que las cumplan.

El resultado es que según los programadores no fracasados ascienden y entran nuevos programadores, se tropieza una y otra vez con los mismos problemas, la misma forma no idónea de hacer las cosas.

Y es que programar bien es casi un arte. Un antiguo artesano era capaz de hacer un buen bolso de cuero, un buen botijo o unos zapatos estupendos sólo después de haber pasado unos años de aprendiz de un maestro y sólo después de haber pasado otro montón de años haciendo él mismo de maestro. Un programador entra en la empresa y nadie le enseña nada, aprende sobre la marcha y cuando aprende a compilar sin el IDE, le hacen jefe de cualquier cosa y meten a otro programador.

Así sale el software que sale y pienso que es ese el principal motivo del fracaso de muchos proyectos software, no la falta de una metodología estupenda. Y salen bien los proyectos que cuentan con la suerte de tener programadores nuevos muy, muy espabilados, o conservar programadores con experiencia y que sigan con ganas de hacer cosas sin sentirse fracasados.

Jan 29

Porcentaje de rebote o abandonos

 

Una estadística bastante habitual en las estadísticas de los sitios web es el porcentaje de rebote o abandono. Esta estadística mide el número de visitas que según entran en nuestro sitio, se van. Es decir, miran sólo una página y rápidamente se van a otro sitio. Algunas estadísticas consideran abandono si el visitante se va antes de un tiempo corto, pero no si está un rato leyendo y luego se va. Otras símplemente consideran un abandono si sólo se visita una página. Un porcentaje de abandonos , en principio, es mala cosa, quiere decir que al visitante le ha bastado un vistazo a la página para ver que no es lo que quiere. Un porcentaje de abandonos del 15-20% es muy bueno, del 35% es normal y del 85-90% es un problema.

Hay un par de excepciones a esto. Los blogs, por ejemplo, suelen tener un porcentaje alto, puesto que los visitantes habituales suelen ir a ver el último post, al que entran a través de su "reader" y una vez leído, se van. Otra posible excepción son páginas donde toda la información buscada está en esa página, estilo wikipedia o de tutoriales. Buscas un artículo con google o a través de un enlace, lo lees y te vas.

En muchos sitios te cuentan "en etéreo" como mejorar este porcentaje. Vienen a decir algo así como "Haz la página más atractiva para que a los visitantes le entren las ganas de navegar por el sitio web" o "cambia con frecuencia el diseño y contenido para ver si mejorsa la estadísticas".

Buscando encontré este post en ONGManía en el que dan unos consejos claros y bastante lógicos:

  • Poner enlaces internos en los artículos. Si no los hay, difícilmente el visitante va a ver otras páginas.
  • Usar etiquetas claras y sorprendentes en los enlaces. Que el visitante sepa a dónde va a ir o que le pique la curiosidad al ver el texto. Recuerdo en el blog de Toupeiro los botones a la derecha que dicen "no me pulses" o "este botón te amargará la vida". Es imposible no pulsarlos.
  • Dice que poner una galería de imágenes. Eso no lo entiendo muy bien, quizás es que a mí lo de las fotos no me van.
  • Destacar las páginas más vistas, ya que si son las más vistas, por algo será. Seguramente son las que más interés tienen para los visitantes. Parecido a lo que hacen los blogs con el "post más vistado".
  • Posibilidad de añadir comentarios sin necesidad de registro. Si el visitante puede comentar y no necesita registrarse, hay más posibilidades de que lo haga. Eso retiene al visitante un poco más en el sitio.

Y luego, en otro post de SnobSolutions:

  • El contenido importante o de interés debe situarse a la vista según se entra, sin necesidad de tocar las barras de scroll.
  • Evitar páginas sobrecargadas con publicidad y cosas que no tienen que ver con el contenido.
  • Contenido claro, destacando con negritas o tipos de fuente el tema del artículo, de forma que con un vistazo el visitante sepa si le interesa o no.
  • Ser específico y detallado en el contenido. Cosas muy generales no suelen interesar.
  • Zonas de descanso para los ojos, que la página no agote visualmente al visitante.
  • Poner un buscador en la parte superior. Si el visitante no encuentra a primera vista lo que quiere, quizás lo use.

En fin, cosillas a tener en cuenta, sobre todo yo, que ando por el preocupante 80% de abandonos. ¿Por dónde andas tú?