Archivo de la categoría: Negocios

Sobre incendios, CPD’s y otros desastres naturales

General, Negocios, Proyectos, Sistemas, Técnico, , , ,

Supongo que a estas alturas ya la mayoría os habréis enterado del incendio ocurrido en uno de los CPD’s (centro de proceso de datos) que The Planet tiene en Houston, Texas. Al parecer la causa del incendio fué la explosión de uno de los transformadores que dan servicio al CPD. Debido al incendio se tuvo que cortar completamente sl suministro eléctrico del centro provocando con ello el apagado de unos 9.000 servidores, entre ellos los DNS principales de la antigua EV1, había servicio de respaldo pero los bomberos obligaron al corte completo como medida de seguridad. Creo que han tardado algo más de 24h en restaurar completamente el servicio, desde el foro se pudo seguir la evolución de la incidencia.

El CPD en cuestión era uno de los que EV1 Servers tenía cuando fue adquirida por The Planet hace un par de años y el más antiguo de la compañía.

Pues bien, nosotros tenemos servidores en The Planet desde 2002, de hecho teníamos servidores en ese CPD de EV1 hasta agosto del año pasado cuando, gracias a unas buenas ofertas, los migramos a nuevas máquinas y con ello cambiamos de centro de datos, ahora estamos en Dallas, sino ahora mismo seríamos uno de los afectados.

He leído mucho estos días acerca de lo ocurrido. He llegado a leer si realmente vale la pena llevarte la infraestructura a USA cuando puede ocurrir esto que ha ocurrido. Y yo me pregunto, ¿acaso esto no podría ocurrir en España? Esto y mucho más 😉 , los problemas son independientes del lugar, si no es un transformador el que explota es una regleta que se quema, una fuente estropeada o un router colgado. También podría ser otra máquina con la que compartes RACK y/o router que ha sido atacada o mil historias más, ¿verdad Raúl?, pero problemas los hay en todas partes. ¿Acaso por tener tus máquinas en un CPD de Logroño estando tú en Valencia vas a resolver algo que no podrías resolver si están en USA? La respuesta es obvia a no ser que tengas enchufe y te vayan a tratar antes y mejor por ser tú, cosa poco probable para la mayoría. Lo que debes pensar es en tener gente detrás que vaya a solucionarte los problemas que tengas y que no puedas solucionar tú.

Nuestra experiencia, tanto en EV1 primero como en The Planet después, es inmejorable. Rápida respuesta a los pocos problemas que nos han dado, avisos con semanas de antelación de ventanas de actuaciones, soporte rápido y eficaz, etc. Cuando hemos tenido algún problema más grave han hecho las cosas con profesionalidad y siempre preguntando primero, reinicios manuales, fsck’s controlados, cambios de cables de discos defectuosos que estaban provocando problemas, etc. En una ocasión incluso se hizo el cambio de un disco defectuoso con dos parones de unos 5 minutos cada uno, el disco no había dejado de funcionar, simplemente lanzaba errores esporádicos de lectura/escritura. En una parada añadieron un disco duro para que lo preparásemos todo y en la siguiente reemplazaron el original por la copia. Todo funcionó a la perfección y en 24h se cambió un discon sin afectar al servicio. Reconozco que también puede ser que hayamos tenido algo de suerte 🙂 .

Profundizando un poco más en el asunto, el incendio de The Planet es sólo uno de los problemas que pueden ocurrir y ante los que apenas hay opciones de protección. Recordemos casos como el del Edificio Windsor de Madrid donde había ni más ni menos que un CPD de Colt Telecom, o las inundaciones en Louisiana tras el Katrina donde todo quedó arrasado y devastado. Nadie ni nada puede asegurar que sus servidores estarán seguros 100% y que nunca ocurrirá nada. Por contra, tú si que puedes asegurar que estarás protegido ante estas situaciones y así poder minimizar los efectos. En función del presupuesto de que dispongas podrás estar mejor o peor preparado, pero lo básico es muy barato y sencillo.

