(Vía Secret Geek)

Tan real como la vida misma. Y es que por un lado tenemos el codigo spaghetti y por otro lado, los ficheros KK

En todo proyecto informático que se precie hay uno o más ficheros “kk”, que no sirven para nada, que nadie usa, pero que si se te ocurre borrar el proyecto deja de funcionar.

También suele haber varias versiones de ejecutable, cuyos ficheros se llaman así ejecutable_bueno.exe, ejecutable_nuevo.exe, ejecutable_hoy.exe, ejecutable_ultimo.exe. Está claro que esta nomenclatura de nombres es la más adecuada para saber cual es el que hay que arrancar, en función de que se quiera el bueno, el nuevo, el de hoy o el último.

…

Sigue leyendo el post de los ficheros KK en el genial Chuidiang

(Continuación de “Fabrica” vs “Tienda”. Parte 1)

El conocimiento de estas fases por parte del desarrollador variará en función del tamaño de la empresa, el presupuesto del proyecto y si trabaja en una consultora o directamente en el cliente. En general, trabajar en el cliente y un mayor presupuesto suelen derivar en un mejor estilo de vida dentro de la “fabrica”, aunque siempre hay excepciones. De todas formas, el espíritu es siempre el mismo: Crear y vender un producto, trabajar en un equipo medio en cadena, con un análisis y una estrategia definidos para abordar el proyecto. Además tenemos el deadline o plazo de entrega final y un presupuesto general para hacerlo todo.

Ahora veamos el apasionante mundo de sistemas: el trabajo modo “tienda”.

La diferencia fundamental entre desarrollo y sistemas es que en sistemas, evidentemente, no se programa. Por lo tanto, ni se crea software ni se vende ningún producto. Lo que se vende es un servicio, que consiste en administrar sistemas en producción: conjuntos de aplicaciones instaladas en muchas máquinas que están utilizando personas (los famosos usuarios) y que, si dejan de funcionar, no pueden trabajar. Y si una persona (o más) no puede/n trabajar, el cliente pierde dinero y eso tampoco es bueno.

Si la única labor del administrador fuera que las máquinas no se caigan para que los usuarios las utilicen, sería todo mucho más fácil. Pero no lo es, por lo tanto, el trabajo diario de un administrador esta lleno de múltiples incidencias en las aplicaciones que hay que resolver de inmediato y nuevas versiones de dichas aplicaciones que hay que instalar, sin que impacte demasiado en el trabajo de los usuarios.

Vemos claramente que es un trabajo tipo “tienda”, en el que cada día y por lo general, no tenemos ninguna planificación inicial ni sabemos lo que vamos a hacer como en la “fabrica”. En cambio, el trabajo va llegando poco a poco (o de golpe) y de una persona en concreto, la cual quiere que se lo atiendas y resuelvas en el menor tiempo posible. Esto, por muy caótico que parezca (que lo es), tiene una manera de regularse, una metodología:

