Bajos salarios en TIC

La crisis por la que atravesamos ha dejado una marca en los profesionales TIC, que para mantener su trabajo han tenido que aceptar más horas durante sus jornadas y salarios congelados desde que el problema comenzó. Un reciente artículo de ComputerWorld titulado "Salarios estancados empujan a trabajadores TIC a buscar empleos", comenta el resultado de una encuenta realizada por ellos a 343 profesionales TIC, que revela el hecho de que el 36% está actualmente en busca de un nuevo empleo en los próximos seis meses y el 69% reporta que no ha recibido un aumento en los últimos seis meses. El mensaje no puede ser más claro para los empleadores, con las noticias de que "lo peor ha quedado atras", los profesionales más telentosos están buscando mejores oportunidades laborales.

Otro dato interesante de esta encuesta es que el 54% de admite que su salario es ahora superior al que percibian en el 2008, el 26% dice que su salario ha estado estanacado y el 20% (es decir 1 de cada 5) dice que ahora gana menos que en el 2008. Esto es debido en parte a que sencillamente las empresas no están invirtiendo o lo hacen en tecnologías que permiten aumentar la productividad con lo que se requiere menos personal y por lo tanto es el empleador quien tiene la sarten por el mango.

Los resultados de esta última encuenta están en línea con otra realizada también por ComputerWorld en agosto del presente año, donde informaba que el 61% de los trabajadores TIC con un salario entre U.S.$ 35,000 y U.S.$50,000 al año estaban pensando cambiar de trabajo en los próximos 12 meses como resultado de que percibian que la situación económica había mejorado, pero sus salarios no.

Como dicen la mayoría de analistas, este es un jobless recovery, es decir una recuperación que no está creando trabajos y es así en parte porque la recuperación es sólo en papel, para la foto. Para que los publicistas puedan decir que la recesión ha terminado, claro diciendo que es la más larga que hemos tenido desde la segunda guerra mundial, pero terminó y por lo tanto cualquier otra caída sería una "nueva recesión". De esa forma estadísticasmente podemos decir que no estamos en depresión, algo que es materialmente cierto aunque no estadísticamente demostrable.

Ya lo dicen muchos analistas, cada vez se necesitaran menos trabajadores en todos los sectores productivos, con salarios a la baja en promedio, trabajando las horas que sean necesarias, cuando sea necesario, es decir la temporalidad será la constante y no la norma en los años por venir. Y específicamente en el sector TIC todo estará basado en proyectos, con fechas límites y presupuestos super ajustados. Sumado a lo anterior, las nuevas herramientas que hacen mucho más fácil abordar tareas como programación de aplicaciones (algo que ya comenté en el post "El ascenso del Programador Ciudadano") pondrá a más aprendices de brujo a la caza de las cada vez más escasas oportunidades laborales en las TIC. Como es lógico una mayor oferta de mano obra TIC hará que los precios tiendan a la baja en el futuro previsible.

Vampiros vs. Hombres Lobo

El presente título copia el de un post del blog Coding Horror, en el cuál Jeff Atwood nos cuenta como muchas veces los programadores (que el asocia con los vampiros) entran en conflicto con los system administrators (que son representados como hombres lobo). La pregunta que origino el post de Jeff, fue formulada por su sysadmin Kyle Brandt en el blog de Server Fault, que tanto control se le debe dar a los programadores sobre servidores en producción.

Aunque como dice tanto Jeff, no hay una respuesta simple y por el contrario en lugar de buscar este conflicto entre sysadmin y programadores, lo que dbe haber es una autoridad superior que defina objetivos claros para la empresa y los haga trabajar juntos en busca de un objetivo común, en lugar de que inicien discusiones unos contra otros. Jeff dice claramente que en muchos lugares donde esto ocurre es simplemente porque la división del trabajo no ha sido hecha adecuadamente y hay demasiado tiempo libre para perderlo en disputas sin sentido.

Por otro lado algo que no se discute en el post es que suscede en la empresas pequeñas, en donde los roles se vuelven más difusos debido a las limitaciones de presupuesto. Es en las pequeñas empresas donde por lo general el programador hace las veces de sysadmin o puede suceder que un sysadmin termina convertido en un programador por acceidente.

