viernes, 29 de octubre de 2010

Taxistas de la informática

- ¡Taxi!
- Dígame, ¿a dónde le llevo?
- No, mire, en realidad es que tengo un problema, porque son las 18.30 y acabo de acordarme que para mañana a primera hora tengo que tener listos unos informes y claro, hay que reprocesar. ¿Le paso los ficheros y me reprocesa la base de datos?
- Esto... ¿pero qué me está contando?
- Entiéndalo, es una urgencia.
- Si es una urgencia hable con su seguro. ¿Qué narices me explica a mí que soy taxista?
- Ah, buena idea.

- Seguros Awa, le atiende María de la Asunción, ¿en qué puedo ayudarle?
- Sí, mire, es que tengo un problema porque tengo que reprocesar la base de datos...
- Ehm... Me temo que su póliza no lo cubre. Para ello debería pagar un plus de intervención en itinerancia.
- Ah... ¿Y no puede hacer una excepción? Es que sólo va a ser esta vez...

Ya he hablado de ello en alguna otra ocasión acerca de las licencias que se toman ciertos clientes en determinadas circunstancias. Los proyectos son complicados y a veces algo tiene que estar de un día para otro (las fechas a cumplir son las que son y suele merecer la pena hacer UN esfuerzo PUNTUAL por tener una entrega y tener al cliente contento).

No obstante, en muchos casos nos encontramos con circunstancias que hacen que de forma continuada se deban realizar esfuerzos, como si el horario laboral se extendiese más allá de la hora de salida, con una disponibilidad cercana al 24x7 que llega a agotar a más de uno.
Aquí el problema no es que deba realizarse un 24x7. El problema es pagarlo.
Para una empresa de servicios informáticos es complicado que le salga rentable algo como lo siguiente:
Yo quiero que cuando llame por un problema o pregunta haya alguien que conozca perfectamente mi implantación y me lo solucione en poco tiempo. Eso sí, me facturas sólo lo que estés dedicado a mis incidencias o problemas.
Lo habitual es que si se llama en un determinado momento uno pueda recibir una respuesta de un 'taxista' que pondrá el taxímetro en marcha, pero que no necesariamente será lo que uno esperaba si necesita de un camión de mudanzas.
Y claro, si se plantea un seguro, dependiendo de lo que haya que cubrir, puede no salirle a cuenta a un cliente para las veces que declara un siniestro que no sea una rayada en la puerta pero luego acordarse del buen y rápido servicio que obtiene por pagar un poco más la vez que se encuentra empotrado contra una farola.

Así pues, ¿vamos hacia una consultoría Low-Cost? ¿El acceso a las nuevas tecnologías por el común de los mortales banaliza la mayoría de los trabajos de los buenos profesionales?

El tiempo lo dirá.

jueves, 28 de octubre de 2010

Si Marty McFly levantara la cabeza...

El fantástico De Lorean de Regreso al Futuro (si queréis regalarme un día un coche, no me parece mala opción...) tenía una cualidad que ni el ISS Enterprise de Star Trek: Viajaba en el tiempo.
No hace tanto circulaba por internet una imagen que nos recordaba que ya estamos en el 'futuro' que se planteaba en la segunda película de la saga. Pero quitando la anécdota, hoy os propongo un viaje en el tiempo con varios saltos y giros pintorescos enmarcado en las fabulosas decisiones de los proyectos informáticos que se suponen que ayudan a la toma de decisiones.

"De cómo se gastaron muchos millones de pesetas y tal vez alguno de euros en estar al día que no tocaba"
1990, Those good ol' days
- ¿Dígame?
- Oye, Paco, que necesitaría que me echaras un cable. Verás, he de informatizar un poco mi empresa para gestionar mejor y claro, es un problema. ¿Puedes ayudarme?
- Por supuesto. Vamos a analizar tus necesidades y vamos a hacer un programa con clipper a medida.
- Oye, pues muchas gracias. ¿Me va a costar mucho?
- No, hombre