• Incidencia/petición. No es lo mismo que algo no te funcione o falle (incidencia) a que necesitas alguna cosa como subir un archivo a un sito, saber la versión de algo, instalar un software (petición). La diferencia básica es que una incidencia es más urgente que la petición. Cada una tendrá un tiempo de resolución asignado, además de una urgencia.
• Programa de gestión de incidencias. Todas las incidencias y peticiones te han de llegar por esta vía. A través de este programa instalado en tu máquina, podrás verlas y actualizarlas, cambiarlas de estado (en progreso, pendiente) y marcarlas como resueltas. Aquí es donde entra en juego la verdadera espada de Damocles del administrador: el nivel de servicio. Cada incidencia asignada a ti o a tu grupo tendrá un tiempo máximo de resolución, que variará en función del tipo y urgencia. Por supuesto no se tiene en cuenta tu carga de trabajo actual o si tienes más incidencias abiertas. Si dejas una incidencia pendiente, el tiempo se parará, pero tendrás que justificarlo en su worklog (un registro dentro de cada incidencia donde todos pueden escribir comentarios). Si el tiempo de resolución es mayor que el prefijado, se penaliza el servicio. Al final de cada mes y cada año, se hace un informe muy complejo para medir el servicio en el que entran todas las penalizaciones.
• El correo. Tu cliente de correo recibirá al día cientos, quizá miles de mensajes. Por un lado todos los avisos y alarmas de todas las máquinas. Cada vez que se ejecute un cron, un filesystem se quede sin espacio, una máquina no responda a un ping o dios sabe que te llegará a un correo. Pobre de ti si no estableces unas buenas reglas para organizarte, o el caos esta asegurado. La mayoría de los correos se borran de inmediato ya que no te afectan. Y por otro lado, las distintas guerras entre usuarios, departamentos y grupos relacionadas con las incidencias y peticiones. Estos correos no van dirigidos a ti, sino al email de tu grupo (una lista de correo) al cual perteneces, por lo que puedes ser participe de la conversación o ser simple espectador, sea lo que sea, todos los correos te llegarán y tu gestor de correo corporativo acabará reventando.

El tipo de tareas a realizar es variopinto, pero de eso hablaremos más adelante…

Si trabajas en informática muchos años, la metodología de trabajo del propio negocio en sí te va modelando como persona con el paso del tiempo. Esto hay que tenerlo muy en cuenta antes de decidir de qué trabajar.
Podemos resumir que el modo de trabajo en desarrollo es tipo ?fábrica? y en sistemas es tipo ?tienda?.

El increíble mundo del desarrollo: el trabajo modo ?fábrica?.
Como todo, está lleno de buenos momentos y también malos, épocas de mucho curro o poco curro, cambios de proyecto y de personal, situaciones increíbles, etc. Construir software no es sencillo, por lo que durante este proceso, en la ?fabrica?, pasa de todo.

El trabajo tipo ?fabrica? es un trabajo de duración media-larga, realizado medio-en cadena y medio-coordinado por alguien que sabe más que tú en el que el objetivo final es crear un medio-producto (software) para medio-venderlo a un precio fijado antes de su producción.

Esto último se convertirá en la espada de Damocles de todo el equipo: dado que el precio se establece de antemano, el coste final de su producción no puede ser superado en ningún momento, ya que entonces no sería rentable y la empresa perdería dinero, y eso sería el fin. Por esta razón, el desarrollo esta lleno de cálculos sobre estos costes con limitaciones de medios y recursos para abaratarlo: cambios continuos en la plantilla (se pasan de 5 programadores a 1 y de 1 a 5 cada mes), estrategias de juego sucio con el cliente, etc

Las situaciones típicas que el programador sufre durante las fases del desarrollo son:

• Inicio del proyecto. Puedes tener suerte y formar parte del análisis: hablar con el cliente y hacer documentación. Incluye también montar todo el tinglado, elegir frameworks, entornos, etc. Es lo más bonito, por eso es la fase que menos dura. La mayoría nunca vive esta fase y entran en el proyecto ya empezado, cuando no sabe nada y se pasan el día preguntándolo todo.
• Desarrollo general. Incluye programar un día y deshacer lo programado al otro porque han vuelto a cambiar los requisitos. Cambios continuos de proyecto por lo que nunca conoces un proyecto completamente y hace que no tengas nunca claro en que estás trabajando: síndrome del programador itinerante. Plazos de entrega imposibles que se van aplazando una y otra vez hasta la eternidad, dando la sensación de que la semana actual es siempre la última semana (y se trabaja como si así lo fuera). Síndrome del ?último empujón y entregamos?.
• Fase de entrega e implantación, que es cuando aparecen los verdaderos problemas de cosas que no se han tenido en cuenta (?ah, era en cluster??) y se aplican parches de última hora en jornadas maratonianas de 24 horas, fines de semana incluido.
• Fase de mantenimiento, aburrida y monótona en la que se aplican pequeñas (o grandes) correcciones, parches o nuevos módulos. Si el equipo de desarrollo lo formaba más de una persona, se verá reducido a una sola. Si el equipo ya era una sola, entonces está asumirá el mantenimiento mientras inicia un nuevo desarrollo a la vez y sin modificar los plazos debido a la sobrecarga. Efecto ?todo a la vez?