Yo, soy por definición un sysadmin, ya que tanto por vocación, como por formación soy un ingeniero (mecánico electricista para más señas). Es decir carezco del sentido estético del que muchos programadores se enorgullecen. Por el contrario yo estoy más enfocado en eficacia y eficiencia, es decir terminar el proyecto dentro del presupuesto, en el tiempo estimado aunque haya que aplicar ciertos ajustes (muchas veces recortes) en el camino, ya que una solución parcial es infinitas veces mejor que una solución perfecta en un futuro distante.

Por el contrario muchos de los programadores con los que me he topado, suelen por lo general querer inventar la rueda, no desean usar código de otros programadores y sienten un profundo rechazo a documentar su código, algunos dicen que eso les reduce su productividad y hay que casi amenazarlos de muerte para que lo hagan.

En fin, este es un debate abierto ya que cada lado puede señalar los defectos del otro, sin embargo hay que sobre todo ser tolerantes y aprender a convivir en una empresa que necesita que ambos roles trabajen juntos, en lugar de estar tratando de demostrar quien tiene la razón.

Clonando instalación Debian (o cualquier distro que use dpkg)

Definitivamente el sistema de paquetes .deb es de lo mejor, y su herramienta de administración dpkg permite la fácil instalación/desinstalación de paquetes. Por otro lado las tecnologías de virtualización como Xen o VMWare facilitan tremendamente el desplegar servidores de prueba, el problema muchas veces es cuando se debe pasar de la fase de prueba a la implementación, muchas veces olvidamos llevar un control de que paquetes o que seteos aplicamos a los servidores de prueba, con lo que muchas veces no queda otra más que escribir un pequeño script que colecte los paquetes instalados y luego otro que haga la instalación en el nuevo entorno, pero he encontrado una estrategia mucho más sencilla en el blog PR0GR4MM3R, que sólo necesita 3 simples instrucciones.

Primero, generar un listado de todos los paquetes del sistema y su estado actual con el comando:

origen# dpkg –get-selections > lista_paquetes.txt

Luego, copiamos este archivo de texto al nuevo servidor que desamos tenga la misma configuración y ejecutamos los siguientes comandos:

destino# dpkg –set-selections < lista_paquetes.txt

destino# apt-get dselect-upgrade

Listo, con eso ya tenemos todos los paquetes que fueron instalados en el servidor "origen" en el servidor "destino". Esto funciona además de en Debian, en todas las distribuciones que usen el sistema de paquetes .deb como es Ubuntu y sus derivados.

Convirtiendo archivos AMR a MP3

Le ha pasado que sus usuarios reciben un archivo atachado en un e-mail que resulta haber sido enviado desde un Blackberry, iPhone o Andorid, que contiene un "importante" mensaje pero que según sus usuarios está corrupto porque no pueden abrirlo y culpan a tu servidor de correo, o le pides a alguien que te envié en nuevo mensaje de bienvenida para el PBX que sólo acepta WAV o MP3 como formato y reciber un archivo con extensión AMR. Pues a mi me ha estado pasando muy a menudo, así que he decidio escribir un mini-howto de como personalizar una versión de FFmpeg para soportar la conversión de AMR to MP3.

Por defecto FFmpeg no soporta ni AMR, ni MP3 en la mayoría de distros (en realidad las principales) por la sencilla razón de que ambos son formatos propietarios e incluirlos por defecto, más alla del hecho de que va contra el espiritu del Open Source, sería una violación de patentes y términos de licencia, que las comunidades que soportan dichas distribuciones no pueden hacer ya que se verían expuestas a demandas legales. Eso no quiere decir que para tu uso particular no puedas compilar desde las fuentes para obtener una versión de FFmpeg que tengas los codecs de ambos formatos.

Pues bien comencemos con el mini-Howto.

Primero, debemos descargar e instalar la librería x264 (Aquí sólo mostramos los comandos que debe tipear):

# cd /usr/src
# git clone git://git.videolan.org/x264.git
# cd x264
# ./configure
# make   
#make install
#ldconfig

Ahora, debemos descargar e instalar la librería que dará soporte al formato arm llamada opencore-amr:

# cd /usr/src
# wget http://downloads.sourceforge.net/project/opencore-amr/opencore-amr/0.1.2/opencore-amr-0.1.2.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fopencore-amr%2Ffiles%2F&ts=1285678081&use_mirror=surfnet
# tar -zxvf opencore-amr-0.1.2.tar.gz
# cd opencore-amr-0.1.2
# ./configure
# make all
# make install

Seguimos con los requerimientos, ahora a descargar e instalar la librería que da soporte al mp3 que se llama LAME:

 # cd /usr/src