Si tu presupuesto lo permite, lo mejor es, sin duda, tener siempre un CPD de respaldo con toda tu infraestructura de producción duplicada, actualizada y preparada para entrar en producción cuando la principal se venga abajo. Obviamente esto es un gasto que casi nadie va a ser capaz de justificar ante sus superiores.

Si, como la mayoría, no puedes permitirte un CPD de respaldo, mantén una buena política de copias de seguridad y un plan de contingencia bien documentado y actualizado. Si lo haces bien, en apenas unas horas podrás tener levantado desde cero una máquina que haya fallado. NO, repito, NO confíes en los RAID1 (espejo) y ve con cautela con los RAID5, he visto muchos servidores completamente perdidos por culpa de la controladora RAID. ¿De qué sirve tener un RAID1 bien chulo si al petar la controladora se van los dos discos a paseo? A la hora de hacer tus backups ten en cuenta que no sólo necesitas los datos propiamente dichos, sé previsor y guarda todos los archivos de configuración y scripts que te has ido haciendo con los años y que sigues utilizando. Documenta en el plan de contingencia cada detalle que estimes oportuno para restaurar el servicio. Apunta cada cambio que haces en la configuración de cada servicio. ¿De qué te va a servir tener todos tus datos si no has guardado la configuración de Apache y ahora tienes que crear uno a uno todos los Virtual Hosts?

Finalmente, aunque parece evidente, llegado el momento muchos se olvidan. Distribuye tus copias de seguridad. NO tengas el backup en el mismo CPD y mucho menos en la misma máquina. A ser posible almacena los backups en varios sitios. A mi me gusta hacerlo en otro CPD bien alejado del de producción y en tus oficinas.

Como último consejo, pon en marcha el plan de contingencia al menos una vez al año. Coge una máquina limpia, tu plan de contingencia y mide el tiempo que tardas en tenerlo todo online y revisa los problemas que te van surgiendo. Alimenta con esta experiencia tu plan de contingencia para hacer frente a posibles imprevistos llegado el momento.

Eso es todo amigos, ojalá nunca tengáis que poner en práctica el plan de contingencia 😛 .

Cliente IRC online en Flex en colaboración con Irc-Hispano

Negocios, Programación, Proyectos, R.I.A., Técnico, , , , ,

Ayer lunes entró en producción uno de nuestros proyectos más ambiciosos junto a Irc-Hispano, la red de chat más grande e importante del mundo hispanohablante. Se puede acceder a nuestra aplicación desde aquí.

Cliente IRC Flash

Hacía muchos años que queríamos algo así pero no existía la tecnología necesaria. Los que usamos Internet desde hace muchos años, en mi caso desde 1994, sabemos que antes de que existiese el Messenger ya estaba el IRC, el chat de toda la vida. El problema era que se necesitaban programas concretos para utilizarlo (Mirc) y después había que saber configurarlo y tener unas nociones básicas (servidores, nicks, canales, kick, ban, join…). Muy complicado para el usuario no experto. Así apareció a finales de los 90 la probablemente mayor utilidad de los applets de Java: el cliente IRC online. Ahora los usuarios ya no necesitaban conocimientos ni instalarse nada, simplemente accedían a la web, ponian su nick, el canal donde querían chatear, y a “relacionarse”. Incluso aparecieron clientes IRC en HTML, muy útiles pero sin las opciones de usabilidad de las otras.

La idea era muy buena, pero nadie había contado con los problemas asociados: necesidad de la máquina virtual de Java, lentitud, pesadez, etc. Los usuarios no tenían más que problemas.

Corría entonces el año 2002 cuando se nos ocurre hacer lo mismo pero en Flash, una tecnología presente en la mayoría de navegadores y con una implantación mucho mayor que la de Java. Nos pusimos a investigar y nos llevamos una gran decepción, no había forma de comunicarse con un servidor IRC estandar, en aquél momento Flash sólo disponía de xmlsocket, que permitía conectarse a hosts remotos pero siguiendo unas especificaciones especiales.