Continuará en unos días…

Java y la meta infinita.

De la misma manera que el problema de Aquiles y la tortuga generó dolor de cabeza a los matemáticos durante siglos, el lenguaje de programación java nos lo causa hoy en día a todos los que de una manera u otra trabajamos en torno a este lenguaje. El problema es básicamente el mismo: por más tiempo que pase no logramos alcanzar una meta.

Dentro del mundo Java están apareciendo contínuamente framewoks y más frameworks de desarrollo, nuevas maneras de hacer lo mismo pero de forma distinta. Para los que conozcan este lenguaje más o menos desde sus inicios pueden echar una mirada hacia atras y darse cuenta de que las aplicaciones que hace muy pocos años usaban arquitecturas punteras ahora mismo parecen piezas de museo. Para los desarrolladores es muy complicado mantenerse al día, ya que si caen en un proyecto de más de 1 año de duración se quedarán obsoletos.

Todo esto trae multitud de problemas, en muchas ocasiones se usan framewoks que están “de moda” pero que no están ni de lejos maduros, y claro…. eso ya sabemos todos lo que supone. Cada vez más librerías, más capas, más patrones… Con esto no quiero quitarle importancia a un buen diseño y huir del llamado código spaguetti (del que seguro que Alberto os hablará gustosamente) pero muchas veces pienso que los encargados de diseñar arquitecturas gozan, sienten un orgasmo por cada capa, librería y patrón que consiguen meter, aunque sea con calzador y la complejidad final de sus diseños sea algo infumable.
Por eso, por mucho que corro, jamás consigo alcanzar a la tortuga…..

Dos viejos amigos locos informáticos y, como no, programadores, se incorporan al Staff de este humilde blog: David y Kotrina. Espero que la calidad de los posts aumente, así como la frecuencia de actualización, que ultimamente ha decaido un poco debido a lo de siempre: trabajo + facultad = poco tiempo.
Seguiremos informando.