# wget http://downloads.sourceforge.net/project/lame/lame/3.98.4/lame-3.98.4.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Flame%2Ffiles%2Flame%2F&ts=1285677746&use_mirror=softlayer
# tar -zxvf lame-3.98.4.tar.gz
# cd lame-3.98.4
# ./configure
# make all
# make install

 Ya tenemos todas las dependencias ahora a instalar FFmpeg desde las fuentes y activando el soporte para AMR y MP3:

# cd /usr/src
# svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg-svn
# cd ffmpeg-svn
# ./configure –enable-gpl –enable-pthreads –enable-libx264 –enable-libmp3lame –enable-version3 –enable-libopencore-amrnb –enable-libopencore-amrwb
# make all

Listo ya tenemos el binario que necesitamos, pero para evitar problemas y que esté en conflicto con otras versiones de ffmpeg que puedan estar instaladas le vamos a cambiar el nombre y luego moverlo manualmente a "/bin"

# mv ffmpeg ffmpeg+amr+mp3
# cp ./ffmpeg+amr+mp3 /bin

Listo ahora ya podemos convertir el formato de los archivoc de AMR a MP3 de la siguiente manera:

$ ffmpeg+amr+mp3 -i file_name.amr file_name.mp3

Espero les sea de utilidad este información.

Portal cautivo WifiDog

Internet se ha vuelto más ubicuo en los últimos años, el abaratamiento del acceso de banda ancha a través de ADSL y cable ha llevado Internet a casi cualquier rincon en una ciudad, si a eso le añadimos la proliferación de routers que traen incorporado el acceso wi-fi, es posible que en zonas densamente pobladas no haya un sólo centímetro cuadrado sin cobertura Internet, todo lo anterior sin considerar el continuo abaratamiento en los precios de acceso 2G y 3G a través de celulares.

Muchas empresas, especialmente aquellas que dependen del tráfico de público como restaurantes, cafés u hoteles, ofrecen acceso gratuito a sus access point a través de una contraseña que se entrega a los clientes, este método no siempre es el más apropiado ya que el hecho de que la contraseña no sea actualizada frecuentemente y que sea distribuida verbalmente abre la posibilidad de que esta sea usada potencialmente por personas que no usaran los servicios del establecimiento comercial.

WifiDogUna forma alternativa de controlar el acceso es através de portales cautivos, dentrol de los muchos que hay he encontrado que WifiDog es uno de los más completos y fáciles de implementar, además de ser uno de los pocos que permiten la administración de múltiples nodos a través de un sólo control panel.

Wifidog es un producto Open Source desarrollado por la comunidad de hotspots públicos de Quebec (Canadá)  Île Sans Fil ("Isla inalámbrica"). Cómo todo portal cautivo tiene dos partes, el servidor de autenticación y el gateway. El servidor de autenticación está hecho en PHP y usa PostgreSQL como su motor de base datos, además de estar desarrollado en base a Smarty, con lo cual es muy sencillo cambiar el look del site por defecto. El gateway está programado 100% en C y utiliza sólo llamadas estándar de Linux, con lo cual puede ser integrado en cualquier servidor que haga de firewall o routers compatibles con los proyectos DD-WRT, OpenWRT y Tomato. Yo lo he probado con DD-WRT v2.4 y funciona sin mayores problemas, ya que la parte gateway de Wifidog está ya incluída en la versión standard.

Una de las características interesantes de Wifidog, es que permite que sea el propio usuario que registrándose con su dirección de correo electrónico gane acceso al hotspot, además que nos permite definir cuantos usuarios concurrentemente deseamos soportar a través de cada nodo wifi (por defecto son 10). Ya que tenemos una dirección de correo electrónico podemos posteriormente enviarle ofertas y promociones a nuestros usuarios, además gracias a su muy detallado sistema de estadísticas podemos identificar los 10 usuarios más móviles, los 10 más frecuentes, los 10 que usan más ancho de banda, etc., con lo que la administración de múltiples hotspot se vuelve bastante sencilla. En dos palabras "super recomendable", para todo negocio que tenga más de un local comercial y un hotspot público en ella. Otra alternativa es que permite crear un red de hotspot federados de negocios independientes pero relacionados al mismo rubro que pueden promover sus actividades de manera conjunta a través de ofrecer el acceso público wifi, ya que una cuenta de acceso creado en WifiDog permite que el usuario se conecte en cualquiera de los nodos que forman parte de la misma red y en cada nodo verá el logo del negocio que le está brindando el acceso en una determinada ubicación geográfica.