Uso de AJAX para minimizar el tráfico

Igual se lo deberían plantear en alguna gran ciudad, a ver si reducen los atascos... perdón, ya me callo, es un chiste malo.
Se ha publicado en TheServerSide una referencia a un artículo titulado: Using AJAX to Improve the Bandwidth Performance of Web Applications. En dicho artículo se comenta un ejemplo de una aplicación web en la que reducen alredor de un 60% del ancho de banda necesario para su funcionamiento.

Hay dos casos de aplicación de AJAX, como mecanismo de mejora de aplicaciones ya existentes, o como método de implementación de nuevas funcionalidades.
La remodelación de una aplicación existente, para evitar recargar páginas completas, y obteniendo la información necesaria únicamente para redibujar una parte de la página puede significar un importante ahorro en ancho de banda y mejorar la eficiencia general. Pero se debe tener en cuenta el tipo de comunicación a establecer, enviando HTML, o XML, o Javascript... para no crear un pequeño monstruo que cargue en exceso la máquina cliente.
Al crear nuevas funcionalidades con AJAX, el objetivo suele ser dotar de mayor interactividad a las páginas, lo que conlleva el crecimiento del número de peticiones HTTP a los servidores. el típico ejemplo de validación de formularios cada vez que el usuario pulsa una tecla en una caja de texto, multiplica las peticiones y por tanto la carga en el servidor.
La aplicación utilizada en el artículo entra en el primer caso, pero es un ejemplo tan básico que realmente no explica demasiadas cuestiones sobre la complejidad de los factores a tener en cuenta para la eficiencia de una aplicación real.

La "realidad" y la blogsfera

Seguro que os habeis enterado del problema de Enrique Dans con Air Europa. Aparte del problema en sí, nada nuevo, me temo, en una linea aerea, me ha llamado la atención el alto número de enlaces y comentarios que ha generado.
Otros problemas más graves, bajo mi punto de vista, comentados por Enrique (perdón por el tuteo) no han tenido el mismo eco. ¿por qué este en concreto sí? ¿puede llegar a tener repercusión importante si toda la blogesfera lo comenta?
Me imagino que muchas personas se han sentido muy identificadas con su problema, y comentan casos parecidos. Otros problemas más graves, no afectan directamente a los lectores de Enrique, y no generan tanta repercusión. Además me imagino que la solidaridad de haberse enfrentado a problemas similares anima a escribir. El caso es que este post sobre Air Europa ha generado más de 80 comentarios.
Otra cuestión es la repercusión que pueda tener una protesta por Internet, y específicamente alrededor de los Blogs. No me cabe duda que el poder de los bloggers más leidos irá aumentando conforme aumente su audiencia, pero hoy por hoy se necesita de medios "tradicionales" para lograr un impacto medianamente fuerte en la sociedad.

Extensión para Firefox: Tamper Data

Siempre desarrollo las aplicaciones WEB con FireFox, antes en Netscape. Es mucho más cómodo y sencillo. Con esto no creo que descubra nada nuevo a nadie. Lo malo es después hacerlo funcionar correctamente en el explorer :) pero eso es otra cuestión.
Ahora he descubierto otra extensión que me ha parecido utilísima. Tamper Data. Puedes ver todas las peticiones HTTP que va haciendo el navegador, e incluso modificarlas antes de que las envíe, tanto GET como POST. Así podrás ver también tus peticiones realizadas con XMLHttpRequest si ya te has pasado a la WEB 2.0 ;).

El soporte del software libre

Y vuelvo con la temática original de este blog, el modelo de negocio del software libre. Dos posts me han parecido interesantes ultimamente.

• Red Hat: The mother of all open source business models
• El soporte técnico no es un modelo de negocio viable
  

¿Pero no era el principal modelo de negocio el soporte de estos productos? Los servicios relacionados con el software libre son varios: consultoría, desarrollo de personalizaciones,... y el soporte parece que puede ser uno de los más atrayentes para los clientes, para esas empresas que se quieren ahorrar dinero en licencias, o usar unos productos cada vez más competentes y superiores a sus homólogos privaticos.
Pero lo que parece es que el soporte técnico profesional no es tan necesario en las empresas. Cada vez más, las comunidades de los productos funcionan, y se puede encontrar solución a los problemas en el conocimiento exparcido por Internet, pero que es localizable facilmente.
Si una empresa cuenta con profesionales cualificados, y confía en ellos, es más que posible contar con las herramientas adecuadas con su mantenimiento de manera segura, sin soporte profesional.

la experiencia de los 3 años que llevamos fabricando y vendiendo Software Libre en KnowGate: el grueso del dinero lo genera la venta de bits, no los contratos de soporte técnico.

No poseo la experiencia de Sergio, así que no se lo voy a discutir, de hecho, yo diría que las razones en muchas empresas de compra de soporte es puramente política, que después esos soportes ayudan poco, y que las verdaderas ayudas de los fabricantes se pagan a precio de consultoría.

Es posible que compren derechos a parches de seguridad y actualizaciones ultra-rápidos por miedo a virus, pero, de nuevo están comprando bits, no soporte.

Red Hat makes it hard to impossible to get the compiled, binary version of its tested/supported/enterprise-ready software without paying it. (A recognition that while source is free, few actually want source, and even fewer pay for it.)

El modelo de negocio de Red Hat es alabado por Matt Asay por haber conseguido ver las razones por las que sus posibles clientes están dispuestos a pagar por su producto, y a la vez, mantener y apoyar a una comunidad a la que mima por que sabe que es parte importante de su producto.

Vuelta a casa

Después de un mes algo liadillo, entre niños y obras (me mudaré de piso a principio del mes que viene) me vuelvo hacia Najaraba con intención de ser algo más constante, aunque sería mejor no decirlo por si no lo cumplo...
Ahora veo que desde el 2 de Diciembre (!) no escribía nada, perdón por el silencio ;). La verdad que no he dejado de leer mis blogs favoritos, y supongo que si hubiese leido menos, hubiese podido dedicar más tiempo a escribir, pero es que si dejas acumular los mensajes, luego apareces con el estrés tecnológico...

AJAX vs. Accesibilidad

Actualmente las dos tendencias que más encontramos en las aplicaciones WEB son tendencias que en principio parecen contrapuestas.

• Las administraciones públicas deben tener páginas accesibles por la mayoría de los ciudadanos, aunque tengan algún grado de minusvalía. Y para ello deben cumplir los niveles AAA del W3C.
• Y está la cosa esta del web 2.0. Más AJAX,  más interacción, más JavaScritp. Páginas mucho más interactivas y  dinámicas.

Veamos un guía del W3C, otra vez.

6.3. Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

¿Son las dos opciones compatibles? Y si no lo son, ¿importa? Lo importante es observar el público objetivo de tu aplicación o servicio, y las obligaciones cívicas de la administración.

Jornada de software libre en Mallorca (2)

Pues ya asistí el martes pasado a las jornadas organizadas por el IBIT. Ellos mismos han hecho un interesante resumen. Aunque tengo que hacer una puntualización: lo que yo comenté sobre la consultora Doblin, se trata de su clasificación de los tipos de innovación, no de un estudio que hubiesen realizado ellos sobre el software libre, que da la impresión tras la lectura del resumen.
En general fue muy interesante para mi esta jornada. Agradezco a los organizadores su interés en mi trabajo, y la confianza para participar en estas jornadas. Espero haber estado a la altura del resto de ponentes.
En general las ponencias versaron sobre los modelos de negocio, excepto la de Maika Díaz, de Fundecyt, que nos explicó el trabajo realizado en Extremadura con la aplicación del software libre en el gobierno y administración local.
En general el público eran empresarios, aunque Ricardo Galli también estaba por allí. Y debio aburrirse bastante, por que no hacía más que charlar con su compi de al lado y mirar su portatil. Pero espero que al resto del personal le resultase interesante, y les haya dado nuevas ideas sobre el mercado del software y alrededores.
Tras la jornada, nos invitaron a comer :) y tuvimos algunas charlas muy interesantes entre los ponentes, miembros del proyecto europeo eSafer, y miembros de empresas mallorquinas que asistieron a la "mesa redonda". ¿que qué me acuerdo por ejemplo?

• Que hablamos mucho del software libre pero que hacemos poco, salvo honrosas excepciones.
• Que tengo que darle una vuelta más a la idea del colegio de informáticos, a la que siempre he sido contrario, tras hablar con Eduardo Elias, del colegio de Cataluña. Ya hablaremos.
• Que el software libre debe ser evitado que se vea como una solución para "pobres", que no lo es.

Bueno, iré comentando cosas conforme me acuerde, pero es que pasaban los días, y tenía que contar algo sobre mi primera ponencia sobre el software libre...

Jornadas sobre software libre en Mallorca

En cuanto mi proyecto más importante me deje algo de tiempo, contaré mi impresión sobre unas jornadas sobre software libre a las que asisto en Palma de Mallorca, organizadas por la fundación IBIT de la isla. Creo que van a ser muy interesantes, y espero poder colaborar a que lo sean!

Un proyecto importante de verdad

No suelo escribir de cosas personales, pero esta vez no lo puedo evitar. Este es Iñigo:

Innovación y software libre

Ya he hablado alguna vez más sobre la innovación que puede producir el software libre. Pero únicamente se veía la innovacióndesde el punto de vista de producto. Y ahora he llegado a unos documentos muy interesantes sobre innovación y nuevos modelos de negocio.
Primero, este “Sobre el arte de identificar modelos de negocio” de Mario Lopez de Ávila. Plantea que hay cuatro recursos o procesos sobre los que se asientan todas las empresas:

• financieros
  
• de infraestructura
  
• de relaciones
  
• de contenidos
  
• de tecnología
  

Y sobre uno de estos recursos de manera predominante es sobre el que las empresas fundamentan sus operaciones de innovación y la naturaleza de ese recurso condiciona el desarrollo del proceso innovador. Mario deduce entonces que "las empresas 'sufren' parecidos condicionantes, se enfrentan a dilemas similares en su gestión y, lo que es más imporante, desarrollan estrategias casi idénticas de respuesta a esas limitaciones" según el recurso dominante.
Y el señor Martinez comenta que había escrito un post sobre los procesos de innovación. Lo que nos lleva a los 10 tipos de innovación de Doblin.

