Para programar software para empresas hay que ser un machote (o machota), un auténtico pro, un técnico que tiene lo que hay que tener. Por ejemplo, a la hora del diseño gráfico de interfaces: no os creáis que porque hayáis trabajado 10 o 12 años con Photoshop o ganado algún premio Webby estáis preparados para diseñar interfaces de usuario de software corporativo. Para esto no basta querer, hay que valer…

RT @Geek and Poke

Sé que soy un privilegiado por disfrutar del apoyo de Sixservix para volver a asistir a la conferencia. Un apoyo que, desgraciadamente, es difícil de encontrar en el sector de las TI en España y América latina. Pero, en cualquier caso, conozco gente que, aún pudiendo asistir, ni siquiera se lo ha planteado; bien por desconocimiento del evento en sí, bien por antiguas y falsas creencias o leyendas. Así que, permitidme que os explique qué espero encontrar allí, qué pienso hacer y cómo pretendo hacerlo. Ojalá que, cuando acabéis de leer este artículo, todos estéis deseando acompañarme. Si no este año, quizás el siguiente.

UNA CIUDAD. UNA SEMANA. TRES CONFERENCIAS

Ya comenté el año pasado como la javaOne cumplía con las 3 Bs: bueno, bonito y barato. Este año, después de unos meses de incertidumbre en los que ni siquiera sabiamos si iba a celebrarse, nos encontramos con que Oracle, el nuevo amo y señor de Java, ha montado la mundial. No sólo sigue celebrándola sino que ha decidido juntarla con Develop, su conferencia de desarrolladores,  y OpenWorld, su evento más orientado a tíos-que-manejan-la-pasta y cuellocorbatas.

La primera consecuencia de todo esto es que San Francisco va a estallar. Si a los 15.ooo asistentes de la javaOne les sumas los 43.ooo trolorolos que asistieron a la OpenWorld del año pasado y reservaron 81.000 habitaciones de hotel, te encuentras con que es más facil conseguir batir el récord olímpico de petanca que conseguir una habitación de hotel económica en la ciudad del Golden Gate.

La segunda consecuencia es que, durante una semana, San Francisco probablemente disfrute del mayor número de técnicos y desarrolladores reunidos de la historia. Porque, a la tremenda horda invasora, hay que sumar la población local de tipejos que desarrollan cosas como Twitter, Google o cacharros como los de Apple o Hewlett-Packard.

En definitiva, 2.150 sesiones condensadas en una sóla ciudad y una sóla semana. La posibilidad de asistir a charlas de cualquier tecnología o lenguaje que se te pueda ocurrir impartidas por los mejores: sus creadores. Y, por supuesto, la posibilidad de conocerlos.

No hay nada ni remotamente parecido en el mundo de las tecnologías de la información. Ni en tamaño ni en posibilidades. Ni para aprender, ni para hacer networking. Nada se acerca a lo que va a verse en esta JavaOne.

LA MISIÓN: LIARLA PARDA

¿Y qué espero este año de la javaOne? ¿Qué pretendo hacer allí? Evidentemente, dar un paso más en mi plan secreto para dominar el mundo y, de paso, aprender todo lo que pueda, conocer gente interesante y divertirme. Voy a intentar resumir en 6 puntos mis expectativas:

• APRENDER MUCHO. Sí, es verdad que con Internet no hace falta asistir físicamente a una conferencia para aprender cualquier conocimiento pero, sinceramente, ¿cuántos de nosotros tenemos tiempo en nuestro día a día para ponernos a leer complejos tutoriales o sumergirnos en vídeos y vídeos de charlas y ponencias? La javaOne permite que durante una semana, nos aislemos de todo y de todos y nos dediquemos a lo que más nos gusta: aprender.
• HACER NETWORKING. Sí, networking, pero del de verdad. Espero conocer a mucha gente-que-de-verdad-hace-cosas como los denomina Alberto Molpeceres. Todo lo contrario a los eventos de tipo “reinventa Internet” que han crecido como setas en mi país.
• CREAR COMUNIDAD. El año pasado constaté que los hispanohablantes éramos más de los que cualquiera pudiera creer pero, al contrario que los brasileños, nos falta marketing. Espero que en esta javaOne se oiga el castellano más que nunca. Por mí no va a quedar.
• COMUNICAR, COMUNICAR, COMUNICAR. Si el año pasado perdí horas de sueño haciendo las crónicas del día para javaHispano, este año el trabajo se multiplica. No sólo intentaré enviar las crónicas diarias, sino que podréis leer la versión gamberra y desenfadada de las mismas en este blog. Además, nuestras cuentas de twitter echarán humo, por supuesto y, como gran novedad… MEGATÓN: intentaré retrasmitir al más puro estilo reportero dicharachero mediante screencast. Eso, si consigo averiguar cómo funciona la cámara que me regaló Jeroclo por mi cumpleaños.
• COMER PATO LAQUEADO EN CHINATOWN. Una sana costumbre que instauramos Álvaro Hernandez y yo el año pasado y a la que esperemos que se sumen los nuevos fichajes de este año: Erick Camacho, compañero del metal en javaHispano, y Jeroclo, el espartano, amigo, camarada y socio, en representación de Funius. Por supuesto, habrá que ir a disfrutar del brunch del domingo al Top of the Mark y seguro que caerá más de una porción de tarta en el Cheesecake Factory de Union Square. Al fin y al cabo, las tradiciones están para respetarlas, ¿no? :P

BONILLA 3.0

Este año todo ha cambiado, TODO es diferente. Y no sólo hablo de la compra de SUN por parte de Oracle, sino de cambios a nivel personal y profesional que, en parte, han sido motivados o acelerados por mi visita a la última edición. Apenas me reconozco cuando pienso en el Bonilla que asistió a la edición del año pasado.

Hace un año, este blog no existia. Hace un año, no conocía a toda la gente interesante que me ha enriquecido en los últimos 365 días. Hace un año, ni siquiera estaba viviendo con mi novia, que en menos de 3 meses se convertirá en mi mujer. Hace  un año, no tenía cuenta en Twitter. Hace un año, España ni siquiera soñaba con ser campeona del mundo. Hace un año, no era ágil. Pero, sobre todo, hace un año, no tenía tan claro como ahora qué es lo que quiero hacer y cómo lo quiero hacer.

La asistencia a la javaOne del año pasado consiguió que me enamorara definitivamente de mi profesión. Que me diera cuenta de que las cosas que no me gustaban de ella no tenían que ver con LO QUE hacía sino con CÓMO lo hacía. Hace un año, vi que había otro modo de hacer las cosas y que te podías ganar muy bien la vida haciéndolas.

Al acudir a la javaOne, pude conocer a gente que estaba a años luz de mi círculo de influencia, como Kohsuke Kawaguchi o Vinicius Senger, tuve la posibilidad de acercarme a tecnologías y proyectos antes de que se difundieran en España y demostrarme a mí mismo que puedo defenderme con mi inglés en Estados Unidos, Albacete o Sebastopol.

Hace algunos años, perdí 25 kg y cambié de estilo de vida. Mis amigos se sorprendieron tanto que bromeaban llamándome “David 2.0“. Durante este año, creo que he cambiado tanto que he pasado a la siguiente release y puedo considerarme “Bonilla 3.0“.

No, no me he vuelto loco. No creo que la javaOne me haya cambiado la vida pero, sí estoy seguro de que sirvió como trigger para ayudarme a reconocer qué es lo que quería hacer con mi trabajo y mi profesión y comenzara a dar los pasos necesarios para lograrlo.

CONCLUSIONES

Un año más, debo agradecer la confianza y soporte de Sixservix que me va a permitir asistir a la conferencía. Además, Jeroclo, Erick y un servidor viajamos a la conferencia con entradas gratuitas de bloggers por deferencia de Oracle en general y su Directora de Comunicación para España y Portugal en particular, Mildred Laya, que nos ha hecho sentirnos “importantes” aunque sepamos que no lo somos.

Al que sea mal pensado y crea que nos hemos vendido a Oracle, decirle que no sabe de lo que habla. Yo no podría venderme jamás a Oracle. Todo el mundo sabe que Microsoft paga mucho más.

Al que haya llegado hasta aquí y vaya a ir a la javaOne, animarle a que se ponga en contacto conmigo a través del formulario de contacto de este blog. Cuantos más seamos, mejor, más ruido haremos y mejor nos lo pasaremos.