1994, algunos años y pesetas después
- ¿Dígame?
- Oye, Paco, yo lo siento mucho pero es que tu programita ya me está fastidiando otra vez.
- ¿Pero aún sigues con aquello? Pero hombre, que aquello no era escalable. Lo que tienes que hacer es comprar un programa como el PC-Conta que te permita gestionar mejor.
- Ah, claro. ¿Y qué hago con lo que ya tengo?
- Uf, eso va a ser un problema. Yo de ti lo llevaba en paralelo durante un año y luego jubilas el sistema antiguo.
- Pero eso va a ser complicado
- Claro, pero luego verás qué bien.
-¿Y eso cuesta mucho?
- No, hombre.

1999, muy cerca del efecto 2000
- ¿Dígame?
- Oye, Paco, que resulta que el programa que compramos se quedó descontinuado hace un par de años y ahora estamos acongojados con lo del efecto 2000 y eso.
- No te preocupes. Tú lo que tienes que hacer es implantar SAP y te olvidas de esas cosas. Yo te ayudo.
-¿Y eso cuesta mucho?
- No, hombre.

2004, cuando las vacas gordas
- ¿Dígame?
- Oye, Paco, que llevamos ya 4 años con la implantación de SAP y no acaba de ir fina.
- ¿Aún estáis así?. Bueno, pasa a veces, pero es un sistema muy robusto.
- Ya, pero es que necesito poder planificar la expansión internacional de la empresa y tengo que tener algo que funcione.
- No te preocupes, que para esto haremos un desarrollo a medida en Java y te olvidas del SAP, que para algunas cosas no vale.
- ¿Y eso cuesta mucho?
- No, hombre

2008, cuando las vacas anoréxicas
- ¿Dígame?
- Oye, Paco, que la expansión internacional la hemos tenido que tirar finalmente para atrás por la crisis y tenemos tu aplicación, que está muy bien, pero que claro, para hacer lo mismo con nuestro SAP...
- No te preocupes. Ten en cuenta que ha salido una versión nueva y eso lo hace de forma nativa. Una migración sencillita y listos.
- Ah, qué bien. ¿Y eso cuesta mucho?
- No, hombre.

2010, no hace tanto
- Tiene una llamada a cobro revertido. ¿Quiere aceptarla?
- Sí
- Oye, Paco, que al final la empresa ha tenido que cerrar. Hicimos la implantación de lo que dijiste pero no fuimos capaces de salir adelante con un sistema estándar. Y ya ves.
- Es que te equivocaste desde el principio. Lo que tenías que haber hecho era implantar un ERP en condiciones en los 90 y no aquello que me hiciste hacer en Clipper... Y mira que te lo dije. Si no fuera por mí habrías quebrado mucho antes pero como tampoco me hacías caso del todo así te ha ido.
- Bueno... ¿No conocerás a alguien que necesite una ayuda o algo?
- Mmmm... ¿Tú te acuerdas de programar en Clipper?

Moraleja (urbanización de Madrid): El mercado tiene sus propios ciclos de herramientas estándares - desarrollos a medida. Ir a contracorriente es peligroso. Crear tendencias también. No todo lo que es moda es bueno para las circunstancias de cada empresa. Sólo con sentido común deberían tomarse ciertas decisiones que se dejan muchas veces en manos, boca y mentes que ni conocen bien la empresa ni están interesados en más que vender.

Mucho cuidado ahí fuera.

miércoles, 27 de octubre de 2010

De 13 y poco a 17 y pico

Ah, recuerdo aquellos años de la feliz adolescencia (es un decir) cuando iba al instituto entre los 13 y poco y los 17 y pico años.
Pero hoy no me quiero referir a aquellos tiempos en que comenzaba a relacionarme con los pcs (con mi fabuloso 386 dx33...). Hoy quiero hablar de tamaños. Y por mucho que me digan, el tamaño importa.