(Continuación del post De programador a Administrador (I)

3. Picapica leader.
Ya es capaz de llevar todo el proyecto él sólo y empezar otro igual al mismo tiempo. Tiene uno o varios picapicas rasos/power a su cargo, de los cuales no llega a ser su jefe, pero si es su responsable. Toma decisiones, va a reuniones el sólo, visita a clientes y se hace cargo de los errores que nadie sabe arreglar.

A partir de aquí, la carrera del picapica leader es difusa y diversa y dependerá de muchos factores, entre ellos de los beneficios directos que sus proyectos aporten a la empresa, en función de los cuales se le dará más campo de maniobra para afrontar otros proyectos u otras areas. Es posible que se convierta en…:

4.Picapica gurú.
Nadie sabe lo que hace realmente, ya que es el único que conoce una metodología, un proyecto o un sistema en su empresa y nadie le cuestiona nada. Se pasa el día respondiendo preguntas, documentándose sobre nuevas tecnologías.Pica solo lo que le gusta y lo hace como le da la gana. Define arquitectura y modelos de desarrollo.

5.Mutación a otra cosa desconocida
Puede que la empresa y/o la tecnología desarrollada se queden pequeñas o se vean limitadas por la perspectiva de negocio actual y se necesite “comer de otro plato”. La necesidad de aprender cosas realmente distintas pueden dar lugar a transformaciones aleatorias, algunas más afortunadas que otras: intento de comercial, intento de jefe de proyecto, intento de instructor, intento de consultor, aprender otro lenguaje, plataforma, etc. El resultado final es totalmente imprevisible. Los finales son varios y dependerá del tipo de persona que encuentre o no la felicidad. Se puede acabar haciendo documentos todo el día, se puede acabar de cara al cliente vendiendo… Si eso es lo que se quiere, puede ser un buen final. Al menos de momento…

Bueno, el final de mi carrera como picapica en funciones (solo en funciones, porque el que nace programador, muere programando) ha sido otro muy distinto.
Aprovechándome de mis conocimientos de programación Java, he acabado como administrador de servidores de aplicaciones (no dire cuál) en una empresa bastante tocha (tampoco diré cuál).
Tengo que decir que me siento pleno: hago mi trabajo y lo hago bastante bien. Pero estoy tan acostumbrado a trabajar entre programadores, analistas, maquetadores y comerciales, que el no verlos ni trabajar con ellos me resulta extraño. Ahora me rodean adminstradores de Unix, de Oracle, de Windows y otros muchos más. El curro no viene definido en un project y se factura a un cliente, sino a través de incidencias que debemos resolver en el menor tiempo posible. Todo un gran cambio en el modo de trabajo. Hablaré de ello en el siguiente post.

“Después de unos cuantos años programando uno empieza a pensar en la cantidad de lineas de código que ha escrito, la cantidad de programas y aplicaciones en las que he participado. Todas esas líneas de código están por ahí, ejecutándose en algún ordenador, otras, la mayoría, abandonadas en algun soporte magnético y otras ni siquiera ya existen”

Sigue leyendo pensamientos filosóficos del mundo de la programación en la web de mi amigo kotrina

La alucinante aventura de un programador que se pasó a sistemas.
?Que es lo que sucede cuando un programador, con 7 años de experiencia en el desarrollo, se pasa a sistemas como administrador de servidores de aplicaciones?

Antes de empezar, deciros que llevo trabajando en el mundo del desarrollo 7 años, los 3 últimos con Java. He pasado por varias empresas, algunas grandes, otras pequeñas, pero siempre me he dedicado al desarrollo. Como casi todos los programadores, mi carrera ha sido más o menos parecida. Olvidaros del modelo de categorización ?programador - analista programador ? analista - jefe de proyecto - gerente de cuenta?. Ese modelo está obsoleto y no es real, al menos en la pequeña y mediana empresa española. El nuevo modelo, que a continuación voy a describir, tiene como peculiaridad de que cualquier categoría incluye a todas las anteriores, de manera que a mayor categoría, mayor nivel de trabajo o ?enmarronamiento?.
Sin más preámbulos, las verdaderas categorías que dividen a los programadores en las empresas españolas son las siguientes.

1. Picapica raso
Conoce mucho el lenguaje pero no conoce la metodología ni el proyecto. Suele ser joven e inexperto, por lo que tiene a otro picapica (ver picapica power/leader) que le enseña como funcionar y se pasa el día preguntándole cosas. Llega pronto y se va a su hora. No sufre, pero tampoco piensa, por lo que es feliz, pero gana poco. Un picapica raso puede serlo toda su vida o, si se esfuerza, se documenta y aprende rápido, puede llegar a convertirse en…

2.Picapica pauer (power).
Conoce mucho el lenguaje, conoce la metodología y conoce el proyecto. Como programa rápido, participa en varios proyectos, a veces a la vez. Descubre errores de arquitectura en el código, propone ideas y participa abiertamente en el desarrollo. Va como apoyo técnico a algunas reuniones y le arregla los problemas a su jefe. Este programador es feliz, pues hace lo que le gusta y lo hace bien, por lo que es respetado.
Pero si tiene mucha iniciativa probablemente se vea limitado dentro de su equipo, ya que querrá empezar a hacer las cosas a su manera, mejorando la arquitectura actual o utilizando nuevo software (librerías open source por ejemplo) y se verá frustrado por el verdadero espíritu de ?mínimo coste? de la empresa de servicios. Sus ideas son vetadas y no se le permite volver atrás para mejorar lo creado hasta ahora, ya que requieren tiempo de implementación y bajo ningún concepto se querrá asumir este coste adicional. Si la aplicación funciona, la empresa lo quiere tal y como está, no hay tiempo para mirar atrás.
Por esta razón, tendrá que trabajar todavía más duro para conseguir hacer todas estas mejoras con éxito sin implicar retrasos en el proyecto, tarea bastante arriesgada, por lo que se empieza a quedar tarde. La felicidad de ésta persona es directamente proporcional a su amor por la tecnología. De la calidad de su trabajo para no morir en el intento y la ?permisividad? de la empresa para tolerar este tipo de iniciativas dependerá que llegue a convertirse en…

Continuará…

Para mí, la informática y la programación han estado siempre unidos de una manera especial. Desde que mi padre en 1986 me regaló mi primer ordenador, un Amstrad de 64k, mi inquietud por saber como funcionaban los ordenadores por dentro me ha llevado siempre al aprendizaje de la programación.

Claro que entonces no era como ahora. Aquel Amstrad (que todavía conservo como un tesoro) venía con dos libros: un manual de usuario y una guía de referencia Basic. Eso era lo bueno, que el propio sistema tenía un lenguaje de programación integrado. Podías picar tres líneas, darle a RUN y tenías un programa funcionando sin tener que compilar ni linkar.
Así que ni corto ni perezoso cogí los dos manuales y empecé a leer. El libro de referencia Basic era incomprensible. Con ocho años es un poco dificil leerse del tirón la sintaxis completa de todos los comandos de un lenguaje. Sobre todo cuando lo más complicado que habías leido hasta ahora había sido el “Pirata Garrapata” o “Fray Perico y su borrico” del Barco de Vapor.

Sin embargo el manual de usuario se podía seguir bastante bien. Era como una especie de tutorial desde cero que explicaba como funcionaba todo, desde cargar y ejecutar programas (desde cinta, ojo) hasta una explicación del lenguaje Basic. Venía con cientos de ejemplos que se podían copiar (a mano claro) y probar. Era realmente estupendo teclear lineas y lineas llenas de palabras en inglés mezcladas con números y ejecutar luego a ver que pasaba. Podías improvisar algo y cambiar el funcionamiento de tu pequeño programa. Hacer pequeños calculos y escribirlos en colores, dibujar figuras geométricas, hacer sonar estridentes melodías. Es imposible explicar esa sensación.

Después de jugar empezó a llegar lo gordo. Primero fueron las variables, más tarde las condiciones y los saltos. Los bucles, la entrada de datos, los arrays. Entonces los programas de ejemplo ya empezaban a hacer cosas más complejas: tenían menúes, interactuaban con el usuario y mostraban información útil.

El final del libro no podía haber sido más apoteósico: el listado completo de tres pequeños juegos. Una especie de arkanoid llamado “rompeladrillos”, un bombardero y un juego de tablero que nunca supe como jugar. Teclear el listado completo fue algo agotador y me llevo varios días. Había que salvar en cinta y continuar al día siguiente. Finalmente al ejecutar el juego no funcionaba: había errores. Así que había que volver a repasarse el código entero en busca del “bug”. Finalmente el juego funcionó. No sabéis lo que disfruté cambiando los colores del juego, la velocidad de movimientos o toqueteando por que sí. Fue apoteósico. Si no hubiera sido por aquellas tardes pegado al ordenador, ahora hubiera sabido jugar al futbol.

Al cabo de no mucho tiempo, el segundo libro de referencia empiezó a cobrar sentido. Era como una chuleta gigantesca, donde estaban todos los comandos, para que servían y como se utilizaban. No era facil entender que hacían algunos, pero con probarlos a veces podías averiguar para que servían. Otras ni probando claro. Después vinieron las revistas, los videojuegos y los cargadores (con los pokes)… la verdad es que fueron años cojonudos, llenos de diversión y aprendizaje en un rústico lenguaje que ahora casi ni recuerdo. Basic.

Bueno, y así fue como aprendí a aprender a programar.