Si, por el contrario, aún no tienes entrada, te recuerdo que el periodo de early bird o precio reducido ha sido prorrogado hasta el 30 de julio. Aún estás a tiempo de animarte y venirte a San Francisco. Te costará bastate menos que cualquier curso de formación de alto nivel de una semana que puedas tomar en España.

En cualquier caso, y como a veces pido a los amigos, difundid la palabra de Bo: retwittead, reenviad o mandad por correo este artículo. Que no haya ni un sólo hispanohablante que vaya a la javaOne y no se una a nuestra Spanish Armada. Este año, vamos a por todas y aquí te lo contaremos.

Artículos relacionados:

1. Mi agenda para la javaOne 2010 Esta es mi agenda preliminar para la edición 2010 de...
2. ¿Habrá JavaOne en 2010? Uno de los principales damnificados de la fusión entre Oracle...

Jeroclo, el espartano, me advirtió sobre la existencia del vídeo. Como sabía que iba a estar de acuerdo en muchas cosas y en desacuerdo en otras y que no suelo callarme lo que pienso, me pidió que escribiera un artículo al respecto de los que a él le gustan, a lo Karate Kid, por lo de “dar cera y pulir cera”.

Ahora que Larry es oficialmente mi jefe, después de haberme contratado por una botella de vodka, creo que es más que oportuno que matice las palabras del líder. Así que, allá vamos. Abróchense los cinturones.

El vídeo de Larry. Tiene subtítulos y dura sólo cinco minutos. No os asustéis, ¡cobardes!

Pinche aquí para ver el vídeo

A Enrique le tiene que gustar mucho el vídeo, no obstante lo ha exportado desde formato Real Video, lo ha recortado, subtitulado, subido a YouTube y reconoce que lo ha utilizado como material lectivo en todos sus cursos.

Hombre… el vídeo es bueno. A Enrique -al que sigo y del que aprendo- se le agradece el esfuerzo y Larry está gracioso diciendo verdades como puños pero, ya que se va a utilizar como material lectivo, me gustaría puntualizar algunas cosas al respecto desde una perspectiva diferente, no la del “manachment” que aporta Enrique -me he leído su curriculum y ha sido profesor, consultor, miembro de comités que ni siquiera sabía que existian y accionista o consejero de startups del más diverso pelaje pero, no he podido encontrar un sólo trabajo como picateclas raso o brown eater junior-, y más cercano a las trincheras, al programador que tiene que implementar las ideas que Larry y otros guruseles de las TI programan en Powepoint o en Keynote, que queda aún más cool.

Dice Ellison que los grandes problemas de la gestión de la información en las empresas se pueden resumir en tres puntos:

• La dispersión de la información. Enrique lo traduce como “fragmentación de los datos” pero, cualquier informático, sobre todo cualquiera que trabajara con bases de datos de Oracle, empezaría a pensar en bloques de datos de n KB y fragmentación de datos en disco. Nada más alejado de lo que quiere decir Larry, que se refiere a que los datos de una empresa, suelen estar dispersos en mil y una bases de datos corporativas, departamentales, dedicadas a una aplicación especifica y más.
• La integración del software. Larry se queja de que los desarrolladores nos dedicamos a, sorprenderos, ¡desarrollar software! y, evidentemente, ese software no está diseñado para trabajar conjuntamente, lo que produce grandes quebraderos de cabeza para integrar y hacer funcionar todos los productos y tecnologías que utilizamos en nuestra empresa.
• Adaptabilidad del software. Larry habla de “automatización” y Enrique lo traduce as is, pero una vez más, no creo que la traducción sea la más apropiada. A lo que se refiere Ellison es a las dificultades de la industria para producir software corporativo out-of-the-box, es decir, de los de “mete el CD en el ordenador, instálalo y ponte a utilizarlo al momento”. Parece que los desarrolladores no sabemos o no queremos hacer software sencillo y autoexplicativo para su uso en distintas empresas.

Bueno, pues aunque Larry no ha descubierto la polvora, la verdad es que tiene más razón que un santo. Lo que pasa es que en el vídeo se le ha “olvidado” alguna cosilla que vamos a intentar recordar aquí:

• La dispersión de la información. Es verdad, tenemos más bases de datos que sentido común. Es fácil encontrar ofertas de hosting en donde te ofrecen “5 bases de datos y en la versión premium, 10″. Pero, aunque tengamos una única base de datos, de nada sirve si nuestras sucesivas aplicaciones se instalán en schemas distintos o utilizan sus propias tablas. Otra cosa que Larry y Enrique pasan por alto es que esta batalla no se juega en la base de datos, sino en un territorio mucho más hinospito: la ofimática. Porque la mayor dispersión de datos no la provocan los desarrolladores, sino las hordas de managers en ciernes que salen de escuelas de negocios como en la que da clase Enrique, armados hasta los dientes con Powerpoints y Excel donde hacen su “yo me lo guiso, yo me lo como”, plasman su know-how y “aportan valor” a la empresa. Mi primera labor como CEO de una empresa siempre sería la misma: prohibir el Excel y derivados. El Excel puede ser una de las herramientas más dañinas  para la actividad de una empresa y debería utilizarse únicamente como última solución y como herramienta de apoyo, nunca de trabajo ¿Sabéis qué es el Excel Hell? Pues si habéis trabajado como informáticos en ambientes corporativos, seguro que lo habéis sufrido…
• La integración del software. Pues sí. Es difícil conseguir que un programa de facturación hecho por un equipo hindú se integre correctamente con un programa de nóminas hecho en Albacete. Para solucionarlo, tenemos dos posibilidades. La primera, la que sugiere Larry: “me lo compras todo a mí y, a cambio de mucho dinero, te prometo que te ahorraré aún más dinero. Te ahorrarás mucha pasta en técnicos, que emplearás en pagar a mis consultores”. Porque, no nos engañemos, optar por una solución de Oracle no implica que todo funcione al instante y mágicamente. Cualquier técnico que haya intentado instalar una suite de aplicaciones de Oracle sabrá que es complicado, muy complicado. En cualquier caso, es una opción, que es muy válida para grandes empresas donde es más importante la respetabilidad y seguridad financiera que da una megacorporación como Oracle, antes que el ahorro de costes y la optimización técnica que prometen esos hippies que cobran millonadas y que pueden dejarte tirado de un día para otro para irse a cultivar alcachofas a un kibutz israelí ¿Cómo los llama Larry? ¡Ah, sí! technicians. Hay otra opción, impulsada no por Larry precisamente, sino por alguno de esos technicians locuelos. Se llaman Web Services o REST y consiguen que aplicaciones que tienen que ver tan poco entre sí como Aznar y el Che Guevara se comuniquen sin problemas. Probablemente a Enrique y a sus alumnos no les suenen estos términos, porque remangarse y mancharse las manos entendiendo BIEN qué es eso del protocolo HTTP no es nada cool para el “manachment” pero, si supieran que la API que hace que su adorado twitter sea lo que es hoy en día es una API REST como una casa de grande y que por eso tiene ese enoooorme ecosistema de aplicaciones alrededor, seguro que le prestaban más atención al respecto.
• Adaptabilidad del Software. Vaya, se queja Larry de que configurar un programa complicado es… complicado. Y tiene razón pero, ¿qué solución da al respecto?. ¿Alguien ha jugado a un videojuego de última generación? ¿Un Metal Gear, por ejemplo? Cualquier videojuego medianamente complejo te puede incluir un tutorial de cuatro horas que todos los jugones nos tragamos sin rechistar. Y eso sólo para aprender los rudimentos básicos del juego. ¿Alguien se puede imaginar al usuario medio tragándose un tutorial de cuatro horas antes de poder hacer algo con un programa en la empresa? Antes de que haya trascurrido media hora, te tiran el monitor a la cabeza. También dice que los ERPs, los CRMs y no se cuantos programas más están “sin acabar”. Mal ejemplo Larry, MUY MAL EJEMPLO. ¿Por qué? Porque el dominio funcional de un ERP, por ejemplo, es taaaan complejo que es literalmente IMPOSIBLE crear una aplicación capaz de modelar todas las realidades de una empresa. Créanme, sé de lo que hablo. No soy usuario avanzado, ni comercial, ni consultor de uno o varios módulos de un ERP. Yo he diseñado y programado un ERP desde cero, de la nada y es realmente difícil crear algo que se adapte a inputs y outputs tan variables como los que puede dar una única empresa. Imaginaos algo capaz de adaptarse por igual a una empresa como Recauchutados López o Indra. Podéis pensar que, aquí, el único paquete soy yo, pero a esa pequeña empresa llamada SAP, le pasa algo similar. Hay procesos SAP con más de 800 parámetros y, aún así, un CD con una instalación de SAP tal cual, vale lo mismo que un Open Bravo: cero patatero. Siempre hay algo que programar, siempre hay algo que adaptar, siempre hay un Director Financiero que quiere el informe en verde, no en naranja. ¿Oracle soluciona mejor que nadie todo esto? No tengo ni la menor idea. La última vez que intenté comprender por completo el portfolio de Oracle (¿Peoplesoft? ¿JD Edwards? ¿Siebel?), me empezó a doler la cabeza como cuando me pregunté “si antes del Big Bang no había nada, tenía que haber algo, porque el mismo concepto de la nada implica que haya un algo que se contraponga”. No he encontrado respuesta en ninguno de los dos casos.