Todo estaba perdido hasta 2006. En junio de este año Adobe (que ya había absorvido a Macromedia) lanzaba Flex2 y junto a él la versión 9 de Flash Player con la funcionalidad más esperada por nosotros: la posibilidad de crear sockets binarios. Con esto ya se podían hacer en Flash clientes pop/smtp, ftp y, por supuesto, IRC. Esto marcó un antes y un después y nos pusimos de inmediato a planificar nuestro sueño. Tardamos más de seis meses en meternos de lleno en el proyecto puesto que ya estábamos trabajando en otros.

Desde el primer día tuvimos que comenzar a pelearnos con el RFC del protocolo IRC, fundamental para conocer el funcionamiento del sistema ya la sintaxis de todos los mensajes de ida y vuelta con el servidor. Una vez tuvimos el núcleo básico fue relativamente sencillo construir toda la interfaz de usuario sobre él, creando los comandos y acciones así como los eventos de respuesta. El primer problema era que había muchas opciones distintas, así que fuimos fijando prioridades y trabajando sobre ellas.

Cuando teníamos una versión básica pero funcional y debido a las políticas de seguridad de la máquina virtual Flash, nos pusimos en contacto con Irc-Hispano y desde el primer momento les encantó la idea, los planes y nuestro prototipo, con lo que fue sencillo llegar a un acuerdo que beneficiase a ámbas partes. Mientras nosotros desarrollábamos, la gente de Irc-Hispano se ocupaba del testing.

Hablando ya técnicamente, y aunque esté mal que yo lo diga, se ha hecho un trabajo impresionante exprimiendo toda la potencia de Flex. Hemos conseguido integrar bastantes cosas que a simple vista son casi imposibles de utilizar en Flex, como los smileys en un área de texto, o los colores de fondo. Documentándonos por aquí y por allí y viendo lo que habían conseguido otros conseguimos adaptar ciertos sistemas a nuestras necesidades quedando el conjunto francamente bien.

Desde el primer momento tuvimos claro que la única forma de conseguir sacar una aplicación de este tipo era usando técnicas de desarrollo ágiles, y así lo hicimos, preparando periódicamente versiones funcionales de lo que hubiese y poniéndola a disposición de los usuarios para que nos aportasen el feedback necesario, no solo de errores sino también de usabilidad y funcionalidad en general. La experiencia ha sido perfecta y todo el equipo ha salido beneficiado de este modo de trabajo, ya que se elimina automáticamente el estrés del miedo a los cambios cuando el producto está ya terminado.

Y así llegamos hasta hoy en que se lanza públicamente. Se han hecho muchas más funcionalidades de las previstas inicialmente y seguramente se irán haciendo muchas más a medida que se vaya utilizando. Por nuestra parte ha sido un esfuerzo enorme en horas de trabajo y quebraderos de cabeza para hacer y solucionar problemas sin respuesta aparente, pero el resultado ha valido la pena.

A partir de ahora esperamos ir corrigiendo bugs y añadiendo mejoras, ideas no nos faltan y seguramente habrá muchas sorpresas ;). Algún día también refactorizaremos :P.

Urchin vs. Analytics, la batalla se libra en casa

General, Negocios, Proyectos, Sistemas, Técnico, , , , ,

Webalizer (con su excelente fork continuado awffull) y awstats han tenido históricamente fama de contar visitas y páginas de más, sobre todo desde que Google abrió al público su Analytics y ya nada volvió a ser lo mismo. Hace años tuvimos alguno de nuestros proyectos auditado por OJD y la diferencia con webalizer era mínima, sin embargo las distancias con Analytics son abismales.