Y me ha gustado esta tabla, por que los técnicos, muchas veces centramos el proceso de innovación en el producto. Un software es innovador si utiliza la última tecnología, web 2.0, AJAX, SOAP,... la que sea, y además está creado sobre una idea nueva de producto. Pero se puede innovar de muchas maneras. Lo que voy a hacer ahora, retomando un poco el tema del software libre, es intentar ver que hay de innovación en cada area entre el software libre y el privativo. aunque una cosa hay que tener en cuanta, además de todo, una cosa para ser innovación, debe ser nueva. Y el software libre no es nuevo, existe desde el inicio de la informática. Pero basándonos en este análisis podremos hacer otra disección del software libre como modelo de negocio.

Librería (JavaScript) para el manejo de capas

Despues de ver cosas de la web 1.99 como netvibes o EyeOs, tenía ganas de mirar algo para el manejo de las capas, imágenes y demás elementos que permitiese hacer cosas tan aparentemente potentes como esas aplicaciones.
Y ya la he encontrado. No sé si es conocida o no, como en temas de diseño no suelo andar demasiado enterado, la he conocido hoy. Se trata de un librería creada por Walter Zorn:

• JavaScript: DHTML API,Drag & Drop for Images and Layers

A mi me ha parecido que tiene un API muy sencillo, y que proporciona una funcionalidad más que suficiente para proyectos WEB con interfaz compleja. Además, es distribuida bajo licencia LGPL (GNU Lesser General Public License). ¿qué más podemos pedir?

Actualizado: Pues que casualidad, en Navegapolis acaban de recomendar esta otra librería JavaScript para realizar efectos con capas.

Interacciones Humanas en Programación

Algo así se podría traducir el grupo de Microsoft "HIP: Human Interactions in Programming" que ha publicado un interesante trabajo titulado :"Software Development at Microsoft Observed: It’s about people … working together". Me entero de este trabajo por el informadísimo blog Navegápolis.
Si de algo podemos estar seguros es que en Microsoft, te guste el trabajo que hacen o no, hay mucha gente trabajando. Mucha gente programando, diseñando, analizando, y por tanto muchos equipos, "interacciones humanas", y... problemas, seguro. Este trabajo nos explica la información obtenida en una encuesta a los trabajadores de la empresa.
No creo que Microsoft sea una mala empresa para trabajar, y una investigación sobre los métodos de trabajo de la gente en semejante empresa, debe ser tenida en cuenta. Aunque lo primero que me llama la atención es que de mil personas a las que mandaron la encuesta (aleatoriamente entre desarrolladores y jefes de equipo) unicamente la respondieron 187. Pocos me parece.
Comentaré dos cuestiones que me han llamado la atención, pero os recomiendo que leais el artículo entero, y que sigais la pista al grupo este de HIP:

• Prácticas de programación ágil: Se comenta que las metodologías ágiles se van implantando en "islas" dentro de la organización, y se pregunta en las encuestas por el grado de aceptación de las técnicas utilizadas. Ninguna supera el 50% de aceptación.
• Modelos mentales del código: Una de las preguntas abiertas para el futuro dice así (traducida como buenamente sé): "Sabemos que los desarrolladores tienen completos modelos mentales del código, y que esos modelos son raramente externalizados. ¿Qué sucede cuando dos desarrolladores hablan sobre código? ¿Como alinean sus modelos mentales?". ¿no os ha pasado nunca que no sois capaces de visualizar la manera de codificar que os están explicando en ese momento?

Creo que estos dos puntos me darán para algún post más. Interesantes.

Creación de software libre en España (y 3)

Ricardo Galli vuelve a postear información sobre la situación del software en España. Y nos da un enlace a Cinco Días donde se comenta la situación de la creación de software en España. Habla este artículo de unas 400 empresas que utilizan software libre. Y yo me imagino que lo utilizan, pero ya hemos visto que crearlo, parece que hay pocas.
Parece que la situación de creación de SW en España se centra casi exclusivamente en las consultorías y desarrollos a medida, fundamentalmente realizado por PYMES. Los programas "empaquetados" brillan por su ausencia salvo en nichos como la gestión farmaceutica, medicina o contabilidad. Y en Francia o Alemania debe ser similar la situación.
En definitiva, este no es un país productor de software. En fin, tampoco el software libre ha empujado este campo. Solo ha venido a ahorrar costes a algunas compañías y dar ventajas competitivas a otras. ¿y por qué determinados paises crean más software, innovador o no? El caso de India, parece bastante claro, que es por el costo del desarrollo en aquel país, y la gran especialización de sus trabajadores en este campo. En el caso de EEUU, el gran innovador todavía en el mundo de la informática, no me lo nieguen, creo que la innovación se da por la cantidad de gente que está dispuesta a arriesgarse para hacerse rico. ¿por qué lo creo? Por este magnífico artículo de Paul Graham sobre las diferencias económicas y el riesgo (Inequality and risk).

Actualización: Seguimos igual en España, mirad lo comentado en la coferencia WebDosBeta, Mesa redonda - ¿Hay innovación fuera de EEUU?

De idea a software (8)

Así que seguiríamos trabajando en la aplicación-servicio a construir. Con más o menos tiempo libre que le podríamos dedicar a implementar la solución ideada, no hay que perder el punto de vista del negocio. Hay que dedicar tiempo a estudiar a los expertos, y por supuesto que no me refiero a mi. Esta semana han aparecido dos entradas en sendos blogs que me han parecido muy interesantes:

• Fernando Polo nos cuenta su experiencia sobre "De DiceLaRed a LastInfoo: de la idea al producto (I)". Esto es real. Aquí intento averigüar que iría haciendo yo, pero esto es un ejemplo genial. Dos cosas comenta muy interesantes: sobre la innovación y las lecciones aprendidas.
  Respecto a la innovación, que la innovación por sí sola no produce rentabilidad. Solo la necesidad de los clientes de tu producto te generará un modelo de negocio rentable. Ahora bien, ¿estás llevando tu idea hacia un producto-servicio por negocio o por placer? :O
  Y de las lecciones aprendidas, una me decepciona enormemente: "En España, los inversores oficiales no existen para la WebDosBeta. Sólo “friends” & “family” te ayudarán a salir adelante. Y si la cosa tira, rehúye la inversión oficial española, y búscala fuera de España." Que triste.
  
  
• Y un aspecto del que nunca me acuerdo pero es muy importante. La imagen de marca, en concreto el logotipo del producto. Sobre esto, mi invalidez para ver si dos colores se "llevan bien" o crear un diseño elegante, me hacen rehuir siempre de este tipo de cosas. Así que os recomiendo este interesantísimo post de cómo han creado el logo de Panoramio (una aplicación de imágenes sobre los mapas de Google)

Repasa por tanto, mientras construyes tu idea, la red. Siempre ofrece información interesante.

¿Todavía no usas AJAX?

Dos enlaces muy interesantes me llegan en cuestión de minutos de diferencia sobre la nueva tecnología de moda.

• Vía Software As She’s Developed podemos conocer este repositorio de proyectos de framewors sobre AJAX. Son unos cuantos, para la mayoría de tecnologías WEB, así que elige el tuyo.
  


• Y vía Version Cero he llegado a este FAQ sobre AJAX. Se edita dentro de los blueprints que edita Sun sobre JavaEE.
  

Así que planteate ya si debes actualizar tus páginas HTML, que esto va muy rápido. La verdad que ya se ven aplicaciones impresionantes con esta tecnología.

"Recolector de Basura" de Java

Qué mal suena el "Garbage Collector" en castellano.
Un artículo muy interesante publicado en IBM sobre los mitos y realidades sobre la eficiencia del manejo de memoria en JAVA. La verdad que el GC siempre ha sido un tema muy interesante para comprender cómo sacar el máximo rendimiento a la JVM. Debes comprender bien cómo funciona para lograrlo.

Which language boasts faster raw allocation performance, the Java language, or C/C++? The answer may surprise you -- allocation in modern JVMs is far faster than the best performing malloc implementations.

La verdad es que es un tema muy interesante, y la evolución que ha llevado desde las primeras másquinas virtuales de JAVA ha sido espectacular. El cambio que anuncian para el JAVA 6.0 lo será también. El compilador será capaz de detectar dónde los objetos creados deben ser instalados (o ni siquiera instalados) según el uso que se vaya a hacer de ello. Todo eso liberará de más trabajo al "Garbage Collector".

Revolución con WEB 2.0

Me preguntaba netyweb sobre lo que pensaba yo que debía entrar en esa revolución de los navegadores a la que me refería en el post anterior. Pues realmente no lo tengo muy claro, ¿o alguién sabe realmente qué es WEB 2.0? :)
Pero estos son algunos de los cambios que se me ocurren para una web más dinámica, más 2.0:

• Protocolo HTTP: Se ha quedado un poco pesado para estos menesteres. Haría falta un protocolo statefull, con mantenimiento de estado, y además aliviar el tráfico de cabeceras en cada petición.


• Navegadores: Y relacionado con el protocolo, que se puedan recibir notificaciones de tipo PULL. Que se pueda comunicar el servidor con el cliente sin petición anterior, una vez establecida una conexión abierta por el cliente.


• Interfaces: Personalmente HTML me gusta, será ya deformación profesional, pero obviamente tiene cosas mejorables para dar mayor dinamismo a las interfaces, sin llegar al extremo de tener que hacerlo todo en Flash. (no me pregunteis cómo, no se me ocurre, no lo he pensado)


• Estándares: Hay que hacer las cosas una sola vez. No tres o cuatro para cada navegador. Esto ya va avanzado bastante, menos mal.


• Identificación: Si las redes sociales toman importancia, debe existir algún sistema de identificación "universal", ¡pero sin eliminar la participación anónima!


• ¿que más? Help!