Bueno, al fin y al cabo esto sólo es un ladrillo de un Jedi seducido por el lado oscuro, de un técnico que navega entre el manachment y el entrepeneurship.

Probablemente, todas estas divagaciones sólo lleguen a mis fieles espartanos. A Jeroclo, a Vilches, a Beas, a Arranz y a tantos otros. Pero, por una vez, sólo por una vez, me gustaría que todo este texto llegara a alguien más, a Enrique Dans, y que pudiera completar la lección que incluye el gran vídeo de Larry con esta humilde aportación. Quizás así, la nueva generación de “manachment” que se hiciera cargo de las empresas de tecnología de este país pudieran tener una perspectiva más amplia, más allá de la moqueta y más cercana a las tripas del negocio, donde trabajan los técnicos.

Así que, si quieres ayudarme a intentarlo, copia, pega, pinta y colorea, menea, retwitea, envía, comenta y menciona este modesto artículo. Si conseguimos que llegue hasta Enrique, prometo pagarle una ronda de cervezas a mis fieles espartanos. Y yo siempre cumplo mis promesas.

]]> http://sixservix.com/blog/david/2010/06/22/problemas-gestion-informacion/feed/ 27 http://sixservix.com/blog/david/2010/06/17/oracle_y_bloggers/ http://sixservix.com/blog/david/2010/06/17/oracle_y_bloggers/#comments Thu, 17 Jun 2010 05:51:27 +0000 David Bonilla http://sixservix.com/blog/david/?p=3350

Ayer tuve la oportunidad de asistir a un encuentro de bloggers relacionados con las necesidades tecnológicas de las pymes, organizado por Oracle.

Cuando recibí la invitación, después de haberles dado tanto y tan duro, pensé que todo era una trampa para secuestrarme y condenarme a galeras remando en el barco de Larry Ellison. La verdad, ver entre los organizadores a Jaime Cid, compañero del metal con el que he compartido algún que otro podcast y cara amable de Oracle ante la comunidad española de desarrolladores, me tranquilizó un poco.

Para mí, el formato elegido fue un acierto porque favoreció una conversación natural y fluida. No intentaban vender producto o servicio alguno. El objetivo era conocer las inquietudes de la pequeña y mediana empresa en una comida-debate donde los 11 invitados pudimos charlar en un ambiente relajado y distendido.

Algunos me echasteis en cara el no tuitear nada durante la comida. Siento no haberos informado de los planes secretos de Oracle para conquistar el mundo en tiempo real, pero los compañeros de mesa y el debate generado fue muy interesante y, como casi siempre, yo me metí en todos los charcos que fueron saliendo.

Además de Jaime, hicieron de anfitrionas Mildred Laya, Directora de Comunicación de Oracle para España y Portugal, y Carmen Pizarro, Directora de Marketing para PYMES; que nos dejaron total libertad para proponer los temas y preguntas que nos interesaran.

Como resultado, hablamos de todo un poco y también, como no, de Oracle. Os enumero algunas de las ideas principales que se plantearon sobre la mesa con un pedazo de disclaimer como un piano de cola de grande: en ningún caso son las opiniones oficiales de la compañía californiana, sino de la mesa de debate.

• Oracle orienta su portfolio a clientes con características muy definidas: a partir de 50 empleados y unos 10 millones de euros de facturación.
• Oracle no ha definido aún una estrategia clara para proporcionar SaaS. La política de Larry Ellison es entrar en un mercado “cuando hay que entrar” no antes.
• Oracle mantiene su apuesta por un modelo de negocio basado en la venta de licencias y servicios de valor añadido asociados a dichas licencias.
• Apuestan por la red de partners para llegar donde ellos no llegan, fundamentalmente completar la red de venta hasta el cliente final en todos los territorios y los servicios de integración y desarrollo.
• La integración efectiva con SUN, en España, se hará el 1 de julio.

Pero lo más interesante de esta comida fue conocer de primera mano que Oracle conoce y asume que uno de los mayores activos que ha adquirido con la compra de SUN es la inmensa comunidad de desarrolladores que hay detrás de tecnologías como Java.

Oracle ha tenido una relación fría y distante con la comunidad de desarrollo hasta el momento. Hasta ahora, no debía ocuparse de la Comunidad porque NO TRABAJABA con la Comunidad, pero al completar la fusión del 1 de julio, sus clientes habrán cambiado, su portfolio habrá cambiado y, desde luego, su negocio habrá cambiado. Deben variar su estrategia de comunicación e incluso de venta para adaptarse a estos cambios

Parece que han comenzado a darse cuenta de la importancia de los técnicos en los procesos de decisión de compra. La propia Carmen comentó que iba a encargarse de gestionar estas relaciones con la Comunidad.

Esta comida parece un gesto de apertura y un buen primer paso. Esperemos que sea el primero de muchos y que permita acercar los productos y tecnologías de Oracle a los verdaderos presciptores de los mismos: los desarrolladores.

Artículos relacionados:

1. James Gosling deja Oracle James Gosling, 'padre' del lenguaje de programación java ha dejado...
2. Bonitruco: averigua desde donde se configura Oracle Uno de los problemas más habituales a la hora de...

]]>

Si, siempre quedaba la última opción: copiar el texto y grabarlo como preformateado, pero eso, básicamente, sólo implicaba cambiar la fuente y el tamaño del texto.

Afortunadamente para mi y los lectores de este blog, el amigo Alberto Peña acudió al rescate y me aconsejo que utilizara los Gist de gitHub para solucionar el problema.

¿Que qué eso de un Gist? Pues una forma muy sencilla de compartir fragmentos de código con otros. La forma de utilizarlos es muy sencilla:

1. Lo creas, copiando y pegando el código que quieras compartir
2. Lo guardas
3. Utilizas el código que te proporcionan para utilizarlo en cualquier sitio

Sencillo ¿verdad? Por supuesto, también puedes modificarlo en un futuro o incluso configurar las opciones de visibilidad del mismo.

Para poder utilizarlo en tu blog de Wordpress, sólo hay que seguir los siguientes pasos:

1. Instalad este hack del plugin de Paul William
   • Cread un subdirectorio que se llame /gistson
   • Grabad el Gist del enlace del hack como gistson.php dentro del subdirectorio anterior
   • Copiad el subdirectorio dentro del directorio /wp-content/plugins de vuestra instalación de Wordpress
   • Modificad el fichero header.php de vuestro tema de Wordpress para que incluya este enlace a la CSS de los Gist dentro de la etiqueta <head>: <link rel=”stylesheet” href=”http://gist.github.com/stylesheets/gist/embed.css”/>
2. Cuando queráis insertar un Gist con vuestro código en algún artículo utilizareis la siguiente notación: donde el id será el ID del Gist que hayáis creado y nometa indicará si queréis o no que incluya metadatos.

Como resultado obtendréis algo parecido a esto:

<link rel="stylesheet" href="http://gist.github.com/stylesheets/gist/embed.css"/>

Facile e divertente…

Artículos relacionados:

1. Cómo incrustar Flash en Wordpress Por seguridad, Wordpress impide incrustar flash y objetos con la...

El bueno de “Ponytail” viene a decir que comprende el poder de las patentes de software con un carácter defensivo más que como una fuente de obtener ingresos. O, lo que es lo mismo, que recomienda que las compañías patenten sus “nuevas tecnologías” como pollos sin cabeza porque, en algún momento, cualquiera -incluidos posibles demandantes- utilizará alguna de tus patentes y eso puede protegerte de sus futuras demandas.

