Please don’t tell me how your java API does the same that the ABAP API…please don’t even try it with all the dust I have already eaten from SAP integration projects!. Let’s just not get started with JCO.

What really grinds my gears is all the sectarianism coming from 25 to 35 year olds SAP consultants who paid 5 digits for their SAP masters and now see how their customers just want to have their data in XML format and move elsewhere where the licenses are cheaper and you are not billed at hello (yes, McGuire pun intended).

I have heard so many SAP consultants say customer data is SAP property, and that this data should not be exposed in standard ways that they almost sound like a witchcraft coven.

It is even more annoying in the public sector. This is where really there is absolutely no reason for such isolationism and such lack of respect for cooperation and standard. If you are going the SOA way, go the SOA way, and stop playing “black-box strategy” right now because the 2008 stock crash was a clear message to you… go open, or go bankrupt, it is that simple.

Por razones familiares me he tenido que pasar día sí, día también, de visita en el hospital, de urgencias a observación, de observación a la habitación, de la habitación a la UCI y de nuevo a esperar a la habitación las noticias del cirujano. Por cierto, chapeau por la sanidad pública (y lo dice un antiguo fan de Sanitas).

¿Qué haces tú cuando esperas que operen de urgencia a tus seres más queridos?, ¿Cuándo no sabes si mañana les miraras a los ojos sonriendo o les tendrás que susurrar al oído sin saber si te escucharan?. En mi caso, lo que hago para poder aguantar la espera es programar el mejor puto código que te hayas podido echar a la cara: patrones de diseño, análisis estático, pruebas de rendimiento, refactorización del código “heredado”, test de accesibilidad, documentación de lo que el código no explica… “you name it”.

Había probado a pasear por los pasillos, pero después de haber andado unos 15 kilómetros de un lado a otro ya me había imaginado todas las secuelas que una operación te pueden dejar y ya estaba poco menos que temblando.

También había probado a comer, igual que cuando era pequeño, atiborrandome de chocolate, una bolsa de vending tras otra.

Probé a mirar la pared, a ver la tele, a leer un libro, a hablar con mis otros familiares,  pero solo el código me dió lo que necesitaba: una total y absoluta concentración en algo ajeno a la realidad, algo ajeno al mundo de los vivos, algo insignificante y a la vez eterno como es el código, esa abstracción simplista de nuestra propia evolución racional, ese ente abstracto y sin embargo tan tangible y útil que está marcado a fuego la entrada en la era de la información y revolucionando esta parte de la galaxia: desde la Tierra hasta más allá del cinturón de Oort. Ha sido el código el que ha puesto a los milmillonarios frente a los que mueren de hambre y les ha avergonzado hasta la solidaridad.

¿Te apasiona lo que haces?, no dejes que te quemen, disfruta o cambia, cambia primero tu vida y después cambia el mundo.

Se ha iniciado una guerra de difamación en la red sobre ¿quien creo el meme de la chica con sindrome de down?, recientemente salió un reportaje en la televisión británica divulgando el abuso que ha sufrido esta chica mediante el uso de su foto en un meme denigrante que está muy extendido por Internet.

Lo curioso es que 4chan ha lanzado una de sus famosas campañas “virales comunitarias” para echar la culpa a 9gag, mientras que knowyourmeme (en el momento de publicar esta entrada de mi blog) decía que la idea del montaje de un paciente de sindrome de down en realidad fue promovida por la comunidad de funnyjunk en Febrero de 2010.

Puede sonar a frikada pero teniendo en cuenta la rentabilidad de cualquiera de los sitios que he mencionado estamos hablando de mucho perjuicio económico que al menos uno de los arriba mencionados va a sufrir, me alegro!.

Bueno, no está mal, es decir, es una opción que puede ser valida en ciertos contextos, por ejemplo si solo quieres volcar unos cientos de polizas a tu sistema informático y las aplicaciones de dicho sistema son irrisorias, prescindibles o sino al menos, sustituibles a bajo coste.