Y mientras la WEB 2.0 será una revolución, si la hacemos y la consideramos así. Lo que no cabe duda es que las nuevas aplicaciones que surgen estos días en la web son un punto y aparte con lo que ha existido unos años atrás.

WEB 2.0

Bueno, pues toda esta movida relacionada con la web 2.0, se está poniendo muy de moda. AJAX, blogs, sindicación, redes sociales, web más interactiva... pero no nos acabamos de enterar muy bien qué es realmente.
Parece un movimiento que ha surgido de los blogs, o como yo lo he conocido ha sido así, y que con el AJAX ha encontrado la herramienta que aparentemente le era necesaria. De repente han crecido numerosas aplicaciones sobre esa heramienta. De ahí, y con lo que venía de atrás de las redes sociales, sindicación y esa palabra que no acabo de conocer: folksonomías, se ha creado la web 2.0.
La idea que yo veo detrás de la web 2.0 es revolucionar las aplicaciones web actuales. Nada de esperas, de envío de formularios y respuestas,... Pero ¿no hará falta alguna herramienta tecnológica nueva para esa revolución? Si los navegadores actuales deben ser el soporte de la web 2.0, llegaremos a mejorar la interactividad, la interfaz, y haremos más aplicaciones interconectadas, pero no se podrá "revolucionar" mientras no haya un cambio más fundamental en los navegadores. ¿no os parece?

De idea a software (7)

Cuando vas a empezar a realizar tu proyecto, ya debes tener claro entonces más o menos cual va a ser el modelo de negocio (cómo vas a ganar pasta, vamos), cuales son las ideas básicas que no debes renunciar a implementar, una arquitectura básica de la aplicación,... y muchas ganas.
Si yo tuviese una idea que quisiese convertir en negocio, quizás hasta me plantease escribir un blog sobre cómo lo voy desarrollando.
Si sois dos personas os planteareis cómo empezar a desarrollar el trabajo, y cada uno cómo sacar tiempo extra de cada día para poder escribir las primeras lineas de código. Cuando lo encuentras, debes tener claro el objetivo final en cada condición o asignación que escribas. Te ayudará a no enfrascarte demasiado en problemas menores, que se podrán dejar para solucionarse más adelante.
Hay que crear el esqueleto funcional y arquitectónico lo antes posible. Desde ese esqueleto es más facil dividirse el trabajo entre dos para ir completando las tareas imprescindibles, de forma que se pueda "duplicar" la velocidad de desarrollo.

Programando JDBC vs. Frameworks

Cuando en un proyecto JAVA te planteas como vas a realizar la persistencia de la información, debes elegir si vas a utilizar algún framework, como Hibernate, EJBs, Expresso,... o vas a acceder directamente programando con JDBC.
Algunos puntos interesantes a tener en cuenta pueden ser estos:

• Velocidad de desarrollo: Pues típicamente aquí ganan los frameworks, claro que lo más influye realmente es la experiencia en cada campo. Teóricamente, los frameworks nos permiten abstraernos de los problemas de la BBDD.


• Eficiencia: Los frameworks más utilizados en JAVA, como Hibernate presumen de utilizar numerosas técnicas para minimizar el impacto del mismo en la BBDD, y de optimizar incluso los accesos. En mi opinión, únicamente se pueden exprimir al máximo todas las posibilidades de JDBC accediendo a este directamente, donde te preocupas que cada SQL o proceso batch se haga de la manera ideal.


• Eficacia: ¿Nunca os habeis encontrado con alguna limitación que os ha obligado a bajar de nivel (a JDBC) o a realizar las cosas con su típico "work-around" (como dice Oracle) :) ?


• Curva de aprendizaje: Este punto depende del mundo del que vengas. Si sabes mucho SQL, entonces JDBC será más fácil. Si dominas JAVA al dedillo y no te cuesta nada hacerte con nuevos APIs, y crees que las BBDD son cosas de los de sistemas, probablemente te engancharas a un framework como a un enchufe.

Tú eliges.

Artículo sobre convertirse en freelance

Otra posibilidad, si no tienes la idea para convertirla en software ;), pero quieres intentarlo solo, es convertirse en freelance. Vía Business Opportunities he encontrado este interesante artículo sobre los pasos que se deben tener en cuenta para establecerte como autónomo, específicamente como desarrollador web.
¿Qué informático no lo ha pensado alguna vez, harto de los jefes o algún cliente?

Gran hermanos, triunfitos, y ahora teleemprendedores.

No, no es que te envíen un emprendedor a domicilio, es que hay un Gran Hermano en la televisión vasca, ETB2, para elegir la idea innovadora y llevarla a cabo. En esta web a veces hemos hablado sobre los emprendedores, obviamente centrándonos en el software, así que quería informaros de esta idea, que personalmente, me parece un poco ridícula.

SPRI y las 3 diputaciones promueven un concurso
televisivo para apoyar a los emprendedores[...] El Director
General de SPRI, Aitor Cobanera, el Diputado de Promoción Económica de
Alava, Carlos Samaniego, el Diputado para la Innovación y Sociedad del
Conocimiento de Gipuzkoa, Joaquin Villa y el Diputado de Promoción
Económica de Bizkaia, Ricardo Barainka han presentado hoy una
iniciativa común que tiene como objetivo promover la cultura
emprendedora en Euskadi. [...]
Se trata de un programa-concurso, denominado Generación XXI, que
potenciará el desarrollo de proyectos empresariales innovadores en
nuestra comunidad, y que forma parte de una serie de iniciativas
dirigidas a apoyar los emprendedores.

En fin, yo me pregunto si con la pasta que les va a costar el concurso en televisión no podían ayudar a los 27 participantes a la vez. Está bien promocionar la cultura emprendedora, pero creo que esto está un poco fuera de contexto. ¿no es mejor invertir en las universidades o escuelas de negocio? La verdad que me ha sorprendido bastante esta iniciativa; reflexionaré sobre ella.

Java Server Faces

Me he dado cuenta que no había comentado mi opinión sobre JSF en la bitácora, y lo he hecho varias veces en algún post de The Server Side.
Me recuerda JSF mucho al estilo de programación con un "viejo" servidor de aplicaciones llamado NetDynamics (¿alguien se acuerda?). Era como programar por eventos en la web. Es como esconder que realmente estás en un entorno en el que en medio existe un protocolo llamado HTTP, y que a veces para ser efectivo y programar eficientemente necesitas conocerlo a fondo.
Por eso no me gusta tampoco JSF. El hecho de que generes unos códigos que ya desde el principio se decía que es que habría IDEs para generarlos, te hace pensar que pueden ser mucho más engorrosos para exprimirlos al máximo.
Y me he acordado de esto, por que ahora hay un artículo interesante sobre la que todo el mundo habla casi como una nueva manera de programación para la WEB, con AJAX: Does JSF + AJAX really make sense?.

I wonder if it would not be better to either use AJAX very sparingly so it doesn't interfere with existing request processing patterns, or move the controller entirely to the client and forget server-side web frameworks as we know them today.

Estoy bastante de acuerdo con él, aunque no creo que haya que ser tan drástico, puesto que, para ello, los navegadores aún deben evolucionar bastante (para soportar un controlador complejo sería mejor algo más que el rudimentario JavaScript). Y también ya se ven numerosas páginas que hacen un uso impactante de AJAX, por ejemplo: netvibes.com.

De idea a software (6)

Si estuviese intentando implementar una idea, que habría reflejado en tres o cuatro hojas en un documento de texto (de OpenOffice, claro ;) ), antes de empezar ya sabríamos que quedan infinitud de detalles para definir. Así que en estos casos, me quedo con el desarrollo al más puro estilo de las metodologías ágiles. Se puede empezar por un prototipo básico, que no haga más que dos o tres funciones de las cientos que estás pensando que deben ser claves para tu servicio o programa. Después ya iremos iterando sobre él, por que la idea va a evolucionar, y nos comportaremos como los clientes de nuestras peores pesadillas. O puede ser el inicio un pequeño esqueleto que realice las funciones más problemáticas en una versión de prueba, para asegurarte que la solución es viable o que se puede realizar lo que tienes en la cabeza.
Obviamente, a mi entender, si lo estás haciendo entre dos personas, no te vas a poner a hacer "pair programming", a no ser que tengas que hacer un algoritmo que sea crítico o algo así. Divide el trabajo de ese par o tres de casos de uso a implementar, e intenta que se puedan acabar antes de un par de semanas. Iteraciones cortas y numerosas. Pero con la vista puesta en el horizonte, en el documento global de descripción de la aplicación. Eso es lo que buscas, tampoco dejes que las nuevas ideas te desvíen demasiado.

De idea a software (5)

Al observar el espacio exterior mientras te dedicas a discernir los pasos de la implementación de tu idea genial, observas cómo todo a veces parece oscuro. Sigue adelante. Asume los riesgos. ¿qué puedes perder?

Representación del modelo abstracto

Cuando diseñamos una aplicación, se nos crean en la mente un montón de objetos que vemos que deberán ser necesarios: usuarios, facturas, documentos,... por poner algunos típicos. Conforme empezamos a estudiar el dominio de la aplicación completamos más la foto mental, y empezamos a realizar esquemas escritos sobre las relaciones entre ellos, y averigüar además qué comportamiento debe tener cada uno. Esto me refiero a que lo hacemos, auqnue sea mentalmente, mientras hacemos la captura de requisitos. Yo por lo menos, no puedo evitarlo, ni quiero evitarlo.
Posteriormente, hay un momento en que nos decidimos a realizar en esquema entidad-relación, o un diagrama UML de las clases del sistema, o una presentación simple con las figuras que nos aparecen en la aplicación. Y antes o después, según los gustos de cada uno o la metodología utilizada, realizaremos el interfaz de usuario.
Vayamos al típico caso de aplicación compleja, para la web (por lo menos es típico para mi, claro ;) ), y que se desea realizar mediante una estructura de tres niveles. Aquí tienes muchas opciones, pero centrémonos en la capa del modelo. ¿o no hay capa de modelo?
He visto casos donde se define el modelo de base de datos, y se hacen clases que representan prácticamente de manera unívoca las tablas. Otros donde desde la interfaz se generan las acciones que se ejecutan en el controlador y ahí se hace lo que se puede para realizar la acción.
A mí me gusta tener claro primero el modelo abstracto, e implementar este. Luego puedes ir en dos direcciones. Hacia la base de datos y desde la interfaz al API expuesto por el modelo. Pero después está el tema de las sesiones WEB, ¿qué guardas en la sesión? Debes guardar la mínima información para asegurar que en la siguiente acción del usuario vas a tener el modelo exactamente igual a como lo dejó la acción anterior.
Luego "solo" hay que bajar de esta abstracta explicación a picar código...