Para ilustrar sus ideas, Jonathan “saca pecho” y cuenta algunas batallitas de abuelete, como cuando Steve Jobs quiso intimidarle para que SUN no comercializara un producto que “supuestamente” infringía patentes de Apple y él contraatacó con las evidentes similitudes entre Concurrence -un software de presentaciones creado por la anterior empresa de Schwartz, Lighthouse Design- y Keynote.

Una anécdota similar es la que sufrió cuando Bill Gates y Steve Ballmer le hicieron una visita para intentar cobrar por cada copia descargada de OpenOffice y Jonathan les recordó la ristra de patentes de java que había infringido una tecnología como .NET.

Por fin, alguien habla alto y claro sobre la absurdez a la que se ha llegado en las patentes de software… aunque hayan tenido que  despedirle de SUN para que lo haga. No obstante, el blog de Schwartz se titula -literalmente- “Lo que no podía decir” y el famoso artículo de marras “Los buenos artistas copian. Los grandes artistas roban“, frase que el mismo ha tomado prestada del gran Pablo Picasso.

Yo creo en las patentes de software, pero sobre productos terminados y completos o incluso sobre complejos algoritmos que aporten valor, pero, ahora mismo, hay compañías como Amazon con patentes sobre supuestos procesos de negocio -como el one-click buyin- que están basados en algo tan neutral y disponible como el uso de cookies. O, lo que es peor, intentando patentar características. Como cuando Microsoft intentó patentar el hecho de que un procesador de texto muestre y permita editar al mismo tiempo el contenido de la página, el pie y la cabecera.

La pregunta que Jonathan no nos contesta en su artículo es: ¿Y cómo quedan las pequeñas compañías y desarrolladores independientes en todo esto? Porque, evidentemente, no todo el mundo tiene la capacidad y posibilidad de iniciar innumerables y costosos procesos de patentado internacional por cada algoritmo o solución que se le ocurra ¿Cómo reaccionaríamos cualquiera de nosotros si Steve Jobs o Bill Gates nos llamase para amenazarnos con un litigio de proporciones bíblicas? ¿Hubiera sido tan “machito” Schwartz sin la fuerza de SUN detrás de él?

Afortunadamente, cuando se trabaja con java no se utilizan estos ficheros de configuración externos. Se pueden guardar y utilizar las adenas de conexión y usarlas directamente con el driver JDBC de tipo 4 de Oracle, pero  siguen siendo necesarios para usar cualquier cliente o programa que utilice el driver nativo de la base de datos como el PL/SQL Developer o el Toad.

La teoría dice que la variable de entorno TNS_ADMIN es la que configura la ruta donde se encuentra el fichero de configuración tnsnames.ora, pero la cosa se empieza a complicar cuando también se involucra a la variable de entorno PATH.

Cualquier instalación de un producto de Oracle -desde Weblogic a Discoverer- suele manipular la variable de entorno PATH, lo que puede provocar, desde el sorpresivo cambio de la versión de JDK de java que se esta utilizando… hasta el cambio de tnsnames.ora que configura el acceso a base de datos Oracle del sistema.

Para acabar de rematar la faena, Oracle utiliza una búsqueda jerárquica de ficheros de configuración y, además, esta jerarquía es distinta según el sistema operativo utilizado. Hasta puede llegar a utilizar configuración guardada en otra fichero de configuración: sqlnet.ora, lo que puede volver loco al programador mas duro.

Hay un truco para solucionar este problema y averiguar el fichero que configura las conexiones a Oracle: el comando tnsping.

El comando tnsping sirve, originalmente, para hacer un ping que compruebe la conexión a una base de datos remota mediante la siguiente sintaxis:

tnsping alias_de_base_de_datos

Pero, además, tnsping indica la ruta física del fichero de configuración y la propia instalación de Oracle hace que este disponible en el path del sistema, así, se puede utilizar para averiguar donde esta el fichero de configuración de las cadenas de conexión de nuestro sistema, haciendo ping a una base de datos existente o ficticia:

Artículos relacionados:

1. Compartiendo mesa y mantel con Oracle Ayer acudí a un encuentro de bloggers organizado por Oracle...

Si quieres saber cómo solucionar este problema, ahorrándote la búsqueda en la documentación oficial (déjalo, no viene como solucionar este problema) y sin volverte loco revisando la configuración de permisos de la aplicación, te cuento como hacerlo.

El truco está en que JIRA sólo te permite compartir los objetos con los grupos de usuarios de los que eres miembro. Es decir, que aunque seas el ASDLM (Administrador Supremo De La Muerte) de tu instalación de JIRA, si no perteneces al grupo de usuarios “Comerciales que merecen morir”, no podrás compartir ningún objeto con ellos.

Bonitruco:

1. Como eres Administrador de la muerte, te incluyes en dicho grupo de usuarios (o le pides a tu Administrador que te incluya temporalmente)
2. Compartes el filtro, el dashboard o lo que sea
3. Una vez que lo hayas compartido, te excluyes del grupo

]]> http://sixservix.com/blog/david/2010/02/17/compartiendo-jira/feed/ 0 http://sixservix.com/blog/david/2009/11/30/yo-programe-el-notepad/ http://sixservix.com/blog/david/2009/11/30/yo-programe-el-notepad/#comments Mon, 30 Nov 2009 06:15:52 +0000 David Bonilla http://sixservix.com/blog/david/?p=1027 “… y yo programé el Bloc de Notas” Ésta es una de las frases que más he utilizado cuando algún  ser humano de sexo femenino me preguntaba, cubata en mano: “¿Informático?… ¿Y tú que haces exactamente?” cuando, después de 5 minutos intentando impresionarla con nuestra ensalada de siglas habitual -ERP, IDE, SQL…-, veías que te empezaba a mirar con ojos bovinos. “¡Oh! ¿El Bloc de Notas?… ¿En serio?“. “No, mujer. En broma”. Atribuirte la autoría del Bloc de Notas siempre te ha garantizado, al menos, una sonrisa.

Pero esta pequeña broma no es más que una introducción para presentar uno de los grandes misterios de la informática. A pesar de que el Bloc de Notas (o Notepad, para los de Wisconsin) es una de las piezas de software más utilizadas de toda la historia, ¿Alguien tiene la más remota idea de quién o quiénes lo programaron? Bueno, pues yo lo he averiguado… o casi.

Al final de la década de los 90, una asociación de profesionales de Internet organizó una encuesta para determinar el Mejor Servidor Web o el Mejor Navegador Web. Increíblemente, el ganador en la categoría de Mejor Herramienta de Desarrollo Web fue… el Bloc de Notas.

Cuando la organización se puso en contacto con Microsoft para averiguar el autor del Bloc de Notas y poder invitarlo a la ceremonia de entrega de premios, nadie en el equipo de desarrollo de Windows pudo recordar quien o quienes habían programado el Bloc de Notas. Una década después, la autoría del Bloc de Notas seguía perdida en las arenas del tiempo… hasta que Raymond Chen levantó la liebre en su blog.

Raymond explica que consiguió la información gracias a una “fuente independiente” que le confirmó la autoría del programa. Según el Señor Chen, el autor del Bloc de Notas trabajó como Jefe de Desarrollo en el equipo de Windows 95. Después del lanzamiento de Windows 95, abandonó el desarrollo de software para convertirse en profesor de Ciencias en un instituto.

A pesar de la insistencia, Raymond se ha negado a revelar el nombre del autor. Según él, “para preservar su intimidad”.

No he conseguido averiguar el nombre del Jefe de Desarrollo de Windows 95, pero lo que sí he encontrado es un huevo de pascua documentado de Windows 95, con el que podemos ver el nombre de todos los miembros del equipo de desarrollo.

Aquí me he quedado, no he querido ir más allá. Quizás porque tenga miedo a despertar a los espíritus de la programación si llego a encontrar al autor; quizás porque nunca se sabe cuándo vendrá bien atribuirse de nuevo la autoría del Bloc de Notas :); pero, sobre todo, porque hay cosas que es mejor que permanezcan ocultas. Nuestra profesión, probablemente la mejor profesión del mundo, perdería un halo de romanticismo y de misterio si todo, absolutamente todo, se supiera. Incluido quien demonios programó el Bloc de Notas.

Para aquellos que se atrevan a ir más lejos, allí donde yo no he llegado, aquí les dejo un vídeo con el famoso huevo de pascua donde aparecen todos los miembros del equipo de desarrollo de Windows 95. Supongo que sólo es cuestión de empezar a googlear nombres hasta dar con el autor. Os deseo suerte.