Resulta que la semana pasada durante un viaje, tras hacer a mi flamante ProBook 4310s color Burdeos (el de la foto) trabajar hasta ciertas horas un tanto intempestivas al día siguiente le dio por no ponerse en marcha por, según parece, un problema con la bios o la placa. Más allá de que estuviera mejor o peor montado (la verdad es que tratar de desmontarlo incluso con el material adecuado era una película de terror del bueno y no como las que hacen ahora) acabé resignándome y tratando con el servicio técnico que me lo tendrá reparado vete a saber cuándo (no les meto prisa).

El caso es que como no puedo estar sin ordenador (es lo que tiene ser un profesional de la informática), he cogido de prestado un Packard Bell de 17 pulgadas. Más allá de tener que reinstalar, recuperar datos, poner más o menos en solfa mi 'oficina' lo que no he podido poner en solfa ha sido mi utilización habitual del portátil.
Sé que la categorización de los ordenadores por su tamaño es variopinta: fijos, portables, portátiles, mini-portátiles y ultra-portátiles. Los hay más potentes y menos potentes.

Como sabéis si leéis mi blog, viajo mucho en tren. No me voy a quejar del peso añadido de llevar un portátil de 17 pulgadas (kilo y medio largo más) ni de que me ocupe más espacio en mi flamante maletín de mafioso (el maletín del dinero, que dice mi hijo con más razón que un santo) ni de que tiene un tamaño incómodo para abrir en un cercanías. De lo que me voy a quejar es de la falta de ergonomía como portátil.

Desde mi punto de vista, los portátiles con teclado numérico deberían estar prohibidos por la convención de Ginebra y de cualquier bebida alcohólica adicional. Si trabajas en una mesa, la disposición de tus manos hace que estés 'medio de lado': no es cómodo, no cumple las especificaciones de confort ergonómico (aparte de que según la ley española, un portátil no es un puesto de trabajo fijo y no debería ser habitual trabajar con uno)... Pero es que en el tren... ¡Uf! Entre que te lo pones en la falda, como quieras trabajar un poco estás incómodo y medio ante una postura más que forzada tratando de escribir mientras haces malabarismos para que no se te caiga o acabas aguantándolo con las dos manos y limitándote a usarlo de tele (eso sí, la pantalla es de lujo para un cercanías).
Y eso por no decir de la curiosa disposición de ciertas teclas que casi no se usan (av pág, re pág, inicio, fin...) en combinación con los cursores y las teclas de función.

Por eso, si sirve de algo, quiero pedir a los fabricantes de portátiles que por favor piensen un poco más en la ergonomía de uso de los portátiles grandes y no me vale eso de que 'te lo has comprado porque has querido, tenías más opciones' porque en el momento en que se diseña directamente no se ha tenido esa consideración. Dentro de mis posibilidades, voy a desaconsejar a cualquiera que pueda la compra de portátiles con teclado numérico.

Y por cierto, un portátil de 17 y casi 4 kilos no es portátil, es portable.
Y uno de 19 y más de 4 kilos, por mucho que se empeñen, no es portable... Es arrastrable.

sábado, 23 de octubre de 2010

La gran estafa de los gigas americanos

Al leer el titular uno se pregunta qué diablos son los gigas americanos. No es que hayan nacido en Nueva York o que sean de Rio de Janeiro. Es un criterio de simplicidad.

Si recordáis cuando íbais al instituto y utilizábais la calculadora científica, a la hora de hacer operaciones trigonométricas el aparatito normalmente tenía 3 modos: DEG (grados), RAD (radianes) y GRAD (graduanes o grados centesimales).
El último caso, que no se utilizaba casi nunca, supone que un ángulo recto tiene 100 graduanes y que una circunferencia completa tiene 400 y resulta que se usa muy mucho en países anglosajones (cosa que resulta curiosa con su fabuloso sistema métrico basado en millas, pies, yardas, pulgadas, etc). Supongo que para compensar lo fácil que es, eligen la utilización de ese sistema en sus cálculos trigonométricos.