De idea a software (4)

Ya hemos establecido el documento de objetivos del proyecto (DOP) o el documento que representa el "Big Up Design Front". Pero debemos estar dispuestos a cambiarlo en cualquier momento, sobre todo si es para mejorarlo, obviamente.
Por tanto hay que empezar. Esto es importante y por tanto lo repito: hay que empezar. Si estás convencido, o casi convencido, inténtalo. Mientras empiezas el diseño, averigüa como es la situación externa que puede afectar a tu proyecto. Infórmate si te conviene lanzarte a crear una sociedad limitada desde el primer momento, o esperar a ver como va el asunto mientras trabajas en una empresa de fijo.

De idea a software (3)

Si yo tuviese mi idea secreta de proyecto, como Juanjo su weblog :), creo que me leería antes de llevarla a cabo algunos de estos artículos o comentarios que me han llegado últimamente:

• Como empezar una start-up
• Argumentaciones sobre Usabilidad
• Hacer Estrategia
• Marketing Personal vs Marketing Empresarial
• Cultura Organizacional
• Si es con temas relacionados con el software libre: Najaraba.com! (es broma)
• Y la mayoría de los artículos de Joel Spolsky. Y hay muchos en castellano. Para mi es uno de mis escritores favoritos en estos temas. Echadle un vistazo a fondo si no lo habeis leido nunca.

Bueno, todo esto debe quedar en "background". Obviamnete no hay recetas mágicas ni libros de instrucciones. Pero me gustaría tener todas esas cuestiones (!y muchas más¡) a la hora de plantearme crear un software para ser una cosa de esas que llaman emprendedor.
Y otra cosa que se me olvidaba. Buscate alguien con quien hacerlo, alguien de confianza y que creas que tiene las mismas ideas que tú. Al principio compartireis gastos, observareis con cuatro ojos, y tendreis el doble (!) de ideas geniales.
Y seguiremos, ya arremangándonos para picar código. Si se me ocurre algo, claro, y si alguien lo prueba, que me lo cuente!

De idea a software (y 2)

Aquí es dónde realmente puedes sacar a la luz tus habilidades de diseño/programación. Puedes hacer las cosas como quieras, para eso eres el lider / analista / diseñador / arquitecto / programador. Puedes tomarlo de dos maneras, o lo haces rápido y por tanto con tecnologías que ya conoces. O te lo tomas como aprendizaje para el uso de esa tecnología que llevabas tiempo queriendo echarle un vistazo.
Estas cuestiones son importantes para la decisión de la tecnología en la que vas a implementear tu idea. Depende de dónde, y sobre todo cuando, quieras llegar con ese proyecto, podrás utilizar unas tecnologías u otras. Así que puede ser que te encuentres con el mismo tipo de restricciones que tenías hasta ahora en las empresas. Pues vaya.

De idea a software

Ahora que estamos tan pendientes de los emprendedores en Internet, o por lo menos esa sensación me da a mi por los blogs que leo, me pregunto que tienes que tener en mente para materializar una idea en un software que funcione, una aplicación que atraiga a los usuarios.
Primero, claro está, la idea. Sobre eso, poco puedo decir, !imaginación¡ Y a lo mejor algo de ayuda no viene mal.
Ya tienes la idea, ahora debes plasmarla más concretamente antes de ponerte a picar código. ¿qué eliges? ¿UML? ¿tarjetas CRC? ¿casos de uso? Pero bueno, esto suena a demasiado complicado para total hacer un pequeño proyecto tú solo, y que lo tienes en la cabeza. Pero nunca está de más escribirlo, al escribir te fuerzas a concretar y te salen las dudas razonables y las imprecisiones imposibles. Aquí me quedo con la solución menos "ingenieril". Escribe un documento en tu procesador de textos favorito explicando lo que quieres que haga la aplicación. Haz un documento base, luego ya lo refinarás. Es un primer paso, te va a ayudar a definir la idea, seguro que la "estilizas" mucho.
Posteriormente deberás decidir qué lenguaje y/o plataforma utilizas para la implementación, y estudiar aquellas librerías o servicios que creas que vas a utilizar. Ya seguiremos.

Los casos de uso no son "funciones"

Volvemos a situarnos a ras de tierra, para comentar un tema que me parece importante en los inicios del diseño con UML. Los casos de uso son una buena herramienta para que el cliente sea capaz de ver representado los requerimientos que nos pide. Pero al principio es fácil usarlos mál. Para mi, fue muy ilustrativo el artículo: Why usecases are not functions
El artículo destaca el concepto equivocado que se suele tener de los casos de uso: un cso de uso por cada acción del usuario. Pero no es así.

I like to regard a use case as a story about some way of using a system to do something useful.

Si una acción del usuario debe realizarse en varios pasos, debemos tener en cuenta cual es el objetivo del usuario, y convertir en un caso de uso aquella que sea útil y de un valor medible al usuario. Debemos tener en cuenta que no existe orden en los casos de uso, y que romper estos en miles de subcasos nos creará mayor complejidad para la fase del diseño en la que nos encontramos.
Debemos pensar en los actores del sistema y en qué es lo que realmente esperan obtener del sistema. Seguramente no esperan poder añadir algo al carrito de la compra, o borrarlo, o dar los datos de pago. Lo que realmente esperan es poder hacer un pedido de compra. Así, en global. Los refinamientos deberán venir después.
Los casos de uso no deben representar la explosión de las funcionalidades que nos va a permitir el sistema, si no que deben ayudarnos a centrarnos en qué es realmente lo que quiere el cliente.

Desarrolladores y arquitectos

No sabía que fuese tan fácil publicar en el IEEE. Creo que voy a intentar hacerlo un día de estos. "Does free software raise innovation?". :)
No, en serio, es que me ha llamado la atención un artículo editado por Martin Fowler (por otra parte, un señor a seguir con mucho interés), en el que habla de la relación entre las especificaciones empresariales de los productos software y la relación con los requerimientos de los clientes: Enterprise Architects join the Team..
Las organizaciones suelen poner unos requerimientos explícitos a sus aplicaciones desarrolladas para sus clientes, a veces de tipo técnico, como pueden ser usar un determinado framework, o de tipo funcional, para seguir un mismo esquema que dote de "personalidad" a sus productos. El artículo comenta que estos "arquitectos empresariales" deben formar parte del equipo de desarrollo de la empresa. De esta manera se reducen las fricciones, cada parte aprende de la otra y en un entorno de desarrollo "ágil" se podrá controlar mejor estos requerimientos. Es decir, se trata de convertir al cliente interno en cliente del proyecto, y tenerlo disponible de la misma manera que tienes disponible la figura típica del cliente en un proyecto que sigue una metodología "ágil".
Hace mucho que no leo la revista, pero ¿se merece esto un artículo del IEEE? Aunque bien pensado, no está de más remarcarlo, me parece que los requerimientos de marketing, departamento comercial o financiero, son los últimos en llegar al equipo de desarrollo, y los que después más prisa corren, o más influyen en todo el diseño de la aplicación a una semana del lanzamiento.

Dos notas aparte:

No os perdais en Navegapolis el
Tomo II del Compendio de la Ingeniería del Software

Argumentaciones sobre Usabilidad en Alzado

Retomar una aplicación de otros

Bueno, acabas de llegar a una nueva empresa, o llegas de consultor a "solucionar problemas". El caso es que te tienes que meter con una aplicación desarrollada durante más de un año. Cuando te saludan, te dan un sitico con su ordenador, te dicen como conectar al repositorio de CVS y que si tienes alguna pregunta, -no te cortes- pregunta a tus nuevos compañeros.

- Eim, ¿por dónde puedo empezar a leer la documentación?
- Sí, chaval, mmm, no sabes que la metodología XP habla de que el código es la mejor documentación. Es que está muy desactualizada, igual te lía mas...
- ouch, vale, ¿y de qué va la aplicación?
- Bueno, fácil, es una gestión de recursos para "maximizar el valor de nuestros accionistas mediante el contexto estructural asertivo"*.
- Claaaro.
- El caso es que va lento, mira a ver que puedes hacer...

Y ahí te quedas.
Generalmente se da esta situación de dos maneras: O bien para crear nuevas funcionalidades a un proyecto que ya está funcionando, o bien para terminar un desarrollo en que te incorporas en medio del proyecto (o a solucionar bugs o problemas de eficiencia). En cualquier caso, los primeros días suelen ser intensos, y a veces divertidos!

• Intenta conocer el dominio de la aplicación a nivel general. Ten una visión general de TODO el dominio, y más en particular de lo que te vaya a tocar trabajar. O sea, que te expliquen un poco el análisis funcional


• Al principio no te centres en los detalles del código. Intenta ver la estructura desde una buena altura. Que te cuenten las "guías de diseño" que siguieron (si lo hicieron).


• Intenta que al principio tu código no afecte al resto, sobre todo si este funciona. Más tarde te darás cuenta de qué no comprendías exactamente como funcionaba.


• Realiza una aproximación "top-down" sobre los problemas para verlos en su contexto, no vayas directamente al "pedacico" de código que parece dar el error.


• Lee solo la documentación sobre el código que te aseguren que está actualizada. De otra manera solo tendrás un lío mayor.