Pinche aquí para ver el vídeo

El articulo está basado en un estudio de CA sobre el “Índice de estrés en el uso de aplicaciones web”. Porque sí, usar aplicaciones web -ojo respecto a la sutil diferencia con páginas web- produce estrés en los usuarios y nosotros, los malvados informáticos, yéndonos a dormir por las noches sin cargo de conciencia. Si ya el enfoque del estudio me puso en alerta, leer una reseña sobre la opinión de Kobi Korsah, director de Marketing de Productos de CA para la región EMEA, hizo que se dispararan todas las alarmas. Y es que, normalmente, poner a alguien de marketing a lidiar con técnica pura y dura es igual que poner a un mandril en celo a cuidar de tus hijos pequeños: puede salir bien, pero de casualidad.

El bueno de Kobi y su estudio nos comentan que el 73% de los trabajadores ahora dependen más de las aplicaciones web que hace dos años y casi todos los encuestados (un 97%) no podrían hacer su trabajo diario sin ellas. Bien, esto es bueno, sobre todo para los que programan aplicaciones web como es mi caso, pero ¿de verdad hacía falta encargar un estudio para saber esto? No soy un gurú, pero hace años que yo y cualquiera que esté en la industria del desarrollo de software sabe que todo tiende al mundo web. ¿Porque es más bonito? No. ¿Porque es más fácil de desarrollar? No. ¿Porque es más rápido? No, ¡pardiez no! Porque te permite acceder a tu aplicación desde cualquier sitio del mundo, hasta desde el teléfono de tu abuela y porque eso de instalar una aplicación en 300 ordenadores de una empresa y, sobre todo, mantenerla, suena un poco a Los Picapiedra ¿no?

Ahora podríamos entrar en el debate de ¿qué es rápido y qué es lento? ¿Es lento un proceso que te calcule los seguros sociales de 40 empleados y te genere un fichero para enviar a la Seguridad Social, un PDF de resumen y te muestre una traza por pantalla con todos los detalles del cálculo en menos de 5 segundos?  Algunos dirán que sí, otros dirán que no. Entre los usuarios de Kobi, por ejemplo, el 46% espera que la web le responda en menos de 10 segundos y, cito textualmente “a los 20 segundos, el 72% ha agotado la paciencia y ha pasado a otra web, y al minuto, el 90% de las personas se ha ido a otro sitio web“. Hombre… a lo mejor yo soy muy impaciente pero, en un minuto no me he ido a otro sitio web ¡me he ido a por un café corporativo y he vuelto!

Bueno, parece que entonces nuestro limite está en los 10 segundos y que todo lo que esté por debajo de ese tiempo de respuesta es rápido ¿no? Pues ni de coña. Una vez más, el estudio le ha fallado a Kobi y sus muchachos. Si yo le presento algo a mi jefe con un tiempo de respuesta medio, petición a petición, de 10 segundos; podría ver como en menos de esos 10 segundos le empieza a cambiar la cara hasta convertirse en algo parecido a esto:

Mi jefe, después de esperar 10 segundos para que una aplicación web acabe el proceso de login

Llegamos pues a la conclusión de que rápido o lento son conceptos relativos y completamente subjetivos, difíciles, muy difíciles de medir. Lo que sí sabemos, sin tener que encargar ningún estudio es que una aplicación web siempre será, por definición, más lenta que una aplicación cliente-servidor donde sólo viajan los datos de información, no los de presentación, y muuucho más lenta que una aplicación telnet, que se ejecuta en remoto, en el propio servidor donde está alojada la aplicación. Si a eso le añades lo que los veteranos denominan “esas tonterías” (sic) de los desarrolladores de aplicaciones de hoy en día, como esa terrible obstinación por separar todo en n capas o poner la base de datos en una máquina distinta del servidor de aplicaciones y las CAGADAS PURAS Y DURAS, como la tendencia a la sobrearquitectura, los macguffins y a poner 3 millones de imágenes, iconos y flash porque “el cliente dice que queda mas bonito”… pues sí, las aplicaciones web son mas lentas. Lentas de narices. Pero es que es lo que hay, el jamón es jamón y el chóped, chóped. Lo que no puedes  pretender es comer jamón a precio de chopped. Porque -si amigos- al final como casi siempre, todo es cuestión de pasta.

ENSEÑAME LA PASTA I

Es normal que los usuarios quieran una aplicación rápida. Yo también la quiero pero, para conseguirla necesito dinero, más dinero. Dinero para pagar a mis desarrolladores durante el tiempo que tarden en depurar y optimizar la aplicación o dinero para poder contratar a más progamadores que consigan desarrollar al mismo ritmo que lo hacemos ahora pero, además, consiguiendo optimizar el funcionamiento. Ojo, no quiero que esto se vea como una total y absoluta orgía de autocomplaciencia, pero, es cuestión de hacer autocrítica. Igual que reconozco haber encontrado auténticos TRUÑACOS en mi código y en el de mi equipo, como cosas que se hacen 2 o 3 veces sin saber porqué, también tengo que reconocer como me duele ver todos los días la caja sin abrir del Perfomasure que compramos hace dos años sin que nadie haya tenido tiempo de poder utilizarlo.

ENSEÑAME LA PASTA II

Gracias al informe de CA me entero de que mis pobres usuarios sufren de stress-web, provocado por mi inoperancia a la hora de desarrollar y, sobre todo, mi impotencia para cumplir sus expectativas. Y es que, parece ser que “cuando los clientes del sitio web se encuentran ante un problema o error, el 53% esperan que esté resuelto en 10 minutos; el 80% en una hora y el 99% esperan que esté resuelto en 24 horas. ¡Toma ya! ¡10 minutos!

A ver… no soy un genio de la gestión pero, para poder atender las incidencias en 10 minutos, o tengo a un desarrollador atado a una silla 24h, parado y quieto en plan bombero, listo para apagar un fuego cuando este se produzca o, no me salen las cuentas porque, si el mismo equipo de programación te arregla los errores sin haber completado el ciclo de desarrollo, ese ciclo se va a retrasar.

Cuando alguna vez alguien me pregunta si puedo garantizar la resolución de incidencias siempre les digo que SI pero, la sonrisa de satisfacción que ponen, se borra en cuanto les digo que le costaría unos 40.000 euros al año. Todo el mundo quiere el servicio pero nadie quiere pagarlo.

¿CONCLUSIONES?

Las aplicaciones web no son ni rápidas ni lentas. Las aplicaciones web son lo que son y es responsabilidad de todos que sean lo mas eficientes posibles; en primer lugar de los desarrolladores, que deberíamos demostrar un amor por el trabajo y un orgullo profesional que nos empujara a crear el mejor código posible mas allá de las dificultades; en segundo lugar, los gestores, que debemos obtener los recursos necesarios -técnicos, tiempo, dinero- para poder garantizar la calidad deseada; y, en tercer lugar, los usuarios, que deberían mostrar el interés apropiado por lo que son sus verdaderas herramientas de trabajo, en vez de limitarse a aprender lo justito para ir tirando y descolgar el teléfono de soporte y preguntar que hacer en cuanto les salé una botonera de Aceptar/Cancelar. No sé en que grupo estas tú pero, seguro que todos podemos conseguir que nuestras aplicaciones web sean, sino mas rápidas, si mejores.

Puedes encontrar artículos en la web que describen REST en castellano de pe a pa, e incluso completísimos tutoriales sobre como montar tu primera aplicación REST con java, pero quizás todo sea demasiado teórico y complejo para alguien que, como tú, busca una primera aproximación y no tiene porqué tener necesariamente mucha idea de Web Services, SOA o HTTP. Voy a intentar explicártelo muy claro y con ejemplos, como a ti te gusta.

Tranquila mamá, no te sientas mal por no tener muy claro esos conceptos. Hay muchos arquitectos de software y desarrolladores que tampoco los tienen. A lo mejor a ellos también les interesaría escuchar todo esto que te cuento. Es fácil, creo que en menos de 5 minutos tú y ellos os habréis hecho con ello.

Lo primero que tienes que tener claro es que REST no es una tecnología sino una arquitectura. Para que lo entiendas, no es algo que solucione cosas sino una forma de diseñar algo que solucione cosas. ¿Y qué tiene de especial esta arquitectura para que todo el mundo hable de ella? Intentaré explicártelo.