Pero desgraciadamente no suele ser así: en la mayoría de proyectos de integracion corporativos los datos no son pocos y los sistemas de ambas arquitecturas de software suelen ser dispares y heterogeneos. Como muestra un boton: una pareja que tuvo la desdicha de contraer matrimonio durante la integración Bankia-Bancaja se vio obligada a cambiar la cuenta del banco tres veces.

No conozco ese proyecto pero supongo que el equipo de proyecto analizó, argumentó y documentó si la integración de sistemas mediante SOA y la coexistencia de datos no hubiera sido más apropiada que cambiar las cuentas a los clientes.

Puede ser que fuera obligado cambiar el número de cuenta al cambiar el código de entidad, pero ¿se podría haber mantenido el código de entidad y correlacionado los numeros de cuenta  para evitar el cambio de cara al usuario final? o ¿estaban obligados a desterrar el codigo de la entidad descontinuada?,

Pd: Da gusto hablar de proyectos ajenos, sin acuerdos de confidencialidad que te impidan hablar y dando lugar al sano debate ^-^.

Ideas clave (no es una lista exhaustiva):

1. Si tienes un modelo de negocio donde el consumo de trafico te repercuta dinero úsalos, si no tienes ingresos estimados reales, el cloud de pago no es una opción
2. Si vas a usar java, mucho cuidado con las black list, white list y el versionado de los JARs (http://code.google.com/appengine/docs/java/jrewhitelist.html)
3. Como empieces a programar para un proveedor de cloud te casas con el, a pesar del YAML y otras historias, esto probablemente jamas cambie, independientemente de lo que te digan los comerciales.
4. Si te exigen un SLA concreto, eso es un argumento a favor del Cloud serio… pero darle a un cliente español hosting americano va a chirriar en el departamento de protección de datos.
5. Si no tienes ni idea de clustering y no tienes a quien preguntar, ni te lo plantees, necesitas un proveedor de cluster, ya sea cloud o llámalo X.
6. Si tu aplicación no requiere dar servicio el 99% del tiempo con un Mean time to repair (MTTR) mas bajo que una hora (por decir algo) pontelo en servidores propios.
7. Coge todo lo anterior, mételo en la termomix y haz lo que creas… cuando antes te das la primera torta, antes aprendes, lo digo por experiencia. Por cierto: sentido común, haz los experimentos con la gaseosa, no con el pan de tus hijos.

Batallitas de abuelo cebolleta:

Lo primero que diría sobre el Cloud Computing es lo que ya dije hace meses sobre rechazar el cloud por definición, ahora bien, si me preguntas como ha evolucionado la cosa, en general los servicios han mejorado y son mas estables que hace meses, sigue pareciéndome que lo que te ahorras de molestias de hosting lo ganas en otros problemas.

Un problema es saber cuanto te quieren cobrar, por ejemplo las tarifas del Google App Engine son un galimatias: ya no tienes que preocuparte del hosting, sino de lo que te va a costar el hosting, cambias un problema por otro, tu modelo de negocio tendría que estar definido hasta un nivel de detalle que lo haría poco realista (hacer un plan de ROI realista en el mercado tradicional es difícil, en Internet es un chiste).

Mirando en retrospectiva recuerdo que nosotros hemos tenido desde 2001 hosting americano, ni nos planteamos en su momento el hosting español por motivos obvios. Cuando empezamos a hospedar aplicaciones web propias (o aplicaciones SOA que exponen servicios a terceros como apps android) nos dimos cuenta de que era mas barato y cómodo hospedar las aplicaciones en un piso y nos costaba 50 euros al mes entre luz y electricidad, e incluso podíamos aprovechar la conexión para usos ajenos, como echar un Modern Warfare 2 , jaja, que buenos tiempos.

Durante un año usamos hosting compartido JVM, sin comentarios, JAMAS hagas eso, en serio, no pierdas el tiempo y el dinero.

Cuando la cosa empezó a crecer los servicios de cloud estaban en pañales y ademas al ser un coste variable según trafico necesitábamos un modelo de negocio que no teníamos para varios de nuestros proyectos. A día de hoy y con el nivel de ingresos online tan bajo que hay, yo no veo eso de que me cobren por trafico en la mayoría de nuestros proyectos, quizás en alguno si sea una opción, pero tendría que estudiar el ROI en detalle y cruzar los dedos.

Algo más concreto para javeros:

A día de hoy la cosa ha mejorado, pero un tema que me preocupa es la versatilidad del classloading teniendo en cuenta que tenemos hospedados proyectos java que tiran con la java 4, java 5, java 6 y java 7 con tres BBDD diferentes, que nos integramos con sistemas más raros que un perro verde y que cada cliente pide cada día cosas mas frikis. Quizás si lo del “java module”, los “java OSGI” y otros temas evolucionan pasemos alguna cosa a cloud de ese tan chulo que montan Amazon y Google (departamentos legales mediante), pero cuando veo que las consolas administrativas de algunos proveedores de cloud tienen iconos visuales veo claramente que no están pensados para ingenieros que necesitan el 100% de versatilidad, están pensados para los que hacían aplicaciones visual basic, para venderle la moto a los gestores trajeados que saben poquito de todo esto.

Por ejemplo CloudFoundry te limita las APIs de persistencia una barbaridad… como decía el presentador del fútbol cabreado ¡PERO ESTO (del cloud computing) QUE ES! XD.

Por supuesto solo es mi opinión .

• Que sepas que cada vez que cambias la definición de servicio una (foca bebe/gatito/cachorro) muere
• Solo confío en dos tipos de protocolos: uno son los protocolos estándar y el otro no son los protocolos propietarios
• Eres menos fiable que un web service recién publicado
• Eres menos estable que un web service recién publicado
• Vuestros servicios me recuerdan a mi EX: no son fiables, no son estables y desde luego no cumplen el acuerdo que tenemos firmado
• Si esto es SOAP estándar que venga el W3C y lo vea
• Al estar en España podemos usar SOAP: Si se Ostia Asigna mas Presupuesto
• Esto es gobernable, sinergico, reutilizable y proactivo… ahora viene cuando os vendo una licencia de ESB comercial y encima me dais las gracias
• La idea original de los servicios era democratizar Internet, afortunadamente se impuso la cordura.
• SOA es bueno y sabéis porque, porque la otra opción es usar un único sistema centralizado, imaginaros la cantidad de caciques locales que quedarían sin trabajo… pequeños Hitlers en potencia campando por ahí.
• Podríamos hacer definiciones SLA a la española, necesitamos servicios que consuman un 300% de los recursos necesarios y desvíen la CPU sobrante a un paraíso fiscal.

El accidente de Spanair en 2008 fue el ejemplo más visible de como el maltrato a los técnicos puede llevar a la muerte de tus clientes (y de tu propia empresa, que a muchos empresarios retorcidos les parecerá peor). A día de hoy la culpa del accidente se atribuye a los técnicos, pero eso es tan falso como asegurar que la culpa de la crisis financiera es de los pobres y no de los bancos que les concedieron los prestamos.

Cuando los perfiles más técnicos de tu negocio sistemáticamente se saltan las medidas de seguridad la culpa no es suya, es de la política promovida por los gerentes. Eso va desde los técnicos de la aviónica, hasta los subdirectores de oficinas bancarias pasando por todos los perfiles I.T. de la empresa.

La estrategia que muchos gerentes plantean ante situaciones catastróficas donde el ámbito técnico está totalmente viciado es preparar una jugosa prejubilación, aunque sea la misma mañana que va a ser intervenida o cerrada su propia empresa. En España ningún gerente va a la cárcel por eso.

Said so, let’s have a second of silence for the family-managed video renting service that closed just two streets away, two weeks ago (true story) which fought fiercely to keep open but could not survive the illegal activities developed by Megaupload & co.

The sense has come: websites are trying to demote users from sharing copyrighted content and laws like SOPA, although irritant for many users, point in the right direction: Internet must not be a pirates den. I can understand people against SOPA, but if you don’t protect small content creators somehow we will only have “copy-pasta” meme based comics in the near future to entertain us. I say, “fuck Hollywood”… OK, but please don’t fuck small families trying to pay for food and rent.

Some stupidity is also coming this way: funnyjunk.com for example is requesting registered users to insert a captcha AND agreeing to a “non copyrighted content disclaimer” to registered users every DAMN 48 hours!… holy god… come on gentlemen, what happened to common sense?.

Fase 1, “asesoría enorme que pasa de ti”: Mi primera experiencia fue con una asesoría conocida por familiares empresarios que llevaban toda la vida trabajando con dicha asesoría, mi familiar me lo decía claro: “para lo básico valen, pero no les pidas mucho más”.

Que razón tenías… cada vez que iba allí tenia la impresión de ir como a la pescaderia: coja turno y pase que le graben dos números en un papel que se amontona en una pila.  En el año y medio que conté con ellos para la contabilidad solo respondieron con capacidad y experiencia a una pregunta ¿donde está el servicio?.

Fase 2, “asesoría del cacique local”: Visto lo visto dije, error Raul, error, tenias que haber cogido una asesoría pequeña cercana, con poca gente y sobre todo humana… así acabe en “caciquelandia asesores”, donde el jefe estaba mas a su ocio ocasional que al papeleo… todas mis gestiones las hacía el becario, pero ademas, el becario cambiaba cada 5 meses, con lo que cada dos declaraciones del IVA teníamos un nuevo problema de novatos.

Fase 3, “asesoría del desocupado”: Pensé que el error estaba en la zona… digo, estoy buscando mal, voy a lo más visible, a las asesorías “estrella”, tengo que buscar el “underdog”, ese asesor infravalorado, que en el fondo es el Jerry McGuire del tema fiscal… bueno no sabría por donde empezar con este señor. ¿No existe en asesorías fiscales un nivel de ineptitud tal que se considere delito?, supongo que si no lo hay en desarrollo de software tampoco lo habrá en el tema fiscal.

Fase 4, “una asesoría buena”: Una asesoría donde el que te atiende es el experto, donde escriben mails breves y concisos con la solución a los potenciales problemas antes de que surjan, que te informa cuando te tiene que informar, no un día después de pasado el plazo y no te toca las narices con cobros “ocultos” cuando no es menester… 7 años me llevó encontrarla y no la pienso soltar.

Como ingenieros, no debería preocuparnos que lenguaje están usando actualmente en un proyecto, sino que decisiones técnicas soportaron ese uso y la conveniencia de mantenerlo en un futuro. El uso de Criterias no va a perjudicar la mantenibilidad de una aplicación, pero el copy-paste de Criterias sí que puede generar un peligroso código espagueti.

Quizas te han dicho que el LQL (“loquesea” query language) es el futuro, pero después de 5 o 6 años dando vueltas con el mismo tema quizás acabemos dándonos cuenta de que intentar estandarizar lo que no se deja estandarizar no termina de ser rentable.Y pocos proyectos comerciales usan dichos lenguajes con exito:

Tristemente son pocos los proyectos los que se benefician de la portabilidad de BBDD… eso sí, los que se benefician, se ahorran una cantidad de problemas tremenda, como es el estar pagando licencias de BBDD de por vida ¿no nos interesará a todos entonces esa portabilidad?.

Incluso todavía hay gente defendiendo la bondad de los procedimientos almacenados para contener la lógica de la aplicación “en alguna” circunstancia… ¡cosas veredes!.