Y después, insistir, insistir e insistir!! ;)
Cuando llegué a la Editorial Aranzadi como consultor, lo primero, me contaron en una charla de más de dos horas a qué se dedicaba la compañía, cómo se organiza la información jurídica, como eran las bases de datos de legislación y jurisprudencia, etc... Una introducción perfecta para mi labor allí, aunque esa reunión fue un poco dura, no os vayais a creer ;)

*De ESTRATEgA: Hable como un Gurú. :D

Día del Blog

Pues resulta que hoy es el día del blog. Y me extraña que no me haya enterado mañana :), pero bueno, esta vez me entero a tiempo, aunque ya ando tarde para seguir las instrucciones y no tengo mucho tiempo. Así que en vez de nombrar cinco Blogs que me resultan interesantes, he hecho algo que debía haber hecho hace muuucho tiempo y he incluido en esta peque-bitácora mis subscripciones de BlogLines.
Así que por fin aparecen en "Mis Favoritos" las fuentes que suelo leer de vez en cuando. Os recomiendo que les echeis un vistazo tranquilamente, seguro que conoceis la mayoría, pero espero daros alguna agradable sorpresa con el descubrimiento de alguna nueva para vosotros.
Y sí, sé que debo ordenarlas por temática...

Uso de AJAX, crea tu Protopage

Pues era yo algo escéptico con el cambio que supone AJAX para la web, debido a que de todas maneras la latencia por las llamadas HTTP sigue presente. Pero la verdad que han surgido aplicaciones que son realmente interesantes. Mirad si no esta aplicación de páginas de inicio, llamada Protopage. Realmente no te das cuenta de que cualquier cambio que realizas se guarda en el servidor, es muy transparente.
Por lo demás, la aplicación está todavía un poco en pañales. Intenté que apareciesen mis suscripciones de bloglines en una "Sitcky Note", pero no funciona el JavaScript. Ya me pusé en contacto con ellos para comunicárselo, y la verdad que a las 2 horas tenía un email suyo contestándome. A ver si lo solucionan pronto.

Creación de software libre (+)

Dos discusiones en dos foros totalmente dispares me han tenido entretenido esta tarde. La primera que habla sobre algo parecido a lo que comentaba en mi post anterior es el post de Enrique Dans sobre que si el software libre da dinero. La otra es la bitácora de Ricardo Galli, sobre Software libre y empresas regionales. El caso es que en estos dos post, y en las discusiones asociadas, la cuestión de fondo es si la creación de software libre genera ingresos, dinero, innovación (o riqueza empresarial regional).
La cuestión por tanto parece que no es sencilla. Siempre comparando el tema con e software propietario, por supuesto. Lo que parece es que en España no hay creación de software como producto. Nos conformamos parece que con utilizar las herramientas y productos que otros están creando como software. La libertad en el software no ha creado innovaciones de ruptura en este país, o por lo menos, no en mayor medida que el software privativo.

Empresas CREADORAS de software libre en España

Pues me quedé un poco decepcionado con las respuestas a la pregunta en Barrapunto. Estaba yo interesado en conocer las empresas que creasen software libre en España. No empresas que lo utilizasen, colaborasen en proyectos iniciados por otros, o realizasen consultorías o formación sobre SL existente.
La lista se me ha quedado pequeña, después de intentar comprobar en las webs indicadas si cumplían las condiciones. En algunas no ponía nada de software libre, ni que desarrollasen algún producto, o no eran españolas. Las que han quedado son estas:

• http://www.igalia.com
• http://www.aspl.es/
• http://infosial.com
• http://www.knowgate.es
• http://www.xpertya.com
• http://www.carabos.com/

Como veis, poquitas. Seguro que exiten unas cuantas más, y yo pensaba que en Barrapunto me darían el nombre de muchas, pero no ha sido así.
Pero si no ha habido una explosión de empresas que creen software libre, ¿será por que este no disminuye las barreras de entrada tan exageradamente como pensaba? Bueno, obviamente el esfuerzo de crear software es el mismo en un modelo que otro, y en los inicios de los productos libres se está muy solo, pues no se atraen desarrolladores interesados (a no ser que seas Apache y anuncies un nuevo desarrollo).
De manera que las barreras de entrada se disminuyen para las consultorías o desarrollos de servicios, donde se obtiene el software a utilizar junto con su código fuente, pero quizás el software libre no sea tan generador de innovación como volvía a esperar.
Por cierto, no tengo nada que ver con ninguna de ellas.

Capital humano

Me ha gustado el post en Tachnovation sobre si el capital humano de una empresa es activo o pasivo. No sé si será una cosa u otra, más bien ninguna de las dos.
Para los flojos en contabilidad (yo mismo... nunca me ha entrado bien en la cabeza):
- Los activos son las posesiones de la empresa que se pueden convertir en dinero en efectivo. Se dividen en activos circulantes, los que ya se considera dinero de la empresa (dinero en caja o bancos, cuentas por cobrar o inventarios de productos y materia prima) y activos fijos (los bienes inmuebles y maquinaria)
- El pasivo son las deudas de la empresa tanto a largo como a corto plazo (que deben ser repuestas antes de un año).

Vamos, que el capital humano no encaja. No es un bien en posesión de la empresa, aunque a veces se disponga de él como si fuese propiedad particular. Tampoco se le debe un dinero, si no que se le paga por generar algo. Y desde luego, no se puede vender para generar un beneficio (excepto quizás los futbolistas...).
Pero quizás ese "divertido" post del que hablaba al principio de para pensar más de lo que parece.

Diseño y XP

Joel Spolsky está muy contento con su nuevo proyecto, y nos cuenta ahora cómo fueron las especificaciones del mismo. Aparte del proyecto en sí mismo, que se trata de una herramienta para controlar ordenadores desde otro puesto en Internet, me ha llamado la atención el siguiente párrafo:

Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim.

Bueno, es cierto que el Big Design Up Front no está demasiado bien visto por los puristas del "eXtreme programming", puesto que debe ser la evolución del software la que lleve las riendas del desarrollo, y no una idea inicial del proyecto, pero tampoco creo no exista un camino intermedio.
Hace tiempo que me leí un artículo de Martin Fowler titulado "¿está el diseño muerto?". Lo que viene a decir es que exite un camino intermedio, que él no cree que no haya que tener una idea de diseño, pero que la concepción de este se ve afectada por la importancia de la idea de evolución del proyecto en su desarrollo. En XP el diseño no se deja de realizar: "So, is design dead? Not by any means, but the nature of design has changed".

Struts & frames

Volvemos a un post algo más técnico. A raiz de una pregunta por email que me han hecho estos días, he recordado un post en theserverside.com, sobre "struts and Frames". Mucha gente que usa frames para las aplicaciones junto con Struts nos hemos enfrentado un poco a la problemática que supone. En ese post explicaba la posición que habíamos tomado en un proyecto de desarrollo, para minimizar la complejidad del tratamiento de los frames.

We suppose the form data is ONLY needed for the action, so the action executes and change the model as needed. The action decides which is the next page, and if it can have frames it sets a variable "next" in session, which indicates what the frames that must be loades in this way:

Every frame in frameset is redirected to an special action frames.do with two parameters: the place where the frame is loaded and the "next" variable.
For example:

<frameset id="vis" cols="261,*" border="0" framespacing="1">
<frame name="bottomLeft" src="frames.do?position=frameBottom&action=<session:attribute name="next">">
<frame name="bottomRight" src="frames.do?position=frameTop&action=<session:attribute name="next">">
</frameset>

And we have implemented the frames.do action to know which JSP must be loaded, with parameters position and next. In fact, the page that must be loaded is written in struts-config.xml in this way:

<action path="/frames" type="package.FramesAction" name="framesForm" scope="request">
<forward name="frameTop-next1" contextrelative="true" path="/WEB-INF/jsp/jsp1.jsp">
<forward name="frameTop-next2" contextrelative="true" path="/WEB-INF/jsp/jsp2.jsp">
....


So the frames.do makes a forward to the String created with "position+next" (the two parameter of frames.do) and we can establish the JSP in the xml file...

De esta manera conseguíamos el no preocuparnos por el frame al que era dirigido una acción, pues la misma acción podía ser implementada por la misma clase, y devover JSPs con frames diferentes según el nivel del frame al que fuese dirigido. Las redirecciones desde HREFs o SUMBMITs ya simplemente se indicaban en el target.

Con esto también conseguiamos la vuelta atrás de manera sencila aunque implicase el cambio de varios frames, por que la acción de "frames.do" almacenaba los anteriores vistas y era capaz de reponerlas en el lugar adecuado.

¿creación de soft. libre?

La creciente aparición de empresas que anuncian el uso de software libre es importante. Lo que yo pensaba hace un tiempo es que iban a aparecer más empresas DE software libre. Esta diferencia es muy importante.
Las actuales nuevas empresas que dan soporte al software libre suelen convertirse en meras consultoras que dan como valor añadido el uso del SL. Seguramente no es poco valor añadido ahora que el SL es ya, hace tiempo, una plataforma muy válida y que ha demostrado su funcionalidad. Pero yo suponía que iban a nacer más empresas que sacasen su software como libre. Bien el software que tenían, o nuevos desarrollos de esta manera.
¿por qué no se ha producido este hecho? ¿quizás el método del software libre todavía impone demasiado "miedo" en los círculos empresariales, que ven un beneficio más directo en la venta de licencias?
ACTUALIZADO: Lo he preguntado en Barrapunto también. Os haré un listado con las que encuentre. ¡Gracias!

Mudanza de datos

Haciendo una mudanza de casa, mi amigo Gus y yo nos preguntamos que deberíamos remover, limpiar de nuestros cerebros que ya no nos sirva de todo lo aprendido en la facultad. De todos esos magnos conocimientos, ¿qué usamos actualmente en nuestros puestos de trabajo? ¿qué hemos olvidado? ¿es necesario olvidar algo para seguir aprendiendo?

1) Metodología de programación: El uso de precondiciones, postcondiciones e invariantes en los bucles para comprobar matemáticamente el funcionamiento de los programas. vaya, para eso ya tenemos el JUnit, nos podíamos aburrir comprobando cada instrucción mediante matemáticas.
Sin embargo, sí que estas cuestiones te dan un "background mental" dificil de percibir.