Analitycs surge de la compra de Urchin por parte de Google en 2005, otro clásico del software para estadísticas web. Analytics se lanzó primero en beta muy cerrada y bastante después la abrieron completamente al público. Desde el primer día todos nos hemos dado cuenta de las enormes diferencias de datos que había entre lo que contaban nuestros analizadores de logs y lo que contaba Analytics.

Recientemente necesitaba valorar las estadísticas de acceso a distintos proyectos móviles y la única herramienta de la que disponía era el querido webalizer, pero ¡cómo fiase de sus datos!. Analytics no es una opción en este entorno ya que la inmensa mayoría de terminales no soportan Javascript, con lo cual no va a funcionar la contabilización de páginas. Se me ocurrió entonces probar Urchin Software, la última versión del software comprado por Google y que ellos mismos distribuyen y en el que, se supone, se basa Analytics. Aunque el precio de la licencia sea posiblemente prohibitivo para la mayoría, tenemos una versión de prueba de 3 meses, así que dicho y hecho, la descargamos la instalamos y comenzamos a monitorizar nuestros sites móviles. La sorpresa fue mayúscula al cabo de un par de días cuando comprobamos que el resultado es prácticamente el mismo que con webalizer. No nos lo podíamos creer, así que decidimos monitorizar sites también controlados por Analytics para comparar, comenzando por el blog Restaurantes en Madrid. Al cabo de unos días volvimos para comparar el resultado y nos sorprendimos de nuevo. Resultados semejantes a webalizer y completamente distantes de Analytics. Pero ahora la diferencia era enorme, estamos hablando del doble con creces de visitas y páginas que nos muestra Urchin respecto a Analytics.

Urchin (o webalizer, o awstats) se basa en el análisis de logs de acceso del servidor web, mientras que Analytics lo hace a través de Javascript. No cabe duda alguna de que el primer método ha de ser, por fuerza, mucho más creíble y eficaz ya que se basa en peticiones HTTP recibidas de verdad, mientras que el segundo método confía en que el cliente tenga Javascript. Pero ¿qué ocurre con clientes sin Javascript?, más aún, ¿qué pasa con los accesos a feeds?, ¿son visitas no contabilizadas y perdidas? Pues sí. Osea, la herramienta de estadísticas web por excelencia está contabilizando, al menos, un 20% (según he leído en algún sitio) de tráfico menos de lo que en realidad tienes y aún así se ha convertido en el estandar, no lo puedo entender. ¿Los que te leen por RSS no son visitantes también? Se ve que no… La única razón que se argumenta en favor de Analytics es que así no cuenta tráfico proveniente de los robots de los buscadores, pero no dicen nada de los efectos colaterales.

Las críticas que se puedan aplicar a webalizer o a awstats son exactamente las mismas que puedes echar sobre Urchin, con la diferencia de que este último cuesta la nada desdeñable cifra de 3.000 euros. Sin embargo te habrás gastado este dineral para obtener unas cifras nada parecidas a Analytics. Cuando vayas a vender tus espacios publicitarios qué datos vas a enseñar, los de Urchin o los de Analytics, o mejor aún, cuales te van a pedir tus anunciantes?.

Monitorizando servidores con Cacti

Negocios, Proyectos, Sistemas, , , , ,

A nadie le cabe duda hoy por hoy que una de las tareas más importantes y necesarias en el trabajo de los departamentos de sistemas es la monitorización, tanto de máquinas como de servicios.