1. Diseñas tu aplicación exponiendo recursos no funcionalidades. Sí, ya no programo páginas web que tengan direcciones como www.mipagina.com/crearCosa o www.mipagina.com/consultarCosa. Ahora sólo tengo www.mipagina.com/cosas o www.mipagina.com/cosas/12345/atributos. Sí te das cuenta, es como si tuviera mis recursos ordenados en directorios. Y sí, sé lo que te estás preguntando: si sólo hay un www.mipagina.com/cosas ¿cómo sé si mis usuarios intentan crear una cosa o simplemente consultarla? Ahora te explico, ten un poco de paciencia.
2. Utiliza los métodos del protocolo HTTP de manera explicita. HTTP es un protocolo de comunicación que hace que Internet funcione. ¿No te has dado cuenta de que cuando escribes una dirección en el navegador pone http:// por delante de la dirección? Bueno, pues eso es porque te estás comunicando mediante ese protocolo. Lo que no tanta gente sabe, incluidos muchos programadores, es que el protocolo HTTP tiene un montón de métodos definidos en su especificación: GET, POST, PUT, DELETE… y que cada uno de ellos tiene un propósito específico aunque, a veces, te reconozco que los desarrolladores nos lo saltamos a la torera.  No te suena de nada ¿verdad? Eso es porque la mayoría de los navegadores utilizan el método GET por defecto en las peticiones HTTP, excepto que le indiquemos especificamente otra cosa en nuestras páginas web. Así , cuando escribimos el nombre de una página en la barra de direcciones de un navegador, la invocamos con el método GET. ¿Que por qué te he soltado este ladrillo que no te interesa? Espera un poco, ya verás como todo empieza a encajar.
3. Mapea los métodos del protocolo HTTP a las operaciones a realizar sobre un recurso. Fíjate que bueno, si te conectas a un recurso -una página web, para que lo entiendas- invocando el método GET, por ejemplo, yo sé que es lo que quieres porque el método GET se utiliza para consultar un recurso. Del mismo modo, al resto de los métodos principales de HTTP se les mapea una operación específica. Así, POST se utiliza para crear un recurso, PUT para actualizarlo y DELETE para borrarlo, evidentemente. Si, por ejemplo, solicitas la página  www.mipagina.com/cosas con el parámetro id=2345 y el método GET, mi aplicación REST te devolverá la cosa con id=2345. Sin embargo, si repites la misma solicitud con el mismo parámetro pero con el método DELETE lo que  conseguirás es borrar la cosa con id=2345.  ¡Tacháaan! ¿A que ahora parece todo más claro?
4. Transfiere XML, JSON o XTHML. No te voy a calentar la cabeza mamá explicándote qué es cada cosa. Confía en mi. Basta con que sepas que son cosas que se pueden consumir e interpretar desde un navegador y convertir en una de esas bonitas páginas web que tanto te gustan. Sólo para que lo sepas, cuando te digo que te devuelve una cosa, me refiero a que te devuelve algo como esto:

<cosa>

    <id>2345</id>

    <nombre>cosa misteriosa</nombre>

</cosa>

Sé que tendrás algunas dudas. Creo que podré adivinar alguna de ellas :)

• ¿Cómo le indico eso del id? ¿Sólo puedo mandar un parámetro? Y lo de los métodos HTTP ¿Cómo se cambian? Bueno, a ver, el id es un parámetro que envías en tu petición. Y, claro, puedes mandar todos los que quieras. Si lo piensas bien, cuando rellenas un formulario en una página web no estás haciendo más que mandar un montón de parámetros -uno por cada campo del formulario- sin límite alguno. Usando REST no haces mas que navegar así que, SÍ, puedes enviar lo que quieras. Respecto a lo de cambiar el método HTTP a utilizar bueno… eso no es tan sencillo. No vas a poder hacerlo directamente desde tu navegador pero, los programadores de páginas HTML sí tienen la posibilidad de hacerlo. Si llegas a una página web diseñada para utilizar con una aplicación REST y, por ejemplo, ves un botón “Eliminar Cosa“, seguro que vas a hacer una petición con el método DELETE
• ¿Y si no le paso ningún parámetro? No pasa nada. Si, por ejemplo, haces una petición GET a www.mipagina.com/cosas sin pasar ningún parámetro, probablemente conseguirás que una aplicación REST te devuelva un montón de enlaces a todas las cosas que esten relacionadas con dicho recurso. Por ejemplo, una lista de cosas (www.mipagina.com/cosas/0001, www.mipagina.com/cosas/0002…). Si lo piensas bien todo lo que te devuelve son a su vez enlaces REST que puedes reutilizar haciendo nueva petición con el método que te interese contra dichos enlaces. ¡Genial! ¿Verdad?
• ¿Y todos los recursos implementan todos los métodos? Pues, realmente NO. De hecho, hay otro método de HTTP, OPTIONS, cuya finalidad es obtener una lista de los métodos soportados por un recurso. A lo mejor, el programador de una aplicación REST quiere permitirte consultar una determinado información pero no quiere que la actualices.
• Y entonces ¿cualquiera puede borrar cosas de tu aplicación? No. Puedes identificar a tus usuarios con los métodos de autenticación que te proporciona cualquier servidor HTTP o incluso utilizar cosas más sofisticadas.  No te preocupes, puedes conseguir que sólo acceda a tu aplicación REST quien tú quieras.

Como ya te he dicho REST sólo es una arquitectura, no una tecnología. Tienes que evaluar bien si te interesa o no utilizarla. Si te interesa conocer cuáles son algunas de sus ventajas, te explicaré alguna de las más importantes:

• El método HTTP GET y el cacheo. Muchos proxies y firewalls -ordenadores que gestionan una red- suelen cachear las peticiones GET. Que, ¿qué es eso de cachear? Pues guardarse una copia de la página que solicitas con tu método GET y, si otro ordenador de tu misma red solicita la misma página, devolver esa copia mucho más rápido que si tuviera que obtener la página de nuevo.
• No utiliza estado de sesión. A ver como te explico esto… ¿recuerdas cuando me pediste que te enseñara a comprar por Internet y estuvimos comprando libros? Esos libros se iban acumulando en un carrito de la compra y, al final, pagamos con tarjeta de crédito. Bueno, ese carrito de la compra existía porque la página web nos identificó durante toda nuestra sesión de trabajo y, es genial. Lo que pasa es que, al final, somos muchos los que compramos libros y eso puede acabar sobrecargando los servidores donde se alojan las páginas web. Cuando 5 están comprando libros no hay problema pero, cuando son 5000… la cosa cambia. El hecho de que REST no mantenga estado de sesión quiere decir que en nuestras peticiones de recursos y en las respuestas del servidor tiene que viajar toda la información necesaria. Nada se guarda en la memoria del servidor.
• Puedes distribuir una API completa de tu aplicación en un fichero de javascript. Mmmm… para que lo entiendas de una forma sencilla ¿conoces Facebook, no?. Bueno, pues lo bueno de  Facebook, lo que ha hecho que triunfe tanto es que ha posibilitado que terceros creen aplicaciones y las incrusten en la página. Casi todas esas aplicaciones te permiten interactuar con tus contactos de Facebook, pero dichas aplicaciones no tienen acceso directo a la BBDD de la página web, sino a una API, un conjunto de utilidades, que proporciona Facebook y que permiten acceder, por ejemplo, a los amigos del usuario que está ejecutando la aplicación. Créeme, eso es una aplicación REST como una casa. ¿Te imaginas que Facebook tuviera que distribuir por ahí la ruta de acceso a su BBDD? ¿Te imaginas los problemas de seguridad y escalabilidad que supondría?

En fin mamá, que REST está muy bien, pero es una manera más de solucionar las cosas, ni más ni menos. Por ejemplo, no tengo muy claro que fuera la arquitectura más adecuada para ese ejemplo que te he puesto del carrito de la compra, aunque sí para muchos otros supuestos.