2) Física: Claro, son las bases de los funcionamientos de los circuitos integrados, electromagnetismo, integrales de elementos... pero, esto sí que creo que ya lo olvidé nada más salir por la puerta tras acabar el examen. Bueno, alguno no se le olvidará nunca tras verlo cuatro años seguidos.

3) Cálculo: ¿alguno habeis hecho integrales desde que salisteis de la facultad?

4) ADA: En la UPV enseñan desde primero este lenguaje de programación. Únicamente he sabido de una persona que lo ha seguido utilizando tras la facultad, en una empresa de aeronautica, pero... ¿alguién más lo utiliza? Gus dice que le parece un buen lenguaje para aprender, pero opino si no sería mejor empezar con JAVA o algún lenguaje más presente en el mercado.

En fin, estas cosas no usamos en nuestros trabajos actuales, seguro que otros de vosotros utilizais estos temas u otros que a nosotros no se nos ocurren. De todas maneras, no cambiaría demasiado lo aprendido en la facultad, contamos con una buena base para seguir aprendiendo.

Calidad en el software, mejor libre o privativo

En Navegapolis he leido sobre diversos proyectos para asegurar atributos de calidad del software críticos en áreas como rendimiento, modificabilidad o fiabilidad. En estos casos la calidad se entiende si el programa o software satisface las especificaciones descritas para él.
Una cuestión con el software libre, es si su modelo de desarrollo favorece una mayor calidad de los productos.

Ante todo, ¿qué es un software de mayor calidad? Lo definiré como un software que proporciona mayor valor añadido para quién lo utiliza, teniendo en cuenta que sus posibles fallos¨ van a mermar ese valor proporcionado, así como la dificultad en su uso.
Se pueden definir una serie de atributos que debe tener el producto de software, que son comúnmente aceptados para que tengamos un software de calidad:
o Fiabilidad: El software hace lo que se supone que debe hacer.
o Portabilidad: El software puede ser fácilmente transportado a otra plataforma.
o Eficiencia: El software hace lo que hace de la mejor manera posible, economizando tiempo y espacio§.
o Usabilidad: El software es fácil y cómodo de usar.
o Testable: El software es fácil de probar su funcionamiento.
o Entendible: El software es fácil de comprender por las personas que lo van a mantener.
o Modificable: el software es fácil de modificar por las personas que lo van a cambiar.

Si entendemos la calidad como una lista de atributos, los anteriores serían los que debería cumplir. El grado en que un software cumpla esos atributos determinarían su nivel de calidad. ¿pero qué modelo de negocio va a proporcionar mayores valores de estos atributos por sí mismo?
En teoría, ninguno tendría que ser mejor que otro para aumentar el valor de estos atributos solo por el hecho de que el software sea desarrollado bajo un modelo u otro. Tanto los programadores y desarrolladores de ambos modelos pueden crear el mismo producto con la misma calidad. Hemos visto que la clave está en las personas. La Gestión de la Calidad Total insiste en esa idea. Cualquiera de los dos modelos, funcionando correctamente, pueden generar software de calidad.
Pero, y me atrevo a poner un pero, la realidad puede hacer que algunos de esos atributos sean más “queridos” por un modelo que el otro. Mi experiencia me inclina a pensar que el modelo de negocio comercial tiene más ventajas en la usabilidad y la fiabilidad; y que el modelo de código abierto se centra en la modificabilidad, entendibilidad y portabilidad. En estos atributos veo posibles diferencias a la hora de desarrollar los productos. Por supuesto, no quiero decir que se ignoren los otros atributos, solo destaco las visiones que he tenido de los diferentes productos.

Extraido de Nuevos modelos de Negocio

Ubuntu Linux ha llegado

Ya casi ni me acordaba, pero hace un par de meses solicité unos CDs de Ubuntu. Lo primero, he intentado probar el LiveCD en el portatil (un Fujitsu-Siemens Amilo) y no me reconoce, de ninguna manera el CD. Bueno, la idea era instalar esta versión en el de sobremesa, ahí espero que no habrá problemas.
Es curioso, se lo he comentado a algún amigo ajeno a esto de la informática, y se ha quedado pasmado cuando le he comentado que me han llegado 10 CDs de un sistema operativo totalmente gratis. "¿y así ganan pasta?"- se reía. Bueno, pues cada uno tiene su método. Supongo que los gastos que les supone los envíos de los CDs, se tornarán en beneficios en la espera de la solicitud de servicios y mantenimiento de cada vez más gente o empresas. Para conocer la empresa, Canonical Ltd., es interesante ver las razones que daban en guadalinex para basar su versión del 2005 en Ubuntu.

El software libre como suministrador estratégico

Sobre los pilares de la posición estratégica de una empresa comenté algo en los inicios de la bitácora acerca de la rivalidad entre competidores existentes, acerca del impacto en las barreras de ingreso y del poder legislador de los gobiernos. Hacía tiempo que deseaba extenderme sobre este tema que dejé bastante cojo.
Ahora lo retomo para hablar del software libre como sustituto de los suministradores estratégicos de tecnología. El efecto del SL en este determinante de la estructura del sector industrial es, está siendo, bastante importante. En mi tesina seguramente lo infravaloré, y no le di la importancia que ha tenido en el mercado.
La dependencia de las empresas de tecnología de los suministradores "tradicionales" de productos comerciales es muy fuerte. No es facil cambiar de proveedor si tienes 200 máquinas con Windows XP, o algún sistema crítico basado en Oracle.
El SL cambia radicalmente la dependencia del suministrador tecnológico. La disponibilidad del código puede hacer que se encuentren empresas diferentes para dar soporte al mismo producto a un nivel suficientemente alto de calidad, tanto en formación como en solución de problemas o "bugs". O en teoría sucederá esto, por que no sé hasta qué nivel puedes encontrar ahora verdaderos soportes efectivos, de por ejemplo MySQL o Apache. Pero sucederá, si no existen ya, para todo tipo de SL que alcance un número importante de usuarios, como sí existen ya empresas que dan soporte completo a Linux.

Experimento empresarial

He leido en Nodos, un post que me ha dado a conocer un curioso experimento: The Bussiness Experiment.
Se trata de una idea genial: lanzar una empresa, sobre la que todavía se está discutiendo a qué es lo que se dedicará, pero controlada por una verdadera "multitud". Se trata de tomar todas las decisiones empresariales basandose en encuestas a la gente que se apunte al invento este. De alguna manera, se comprobará si la democratización de la dirección empresarial puede dar buenos resultados. Se comprobará la sabiduría de la mayoría,... o no.

Más sobre buenos programadores

Hemos hablado de que los buenos programadores no son solo aquellos buenos técnicamente, si no que además tienen otra serie de habilidades y características. Pero claro, ahora tú, situate en la posición de jefe de proyecto, y planteate: ¿cómo evalúo quién funciona bien en el equipo? ¿cómo sé en que características o habilidades destacan o muestran potencial las personas?
Siempre he pensado que esto es más intuitivo que otra cosa, como pensaba que eran la mayoría de las habilidades interpersonales necesarias para ser un buen "líder". Aunque desde luego se pueden aprender con la observación y la paciencia.
Los grandes proyectos de software se tienden a despersonalizar, con metodologías muy pesadas. Pero si después de trabajar más de dos años con una persona necesitas hacerle un test psicotécnico o psicológico para conocer qué puede aportar en un grupo, técnicamente o que potenciales tiene todavía por desarrollar, planteate que algo no has aprendido todavía.

Los buenos programadores son indispensables

Otro artículo de Joel Spolsky. Este hombre no sé de dónde saca el tiempo, genera artículos como ya nos gustaría a muchos de nosotros.
En esta ocasión habla sobre la importancia de los buenos programadores, que no pueden ser sustituidos por un "montón de mediocres programadores". Esto ya lo ha comentado alguna vez, y no cuenta nada nuevo, insiste en la idea. Pero es interesante recordarlo a más de un jefe de proyecto.
Siempre son recomendables los artículos del Sr. Spolsky.

Java profiling

Hace poco tiempo me he puesto con una aplicación nueva. Está ya en producción y me toca hacer modificaciones y correciones. Por supuesto, no existe demasiada documentación y hay prisas. ¿a alguien le suena esto? :)
El caso es que ya utilizaba hace tiempo la herramienta JProbe, de Quest, un profiler para Java. Ahora lo tengo integrado con JBoss. Como tengo una máquina bastante potente para el desarrollo, siempre ejecuto el servidor de aplicaciones sobre JProbe. De esta manera, en cualquier momento puede ver que está ejecutando JBoss, qué clases y que flujo llevan.

Lo que he descubierto recientemente es que existe una versión gratuita (no libre) de este "profiler". Muy interesante.
Ahora busco uno para analizar la memoria, también gratuita, claro.

Estrés tecnológico

Dos semanas sin ver la "realidad": Internet. Decenas de correos, cientos de posts en foros que solía seguir, miles de posts más en las bitácoras interesantes de mi blogroll... ufff, creo que voy a empezar de cero. Poco a poco, iré superando el hecho de no haber leido los temas de estas dos semanas y no voy a intentar recuperarlos. De otra manera, me volvería loco.
¿me deberé pillar una Palm para conectar desde cualquier parte? Ahora digo que no,... pero también lo decía hace años con el movil...

Evolución técnica del software

J.Spolsky comentaba que los buenos programas llevan diez años. Yo estoy convencido de que porlo menos necesitan cinco, para convertirse en aquello que de verdad se buscaba como idea mítica del software en sus inicios.
Ahora que dejo una multinacional, para irme a una pequeña empresa (aunque eso es otra historia), observo la evolución técnica del producto que se empezó a crear hace 5 o 6 años. Técnicamente, es ahora cuando el (genial) equipo de desarrollo del producto empezabamos a estar más orgullosos de su arquitectura, diseño e implementación. Pasó por muchas fases: servidores de aplicaciones que murieron, servidores de software libre, decisiones drásticas de frameworks, quebraderos de cabeza con algún bug que otro,... y de repente, se convirtió en algo bastante estable, facil de instalar, de modificar, de disfrutar.
Supongo que Spolsky en su artículo se refiere más a que las funcionalidades necesarias para un producto maduro se obtienen a partir de los diez años. ¿qué más se te ocurre añadir necesario a Word o Excel? Pero también la evolución técnica debe madurar, y por mi experiencia, le echo cinco años por lo menos.
Así que cuidado con las primeras versiones y sus bugs (bueno, para Oracle, con todas las versiones ;) ).