El hecho de usar grados o graduanes es lo de menos. Un ángulo recto tendrá 90 grados o 100 graduanes, pero seguirá siendo recto.
El problema radica cuando a un librepensador de una empresa que fabrica dispositivos de almacenamiento se le ocurre la idea:
- Hoy he tenido una idea
- ¿Cuál?
- Vamos a hacer discos de muchos gigas
- ¿Y eso qué es?
- Un giga son 1024 megas
- ¿1024? Jo, qué complicado. ¿Por qué 1024?
- Es que está en base 2.
- ¿Y por qué en base 2? ¿Porque tenemos dos manos? Si es por eso, usemos la notación decimal, que también tenemos 10 dedos.
- Pues ahora que lo dices...

Así, el fabricante decide hacer un disco duro de, pongamos, 100GB. Pero no lo hace de 100GB, lo hace de 100 gigas americanos, siendo un giga americano 1000 Megas americanos, un mega americano son 1000 K americanos y un K americano son 1000 bytes.
Resultado: 100GBA (gigas americanos, no game boys advances) son 100*1000*1000*1000=100.000.000.000 bytes (93,13GB).
Lo que el usuario espera: 100*1024*1024*1024=107.374.182.400 bytes

Así podemos comprobar que hay una diferencia de un 7% entre la capacidad 'nominal' del disco y la capacidad real.
A mí el que un disco tenga 100 o 93GB me da lo mismo siempre y cuando esté etiquetado con la capacidad real y la realidad es que los discos portátiles siempre están etiquetados con la capacidad en gigas americanos, lo que me parece una estafa y desde mi modesto punto de vista es exigible que los fabricantes rectifiquen los envoltorios o realmente sean rigurosos con lo que se espera en el mercado que no utiliza gigas americanos...

...Más que nada porque Windows sí es americano y al enchufar el dispositivo rápidamente queda claro que a uno le faltan unos cuantos gigas. ¿Tendrá la SGAE algo que ver en todo esto?

Seguiremos informando.

Botón derecho, cuadrar y validar

El título de este artículo sería la funcionalidad más maravillosa que podría ofrecer la informática profesional en lo que a gestión de información numérica se refiere.
Lamentablemente, me temo que esta funcionalidad no estará disponible en esta vida, lo que tiene su parte positiva para no aumentar el paro entre los técnicos informáticos que en algún momento de su vida pasan horas y horas validando datos.
Hoy quiero rendir homenaje a este colectivo (entre los que me incluyo) con una historia verídica que da que pensar.

"La fabulosa historia del dato que nunca cuadrará o de cómo usar Essbase como calculadora carísima para realizar sumas sencillas de datos que no existen"
Como supongo que no hay tanta gente que conozca Essbase, diré que es una base de datos multidimensional con dimensiones jerarquizadas en estructuras arborescentes (hala, cuanto palabro) como puede ser Microsoft Analysis Services, SAP BW o Palo.
Una de las funcionalidades más potentes que posee es que se puede llegar a personalizar el cálculo de cualquier elemento de cualquier dimensión incluyendo una fórmula en ese elemento. El cubo, al procesarse, realiza el cálculo (que puede ser más o menos complejo).
A la hora de poner una fórmula en un miembro, hemos de considerar que si este miembro se calcula a partir de otros es posible que debamos ponerlos entre comillas siempre que pueda dar lugar a error. Por ejemplo, miembros con nombres numéricos o bien con espacios en su nombre.

Así pues, imaginad una estructura como la siguiente:
Total
+1
+2
+3
+4
+5
Los números que aparecen bajo el miembro 'Total' no son una suma: son miembros que se llaman 1, 2, 3, etc y son lo que se conoce como 'hijos' de 'Total'.
Ahora imaginemos que el miembro 'Total' ha de hacer la suma de estos miembros. Podría hacerlo directamente mediante la consolidación estándar del outline, pero entonces acabaríamos aquí la historia y no tendría gracia, así que utilizaremos una fórmula.
Pregunta de examen: ¿Cuál es la fórmula correcta?
a) Total=1+2+3+4+5;
b) Total="1"+"2"+"3"+"4"+"5";