Hoy en día está de moda Nagios, no es la primera oferta de trabajo que veo donde buscan desarrolladores de plugins para Nagios. Antes fue Big Brother, todo un clásico de la monitorización. Ámbas son muy semejantes y su funcionalidad es parecida, la diferencia está en que Nagios es Open Source y Big Brother es comercial. En general, su utilidad es comprobar la disponibilidad de servicios en los servidores (http, pop, smtp…). Si en un periodo de tiempo determinado no hay acceso a un determinado servicio (es decir, se ha intentado varias veces sin éxito), se lanza una alerta puesto que se supone que puede haberse caído. Las alertas son ampliamente configurables, se pueden crear grupos de usuarios que la recibirán y pueden ser de distinto tipo (email, pager, sms…). Como herramienta de alertas es perfecta, sin embargo, como herramienta de monitorización se limita a ser un almacén de semáforos, mientras todos están en verde, no hay problemas, cuando uno se pone en rojo, salta a alarma. Así de sencillo. Sin embargo no nos responde a algunas de las preguntas más interesantes:

  • ¿Por qué se ha caído el servicio?
  • ¿Qué estaba ocurriendo en la máquina cuando se cayó?
  • ¿Qué otros servicios de esa máquina podrían estar influyendo en el problema?

Nos informa de la disponibilidad pero no de las posibles causas.

Cacti responde a esas cuestiones de un modo muy eficaz. Cacti es otro concepto de monitorización. Si conoces MRTG sabes de lo que hablamos. Cacti también se base en rrdtool para generar gráficos de actividad periódica. El día que tenga ganas jugaremos con rrdtool puesto que es una experiencia interesantísima, aunque hace ya tres o cuatro años que no lo toco.

Veamos un ejemplo para ir entendiendo sus ventajas. Aquí tenemos una gráfica de uso de CPU con bastante detalle.

Gráfico de actividad con 1 CPU

Alguno dirá, bueno, está bien, pero con mrtg hago cosas parecidas. Vale, veamos el segundo ejemplo, ahora con dos CPU’s, gráficas independientes y combinada.

2cpu.jpg

Vale tío, pero no me has enseñado nada nuevo, se puede hacer con otras herramientas algo parecido. Seguro, pero no con la facilidad de Cacti. Pero mira lo que te voy a enseñar ahora:

Monitorización de servicios con Cacti

No se vayan todavía, aún hay más…

Monitorización de servicios con Cacti 2

Si a estas alturas no estás sorprendido creo que no deberías seguir leyendo :P.

Como veis, podemos llegar a tener gran cantidad de información de cada uno de los servicios que tenemos corriendo en el servidor, no sólo tráfico de red o actividad de CPU. Ahora podemos responder a muchas más preguntas en caso de error:

  • ¿Qué actividad de Apache había?
  • ¿Y de MySQL?
  • ¿Cómo íbamos de tráfico de correo?
  • ¿Y de DNS? A ver si vamos a estar teniendo un DoS a través del DNS…

Más aún…

  • ¿Será un fallo hardware por la temperatura o los ventiladores de la máquina?
  • ¿Falta de espacio en disco?
  • ¿Nos hemos quedado sin memoria?
  • Por curiosidad… ¿como vá el SAI de nuestra máquina?

Con un sólo vistazo a las gráficas respondes a todas las preguntas de golpe.

¿Qué servicio está provocando el incremento de CPU? No hay más que revisar las gráficas de actividad de los principales servicios y ver cual tiene una actividad por encima de lo normal.

Conocí Cacti hará unos cuatro años y desde entonces no puedo vivir sin el. Pero Cacti es mucho más que eso. Llegados a este punto, pensarás:

Si tenemos comprobaciones periódicas de los servicios, ¿por qué no ofrecer una funcionalidad semejante a Nagios en cuanto a disponibilidad?

Voila, parece que alguien ya lo había pensado antes y tenemos un plugin para Cacti que nos ofrece los famosos semáforos verde/rojo.

Semáforos en Cacti

Bueno vale, pero ¿qué pasa con las alertas?. Sencillo, tenemos otro plugin para lanzar alertas al más puro estilo Nagios.

Según mi experiencia, la combinación Cacti/Nagios roza la perfección y se complementan entre ellos.

Hay cientos de plugins para comprobar y registrar servicios desde Cacti, prácticamente todos los servicios conocidos tienen algún plugin, y, si no encuentras lo que necesitas, siempre puedes hacértelo tú mismo. Puedes incluso crear un pequeño script en tu servidor que genere los datos que necesites y configurar un trap snmp que los lea y los devuelva a una llamada remota, de esta forma integras a la perfección tus registros personalizados con un estándar como es snmp con el que Cacti se comunica a la perfección.

