PHP y los salarios en México

Publicado: 08/05/2011

Artículo Original: http://briceno.mx/2011/05/php-y-los-salarios-en-mexico/

Autor: Basilio Briceño

Contenido:

Como programador uno se pregunta ¿en qué lenguaje debo invertir mi tiempo? es cierto que no existe un lenguaje perfecto y que la elección generalmente está basada en preferencias personales o bien, en el tipo de tareas a realizar, sin embargo, existe otro punto a tomar en cuenta: el salario, o en términos simples, ¿en qué lenguaje debo especializarme para ser mejor pagado?

Y es aqui donde nos preguntamos ¿por qué los empleadores pagan más a programadores especializados en ciertos lenguajes que en otros? ¿qué es más importante a ser tomado en cuenta a la hora de establecer tabuladores salariales, la lógica del programador, lo complejo de la tarea a realizar o el lenguaje de programación? Si se contrata a un carpintero, no se le contrata debido a que corta troncos con sierras marca Honda* o por que usa martillos marca Craftman*, se le contrata porque es un carpintero, sabe hacer su trabajo y da resultados, lo mismo aplica para los programadores, entonces ¿por qué tantas empresas insisten en pagar tarifas basadas en el lenguaje y no en el programador?

Y ¿qué tiene que ver PHP en lo anterior?, pues resulta que es un de los lenguajes donde los programadores salen más afectados por el tema mencionado. PHP es un lenguaje fácil de aprender, flexible y se puede desarrollar con él en tiempos muy cortos, además es genial para usarse como pegamento entre aplicaciones. Siendo así, ¿por qué es considerado inferior en términos salariales?

El motivo está principalmente basado en un círculo vicioso generado por los programadores novatos, ¿cómo es esto?, cuando un programador novato trabaja generalmente no presta atención en la calidad, se enfoca únicamente en terminar lo que le piden sin añadir ningún valor agregado a su trabajo, ¿el resultado? programas en estilo código spaghetti, estructuras mal aplicadas, carencia de optimizado, entradas de datos inseguras, y un sin fin de “features” mas. Lo anterior repercutirá en el desempeño del programa, y el empleador curiosamente comienza, no por dudar de la eficacia del programador, sino en el lenguaje.

Así entonces mientras mas novato el programador peor calidad de código, ante tal calidad más desconfianza se genera en el lenguaje, a mayor desconfianza en el lenguaje menores salarios, a menores salarios los programadores de calidad se interesan menos en el lenguaje, a menor cantidad de programadores de calidad mayor contratación de programadores novatos, a mayor cantidad de programadores novatos peor calidad de código y de ese modo el ciclo va degradando el valor salarial.

El programador novato generalmente llega a creer que lo que hace es todo lo que hay en PHP, incluso coloca en su currículo el adjetivo “experto en PHP” o “nivel avanzado en PHP”, y como ya se considera a si mismo “experto” no se esfuerza en aprender más, ni mejorar la calidad de su trabajo. Y este, es un verdadero problema, sin embargo más que solo exponerlo y preocuparnos ¿cómo podemos invertir el círculo vicioso en uno virtuoso?

No es tan complicado, mientras mayor calidad en el código y valor agregado ofrezca el programador, mejores resultados verá el empleador, a mejores resultados el empleador deberá ofrecer mejor salario, a mayor salario más programadores de calidad interesados en el lenguaje, a mayor cantidad de programadores de calidad mayor calidad en el código y valor agregado, y de ese modo el ciclo va enriqueciendo el valor salarial.

Un buen punto de arranque para comenzar a invertir el ciclo es reconocer en donde se encuentra el programador y ponerse metas para aprender y mejorar. A mediados de febrero 2011, surgió en el grupo de programadores de “PHP México” una iniciativa para definir un tabulador sencillo basado en los conocimientos y capacidades de los programadores, lo presento a continuación.