La gente está muy ilusionada con el tema, sobre todo como una apuesta para conseguir de una manera sencilla, rápida y flexible la interoperabilidad entre distintas aplicaciones escritas en distintos lenguajes. Antes todo el mundo pensaba que los webservices eran el único medio válido para conseguir esto de una manera eficiente pero, ahora, hay bastante gente que lo pone en duda porque, la verdad, la especificación donde te explica cómo implementarte por entero un webservice, cómo publicarlo y cómo consumirlo es… un poco dura y pffff… ¡no creo que consiguiera explicártela en 5 minutos como he hecho con esto del REST! Y eso es lo bueno de esta arquitectura. Mamá, si tú has conseguido entenderlo, creo que cualquier desarrollador lo hará.

]]> http://sixservix.com/blog/david/2009/09/30/explicando-rest-a-mam/feed/ 4 http://sixservix.com/blog/david/2009/09/29/el-macguffin-informatico/ http://sixservix.com/blog/david/2009/09/29/el-macguffin-informatico/#comments Tue, 29 Sep 2009 05:30:07 +0000 David Bonilla http://sixservix.com/blog/david/?p=260 El macguffin, expresión acuñada por el maestro Hitchcock, es un recurso narrativo, un disparador, una excusa que permite, que consigue que la trama avance pero que no tiene importancia por sí misma. Un ejemplo actual de macguffin es el maletín que persiguen Travolta y Samuel L. Jackson en Pulp Fiction. Motiva a los personajes, permite que la historia se desarrolle pero, realmente, no tiene importancia dentro de la misma.

Bien ¿Y qué tiene que ver todo esto con el desarrollo de software? Aunque nosotros no lo sepamos, también tenemos nuestros propios macguffins y, desgraciadamente, a veces cobran excesiva importancia convirtiéndose en los verdaderos protagonistas de la trama.

Aunque a veces lo olvidemos, en nuestra profesión, la tecnología no es más que un puro y duro macguffin que no nos puede distraer del verdadero objetivo, del protagonista: el cliente/usuario que demanda aplicaciones para usarlas.

He comprobado que la mayoría de los desarrolladores quedamos cegados por tal o cual tecnología y que tendemos a utilizarlas sin ton ni son, sin preguntarnos si realmente aportan algo al cliente. El que esté libre de culpa que tire la primera piedra. ¿Alguien recuerda la “moda de los EJBs” que sacudió el desarrollo en java entre el 2001 y el 2004? Parecía que, si hacías una aplicación “seria”, si querías estar a la última tenías que utilizarlos si o si. Los EJBs molaban y empezamos a utilizarlos por todos lados. Y sí, eran distribuidos y transaccionales y ¡Oh, Dios Mío! eran compatibles con CORBA. Así que nada, a incrustarlos en nuestra arquitectura, pero ¿REALMENTE necesitábamos EJBs? La respuesta es no, al menos en mi caso.

Me he pasado la mayoría de mi carrera metido en proyectos grandes, lo que llamamos aplicaciones empresariales. Desde un Gestor de Contenidos a un ERP, pasando por la pasarela de pago electrónico del BBVA, y en mi vida he visto una aplicación usando EJBs distribuidos en varias máquinas. Ojo, no quiero decir que no sea útil -o incluso necesario- en algunas ocasiones, pero yo no lo he visto.

Los EJBs están muy bien pero, hoy por hoy y hasta que veamos la distribución lite de la versión 3.1, te hacen pagar caro su uso: te olvidas de utilizar a tu viejo amigo Tomcat y buscas nuevas amistades con gente como Glassfish, Geronimo o JBoss, sólo para descubrir que tardan en arrancan 4 veces más y que, cuando modificas una clase mientras depuras con tu IDE… ¡Ay, como te empiece a redesplegar todo el contexto de tus EJBs!

En definitiva, añadir los EJBs hace más pesada y compleja nuestra arquitectura. Si los utilizamos sin que sea estrictamente necesario, ¿no estamos haciendo que nuestro macguffin sea el protagonista de la película? La tecnología debe ser un medio para conseguir un fin, no el fin en sí mismo.

Sí, lo reconozco, es difícil llegar a un sitio donde utilizan Struts 1 para hacer algo nuevo y no querer meter con calzador Struts 2, Spring MVC o cualquier otra cosa pero, si realmente podemos solucionar de manera eficiente y económica el problema con Struts 1, ¿por qué vamos a complicar la arquitectura de nuestro cliente? ¿Realmente vamos a ayudarlo?

El uso de los macguffins informáticos alcanza su máximo nivel en el caso de los tecnólogos irredentos que ni saben ni quieren saber nada del dominio funcional del cliente. “Yo soy informático, no tengo porqué saber nada de nominas/logística/contabilidad/ventas” es una frase que he oído más de una vez. Puede que hasta yo mismo la haya pronunciado :) pero, ¿qué queréis?, todo el mundo tiene sus pecados de juventud… Y es verdad, no hace falta saber de nada que no sea informática para ser informático pero sí para ser un buen informático. Si no tienes ni idea de lo que necesita el cliente, ni de lo que ha utilizado antes que tu llegaras, ni averiguas porqué lo ha utilizado ni reflexionas sobre como podrías mejorarlo, tienes muchas posibilidades de conseguir que la importancia de tus macguffins empiece a crecer. Ejemplo, nadie que haya visto a un administrativo capturar datos a la velocidad de la luz -creedme, a veces no se les ven ni los dedos de lo rápido que van- se le ocurre crearles una interfaz en un navegador web.

Otro tipo de macguffin típico es el cambio de versiones de librerías o aplicaciones a la última, ultimísima versión recién salida del compilador. Aún recuerdo los cascotazos que empezó a dar una aplicación cuando me empeñé en cambiar la versión de base de datos de una Oracle 9.2 a una 10g. Como excusa, decir que la “g” venía de grid y claro, eso de la “granja de servidores de BBDD” sobre el papel, molaba mucho :D También la he liado parda alguna vez con eso de “¡Huy!… ¡nueva versión de refuncliocluncio que mejora esos bugs que yo nunca he sufrido y que incluye nuevas features que aún no sé si alguna vez utilizaré! ME LO BAJO YA”. Menudo pedazo de macguffin…

Todos tenemos más de un macguffin que se ha adueñado de nuestro trabajo, pero eso no es importante. Reconocerlo es el comienzo para aprender que no hay que ser cada vez mejor informático sino mejor profesional.

Doodle Jump es sencillo, elegante, ingenioso, accesible, adictivo y… sobre todo muuuy divertido. Pero, lo que hace que Doodle Jump sea especial es que consigue retrotraernos a una época pasada, a los maravillosos ochenta -el pleistoceno informático- una era donde reinaban los ordenadores de 8bits y España… ¡era un país puntero en el desarrollo de videojuegos!. En aquel entonces los juegos eran sencillos y terriblemente adictivos. Ninguno tenía complejos tutoriales para aprender a jugar, la diversión y la jugabilidad eran inmediatas y un buen juego SIEMPRE tenía que cumplir la máxima de “fácil de jugar, difícil de dominar“. Pero… ¿de que va exactamente Doodle Jump?

El juego tiene una total, absoluta y MARAVILLOSA falta de argumento :). Eres una especie de bicho trompetero con 4

Disparando con tu trompa

piernas que tiene que saltar y saltar hacia arriba como si no hubiera mañana. Para saltar utilizas unas plataformas de varios tipos, desde las normales -de color verde- a las marrones -que se rompen-, las blancas -que solo duran una vez-  o las azules, que se mueven por la pantalla. Con cada uno de tus saltos, la pantalla avanza con un scroll vertical sin vuelta atrás: si te caes, ya puedes dar por finalizada la partida, sin vidas, sin nuevas oportunidades. Te caíste, se acabo y punto.

Por supuesto, hay mas elementos en el juego como los enemigos, una serie de bichos tan feos o mas que el protagonista y con cuyo contacto, te mareas y caes hacia una muerte segura. Cabe destacar el diseño y variedad de estos enemigos sacados, como el resto del arte del juego, de la cabeza de un niño grande, naiv y genial.

A los enemigos hay que evitarlos con tu pericia en el salto pero, además, tienes un arma definitiva: tu trompa. Tu trompa, como no, dispara bolas de colores de una potencia destructiva sin igual. Con una sola bola puedes matar a los enemigos mas débiles y, con unas pocas mas, puedes acabar hasta con platillos volantes.

También tienes items, powerups de toda la vida, como un cohete portátil a lo Rockeeter o… ¿una gorra con una hélice pegada? que te hacen subir mas y mas deprisa.

Las ¿instrucciones? del juego

En resumen, cuanto mas arriba llegues, mas puntos ganas. Cuantos mas puntos ganas, mas arriba estas en la tabla de mejores jugadores. Ni mas ni menos.