Si aún no monitorizas tus servidores… tarde o temprano vas a pasarlo mal :).

Enlaces interesantes de los últimos días

General, Móvil, Negocios, PHP, Programación, Proyectos, R.I.A., Técnico, ,

Internet Móvil: Adaptar o no adaptar

General, Móvil, Negocios, Técnico, , ,

Importante pregunta ésta. Apple y su iPhone quieren que Internet sea universal, independientemente del dispositivo que utilices siempre verás lo mismo. En un mundo ideal sería perfecto. Incluso en un mundo iPhone podría ser aceptable. La realidad es bien distinta y dista mucho de estar cerca ese idealismo.

No tengo un iPhone con lo cual no he podido probar la experiencia de usuario navegando con él, pero sí lo he hecho con la mayoría de terminales normales del mercado, desde modelos de gama baja hasta los últimos Nokia N95 o HTC Touch y similares incluyendo distintos PDA’s y smartphones. Todos estos teléfonos de gama alta tienen algo en común: utilizan navegadores avanzados, versiones móviles de sus homónimos para web en PC’s. Nokia utiliza uno basado en Safari (sí, igual que el iPhone) y HTC, al utilizar Windows Mobile, tiene Internet Explorer. Otros utilizan Opera Mini. Con todos ellos puedes hacer lo mismo, desde ver sitios web desarrollados expresamente para tecnologías móviles hasta sitios web normales. ¿Cuál es el problema entonces? La usabilidad y la navegabilidad. Y esto hablando de los de gama alta, de los demás mejor nos olvidamos en este artículo.

Cuando ves en un móvil una web, estás viendo en una pantalla de un máximo de 320×240 un sitio diseñado para resoluciones de al menos 800×600, y digo al menos cuando la mayoría de sitios hoy en día se hacen para resoluciones superiores .

¿Qué te parecería ver una web diseñada a 1024px en una pantalla de 800×600? Pensarías de todo y cargarías contra los diseñadores, sin duda, ¡y eso que tienes un ratón para desplazarte lateralmente!.

Esta teoría se puede aplicar tal cual en los dispositivos móviles. Pantallas pequeñas (comparadas a las de los PC’s) para ver sites realizados a resoluciones mayores. Además, por mucho que la pantalla sea táctil, la navegavilidad no es la misma que con un ratón. Tendrías que estar desplazándote horizontalmente contínuamente.

Utilizo desde hace casi cuatro años una PDA, principalmente cuando estoy de viaje. La utilizo sobre todo para leer el correo y planificar rutas y visitas o buscar hoteles y restaurantes, con lo que hago uso de Internet. A veces con Wifi, si la encuentro (muy pocas veces), y otras a través del GPRS del móvil. La PDA tiene pantalla táctil y puedes moverte arrastrando el dedo para desplazarte por la página, como véis no es ninguna novedad lo del iPhone. Os puedo asegurar que es insufrible, el scroll horizontal es de lo peor.

A esto hay que sumarle otro problema muy importante cuando hablamos de navegación con móviles: el coste del tráfico de datos. Vale que se puede utilizar Wifi, pero hoy en día no es fácil encontrar puntos de acceso abiertos. Si cuando nos conectamos a través del móvil vemos un sitio web normal, no adaptado, estaremos viendo cientos de menús y banners supérfluos para lo que realmente queremos ver pero que nos ralentizan la navegación, la velocidad de carga (los procesadores móviles están muy limitados) y, sobre todo, el coste del tráfico que es lo que, a fin de cuentas, más nos duele.