• Newbie – Generalmente escribe PHP, SQL y HTML/JS/CSS en el mismo archivo y acostumbra a copiar y pegar cualquier cosa que se encuentra en internet y según dicen los foros es la solución.
• Apprentice – Programador que ha aceptado que necesita mejorar y decide aprender mejores prácticas y aplicarlas. Consulta en foros no para buscar código para copiar y pegar, sino para analizarlo y pregunta después de haber investigado por cuenta propia.
• Junior – Generalmente separa su código, sabe qué son los patrones de diseño y los usa, entiende qué es REST, CRUD, ORM, SQL Injection, XSS, I/O Sanitization, etc. y usa estas técnicas, es excelente aprendiendo y usando APIs de terceros.
• Senior – Programador capaz de desarrollar sus propias herramientas, consciente de como funciona PHP internamente, sumamente interesado en el performance de las aplicaciones mas allá de su facilidad de desarrollo, no está satisfecho con el funcionamiento de todas las herramientas y APIs de terceros tal cual vienen y siempre busca innovar y crear cosas que mejoren y faciliten el desempeño de su trabajo y aplicaciones. Contribuye con código en diferentes proyectos y comunidades. Entiende que “PHP es el frontend de su backend”.
• Master – Capaz de desarrollar sus propias extensiones para PHP en C, contribuye a PECL y lo contratan para mejorar el performance de aplicaciones de alto rendimiento.
• Core – Contribuye al desarrollo del core de PHP o el motor de Zend, contribuye en algunas extensiones para usadas por muchas personas, generalmente se le ve en conferencias internacionales y es usual ver su nombre en PECL y en los créditos en cambios de versión de PHP.

Respecto de los salarios, estos pueden variar dependiendo la zona, los siguientes son sugeridos en base a los costos de vida de las principales ciudades de México en febrero de 2011.

• Newbie – hasta 8 mil pesos
• Apprentice – de 8 a 15 mil pesos
• Junior – de 15 a 25 mil pesos
• Senior – de 25 a 40 mil pesos
• Master – de 40 al límite que establezca con el empleador.

Considero que lo anterior ayudará a dar una pauta sobre cómo mejorar el salario de los programadores que usan PHP. Ahora bien, no todo recae en el programador, el empleador deberá estar consciente de este tabulador y mejorarlo en base a los resultados de los programadores. De hacerse así es muy probable que se logren mejorar no solo los salarios, sino la calidad del software y se incrementen los beneficios mutuos.

* Las marcas mencionadas son propiedad de sus respectivas compañías, se mencionan únicamente con motivos ilustrativos.

Principios del Manifiesto Ágil

“Métodos Ágiles”  alternativa a las metodologías formales.

Seguimos estos principios:

• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
• Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
• Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
• Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  
• El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
• El software funcionando es la medida principal de progreso.
• Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
• A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en  consecuencia.

Original

Tal vez muchos ya los apliquen pero no se den cuenta de que hay un mundo de información y métodos, si les interesa conocer sobre este tema pueden empezar por conocer XP y SCRUM.

El problema de la diferencia de impedancia

Publicado: Domingo,junio 11 2006 @ 03:15 CDT

Artículo Original: http://www.glib.org.mx/article.php?story=20060611151541892

Autor: ceyusa (Víctor Manuel Jáquez Leal)

Contenido:

La gran mayoría de los programadores estarán de acuerdo que las aplicaciones que ponen comida en la mesa son las aplicaciones con acceso a bases de datos, ya sean aplicaciones web, de escritorio, o a través de cualquier otra presentación. Entonces desde que estudiamos programación, nuestra primera ambición es conectarnos a un manejador de bases de datos (DBMS). Pero, aunque nos emocione saber utilizarlo, aún permanecemos en un estado de inocencia programativa, la mayoría de nosotros, que haría reír a muchos programadores de primer nivel.

Aunque la programación de aplicaciones con acceso a bases de datos es algo que existe desde varias décadas, los programadores seguimos enfrentando un problema aún sin solución definitiva: el diferencial de impedancia  (impedance mismatch). Éste término fue acuñado en la ciencias computacionales a mediados de los años ochenta y se refiere a un problema electrónico cuando no podemos conectar dos componentes con diferente impedancia. Esto mismo pasa cuando intentamos hacer sinergia entre nuestra aplicación, escrita de manera procedural, con nuestros manejador de base de datos, que trabaja de manera relacional. El mundo procedural y relacional son dos universos paralelos para trabajar con datos, sin intersección natural aparente.

La solución ad-hoc que la mayoría de los programadores usa, sin sentarse a pensar seriamente en esta cuestión, es cocinar cadenas de texto con las instrucciones SQL a partir de las estructuras de datos utilizadas en nuestro código procedural. Sin embargo este enfoque tiene fuertes limitantes: primero, no podemos evaluar la instrucción SQL cocinada sino hasta tiempo de ejecución, lo que retrasa el ciclo de programación, además resulta muy difícil asegurar que toda instrucción SQL elaborada sea siempre válida y correcta. Es por esta limitante que vienen los clásicos ataques de seguridad basados en inyección del SQL. Por último, cuando trabajamos con este esquema, terminamos por colocar nuestras operaciones a la base de datos por cualquier lado de nuestro código, en donde nos demos cuenta al momento de programar que necesitemos una, lo que hace muy costoso de modificar nuestro código cuando llega la hora de darle mantenimiento. En otras palabras, es un problema de semántica, ya que por un lado tenemos el significado de nuestro programa, verificado por nuestro compilador, y la semántica del SQL, que sólo conocerá nuestro DBMS en momento de ejecución.