Organización empresarial en empresas basadas en Software Libre

Siguiendo con el tema anterior, voy a transcribir otro fragmento de mi tesis del MBA. otra vez. Hablo de la organización empresarial en organizaciones que quieran basar su actividad en software de código libre.

 

No olvidemos de todas maneras que una estrategia alrededor del software libre siempre debe estar muy centrada en lograr la máxima calidad del producto, o de lo contrario la comunidad dejaría de confiar en una empresa que puede anteponer sus intereses a los del producto de software libre. Por tanto, asegurando la calidad del producto y la transparencia de la empresa en conseguirla, se alcanzará una de las estrategias claves: conseguir la confianza de la comunidad de software libre. Todos los trabajadores deben centrarse en ello, y debe garantizarse mediante la organización empresarial adecuada.

Tradicionalmente el software se ha desarrollado bajo una jerarquía bastante estricta, dónde las personas implicadas podían jugar estos roles:

• Jefe de proyecto: Quien gestiona el equipo y se asegura de su buena marcha.

• Analistas: Que obtienen los requerimientos del cliente y realizan el diseño del software a implementar. A veces se dividen en analistas senior y junior, y se dividen la responsabilidad de tratar con el cliente o la iniciativa de tomar decisiones estructurales del software.

• Programadores: Como último escalafón seguirían los diseños de los analistas creando el código fuente. También se suelen distinguir entre senior y junior, principalmente por su experiencia.

Ahora estamos hablando de que hay que proporcionar mayor confianza a los trabajadores, de que son estos quienes deben relacionarse con el mundo exterior. En este caso, los verdaderos conocedores del código fuente son los programadores. Cada vez más se escucha que se debe dar mayor importancia a los programadores, valorarlos más. Podemos asegurar que la clave de una empresa son sus personas. Las técnicas de organización, de calidad, de producción,... cada vez se orientan más hacia el valor de la persona. Por supuesto, los procesos son también importantes, pero "la clave del éxito son las personas". La organización empresarial de una empresa de software, ya sea comercial o basada en software libre, no debe olvidarlas.

Los roles tradicionales limitan la capacidad de las personas. Nadie quiere ser programador como rol tradicional, porque se limita a realizar un trabajo a veces carente de iniciativa en los proyectos más burocratizados. Además, es un trabajo menos valorado. Una organización que motive a las personas intentará que cada uno rinda al máximo de sus posibilidades, centrándose en los equipos como medio fundamental para la creación de software. En la creación de software esto es todavía más importante, puesto que ya hemos hablado que no se pueden establecer procesos idénticos, porque no existen los mismos problemas. Cada producto de software es único, aunque tengan las mismas funcionalidades.

Ya existen formas organizacionales de los equipos de desarrollo de software diseñadas para eliminar las barreras jerárquicas, para mejorar la comunicación y disminuir la burocracia. Un ejemplo de esto es la metodología de gestión de proyectos de software conocida como "eXtreme Programming ." o XP. Por supuesto, esto puede ser aplicable a empresas productoras de código abierto y las que no lo son.

Habilidades del buen programador

Para ser un buen programador (Robert L. Read), y no quedarse en el programador "mediocre", no solo se necesitan habilidades técnicas, si no que además se necesitan habilidades sociales y personales.
Hacía mucho tiempo que había leido este documento y ahora me ha venido de nuevo a la cabeza tras la historia de las multinacionales.
El caso es que llega un punto en el que se necesita algo más que conocimientos técnicos para ser valorado, y para ser un buen profesional. Puedes quedarte con los mismos conocimientos y mejorar técnicamente, pero después se necesita trabajar en equipo, capacidad de negociación, de asimilación de ideas,... muchas habilidades que desde luego no enseñan en la facultad de informática.
En general, me imagino que no las enseñan en ninguna carrera técnica, pero creo que otro tipo de ingenieros salen con una mentalidad mucho más abierta de la carrera en cuanto a las capacidades laborales que se les van a requerir. Supongo que las pantallas de los ordenadores nos absorben mucho durante la carrera, pero se debe evolucionar para trabajar en el mundo empresarial. O puedes quedarte siempre siendo el gurú ese que está en una esquina y lo sabe "todo sobre casi todo".(que también puede ser una area interesante...)
Os recomiendo el artículo anteriormente comentado. Muy al estilo Spolsky.

DWR: AJAX sencillo, pero ¿útil?

Siguiendo con la fiebre de AJAX, se ha publicado (leido en TheServerSide) la versión "Release Candidate 1" de DRW. El primer vistazo que le he dado ha sido bastante positivo. Parece que simplifica el uso del XMLHttpRequest mediante la casi transparente llamada desde JavaScript directamente a las funciones JAVA. Aparentemente, por supuesto, por que hay que incluir un servlet en tu aplicación, y un JavaScript en tus páginas HTML.

Entiendo que para aplicaciones complejas esto puede tener utilidad, puesto que te abstraes del canal de comunicación por HTTP, y de sus invocaciones. Pero, ¿hasta qué punto se quieren hacer efectos complejos, si seguimos teniendo el problema de la latencia entre la petición y la respuesta por HTTP? Para que AJAX sea útil en una interfaz, debe proporcionar una velocidad que sea prácticamente transparente para el suario, y para ello, no sé hasta que punto nos podríamos poner a realizar tareas complicadas en el servidor.

De todas maneras, la herramienta DRW, será muy útil, para ver AJAX en el desarrollo sin complicaciones.

Multinacionales, desarrolladores... y costes.

¿qué valor tiene un buen desarrollador(programador) o un buen equipo de desarrollo en una multinacional? Obviamente la pregunta podía extenderse a la generalización de todos los empleados, pero como ahora hablamos de lo que hablamos, me pregunto si debería haber diferencias.

A nivel directivo, en una multinacional, los números es lo que cuenta. Los directivos pueden preocuparse más o menos de sus empleados, y de construirles el mejor sitio para trabajar, pero el ROI manda. La teoría de los masters se suele quedar en palabras bonitas sobre cómo tratar a los empleados (y alguna reunión para calmar los ánimos de vez en cuando). A esto se suma el poco entendimiento de la producción tecnológica de software, como un proceso totalmente diferente de la producción de bienes materiales, y a medio camino muchas veces de la prestación de servicios.

Además, se suele hablar de la diferencia que existe entre los programadores "buenos" o "malos". Extensivo sin ninguna duda a los equipos, donde las sinergias entre los miembros pueden multiplicar los factores humanos que inciden en la buena marcha de un proyecto.

¿Existe tanta diferencia entre equipos o personas de otros sectores, como entre los "buenos y malos" programadores? ¿las multinacionales hacen algo por reconocerlos?

Este Post no intenta llegar a ningún objetivo :) , solo reflexionar.

 

Gestión de la innovación: Soft.Libre vs privativo

Extraido del trabajo de Nuevos Modelos de Negocio...

En el mercado del software la innovación tiene una importancia vital. Es muy importante que la empresa este basada en una cultura con sólidos cimientos en la innovación. Es realmente sorprendente cómo el software libre puede ser respaldado por los factores básicos de la cultura occidental descritos por Samuel P. Huntington:

• Igualdad de las personas en cuanto a su dignidad: El software libre iguala tanto al productor como al consumidor en la utilización del software.
• Libertad: Es la base del movimiento, donde se dispone de toda la libertad para cualquier uso, copia o modificación del software.
• Participación: El software libre realmente permite participar en el desarrollo a cualquier persona.
• Solidaridad: El software libre además es gratuito, y facilita la utilización de cualquiera que lo necesite.
• Subsidiaridad: El productor del software no puede tomar ninguna decisión que podría perjudicar a los usuarios, puesto que el software en realidad no le pertenece.
  

Los principios de creatividad, conocimientos, eficiencia y valores humanos descansan sobre estas bases culturales. Estos principios, que deben estar presentes en todas la empresas, parece que se ven más respaldados todavía en este modelo nuevo de negocio, al cumplimentar los factores básicos de la cultura occidental no solo desde el punto de vista de la empresa, si no además del usuario.

Es decir, estos factores en los que se basan los planteamientos estratégicos de creatividad, conocimientos, eficiencia y valores humanos no son solo valorados desde el punto de vista de la empresa. Ahora se da la vuelta a la relación empresa-cliente, y se observan desde el punto de vista del usuario de software. Esto es lo que Richard Stallman planteaba: la libertad de los usuarios que además debe acarrear incluso mejoras sociales.

¿Significa que las empresas comerciales intentan omitir factores elementales de la cultura en su relación con el cliente? Sinceramente no lo creo. Simplemente el punto de vista es distinto. No creo que una relación comercial entre un productor de software y un usuario, la venta de un código binario mediante unas licencias, suponga ninguna trasgresión de los derechos de ninguna de las partes. Pero el nuevo modelo de negocio implica simplemente la visión desde el otro lado, desde el lado del usuario. Y ello ha llevado a cambios muy importantes en el sector industrial.
El modelo de negocio basado en software libre facilita sobremanera la capacidad de innovación mediante la copia. De hecho, la empresa que adquiere la innovación mediante la utilización de software libre, ni siquiera debe hacer esfuerzo en realizar la copia, no supone un trabajo de análisis de producción para alcanzar la producción igual que la original. Simplemente es software el libre, y por lo tanto también lo es la innovación que represente.