Ahora nos quieren vender que la navegación con móviles ha aumentado exponencialmente el último año gracias al iPhone pero no nos aclaran si es navegación Wifi o GPRS. No es lo mismo. Hasta que apareció el iPhone nadie habría pensado en gastarse 500$ y dos años de contrato a razón de una buena cantidad mensual para tener un dispositivo que te permita navegar. Antes del iPhone ya existían dispositivos móviles con Wifi, no es nada nuevo. Encima el iPhone viene sin 3G, es un simple GPRS, con lo que me niego a creer que ese aumento de tráfico de Internet se deba al iPhone propiamente dicho sino a que una gran cantidad de gente ha pasado a tener un dispositivo móvil con Wifi, de otro modo se estarían arruinando pagando a su operadora por ese tráfico GPRS, además de aburrirse de esperar, no nos engañemos, GPRS es lo que es, y si vas a cargar webs ya sabes lo que te espera.

Mi opinión, después de varios años desarrollando portales para dispositivos móviles, es que tardaremos mucho en ver móviles con la usabilidad y navegabilidad necesaria como para ver webs normales. Aquí será fundamental la reducción de precios en la navegación, nos guste o no es el mayor problema. Aunque todos los operadores se pusiesen de acuerdo y ofreciesen tarifas del estilo de Yoigo o Simyo, alrededor de 1 euro diario, si lo utilizásemos todos los días estaríamos pagando más de 30 euros mensuales por Internet en el móvil a lo que habría que sumar los 30 o 40 que ya pagas por el de casa. Yo no lo veo. El segundo problema es el que comentábamos al principio, la gente que tiene un terminal de gama alta de este tipo es un porcentaje diminuto respecto al grueso de usuarios que tienen teléfonos de gamas media y baja y que son, a la larga, los que van a reventar el mercado de Internet para móviles, la gente normal.

Yo, mientras tanto, seguiré adaptando. Hay mucha diversidad de modelos y WML, xHTML Mobile e iMode estarán aquí por muchos años todavía.

Artículos interesantes de los últimos días

Móvil, Negocios, PHP, Programación, Proyectos, R.I.A., Técnico, ,

¿Cómo que falta personal técnico?

Negocios, Proyectos, Técnico, , , , , , ,

Hace unas semanas, Rodolfo Carpintier expresaba su opinión (e insistía) sobre los profesionales del sector informático. Antes lo hizo Enrique Dans aquí y aquí.

Yo, que pertenezco a ese selecto grupo de privilegiados de los que llegan a afirmar que no conocen el paro, no puedo más que sentir indignación. Trabajo en este sector desde 2000 y he visto de todo, incluídas las colas del INEM. Tal como indica Rodolfo, yo soy de los que se creyeron muchos de esos proyectos y terminaron en esas colas.

Ahora bien, cuando hablan de que nos sobra trabajo se refieran a esos de 850 euros mensuales, bueno vale, o 900 (en 12 pagas). Así claro que no hay paro, pero también podemos prostituirnos, bueno, yo lo dudo :). De ahí a los 30.000 euros anuales que comentan creo que hay un largo trecho, y más teniendo en cuenta que hay más país mas allá de Madrid y Barcelona. Yo vivo en Valencia y no he visto una oferta de programador por ese salario nunca, acaso alguna oferta de analista con mucha experiencia.

También habla Rodolfo acerca de startups y equipos de trabajo de horas y horas sin apenas sueldo, a cambio de participaciones en el proyecto. Supongamos que me creo el proyecto y que estoy dispuesto a ello. ¿De qué se supone que voy a vivir los próximos 12 o 24 meses? ¿De lo que he ahorrado los dos años anteriores? Me invade la risa, pero a mi hipoteca todavía más.

Me hace mucha gracia que hablen de que los profesionales con experiencia considerable son cada vez más inalcanzables. ¿Acaso los buenos economistas no lo son? ¿Y los abogados? ¿Y los gestores? Cualquiera de ellos probablemente estará por encima de los buenos técnicos en materia de sueldo.