Al hacerse patente este problema, en los años noventa surgió una alternativa de solución, a la que se le conoce como Mapeo Objeto/Relacional. Esta es una técnica de programación en la cual vinculamos nuestra base de datos con nuestra aplicación orientada a objetos, creando objetos virtuales de nuestra base de datos. Es decir, si existe una tabla llamada empleado, creamos un objeto empleado, el cual se encargará de hacer las operaciones necesarias con la base de datos para insertar, extraer y actualizar tuplas de dicha tabla. Esta técnica se ha ido depurando hasta llegar a un patrón de diseño de software conocido como DAO (Data Access Object), del cual me gustaría hacer un artículo más adelante. Actualmente existen alternativas, tanto comerciales como libres, para automatizar la creación de los esqueletos de código necesarios para montar este tipo de soluciones.

En mi corta experiencia como programador he visto aplicaciones que intentan hacer uso de esta alternativa de solución, pero las implementaciones no hacen uso completo del patrón DAO, quedándose muy limitadas y terminan haciendo caso omiso del patrón para volver a la inserción espaguetti de instrucciones SQL. Lo que busca el patrón DAO es encapsular las llamadas a la API del DBMS para lograr un menor acoplamiento entre las clases, facilitando los cambios en el código, pero no se elimina el problema de la semántica.

A partir de la aparición de Java en el mercado, en la segunda mitad de los 90s, junto con el resto de los lenguajes que funcionan dentro de una máquina virtual que permite operaciones de introspección y otras dulzuras en tiempo de ejecución, surgieron otras alternativas de solución a este problema. En primera instancia, aparecieron marcos de trabajo (frameworks) que buscaron automatizar la generación del patrón DAO, en busca de lo que se conocerían como objetos persistentes, tal como los EJB de entidad. Ya entrado en el siglo XXI, ha aparecido una nueva tecnología que busca una persistencia más transparente al programador conocido como hibernación.
La persistencia busca que, de manera declarativa, establezcamos los objetos persistentes y su reglas relacionales, entonces el marco de trabajo se encarga de hacer las operaciones sobre la base datos, haciendo aun lado el problema de la semántica para el programador, pero perdiendo de vista las distintas capacidades de procesamiento que ofrece cada DBMS específico.

Volviendo y refraseando el problema de la diferencia de impedancia, podemos decir que «Cualquiera que sea el modelo de programación utilizado, este debe permitir que, complejas e intensivas operaciones en datos, puedan ser lanzadas por los programas para ejecutarse en un DBMS».

Si nos fijamos en las soluciones propuestas observaremos dos principios:

1. Todo el programa, incluidas las consultas al DBMS, deben estar especificadas dentro de una semántica unificada. Es decir, que no existan desconexiones de significado entre las operaciones que se envían al DBMS y lo que se realizan dentro de la aplicación.
2. Buscar la eficiencia en la ejecución delegando las operaciones intensivas en datos al DBMS y las intensivas en cálculos a la aplicación, aunque no necesariamente sea así.

Entonces el problema del diferencial de impedancia nos obliga a resolver ambos problemas de manera simultánea, no obstante las soluciones propuestas sólo resuelven una en detrimento de la otra. Por ejemplo, el mapeo objeto/relacional (con sus derivados deformes que pululan), resuelve la eficiencia en la ejecución, pero rompe con al semántica, en cambio, la persistencia elimina las diferentes semánticas pero no tiene mecanismos claros para definir dónde se ejecutar las operaciones intensivas en datos.

El problema presentado aquí es un campo abierto para la investigación en la ingeniería del software y las ciencias computacionales. Si a alguien se le ocurre una solución que acabe con ambos puntos del problema de sólo brochazo, será famoso y deseado por el sexo opuesto.

Bibliografía:

Googlazos ahora anónimos, pero en especial el artículo Safe Query Objects: Statically-Typed Objects as Remotely-Executable Queries.

Copy/Paste

Utilizaré este nuevo blog para almacenar artículos interesantes que he leído y que han despertado la curiosidad de investigación asi como el aprender y cuestionarme más y más….

La categoría será de: «Copy/Paste». Un copia y pega común y corriente con sus respectivas menciones y derechos.

Espero no dañar a nadie….. XD