(Redoble de tambores).
Si habéis contestado la primera os recomiendo la lectura del DBAG de Essbase. Hala, castigados al rincón.
Si habéis contestado la segunda, habéis acertado.
El caso es que las dos son correctas sintácticamente, pero el primer caso hace que 'Total' siempre siempre siempre (incluso aunque falle) sume 15.
El segundo caso, sumará el valor cargado en cada uno de los miembros.

¿Y qué pasó con ésto?
a) Pasó que el que desarrolló el outline y le puso la fórmula no estaba muy inspirado ese día.
b) Aparte de no estar inspirado desarrollando, hizo una validación de Premio Nobel
c) Encima lo entregó
d) Y el cliente no se dio cuenta... Durante varios años.

¿Y qué conclusiones sacamos de esta situación?
a) Que por mucho que queramos, las validaciones nunca son fáciles para el que no conoce al dedillo el negocio y los datos... E incluso para el que los conoce.
b) Que habitualmente almacenamos mucha más información y a un nivel de detalle muchísimo mayor del que realmente se va a utilizar, complicando sobremanera las bases de datos o los cubos.
c) Que en la vorágine de datos de millones de trillones de valores de euros o cantidades, un valor que sume 15 o 5000 pasa fácilmente inadvertido, corrompiendo la sagrada integridad de los datos.
y d) Que debería haber una pena de cortar al menos un dedo de cada mano con movimiento rápido y contacto del pie en la entrepierna al lumbreras que programó, validó y liberó tamaño pecado mortal contra las buenas prácticas de Essbase y de cualquier desarrollo informático.

... Y bueno, el que lo hizo vivió feliz porque no estaba cuando se descubrió el error y además no había pena capital por ello, el cliente miró hacia otro lado y el cubo comenzó varios años más tarde a funcionar como debiera en el final más feliz que podía tener un cuento como éste.

Fin.

miércoles, 20 de octubre de 2010

¿ETL-gonomía?

Aunque cada vez es más conocido, un porcentaje muy grande de los clientes y de los desarrolladores de proyectos no asocian un proyecto de análisis de datos a la complejidad del tratamiento de los mismos que hace que más del 80% del tiempo de desarrollo del proyecto deba dedicarse a la labor de generar y tratar los mismos.

El caso es que muchas veces cuando sí se asocia y se sabe, uno se encuentra con una señora herramienta ETL y en otros casos con una infantil etl. La verdad es que en algunos casos las etl son mastodónticas y multimuchascosas y permiten hacer lo que no está escrito (con más o menos dificultad). En otros casos, son auténticos quebraderos de cabeza que impiden cargar un simple fichero de texto sin tener que pasar por 25 pasos y varios servicios o aplicaciones haciendo bueno al importador de datos de Access.

En el último caso, que suele ser frecuente cuando uno no tiene bien definido todos los procesos de carga, es cuando se hace más patente la absoluta falta de ergonomía de algunas ETL.
Y en este caso quiero hacer especial hincapié en las ETL de Oracle (podría ser extensivo a casi cualquier producto de Oracle, no obstante): ODI y OWHB.

No quiero entrar en su funcionalidad (hacen lo que deben) pero sí en puntualizar algunas cosas:
- El ¿mal? uso de Java como interfaz que hace de cada click un drama (Kettle también usa Java y es mucho más ágil)
- La absoluta falta de la opción de deshacer
- El aspecto tan moderno (apreciación personal, pero es que me recuerda a las aplicaciones de windows 3.1 de finales de los 80).
- La filosofía de desarrollo de ODI, muy lejos de lo que es la filosofía estándar de una ETL.