Enrique comenta que falta personal, mucho personal, y desesperadamente. Que esto está bloqueando el desarrollo de nuevos proyectos en Internet. A esto sólo cabe una respuesta. Mira los salarios que pagan. Él piensa que no puede ser así, por que dada la escasez que existe los precios subirían. Pues no. Hasta hace menos de un año se han cubierto sin problema las demandas de trabajadores a bajos sueldos y siempre había remplazo para ellos. Pero muchos se han cansado. ¿Por qué vas a programar tu por 900 euros si el de al lado, el comercial, que hace bastante menos que tú, se lleva 1800? ¿O acaso en el periodo 2000-2007 no han salido cientos y cientos de programadores? Suma ingenierías técnicas, superiores y ciclos de grado superior. Cientos de profesionales anualmente. La mayoría trabajando por sueldos ridículos en un trabajo altamente especializado. Es indudable que, como bien argumenta Enrique, la profesión sufre de un desprestigio brutal. Pero es un desprestigio provocado por la situación laboral del sector en el periodo 2001-2007.

Todos hablan de la falta de compromiso del profesional y de que quieren hacer sus 8 horas y cobrar su sueldo. ¿A alguien se le ha ocurrido pensar en el compromiso de la empresa para con el trabajador? Osea, queremos pagarles poco y que se comprometan. La empresa para qué se va a comprometer, ya le da trabajo, ¿qué mas quiere?. Pues quiero salir a las 5 de la tarde. Quiero que no me programes una reunión a las 6 de la tarde. Quiero que pienses que soy una persona y necesito mi tiempo libre, que trabajo por necesidad, porque necesito el dinero para vivir. Quiero que entiendas que, si yo estoy contento, mi trabajo será mucho mejor y estaré mas comprometido e integrado y aceptaré más retos y responsabilidades. ¿No lo ves? Además, ahora quieren profesionales comprometidos, que sepan reaccionar y con capacidad de solucionar problemas. Pero, por otro lado, una inmensa mayoría quieren programadores mandados, tú tienes que hacer esto, tú aquello y el otro lo de más allá y lo tenéis que hacer así. A picar código y me avisas cuando termines. Me quedo con esta frase de Enrique Dans:

Y es que pasar de obrero a arquitecto no sólo requiere un nivel superior de cualificación. Supone, además, que existan incentivos para ello.

Ahora está muy complicado el mercado, eso es indudable. Nuestros últimos procesos de selección se han alargado meses y meses y seguimos sin encontrar gente válida. Ya da igual que busques gente con experiencia o comprometida, es que apenas encuentras gente de ningún tipo. Es el precio que nos toca pagar de años de maltrato al profesional.

Personalmente creo que la discusión no debería ser si hay o no gente cualificada sino ¿dónde están todos los profesionales graduados los últimos años? Sencillamente resignados. El que más y el que menos ha pasado por varios trabajillos de esos de sueldos míseros. Para el que se ha pasado estudiando hasta los 23 o 25 años (en el mejor de los casos) es algo frustrante ver que no hay salida. Se han resignado y prefieren un trabajo de esos que les permite vivir tranquilamente y sin agobios esas 8 horas por un sueldo mediocre porque se han dado cuenta que no encontrarán algo mejor, y aunque lo hagan llegan al momento de creerse milongas, aún recuerdo la última vez que oí hablar de incentivos. La situación es el clásico más vale malo conocido que bueno por conocer.

Por favor, dejémonos de quejarnos de una vez. El personal técnico es, en general, gente muy preparada, capaz, profesional y, lo más importante, les encanta su trabajo. Tratémosla como tal y démosle lo que se merece. A fin de cuentas, tal como dicen todos estos gurús, en sus manos está el desarrollo de tu negocio. Recuperemos el valor de nuestra profesión.

Otro día hablaremos de la parte de culpa de las cárnicas consultoras, de las subcontratas y de la situación del sector en las Pymes, mayoría de empresas en este país.