Los controles son maravillosos, limpios, de impecable factura y, una vez mas, sencillos y fáciles. El monigote siempre esta saltando, tu solo tienes que dirigir el salto inclinando el iPhone/iPod Touch hacia un lado u otro y, si tocas la pantalla con el dedo, disparas por la trompa. Nada mas.

Ha sido desarrollado por Lima Sky “inspirándose” ;) en Papi Jump, un juego anterior y, actualmente, gratuito. Pero, Doodle Jump llega mucho mas allá. Lima Sky ha pulido y engrandecido el juego original con detalles de diseño que lo llevan hasta la genialidad. La inexistencia de “paredes” que te permiten saltar por un lado y aparecer por el otro -al mas puro estilo Pac-Man – o la posibilidad de pausar el juego una y solo una vez por partida para que nadie pueda aprovechar la pausa para tomarse un respiro en la frenética subida del monigote, hacen que el juego sea una deliciosa sorpresa.

Por si fuera poco, le han añadido detalles dignos de web 2.0, como la opción de subir tu puntuación a Facebook y compartirla con tus amigos o bajarte la puntuación de los mismos, que se convierten en rallitas de tope que vas superando según vas subiendo. Ver como acabas de superar al vecino del quinto con tu ultimo salto da una satisfacción indescriptible.

¿Y como, donde y por cuanto se puede conseguir esta joya? en el appStore de Apple por… 0,79 € probablemente, la mejor relación calidad/precio que ha tenido un juego en toda la historia.

Lo mejor de todo es que el juego es inspirador. Es el primer juego que no me da pereza clonar así que, no os sorprendáis si dentro de un tiempo tenéis disponible un Boni Jump en java… :D eso si, mientras esperáis, haceros con este juego como sea y, si no tenéis un iPhone o un iPod Touch haceros con uno. Solo por Doodle Jump merece la pena.

Doodle Jump en YouTube

Stickam

No es el primer servicio de streaming ni el mas conocido, incluso tenemos posibilidades locales mas que interesantes, como lo que ofrecen los chicos de StreamES, pero StreamAPI me ha gustado especialmente por varios motivos:

• Es barato, muy barato, y tienes la posibilidad de calcular el coste de servicio de forma sencilla antes incluso de evaluar el producto.
• Funciona como marca blanca y, de cara a los usuarios, ellos no existen
• Es tecnológicamente neutro, funciona con cualquier tipo de lenguaje de programación en servidor
• Su web es sencilla y esta perfectamente estructurada
• Tienen toneladas de documentación sobre su producto
• Proporciona un montón de estadísticas e informes sobre el streaming (de esas que les encantan a los jefes)
• Soporta alta definición
• Esta basado en una plataforma probada, robusta y segura.

Aunque a veces los informáticos no consigamos ver la conexión entre la tecnología y su aplicación en el mundo real, el hecho de trabajar en un grupo empresarial que crea y gestiona multitud de eventos públicos facilita bastante poder comprender las posibilidades del streaming.

Imaginemos que organizamos un evento publicitario, una fiesta -por ejemplo- y. como es normal, queremos obtener el mayor rendimiento de la misma, el mayor retorno de inversión. Hasta ahora, solo los asistentes a la misma recibían el impacto publicitario y el departamento de marketing hacia todo lo posible porque este impacto se multiplicara facilitando la aparición del evento en los medios pero, ¿y si tuviéramos vídeos del evento a disposición del publico y dichos medios de comunicación?. Imaginar que celebramos una fiesta y que los asistentes al evento pudieran decirle a sus amigos “búscame en el vídeo X”.

Algún gurú pensará “para eso ya tengo a youTube” y si, es cierto, puesto que youTube no es ni mas ni menos que un tipo de streaming pero ¿y si quisiéramos retransmitir nuestro evento en vivo? ¿y si quisiéramos retransmitirlo con mayor calidad que la pésima calidad estándar de youTube? ¿Y si quieres tener control sobre el streaming de tu video? ¿durante que horas quieres que sea visible y porque? ¿y si no quieres que nadie incruste publicidad externa, incuso de un competidor? ¿y si quieres empotrarlo en tu web mas allá que como la ventana típica de youtube?

Bueno, parece que youTube podría llegar a quedarse corto para todas las posibilidades de explotación de nuestro evento.

Por otro lado, hay mucho mas casos de posibilidades de uso para el streaming corporativo, desde la posibilidad de grabar e impartir formación online y bajo demanda a poder difundir en directo y a todos los empleados un comunicado como, por ejemplo, la felicitación de navidad del Presidente de nuestra compañía.

Con StreamAPI podemos aprovechar todas estas posibilidades de una forma barata y no intrusiva para nuestra web. Una herramienta mas para construir la web que todos queremos y nuestros clientes o usuarios necesitan. Bienvenidos.

Es tal la consonancia de opiniones que existe respecto al tema que, cualquier debate sobre el mismo suele ser bastante estéril y carente de sentido. Sin embargo, en una entrevista que tuve la oportunidad de hacer a Jaime Cid de Oracle, Jaime se atrevió a pedir a la gente que no quedara deslumbrada por la etiqueta del “gratis total” e intentara ir mas allá.Jaime decía que había diferenciar entre proyectos OpenSource reales y proyectos que utilizan la etiqueta como una herramienta de marketing.

Una de las cosas en las que hacia mas hincapié era en la atención que ponía en un detalle que la mayoría de desarrolladores ignora: la cantidad y origen de los commiters o contribuidores del proyecto.

Por ejemplo, el proyecto Eclipse, que comenzó siendo un software propietario de IBM y que evolucionó hasta un proyecto de código abierto. Actualmente, el proyecto es soportado por múltiples compañías de todo el mundo como Nokia, Oracle, CA, SAP, Sonatype o la propia IBM pero, lo mas importante es que, en la lista de contribuidores por empresa, se puede comprobar que solo el 25% de los mismos procede de la misma IBM. ¿Esto que quiere decir? que el proyecto, aunque soportado ampliamente por la dicha compañía, no depende de la misma para su subsistencia.

¿Que pasaría si alguna vez IBM decidiera dejar de apoyar a Eclipse? pues, probablemente NADA. El proyecto seguiría adelante y alguien tomaría el rol de líder de la comunidad.

Ahora veamos el otro lado de la balanza… ¿quien no conoce Spring? Uno de los fameworks de desarrollo mas importantes que existen para el lenguaje JAVA. Es gratis, es OpenSource pero… ¿cuanto de OpenSource? Si, puedes acceder al repositorio, puedes bajarte las fuentes, puedes tocarlas y compilarlas en local pero ¿puedes contribuir al proyecto?. La respuesta es NO. Spring es propiedad de SpringSource y, como tal, son ellos los que controlan totalmente el roadmap del producto, que es lo que es parte de la distribución oficial y lo que no. ¿Que pasaría si SpringSource decidiera dejar de soportarlo? pues, probablemente que la gente haría un fork o, lo que es lo mismo, un copiar el código y tirar p’alante pero, ¿en que quedaría todo esto? ¿cuantos forks surgirían? ¿cuantos sobrevivirían? ¿quien seria el que diera soporte?. Muchas, muchas dudas ¿verdad?

Casualmente, SpringSource acaba de ser comprada por VMWare… ¿Y ahora que va a pasar? nadie lo sabe.

Peor aun es cuando las compañías utilizan la etiqueta OpenSource como herramienta de marketing. Como ejemplo, uno de nuestros competidores :) Openbravo que, a pesar de ser “opensource” presenta peculiaridades como versiones de pago con licencias de uso por usuario,  características restringidas a dichas versiones de pago como el trabajo con servidores en cluster, lo cual no es ninguna tontería cuando hablamos de un sistema de gestión empresarial de alta disponibilidad, o una carencia enfermiza de documentación disponible de forma gratuita en su web.

Por otro lado, para obtener soporte profesional de sus productos te referencian a su ecosistema de partners pero, una vez mas, no hay ni un solo documento sobre que es lo que exigen para convertirse en partner suyo ni los deberes que ello implica. Una vez más, ¿hay lista publica de contribuidores? ¿se puede contribuir al código de OpenBravo sin contar con la empresa propietaria? Una vez mas, no.

Como conclusión, todo modelo de negocio es valido, toda solución puede ser satisfactoria mientras cumpla nuestras necesidades a un precio rentable, bien sea mediante el pago de licencias, servicios o a personal que lo implemente. Eso si, no debemos dejarnos deslumbrar por el brillo del OpenSource, aunque sea muy brillante.