De estas cosas la que más molesta me resulta es la primera. Entiendo que Oracle potencie el uso de Java al ser ahora su propietario tras la adquisición de Sun, pero no iría mal un planteamiento diferente en lo que a implementación se refiere.

Sun no podía haber elegido un mejor nombre para su entorno de programación que Java: cada vez que ejecutas algo puedes ir a tomarte un café.

martes, 19 de octubre de 2010

RRHH - Recursos Recurrentes Humanos y Hastiantes

Durante estos días que estamos, además de ocupados en nuestros proyectos, realizando muchas entrevistas a candidatos (cosa de la que hay que alegrarse) uno se da cuenta de lo complicado que es encontrar un candidato que cumpla las necesidades ante una posible incorporación en un cliente.

El mercado de BI es muy extenso y las oportunidades a veces se generan con herramientas de nicho de las que hay un número bajo de técnicos en el mercado. Al poner un anuncio en infojobs buscando un determinado perfil a veces se sabe de antemano que el número de candidatos potenciales tiende a ser pequeño pero que en muchas ocasiones suena la flauta y se obtiene un perfil adecuado. La oferta entonces es efectiva.

No obstante, en estos tiempos de crisis que corren en que muchísimos técnicos están en el paro (voluntario o involuntario) o bien en una situación precaria uno esperaba que al poner un anuncio se llenase de forma espectacular pero:
1) no es así, no se da el caso y el recurso perfecto se hace de rogar.
2) la gente no sabe leer, lee en diagonal o le da igual lo que diga la oferta.

Mi jefe dice que soy draconiano a la hora de evaluar un candidato en una oferta, pero es que si no lo soy, no sé por qué, acaba pringando el que escribe y eso hace mucha gracia (léase la fina ironía).
De todas maneras, decidme si no es para ser draconiano la tipología de CV que te encuentras ante una oferta del tipo:
Busco consultor técnico de Hyperion Essbase con al menos un año de experiencia.
En las ofertas solemos poner preguntas para evaluar de forma rápida a los candidatos y poder tener una visión actualizada de sus capacidades más allá de lo que actualicen su CV en Infojobs. La pregunta estrella ante la oferta de antes es:
¿Cuál es tu conocimiento de Hyperion Essbase?
a) Modelo cubos y desarrollo calc scripts
b) Sólo modelo cubos
c) Hace mucho tiempo trabajé con ella
d) No conozco la herramienta
No sé si os sorprendería saber que la mayoría de los que se inscriben no han visto a Essbase en su vida. En cualquier caso, siempre quedan curiosas anécdotas como:
- El que nunca había trabajado en consultoría, su último trabajo era de reponedor en un supermercado y 'hacía tiempo que había trabajado con Essbase'
- El que no conoce la herramienta, no tiene un año de experiencia pero 'aprende muy rápido'
- El que modela cubos y desarrolla calc scripts pero no aparece ni una mención a Essbase en su CV en texto en el que figura hasta que había trabajado de repartidor de pizzas o socorrista piscinero (con todos mis respetos a esas profesiones)
- El que fue un megacrack de Essbase, sus últimos trabajos fueron de mando intermedio y sus pretensiones salariales están 3 veces por encima de la especificada claramente en la oferta.

Y así otros muchos que hacen que uno se pregunte entre muchas otras cosas:
- ¿La gente no se da cuenta de lo mal que quedan si se apuntan a ofertas de las que no cumplen los requisitos mínimos exigidos y además no hay posibilidad de no quedar en evidencia?
- ¿Por qué hay candidatos que se apuntan a todas y cada una de las ofertas que hay independientemente de las tecnologías que deban utilizarse?
- ¿No es más fácil enviar el CV a la empresa directamente que pretender que a uno le fichen de director general cuando se pide un becario?
Y la más importante: ¿cómo se gestionan actualmente los supermercados para que los reponedores tengan que aprender Essbase?