La innovación de ruptura puede venir de distintos departamentos que los encargados del desarrollo. En este punto, la empresa comercial puede tener ventajas sobre una comunidad de usuarios no organizada. Los distintos departamentos de la empresa colaborarán en buscar mejoras de ruptura, que no tienen por qué venir únicamente desde el perfil técnico. Marketing o el departamento financiero, por ejemplo, pueden (y deberían) colaborar en distintas ideas que puedan significar desde su punto de vista una innovación.

En las comunidades de usuarios muy distribuidas, generalmente las innovaciones provienen del esfuerzo de una sola persona. Estas innovaciones pueden ser brillantes, pero por lo general tendrán ventaja los equipos bien organizados de las empresas. Por esto, las empresas basadas en software libre deberían realizar un esfuerzo para encaminar a la comunidad a una organización dónde se fomente la innovación, o realizarla internamente con conexiones al exterior.

En el software de código abierto la innovación incremental es la más aplicada. Los desarrolladores van mejorando un producto, añadiendo cada uno su porción de innovación, pero es más difícil que se planteen un cambio radical al producto.

En las comunidades de software libre la innovación descansa únicamente en los desarrolladores de forma individual, pero las empresas pueden innovar compartiendo visiones distintas: desde el área comercial, desde la alta dirección o desde el área financiera. Estas areas pueden aportar, y de hecho es necesario que lo hagan, un fuerte empuje para facilitar la innovación empresarial.(Aunque cada vez más los proyectos de software libre son liderados por empresas, lo que paliaría esta situación)

Se suceden mayor número de iteraciones para obtener un producto terminado, debido a la externalización de los recursos. Puede tener un coste que hay que gestionar (repositorios, listas de correo,... en definitiva, es muy importante el sistema de información empresarial)

Las redes son la mejor explicación del funcionamiento de las comunidades de software libre. Los intercambios entre las personas y organizaciones involucradas en un desarrollo de software código abierto no sigue ninguna jerarquía, puesto que no existe una súper-organización, al menos explícitamente, que englobe a todas las partes.

La importancia de las 3 Cs: Crear, Colaborar y Compartir, en la innovación es importante. Esto se realiza ya incluso con proveedores, clientes e incluso competencia. Se puede ver a distintas empresas sin acuerdos escritos entre ellos colaborando entre sí. La licencias GPL en alguna manera les obligaría a ello, puesto que deben publicar sus cambios y mejoras. De esta manera, la misma naturaleza de la licencia en cierta manera fomenta la innovación basada en el trabajo de un grupo. Por lo menos de manera más clara se fomenta la creación y el compartir, por que quizá sea en la colaboración como manera de innovar donde se encuentren mayores problemas. Todos colaboran creando el mismo producto, pero es más que posible que cada trabajo vaya en su dirección, la que le interese al programador voluntario, o a la empresa que lo desarrolla.

Método científico de desarrollo

¿Es distinto el método de desarrollo en los sistemas de software libre que en los propietarios?  Ted Schadler  indica que en el software libre el modelo de desarrollo se aproxima más al método científico de investigación, dónde se dan estas características:

• Revisión por pares 
       La meritocracia de desarrolladores da a los mejores programadores las posiciones líderes. Solo las mejores ideas y código se lanzan en las versiones finales. Un “líder”(generalmente el fundador) hace de “dictador benevolente”.
• Resultados publicados 
      Como el código es público, los fallos son corregidos rápidamente. Muchos equipos pueden trabajar en módulos diferentes simultáneamente. Las mejoras se soportan totalmente por el código existente.
• Programadores voluntarios
      Internet mantiene la comunidad unida-virtualmente ilimitada. Los programadores están altamente motivados por que escogen su propio trabajo.
• Versiones lanzadas por ingenieros 
      Se lanzan las versiones cuando los ingenieros piensan que el sistema está listo para producción, no cuando conviene al depto. de ventas.

    Se hace un paralelismo con la comunidad científica, sonde los artículos son publicados, para ser revisados por un numeroso grupo de colegas. Pero en realidad, ¿hasta que punto todo lo mencionado son ventajas que se den realmente? Todo depende en realidad del número de desarrolladores implicados.

    ¿Cuantas veces un código de alguien es revisado "a conciencia"? Más bien, únicamente si se descubre un bug. Y el que otros lo solucionen ¿puede dar lugar a efectos colaterales por no conocer perfectamente el sistema?

    El código público, ¿cuanta gente lo observa mínimamente, o pasa directamente a usarlo? La motivación de los desarrolladores puede ser muy alta en el software libre, pero no tiene por qué serlo menos en una empresa bien coordinada y que valore a sus trabajadores (que no sé si existen! :) ). Además, en muchos proyectos de sw. libre los desarrolladores están en lugares distintos, y en cuestiones organizativas, nadie dudará que una reunión cara a cara es mil veces más efectiva que cualquier otro sistema.

    En definitiva, realmente el modelo de desarrollo del sw. libre o propietario puede ser distinto en alguna manera no radical. Pero no creo que ninguno de los dos sea mejor que otro.

La fiebre de UML

¿conoces a alguien con la  fiebre de UML?
Los procesos de desarrollo de software están llenos de herramientas que podemos usar: tarjetas CRC, diagramas de todo tipo, generadores de código automáticos, documentación...
El problema surge cuando nos centramos más en las herramientas que en el software que debemos construir. Se ve en bastantes proyectos, dónde se manejan ingentes cantidades de documentación, agendas, diagramas; pero no se vislumbra cómo va el desarrollo del software, que es el objetivo final. De repente, nadie sabe exactamente en que estado está el producto. Unos días te hacen una demo de una parte, y días despues de otro módulo, pero entonces te dicen que el del otro día ya no funciona, que hay que revisarlo. Eso sí, los diagramas UML te los enseñan, para descibirte las características internas del sistema.
El artículo "Death by UML Fever" describe con un poco de sarcasmo, los casos clínicos del abuso del UML, sin duda la herramienta más extendida hoy por hoy para el diseño y ayuda del proceso de construcción del software. La falta de experiencia práctica parece ser una de las principales razones para que los ingenieros de software se dejen llevar por las "fiebres" que provocan el uso indiscriminado de UML. Parece más facil e igual de útil pintar diagramas que ponerse "manos a la obra".
Y tú, ¿conoces a alguien afectado por las fiebres del UML?

Newsletters de JAVA

Existen numerosas suscripciones a listas de correo sobre temas de JAVA. Una de las que sigo con más interés es la de Maximun Solution.

En su apartado de Newsletter podeis encontrar todos los artículos enviados desde el inicio de la lista. En general tratan temas para especialistas en JAVA, que requieren un conocimiento avanzado del lenguaje y la plataforma. Si crees conocer JAVA a fondo, planteate echar un vistazo a los temas que tratan. Seguro que algo aprendes. yo por lo menos, lo he hecho, y muchas veces.

Y otro sitio clásico e imprescindible: La guía de "performance" de Jack Shirazi, dónde encontrar los mejores recursos para solucionar los problemas de eficiencia de una aplicación JAVA.

AJAX y Struts

Parece que ahora se ha puesto de moda de repente lo que se conoce por AJAX. Es decir, que desde JavaScript se puedan envíar peticiones HTTP al servidor y obtener la respuesta para ser tratada y mostrada desde el mismo JavaScript sin tener que recargar la página completa.
Desde que Google lanzó su Gmail parece que el mundo ha caido en la cuenta de lo valioso que puede ser este mecanismo de traer datos sin recargar la página, de manera oculta para el usuaario, para mejorar la "experiencia del usuario".
Casi siempre he utilizado Struts en los desarrollos J2EE, y obviamente ya hay múltiples páginas mencionando la integración de AJAX con Struts. Aunque realmente son tecnologías que poco tienen que ver por su lugar en la arquitectura, tratan de estandarizar un poco el proceso de uso.
En definitiva, se trata de crear acciones que devuelvan un formato definido para mostrar en una capa concreta del HTML, posiblemente a respuesta de una acción o evento capturado desde la interfaz mediante JavaScript. El código JavaScript lee la respuesta y la muestra adecuadamente.
En fin, un pijadilla más para mejorar las interfaces en los navegadores.

Java Internal Use License (JIUL)

Sun ha optado por abrir un poco más su mundo JAVA. Ante las peticiones del mundo del software libre, este paso es del todo insuficiente, de hecho la licencia nueva con la que saca el JDK 5.0, no significa que el compilador de SUN sea software libre.
La licencia no permite distribuir una versión modificada del compilador, para eso existen otro tipo de acuerdos comerciales, si no que permite ver el código y que si lo necesitas lo puedas modificar. Luego tienes la opción de reportar esos cambios a SUN que pueden evaluarlos para su siguiente versión del JDK.
SUN sigue apostando por controlar muy de cerca el desarrollo de su plataforma JAVA, y lo más importante, su especificación. Personalmente, creo que los JCP para definición de requerimientos son una buena idea para el funcionamiento de JAVA. No pierdes el control, pero tampoco dejas de lado a la comunidad. Para el mundo empresarial, y eso ha facilitado el crecimiento de JAVA, el control por parte de SUN es muy importante, para evitar miles de distribuciones distintas.

Centrarse en la metodología o en las personas

Desde javaHispano , he llegado por uno de sus comentarios a un artículo de Alistair Cockburn que merece la pena realmente leer. Es posible que sea un artículo muy conocido, pero hasta ahora no había llegado a mis manos. Destaca la importancia de las personas como componente de primer orden para el éxito de los proyectos (de ingeniería) informáticos.
La metodología XP tiene una de sus bazas fuertes en aumentar la importancia de los programadores sobre la metodología, y es uno de sus puntos fuertes. Obviamente, ya hablamos de que XP no vale para todo tipo de proyectos. Pero para mi la conclusión que me ha confirmado este artículo es que es más importante el equipo de personas con el que trabajes, que la metodología utilizada.

Por otro lado, el artículo de javaHispano de crítica al XP tiene algunos puntos buenos, pero en general, da la impresión de que el autor "odia" las metodologías ágiles, y que eso le ha llevado a escribir muchas cuestiones sin sustentarlas en razonamientos lógicos o recapacitados.