Software Factory - Factoria del Software - Fabrica de Software

Tristeza por el accidente areo en Madrid

2008-08-21T12:28:00.002+02:00

Estaba preparando otro post, pero las dimensiones de la desgracia son importantes. Más de 150 muertos confirmados.. Mueren personas en todo el mundo a todas horas, pero cuando es más cerca más se nota.

Mi pesame y apoyo a las familias, y respeto a su dolor.

Ranking Universidades

2008-08-13T08:28:00.010+02:00

En el pasado he defendido la tesis de que la Universidad en España deja mucho que desear, pues vuelvo a la carga. En concreto hablo de la informática, en donde creo que estamos muy lejos de la senda correcta. Hay excepciones supongo, pero casi todo lo que conozco... A la Software Factory sigue llegando gente sin preparación, pese a tener unas notas excelentes, ¿como se come esto? ...
Esto ocurre porque aquí, en España, aún se sigue pensando que la Universidad es libre de decidir que impartir y que no, que una serie de profesores piensan que su libro es el bueno pese a que solo lo compran sus alumnos obligados... por favor señores de la catedra, enterense ya que en esto de la informatica, los americanos nos dan mil vueltas y nos llevan mucho ventaja...(Google, Microsoft, IBM, Sun, Bea, Dell, Intel, Amd, HP, Apple, etc) no piensen más que ustedes saben de este negocio.. Si, es un negocio por si no lo sabían. Es un error que pagan todos los que pasan por su red.

Salgan de sus despachos y pasense por las empresas y vean sus necesidades, después asesorense y hagan unos temarios acordes, promuevan el I+D con la empresa, y dejen que entre aire fresco. Sigan el modelo americano, que parece que les va muy bien, ya que las mejores Universidades del mundo allí están...

Aquí pongo dos ranking de universidades, la primera española aparece en el puesto 141. Ole.

Estos son los dos enlace mencionados:

WeboMetrics Rank

Arwu

Buscad la vuestra..!!!

Si alguien tiene otro que me lo pase.

Por cierto en este aparece Carnegie Mellon University , precursora del modelo CMMI en el puesto 14. Esto es lo que ocurre cuando vas por delante y no por detrás.. que es la empresa la que te sigue. Pero para esto, aquí queda mucho camino por andar.

KNOL a unit of Knowledge

2008-08-06T17:37:00.003+02:00

Google no deja de sorprendernos y esta vez lanza Knol. Para mi es una sorpresa agradable ya que creo que en cierto modo casa con este blog. Knol pretende ser una base de conocimiento, en la cual se realizan aportaciones de personas con un nivel alto de experiencia y conocimiento del tema tratado.

Para el que prefiera la definición en inglés:

"A knol is an authoritative article about a specific topic."

Algunos de los articulos que podeis leer en mi modesto blog, tienen es ocasiones estas pretensiones como la trilogia de Software Factory, que por cierto siguen siendo los articulos más visitados del blog. Creo que intentaré migrar algún articulo a Knoll, esta claro que una versión mejorada del mismo.

¿Quien más se anima?

Pizarras Agiles

2008-08-03T12:12:00.007+02:00

Me ha llegado un articulo sobre el uso de las pizarras en proyectos ágiles.. Creo que la pizarra es un bien universal a todos los proyectos. Por mucho que sigamos avanzando en modernas herramientas de seguimiento o con la integración de los "ToDo" en los entornos de desarrollo, la pizarra para mi es imprescindible..

Lo que nunca me había planteado es el uso de calendarios para representar el estado de animo o motivación del equipo de desarrollo, como representa el Nico Calendar.

Si estás interesados no os perdáis el articulo "Visualizing Agile Projects with Kanban Boards"

Mercado Español de Gestion de Contenidos

2008-07-20T11:16:00.008+02:00

IDC compañia dedicada al análisis continuo del mercado de las Tegnologías de la Información ha publicado un estudio sobre los Gestores de Contenidos en el mercado español. El estudio lo podéis encontrar aquí, aunque solo se puede acceder al resumen ejecutivo sin pasar por caja.

El estudio aporta información interesante sobre el mercado nacional, y el análisis de la demanda.Por otro lado estudia cada uno de los players, aquí la información es restringida, así que no he podido acceder al detalle de cada uno.

Pero lo que si es público es la lista que es la siguiente:

# IBM
# EMC
# Open Text
# Microsoft
# Grupo DICOM (Kofax Division)
# Oracle
# Interwoven
# Vignette
# FatWire
# Divisa iT
# Ever Team
# Xerox

No conozco todos los ECM ((Enterprise Content Management) del mercado, pero si puedo echar alguno de menos rápidamente ALFRESCO, para mi es incomprensible que no este en esta lista.. Cuando sin duda es mejor producto que otros que si están.. Señores de IDC, ¿ALFRESCO no es un player? Yo al menos me lo he encontrado en bastantes sitios..

Estoy de acuerdo en que si nos centramos en los ECM y no en los CMS (Content Management System) la lista se acorta, pero creo que hay muchos que se encuentran en la frontera entre ECM y CMS, y que últimamente se han subido al carro de ECM porque tiene más nicho de mercado. Existen algunos CMS como OpenCms, que creo que sin duda esta al nivel de alguno de la lista.

No deja de sorprenderme la inclusión de Divisa IT, empresa nacional. Que nadie lo lea como una crítica, que es un aplauso, para mi que alguien de la tierra compita con los grandes y consiga aparecer en la lista, es de admiración.. Lo consiga como lo consiga. Ya me gustaría a mi algún día lograr lo mismo..

Por otro lado el otro día pude ver en televisión un reportaje sobre la web del Real Madrid, y como se habían volcado en la distribución de contenidos. Aunque apenas entraron en aspectos técnicos, si mencionaron que la tecnología era Fatwire. Aunque a todo se le pueden poner pegas, (solo idioma ingles y español, y el mercado chino donde van de gira!!), es un magnífico trabajo. La verdad es que me quede con ganas de ver más, y me encantaría que hubiera reportajes de este tipo en los medios..

Firefox World Record

2008-07-03T18:24:00.004+02:00

Pues finalmente parece que se consiguió el record. Estoy contento por poner el granito de arena ya que el navegador es fantástico.

Felicidades Mozilla !!

A vuela pluma

2008-06-30T23:51:00.002+02:00

Hoy acabo una etapa en Caceres, de la cual me quedo con muchas cosas, pero sobre todo con las personas que he conocido...

Gracias por acogerme en ese núcleo, en esa mesa, en esos desayunos, en ese bks, en ese java, en ese cobol, en ese padel, en las comidas, en los chistes, en las gominolas..

Sois geniales, gracias..

P.D: Volveré !!

Pair Programming, Cola y Software Factory

2008-06-28T01:41:00.006+02:00

Hace ya bastante tiempo que conocí el concepto de Pair Programming, que para el que no lo conozca, se trata de una técnica de desarrollo que se basa en que dos programadores trabajan simultáneamente sobre el mismo código. Programan juntos lo mismo compartiendo ordenador, uno teclea y otro dicta.

En realidad la definición es mucho más formal y define a los participantes como Driver (o el que teclea) que es el encargado de implementar en base al cumplimiento de las normas de estilo o buenas practicas de programación, y el Observer que es el encargado del aspecto estratégico, afronta una visión más global del aplicativo, selecciona patrones correctos, etc.

Nunca creí que esto pudiera funcionar, de hecho es algo que descarte nada más conocerlo sin prestarle más atención. Porque para mi un programador tecleando y otro al lado con unos papeles explicándole que hacer, no me entra fácil.. que perdida de tiempo !!!

Evidentemente la técnica evoluciona y ya los entornos de desarrollo distan mucho de los que yo use cuando era programador. De repente me encuentro algo, como Cola y la Edición compartida en tiempo real, y todo ello en Eclipse integrado y con skype..

A continuación os dejo el video, que no tiene ningún desperdicio, pero si al que no le apetezca le dejo un enlace con el plugin de Eclipse que explica como funciona.

Cola: Real-Time Shared Editing from Mustafa K. Isik on Vimeo.

De repente uniendo esto, con el Pair Programming y la Software Factory, empiezo a tener ideas de como un programador senior, quizás fuera capaz de Construir una aplicación manejando a la vez a tres programadores junior, siguiendo sus avances y dictando ordenes.. Además estos podían estar en diferentes lugares...

Vale, ya se que no invento nada, esto se llama Virtual Pair Programming, pero en principio voy más allá.. pienso en la parte NearShore como Observer y el OffShore como Driver.. ¿Imposible? Técnicamente no lo es, y rentable supongo que si sería.. Probablemente sea una locura, pero si pudiera lo intentaba..

Otra idea, que me asusta, es si esto se pude volver un gran hermano (Big Brother) de la programación, en que se controla línea a línea, lo que escriben los programadores.. Esperemos que esto última jamás sea cierto, porque pase la Monitorización se Servidores, pero la Monitorización de Programadores.. :-D

Gracias a Abraham por el video y la idea..

Reglas de Juego en los Proyectos (ground rules)

2008-06-25T19:23:00.006+02:00

La lectura de un post en el Café de Joe, recomendable blog sobre la Gestión de Proyectos, me ha hecho reflexionar sobre el tema de los valores o principios de Software Factory sobre lo que ya escribí un articulo.

Tengo que reconocer que no conocia el termino Ground Rules, ni que estuviera incluido en el PMBOK, pero para aprender estoy. La definición es la siguiente:

Una lista de comportamientos aceptables e inaceptables adoptados por el equipo de proyecto para mejorar la relación de trabajo, efectividad y la comunicación”

Cuando hablaba de valores de Software Factory como esos pilares que debemos tener sobre la mesa, no reflexionaba que para muchas personas su mundo es su proyecto y no existe nada más que eso en sus vidas (laboralmente hablando). Por tanto las Ground Rules que se establezcan para ellos son las reglas que rigen su universo, y si no se sienten cómodos con ellas estarán descontentos y trabajarán peor.. o se irán a otra empresa o pedirán la salida del proyecto.

La alternativa es establecer unas buenas reglas, que nunca puedan ir en contra de los valores de la compañía.. Es decir la compañía no puede estar diciendo que tiene como principio "Conciliar la vida laboral y familiar",y el jefe de proyecto hacerles realizar un overtime de dos horas diarias..

Si entramos dentro del proyecto, es conveniente fomentar que los procesos de comunicación sean robustos, que se escuche la opinión de todos, que las reuniones sea participativas, que exista el compañerismo, el éxito es de todos, tener claro como solucionar conflictos, enfados, riñas..

¿Cuando arrancáis un proyecto pensáis en los Ground Rules? No estaría demás ya que otro JP / PM puede tener otras y el equipo esperar otros comportamientos... Evitemos el "Es que yo estuve en un proyecto en que lo hacíamos así.. ", que me recuerda a la típica frase de partida de parchis entre amigos.. "Es que en mi casa se juega así" Por mi parte empezaré a pensar más en ello, y no dejar cosas al azar..

Según leo parece que la mejor manera de hacerlo es la siguiente:

"El proceso de discutir las reglas de juego permite a los miembros descubrir que valores son importantes para cada uno"

¿pero nos podemos permitir que opinen sobre todo o discutirlo con los equipos? No lo tengo tan claro.. ¿un proyecto es una democracia?

Mozilla Firefox 3.0

2008-06-17T18:55:00.005+02:00

Ya está aquí !! La tercera versión del popular navegador está lista y dentro de poco todos la podremos tener en nuestros equipos.. Instalarla ya en vuestra Software Factory , si os dejan los de Sistemas !!! :-D

Mientras tanto Mozilla pretende batir el record mundial de descargas en un día..

Yo ya me he apuntado.

A las 19:00 estará disponible..

Valores de Software Factory

2008-06-12T19:47:00.004+02:00

De manera rápida me gustaría dejar la idea, más allá del diseño de Software Factory apoyado en un modelo determinado y en unos costes, creo que se pueden establecer una serie de valores que digan que hacemos y que no hacemos.

Hace poco me decía un amigo "No me gusta lo que hacemos" y luego dijo "Mejor dicho como lo hacemos"..

Conclusión:

" No por mucho que te pague por hora un cliente se puede aceptar lo que te pide, por tanto hay que fundamentar la compañía en unos valores o principios. "

Os voy a dar una serie de principios, interesantes:

1. Lo más importante es pensar en el usuario.

2. Es mejor especializarse en algo y hacerlo realmente bien.

3. La velocidad es un valor seguro.

4. La democracia en la web funciona.

5. No tiene por qué estar en su despacho para obtener una respuesta.

6. Es posible obtener ingresos actuando de forma ética.

7. Es imposible abarcar toda la información disponible.

8. La necesidad de información supera todas las fronteras.

9. Es posible ser profesional sin llevar traje.

10. No nos conformamos con unos resultados estupendos.

Como veis son 10, el 10 es un buen número.. :-)

Algunos diréis que no son muy buenos, que los vuestros son mejores, y seguramente no os falte razón, pero estos no son los míos... Son los de Google y la verdad es que no les ha ido mal.

¿tiene tu empresa o factoría los TUYOS? Si coinciden bien, sino.. tu dirás.

Android (primera parte)

2008-05-29T10:12:00.014+02:00

Google en su continua expansión como empresa, sigue dotando al mercado de una gran gama de aplicaciones sobre las que sustentar su negocio base, el de la publicidad. En un entorno en el que se presenta un emergente acceso a Internet desde dispositivos móviles, mayoritariamente los teléfonos, Google se nomina como participante en esta carrera para conquistar a millones de usuarios potenciales con Android.

Naturalmente Google no se puede presentar a la carrera solo y para ello ha levantado una Alianza lo que llama Open HandSet Alliance involucrando a operadores, fabricantes, empresas de sw, distribuidores, etc.. Y la verdad tiene buena pinta, pero creo que aún les quedan aliados por conquistar o atraer. . Por cierto Telefónica está en la lista..

Las premisas en las que se ha basado Google para construir Android son las siguientes:

Open: El sistema debe ser abierto y las aplicaciones pueden usar todos los recursos del HW (camara, BT, llmadas, etc) además el sistema puede ser extendido por los desarrolladores.

Aplicaciones iguales: Todas las aplicaciones pueden ser creadas del mismo modo, no existen ventajas, ni diferencias para aplicaciones creadas por el fabricante o por empresas terceras.

Aplicaciones sin barreras: No poner ningun limite a la inovacion, pudiendo combinar recursos del dispositivo móvil, aplicaciones web, datos del usuario.. Sin limites para innovar.

Desarrollo Fácil y Rápido. Ofrece una serie de aplicaciones y herramientas que permiten poder desarrollar aplicaciones rápidas y dotadas de gran funcionalidad.

Android se presenta como una plataforma para dispositivos móviles, ya que pretende ir más allá de ser un sistema operativo para móviles aportando middleware y aplicaciones. A estas aplicaciones las llama clave, que son aquellas que todos esperamos que nos traiga de base el móvil cuando lo compramos, y el Middleware son todas las aportaciones a nivel de SDK, que nos permitan construir aplicativos que doten al movil de mayores prestaciones funcionales.

Si inspeccionamos la wikipedia podemos encontrar más acerca de Android pero en el momento de escritura de este articulo, no deja casi de ser una traducción de la web oficial de Android ( What is Android?), en la cual podremos leer mucho más..

Desde el punto de vista tecnico tenemos las siguientes características, extraidas literalmente:

Application framework enabling reuse and replacement of components

Dalvik virtual machine optimized for mobile devices

Integrated browser based on the open source WebKit engine

Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)

SQLite for structured data storage

Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)

GSM Telephony (hardware dependent)

Bluetooth, EDGE, 3G, and WiFi (hardware dependent)

Camera, GPS, compass, and accelerometer (hardware dependent)

Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

Sobre todo me quedo con que el núcleo (Kernel) del Sistema Operativo está basado en Linux, lo que nos da unas garantias de seguridad, una eficiente gestión de memoria y HW. El navegador se basa en Safari, y naturalmente supongo que será uno de los aspectos más cuidados. Otro detalle es que han desarrollado una Maquina Virtual (Dalvik) a medida del sistema. Me ha encantado también que traiga una BBDD SQLite, que permite poder desarrollar aplicaciones de peso. Desde luego si sumamos todo, tenemos una plataforma ideal para el desarrollo de aplicaciones Java..

Desde luego a día de hoy la apuesta de Google respecto a Android es llegar a los desarrolladores, puedo suponer que en dos sentidos, uno como testers de la nueva plataforma y otro sabiendo que cuanto mas desarrolladores, más aplicaciones en el mercado, más competitiva es la plataforma y puede competir con Symbian y Windows Mobile .

No hay nada como organizar una competición entre desarrolladores para conseguirlos, y por ello Google lanzó el Android Developer Challenge, cuyas normas, reglas y objetivos podemos leer aquí. Básicamente busca aplicaciones para Android, premiando la originalidad, el uso del sistema, y la funcionalidad que desarrollan..

De esto hablaré en la segunda parte..

Lineas de Producto Software

2008-05-23T13:02:00.005+02:00

Hasta este momento había comentado los Modelos de Software Factory ( I , II , III ) en una serie de artículos que aún esta pendiente de cerrarse, en ellos nos centramos en como presentar el modelo al cliente y como gestionar la producción interna así como los éxitos y beneficios de cada uno.

En este artículo vamos a centrarnos en como organizar nuestra producción desde el punto de vista Metodológico y Técnico con dos claros objetivos:

Ahorro de costes.
Mejora del Time to Market.
Alta calidad del producto.

Evidentemente el que encuentre la manera de conseguir este trinomio y mantenerlo en el tiempo ha conseguido encontrar el Santo Grial del Software. No va a ser tan fácil de conseguir como muchos autores promulgan, pero sin duda las Líneas de Productos Software es el camino.

En general los dos sistemas de reutilización más usados, son el Individual que se basa en el Copy & Paste del programador y el Oportunista que ocurre cuando un componente se parece a otro que hicimos en el pasado y lo encajamos con calzador.

Siempre lo que debemos buscar es una reutilización gestionada, basada en una planificación y en la que pensemos desde el principio de los desarrollos.

Las Líneas de Producto Software (LPS) o Software Product Lines (SPL), para el que prefiera documentarse en inglés, proponen un sistema de producción basado en la reutilización de componentes en un determinado dominio. Si nos fijamos en otra industria como puede ser la del automóvil, podemos ver como una misma cadena puede producir hasta automóviles con 1000 diferencias entre si, aplicando este sistema podemos tener un linea de producción capaz de generar multitud de variantes en una tipologia de SW.

Evidentemente montar este sistema no es cosa de un día, ya que tenemos que tener una metodología de desarrollo que nos permita generar activos sw o piezas de la configuración, almacenarlas en un repositorio, para a posteriori poder ensamblarlas para componer otro producto de diferentes requerimientos.

Naturalmente otra necesidad es saber construir una Arquitectura a medida de este paradigma de producción, ya que no tiene sentido tener un repositorio de activos sw, si el coste de ensamblaje de los mismos es más alto que el de construcción..

Queda mucho trabajo por hacer.. y mucho por leer, por eso empecemos cuanto antes..

Bibliografía

http://www.softwareproductlines.com/
http://bradapp.blogspot.com/2008/03/software-product-line-architecture-and.html
http://www.ieee.org.ar/downloads/2006-montilva-productos.pdf
http://www.sei.cmu.edu/productlines/spl_factory.html
http://worldofreuse.blogspot.com/

Arquitectura: Marca de Software Factory

2008-05-02T00:03:00.007+02:00

Voy a empezar una serie de artículos que tienen que ver con las Arquitecturas, estando más cerca de los conceptos de metodología de desarrollo, arquitecturas empresariales y lineas de productos software, que cerca de la tecnología de implementación de las mismas. Evidentemente al hablar de desarrollo de arquitecturas todo el mundo vuelve la cabeza para mirar Java y .net principalmente.

Hace unos días me comentaba un amigo que se encontraba trabajando en la nueva versión de la arquitectura y que iban a pasar a la versión 4.2, en ese momento le pregunté ¿y porque no la 5?, a lo que me respondió con una serie de argumentos técnicos (todos muy acertados), que justificaban claramente el porque solo un crecimiento en el digito de menos peso.

Muy probablemente en su empresa siguen criterios cercanos a los de Apache http://apr.apache.org/versioning.html , que desde luego me parece un gran acierto y un planteamiento más que respetable.

En resumen lo que dice Apache respecto a su versionado, siendo esto una política muy extendida. Se basa en tres niveles separados por puntos, MAJOR.MINOR.PATCH, aplicando a cada uno criterios diferentes:

* PATCH VERSION: Solo se realizan correcciones, que no cambian el comportamiento de la aplicación, no cambian los parámetros y llamadas. Por tanto al instalar la versión la aplicación no cambia.

* MINOR VERSION: Introduce nuevas funciones, o cambia y modifica el comportamiento de las existentes pero no rompe la compatibilidad con otras Minor Versions.

* MAJOR VERSION: Cualquier tipo de cambio son aplicables a Major Version y no tiene porque guardar compatibilidad con minor versions. Normalmente se aplica cuando se introducen importantes grupos de nuevas funcionalidades.

La verdad es que se trata de un criterio de versionado robusto, pero no olvidemos que normalmente una arquitectura debe ser proporcionada a un usuario de la misma, bien interno (linea de productos sw, departamentos de la compañia, etc) o externo cara a la venta de un proyecto o venta de una arquitectura empresarial o sectorial, a un determinado cliente.

Desde el punto de vista anterior y teniendo en cuenta que un equipo de desarrollo de Arquitectura no lo hace para si mismo, para un agente externo aparenta más solvencia otra manera de presentar versiones. Pensemos que a todos nos da más garantías un producto que se encuentra en la versión 2.2, que uno que está en la versión 1.3... Aunque ambos pueden tener el mismo número de mejoras y correcciones, solo que aplican criterios diferentes.

Si algún lector no me cree, solo tiene que hacer la prueba, muestre dos productos diferentes que tengan funcionalidad similares, apuesten a que en la mayoría de los casos el cliente o usuario se decantara por el de la versión más alta. ¿Por qué? Porque piensa que lleva más tiempo en el mercado, porque piensa que se ha invertido mucho esfuerzo en él, porque si ha llegado a 7 versiones es que será bueno, etc.. La mayoría de estas valoraciones aveces serán acertadas y aveces erróneas.. pero en cualquier caso se basan en un criterio de apariencia.

Por tanto desde este punto de vista, es más fácil vender, justificar presupuesto, etc , aplicando un criterios de versionado ágiles. ¿Es un engaño? No, es Marketing Tecnológico.

Evidentemente no se puede caer en el abuso, y de repente encontrarnos en la versión 23 de un producto. Hay que poner todo en la balanza y aplicar tanto criterios técnicos como marketinianos.

Cara a introducir un nuevo enfoque voy a contar una anécdota empresarial:

Hoy en día, todo el mundo, o gran parte de el, conoce a una empresa como Nokia. Por increíble que parezca Nokia en sus orígenes fabricaba botas de goma para pescadores, y el nombre proviene de un río existente en Finlandia el Nokia.

Sin embargo el mayor acierto de Nokia en su historia, probablemente no ha sido realizar teléfonos móviles, sino ser pionera en el branding, de este modo su marca siempre aparece en todos sus productos, incluso cuando hacía botas

Supongo, que ya vais viendo a donde quiero llegar..

Si tenemos en cuanta las 100 marcas más conocidas en el mundo encontraremos muchas tecnológicas y bastantes dedicadas a los Sistemas de Información.. La primera es Google (¿quién la conocia hace 10 años?), y entre las diez primeras Mocrosoft, IBM , Apple y Nokia . Nadie duda que la marca les ayuda a vender..

¿Por qué no aprovecharnos de este concepto y que nuestra arquitectura tenga marca?

Sin duda, nos costará poco y ganaremos mucho. Algo que tiene nombre existe y es importante...

¿Que necesitamos?

Un nombre y un logo. (por supuesto nada que pise otras marcas)

¿Como lo usamos?

Poniéndolo en toda la documentación, presentaciones, etc.

En mi antigua y querida empresa nadie se dio por enterado que teníamos una arquitectura hasta que le pusimos nombre y logo. En ese momento todo cambió, parecía que las horas no se gastaban sino que se invertían, que teníamos un producto que vender, que ahorrábamos costes empleándola, etc.. Pero ella era la misma, con sus defectos y virtudes..

Eso si, bautizada.

Javahispano Java Cup

2008-04-25T18:32:00.008+02:00

Después de asistir a dos Congresos de JavaHispano y ser asiduo visitante a su web, junto al respeto y admiración que tengo por esta organización, no puedo dejar de publicitar, en medida de mis posibilidades la Java Cup.

La Java Cup es una competición de aplicaciones java, basada en construir un buen algortimo que permita ganar un partido de futbol simulado entre ambos aplicativos.

Si no os ha quedado claro lo mejor es que visiteis la web Oficial.

La verdad, es que quiero aprovechar la ocasión para agradecer todo lo que me aportasteis en su momento en mi modo de pensar respecto a java y sus frameworks y arquitecturas.

GRACIAS

Modelos de Software Factory. (tercera parte)

2008-04-10T20:39:00.005+02:00

En este capitulo vamos a hablar de los Mantenimientos de Aplicaciones, como otro modelo de relación y de gestión dentro de una fabrica de software.

C. Mantenimiento de Aplicaciones

Tenemos que diferenciar entre el concepto de Mantenimiento dentro de la Ingeniería del Software y el termino A.M o mantenimiento de aplicaciones dentro de una Software Factory (Fabrica de Software).

Cuando hablamos del Mantenimiento de un proyecto hablamos de la fase del ciclo de vida, pudiendo ser este evolutivo o correctivo principalmente. En cambio al hablar de Mantenimiento de Aplicaciones hablamos de una externalización de un conjunto de aplicaciones. Muchas veces esta externalización puede tener que ver con un mantenimiento o puede tratarse del desarrollo de nuevas versiones de aplicaciones o funcionalidades concretas.

Este modelo es uno de los más interesantes para una Software Factory, ya que permite tener una previsión estable de facturación durante un periodo de tiempo.

Evidentemente mejor será el modelo según las condiciones que se cierren en el contrato con el cliente. Los siguientes puntos son vitales se lleguen a cerrar con la mayor precisión posible.

- Volumen mínimo anual, pudiéndose tratar en horas y euros, o en ambos sentidos.

- Gestión de picos y valles, cuanto es lo mínimo al mes que se debe garantizar y cuanto puede crecer mensualmente la factoría para gestionar un pico de carga.

- Acotar tecnologías, arquitecturas y herramientas.

- Definir Metodología de Desarrollo acorde a cada necesidad o tecnología.

- Definir pirámide global y por tecnología, coste hora por perfil.

- Definir estimadores o tablas de estimación. (tecnología – arquitectura – complejidades)

- Definir costes de gestión, humanos (jefes de proyecto, gestores, coordinadores).

- Definir claramente SLA´s y penalizaciones.

- Diseñar las condiciones de salida del contrato y penalizaciones.

- Definir normativa de calidad aplicable, ISO, CMMI, ITIL..

- Estudiar costes adicionales y amortizaciones, sw, hw, comunicaciones.

- Medir los costes de formación. Diferenciar entre general y especifica del proyecto / cliente.

- Definir el modelo de relación, responsables, niveles de decisión, escalado, etc.

- Definir hitos de facturación, periodicidades y condiciones de pago.

- Para mantenimientos plurianuales estipular evolución de precios y estimadores.

Naturalmente en función de la capacidad de negociación y la flexibilidad del cliente, junto al interes de las partes por cerrar los termisno contractuales, serán los factores de exito o fracaso del modelo.

Java esta de moda

2008-03-31T23:05:00.005+02:00

Ha llegado a mis manos la publicación de TIOBE (www.tiobe.com) sobre los lenguajes más populares. Es una estadística que se basa en las búsquedas realizadas sobre google, yahoo, msn…

Desde el principio de la publicación del indicador Java ha sido el más popular, y eso hace por lo menos 8 años, según el gráfico que os presento a continuación.

Como observareis salvo en Octubre de 2004, Java ha sido siempre el líder. Cuando lo vi me llamó la atención y comencé a pensar que podía ser que coincidiera con el lanzamiento de alguna versión de .net o algo así. Nada más lejos de la realidad. No es que java dejara de ser el más popular sino que Google cambio su manera de calificar las búsquedas.. quede esto como anécdota.

Creo que para todos 8 años son mucho tiempo, pero evidentemente no representa lo mismo para una persona, para un perro o para un Drago milenario. Lo que está claro que 8 años en informática es mucho, mucho tiempo.

La informática ha demostrado ser imparable, realizando en menos tiempo que cualquier ingeniería una evolución exponencial, y ha sido la tool del resto, desde aeronáutica, caminos, industriales, química, etc , Por eso a este nivel una década, marca una tendencia y Java sin duda es el rey de la misma.

Cuando Java se debate entre los evolucionistas que pretenden que java siga cambiando (o mutando ¿?) continuamente con versiones de JDK y los inmovilistas que creen que java debe frenar su evolución y su continuo chorreo de versiones, que prefieren dejar para lenguajes como Groovy y Scala, EXISTEN personas que creen que Java no debe ser un lenguaje apto para enseñar en la Universidad. Se imaginan que en la facultad de Medicina solo se dieran las enfermedades de hace más de 50 años, o que en Arquitectura no permitieran el uso de programas tipo Autocad, o en Física no usaran los ordenadores, .. Impensable verdad??.

Hoy por hoy, llegan universitarios a la Software Factory que no conocen Java, ni tampoco .net, ni Cobol, ni SAP… siento decir que la Universidad no hace su trabajo y no mira por sus clientes, los alumnos. Si esto sigue así la informática corre el riesgo de salir de la Universidad, y eso espero que nunca ocurra porque creo que Informática y empresa deben ir de la mano.

Entiendo a dos amigos que uno con una asignatura y otro con el proyecto, dicen que para ellos es una bobada tener la carrera. Que razón tienen !! Lo único que les conviene acabar por "El que dirán.. los de RRHH", aunque tampoco hay una carrera de RRHH.. :-D (con cariño que algunos son muy buenos y grandes amigos).

Cuando era mas joven

2008-03-22T17:45:00.007+01:00

Hace unos años publique un articulo en la revista de mi antigua empresa, de cuyo titulo no logro acordarme, ya que se puso en la publicación y no dispongo de ella. He añadido un par de imagenes para complementarlo. Os dejo con el..

Encontrándome ante la tesitura de tener que impartir un curso para Jefes de Proyecto empecé a recabar información sobre la que apoyarme y que me aportara una visión externa de los proyectos y una buena base teórica. Buscando unos datos para la introducción me acorde de Mr Gartner (en realidad es una consultora).

El ver las estadísticas de Gartner hace pensar a cualquiera sobre los proyectos del sector de las Tecnologías de la Información, no tengo intención de dar cifras pero puedo resumir que dependiendo del tipo de proyecto el porcentaje de éxito/fracaso está sobre 50 %. Normalmente esto supone unas perdidas económicas terribles tanto a compradores como vendedores de proyectos.

No puedo imaginar que solo el 50 % de las autopistas que se construyen acabaran exitosamente, o aviones, o edificios o puentes. La informática también es una ingeniería o eso me han contado. Parece que es jugársela a cara o cruz cada vez que alguien se plantea hacer un nuevo proyecto. Evidentemente algo no funciona en el sector.

Una deducción rápida permite afirmar que el 50 % de los proyectos no deben hacerse, la complejidad reside en determinar cuales antes de empezar con ellos, ¿bola de cristal? No, mejor una Metodología.

Claro, la Metodología, que fácil era. Espera no tan rápido, ¿eso no fue la conclusión que se saco en la crisis del SW de los 70? ¿Pero no tenemos ya un montón? RUP, Merisse, Metrica 3, Extreme Programming, etc. Todas tienen éxitos y fracasos, por tanto hemos vuelto al principio.

Cada año aparecen nuevas metodologías milagro que han conseguido éxitos en proyectos en la India o en China, siempre bien lejos, como Pair Programming, ¡ dos programadores por ordenador¡. ¿Cómo no se me había ocurrido antes? Supongo que porque los ordenadores solo tienen un teclado.

Sin embargo para encontrar el camino es mejor mirar donde se ha acertado y cuando se ha acertado y con que. El sector financiero (Banca y Seguros) históricamente ha sido uno de los sectores más robustos en cuanto a sus sistemas y aplicaciones Sw. La mayoría de ellos aún cuentan con todas sus reglas de negocio y core sw realizados en antiguas tecnologías como cobol y RPG, todo ello construido en los 80, y funciona. Cada vez que intentan migrar o generar nuevos procesos se enfrentan al cara y cruz, por eso prefieren, si pueden, no tocarlo.

Tecnologías obsoletas, con menos medios, e informáticos ya jubilados son los que parece que lo hicieron bien, y ni siquiera Microsoft había inventado el Project.

Evidentemente la tecnología es imparable y ahora sin duda todo es mejor, ¿pero funciona mejor?.

Publicado en Te Interesa. Marzo 2006

Fabricas del Software

2008-03-22T12:22:00.005+01:00

En esta entrada del Blog voy a comentaros mi última adquisición literaria "Fabricas del Software: Experiencias, Tecnologías y Organización" publicado en Diciembre de 2007 por Ra-Ma.

En este punto solo puedo daros unas primeras impresiones, ya que no he podido completar su lectura aún, pero no quería esperar más para daros esa primera visión.

En primer lugar se agradece que alguien se adentre en este mundo y ponga un libro en nuestro idioma en la calle y a disposición de todos. En ese punto solo puedo aplaudir a los autores y a Ra-Ma por darles cobertura.

El libro tiene a mi modo de ver dos partes totalmente diferenciadas:

- La primera que repasa la historia de las “software factories”, tecnologías, modelos de desarrollo, orientación a procesos y calidad.

- Una segunda parte en que nos encontramos con varios casos de estudio sobre fabricas del software existentes en la actualidad, unas con más información que otras, pero en cualquier caso da una medida del mercado.

De momento he atacado algunos capítulos, no creo que sea necesario leerlos en orden, y puedo decir que la visión de resumen y la forma de llevar temas que son pesados a quince o veinte páginas me ha gustado. Además aporta una extensa bibliografía al final de cada capítulo para el que quiera profundizar.

En principio es recomendable para todos los públicos, desde comerciales, directores, jefes de proyecto y programadores con inquietudes..

De momento alabo la idea y el formato, además la existencia de varios autores hace pensar en que cada experto tiene "su tema". Ahora solo me queda esperar que los contenidos también sean buenos.. pero eso lo comentaré más adelante.

Lo podéis adquirir tanto en Ra-Ma como en la Casa del libro.

10 cosas que todo Arquitecto debe saber..

2008-03-04T18:19:00.003+01:00

Como mucha gente sabe una de mis pasiones es la vertiente más tecnológica de la Ingeniería del Software, personificada en el concepto de Arquitectura. Antes de nada os dejo una pequeña reflexión.

Cuando hablo de Concepto Arquitectura pienso, sobre todo, en que cada día se demuestra más la tendencia a que vamos a una ingeniera del software gobernada por la Arquitectura, y sin embargo desde el punto de vista del usuario de negocio, esto tiene que dejar de existir ya. La tecnología debe dejar de ser una barrera, sobre todo en cuanto a su continua evolución, y cada día vemos más empresas manteniendo viejos sistemas, aunque es mejor que migrarlos todos cada poco.. no es la solución.

Para mi cada vez esta más claro que el éxito de las arquitecturas empresariales viene dado por pensar en una clara orientación a servicios (SOA) , (quizás es pronto para orientación a eventos EDA) para acabar llegando a BPM. Donde el usuario de negocio debe ser capaz de definir sus propios procesos de negocio… que si ¡!! que esto es viable, preguntar a BEA.

Tenemos que pensar que no podemos construir un BPM como primer paso, sino empezar a pensar en una estructura de Gobierno SOA sobre la cual vayamos creciendo hasta tener una suficiente estructura de servicios de negocio, que nos permitan montar BPM. Por tanto el modo de llegar es ir dando pasos.. no esperar a empezar los últimos la carrera.

A donde quería llegar, sobre las arquitecturas, es proporcionaros un interesante documento que ha llegado a mis manos, el cual se titula “ 10 cosas que todo arquitecto debe saber” y la verdad es que son ciertamente interesantes:

1. La base esta en las personas.
2. Todas las soluciones llegan a ser obsoletas.
3. Los Datos son para siempre.
4. La flexibilidad genera complejidad.
5. Nada funciona según se esperaba.
6. La documentación es el codigo fuente universal.
7. Conozca el negocio.
8. Mantenga la visión.
9. Los arquitectos deben ser programadores.
10. La experiencia es insustituible.

Sobre cada una existen frases reflexivas, que realmente dan que pensar.

Doy las gracias al autor del mismo Richard Monson-Haefel por sus “10 Things Every Architect Should Know”, que aquí publico, creo que siguiendo correctamente la licencia.

Gestion del Conocimiento

2008-02-26T19:00:00.004+01:00

La noticia, que leo en un blog, es la siguiente “un estudio demuestra que el 60% de los jugadores de la nba están en la ruina 5 años después de retirarse”, el autor de dicho blog pretende explicar que lo importante no es solo ganar o generar ingresos sino también saber administrarlo. Esto me hizo pensar en la forma de trabajo de las SWF respecto a la gestión del conocimiento.

Cuando hoy en día nadie duda que el conocimiento es uno de los grandes valores de la SWF, esta muy claro que existe una gran preocupación por tenerlo. Esta reflexion de las SWF viene motivada por dos razones, mayor capacidad de venta “Si conozco más cosas, tengo más mercado y puedo vender más…” y porque impacta directamente sobre la productividad “ Si tengo equipos bien formados, que conocen la tecnología y las herramientas, produzco más rápido y con más calidad”.. Hasta aquí parece que el sistema es bastante simple.

Ahora la problemática es como adquirir Conocimiento, y en realidad esto también es como la mayoría de las cosas, o soy capaz de producirlo o tengo que comprarlo. Para producirlo hay que tener un gran sistema de sw i+d y formación interno, no solo en cuanto al volumen de conocimiento que puede repartir, sino en cuanto a la capacidad que tiene de adaptarse y formar en lo que demanda un mercado cambiante. Para comprar es necesario tener un buen área de selección, que conozca el paño, para poder adquirir el conocimiento de una manera ágil y eficiente.

Otra cosa es cuando hablamos de Administrar el Conocimiento esto no parece tan sencillo, y a toda SWF le puede pasar como a los jugadores de la nba, hoy somos ricos y mañana estamos en la ruina.. y tenemos que volver a empezar.

Si es un hecho, que es difícil gestionar algo que es totalmente dependiente del capital humano, añadimos personas que se encuentran en sedes o centros de trabajo distribuidos geográficamente, nos damos cuenta que todo lo que ganamos lo perdemos rápidamente, ya que continuamente empezamos de 0.

Habitualmente cuando se detecta este problema se ponen medidas, que casi siempre son las siguientes:

Formación presencial y online. Mantener un catalogo de curso accesible para que cuando alguien necesite.. lo realice. Normalmente los cursos no encajan con las necesidades.

Foro: Poner un foro en la web, en la mayoría esto es un fracaso absoluto, cuando entras se ve que hay mensajes de años sin contestar. Nadie lo lee..

Repositorio documental: Se pone toda la documentación en un macro servidor, pero tampoco se usa porque lo más fácil es ir a Google..

De wikis, faq´s, etc.. ya ni hablo la mayoría fracasan en pocos días..

¿Pero entonces hay que dar la batalla por perdida? Si, no, yo que se.. me explico.

Un sistema de gestión del conocimiento funciona muy bien con ese % pequeño de gente, que les gusta aprender y son proactivos.. pero el resto y gran mayoría no participará sino se lo impone. Y ese grupo de buenos técnicos, lo hará igual.. A veces la empresa (SWF) piensa que con todos los medios que ha puesto, no le debe preocupar que se vaya fulanito o menganito, gran error..

Lo mejor, desde mi punto de vista es, además de gestionar el conocimiento, gestionar el talento y pujar por el económicamente.. No permitir perderlo bajo ningún concepto, ya que con el somos capaces de investigar, formar, administrar la documentación, producir mejor y mucho más.. Por tanto gestionado el talento el conocimiento se administra solo.

Tan lejos y tan cerca..

2008-02-15T08:21:00.005+01:00

Por mucho que hablemos de globalización, y siendo las factorías un mercado proclive a montar proyectos en otros países y externalizar parte de su trabajo (normalmente el de menos coste) cuando lo analizas fríamente parece que no funciona tan bien.

Hoy en día cada vez más se manejan conceptos como NearShore y OffShore, pero como todo el mundo sabe, el Near más caro y de mas calidad, o así se espera, y el Offshore más barato con menos calidad y mayor riesgo por lo general.

Mis experiencias en este modelo son claramente mayores siendo Nearshore pero tambien he tenido algún escarceo Offshore.

Teóricamente se supone que hay dos maneras de externalizar a Offshore:

1) Modo un salto. Pasamos directamente de la parte funcional (entorno cliente) a factoría lejana.. Puede funcionar bien con una factoría sudamericana, evita salto de idioma.. Pero no imagino al cliente gestionando una factoría lejana.. el cliente no entiende de carga, picos, valles, perfiles, etc Aunque pongamos el típico Director de proyecto al lado del cliente..

2) Modelo dos saltos: Pasamos antes por el NearShore y que está factoría filtre la carga que se puede enviar a las factorías lejanas.. Me creo que funciona bien siendo las factorías lejanas de Construcción y PU, y la cercana de Diseño y Pruebas..

Ahora bien, a cuantos realmente le esta funcionando el modelo? Mi experiencia es la siguiente:

Creo que puede funcionar con Sudamérica, Argentina, Chile o Colombia. He tenido experiencias tanto con factorías de Argentina y Colombia, y se cumple perfectamente el patrón "es barato y de calidad media", salvas el idioma pero tienes la pega del horario...

Siempre hay gente que dice que hoy en día el inglés no es problema, ja ja ja, una especificación sobre un USE CASE complejo no la hace cualquiera en inglés.. o un buen DT especificado para llevar fuera.. Que algunos de cada factoría pueden hacerlo, si, ¿pero con ellos podemos generar el suficiente volumen para amortizar el coste de levantar una linea de producción offshore? No lo creo.. y lo que esta claro que solo es rentable si tenemos mucho volumen, en el cual podamos amortizar los sobre costes de refinamiento. Y si hablamos de trabajar con china, pega doble, porque ellos hablan aún menos inglés.. así que vamos listos.

Ahora, en mi factoría, hay posibilidades de montar a lo largo de 2008, una conexión con la India y Brasil con factorías de hasta 30.000 personas. No puedo imaginar como debe ser una factoría de 30.000 personas.. Normal que vendan barato, un valle de carga de un 10% representa 3000 recursos parados.. madre de Dios, como para que no funcione bien la Dirección de Producción.

El problema es que para trabajar en offshore necesitamos (el sector) un mayor número de profesionales mucho más cualificados y mejorar mucho nuestro sistema de Calidad. No veo trabajar en Offshore sin un nivel CMMI 3 asentado, simplemente no es viable, y digo en destino y origen.

¿Si ya tengo problemas para generar carga de calidad para mis propios equipos, como lo genero para equipos externos, que además siguen otros modelos de trabajo?

Y sin embargo, es algo que estoy convencido que es imprescindible para una evolución del sector, en la cual tendremos profesionales cualificados y de primer nivel en España y sacaremos la rodaja de producción gorda fuera, con un coste más que razonable.

Modelos de Software Factory. (segunda parte)

2008-02-13T17:10:00.003+01:00

Continuamos hablando de modelos de SWF, en este segundo articulo. Cuando acabe todos los modelos prometo moontarlos en un documento y refinar lenguaje y forma.. alguno me lo ha comentado..

B. Bodyshopping

Entendemos por BodyShopping la venta de recursos (personas), a un cliente determinado en un proyecto determinado y por un periodo de tiempo.

El cliente especifica el perfil que necesita, dando normalmente como entradas los años de experiencia, la tecnología y/o metodología que requiere. El objetivo del cliente es encargar una serie de tareas a esa persona o grupo de personas y controlar su realización. Otro requisito habitual, cara a poder controlar los recursos contratados es que estas labores se realicen en sus oficinas o sede.

Hasta aquí tenemos el modelo clásico de venta, el cual puede ser aprovechado por la SWF ya que dispone de una cantera importante de recursos a poner en el mercado, pero que cuenta con los siguientes handicap:

Ubicación: Normalmente la SWF no esta en la misma ciudad que el cliente, por tanto no puede competir en igualdad de condiciones, ya que debe trasladar los costes de desplazamiento al cliente. También tiene problemas para contratar recursos en una ciudad que no es la suya (no tiene sede), si quiere abaratar costes.

Lentitud: Es lenta para ubicar recursos en un cliente, necesita convencer al equipo para que se desplace y es lenta para sustituir.

Riesgo de fuga: Salvo que los recursos quieran volver al origen, cambiarán de empresa tan pronto puedan, no tiene sentido pertenecer a una empresa sin sede. Puede que no cambie de empresa sino de área de la compañía, pero al final es una perdida para la SWF.

Si pensamos en el modelo clásico que describíamos anteriormente, también lo podemos encontrar referenciado como un modelo ‘Time and Material”. Indica que lo que se cobra es el tiempo invertido de principio a fin (no se estima a priori) y el material invertido. Si nos dedicáramos a la fontanería sería algo como el tiempo de reparar la fuga más el precio de la tubería, eso con el margen pertinente.

Elementos a valorar para ofertar el Bodyshopping, en modelo clásico:

Duración del contrato: Se recomienda no hacer ofertas por un tiempo inferior a 6 meses, ya que si dura menos los periodos de No Asignación y vacaciones se suelen comer el beneficio.

Posibilidades de Prorroga: Este punto es muy importante, ya que cuanto más prorrogas, más beneficio, por tanto interesan los largos proyectos. También interesa más la Administración Pública que la empresa privada, ya que la primera suele tener asignado presupuesto por todo un periodo y es poco probable que corte el proyecto o contrato.

Capacidad de Renegociación: Las personas con el tiempo querrán mejorar sus condiciones salariales, por tanto debemos tener “ventanas de negociación” con el cliente. Normalmente de manera anual..

Absentismo: Si una persona es propensa a las ausencias, de cualquier tipo, que no sean una baja laboral, ante un cliente al que facturamos por horas, con un margen de benefició de un 20 %, dos ausencias al mes nos lo pueden dejar en un 10 %. Solución, seleccionar personas con bajo absentismo y manejar márgenes de más de un 30 %.

Otro modelo es el Bodyshopping deslocalizado, en el cual el cliente controla sus recursos en remoto.

Este suele ser un modelo de venta que se sigue algunas veces en la SWF, pero realmente implica muchos riesgos. Normalmente se tiende a este modelo porque un cliente esta a trabajar en el mismo e interpreta que trabajar con una SWF implica condiciones similares solo que fuera de su sede y a un precio muy competitivo.
Esto sería realmente maravilloso tanto para el cliente como para la SWF, ya que es un beneficio garantizado, los problemas vienen cuando el cliente tiene unas expectativas mucho más altas en su “equipo remoto” que de lo que este llega a hacer.

El problema fundamental es el siguiente:

Los recursos que trabajan en este modelo para la SWF son recursos asignados full-time de los cuales no se tiene que preocupar que dar carga y por tanto la única preocupación es la de facturar como si estuvieran fuera de la sede.

El cliente espera conseguir grandes resultados porque no es consciente de los problemas y retrasos que tiene su equipo, de los cuales si sería consciente si los tuviera en su sede y asumiría en la misma sin problema.

De repente todos topan con la realidad, el cliente esperaba un producto SWF en un plazo y no lo tiene, y no sabe porque.. piensa que en realidad la SWF no trabaja como debe y se siente engañado.

La SWF cuanta al cliente que los problemas no son suyos, sino de comunicación, de que no tuvieron carga, que los analistas del cliente no se preocuparon de especificar bien etc.. Da igual, ya esta claro que llegados a este punto hay que cambiar de modelo.

¿De quien es el error? De la SWF que pensó que era un modelo muy rentable y que no tenia ningún riesgo, además de beneficiarse del desconocimiento del cliente.
Entonces, ¿se puede emplear el Modelo de BodyShopping con éxito en la SWF? La respuesta es si.

Se puede si explicamos claramente al cliente las condiciones del servicio, se puede si asignamos un responsable que levante bandera si algo no va como debe, se puede sino solo se quiere facturar si no hacer SW y reportar avances y resultados.

El modelo encajaría para pequeños proyectos con pocos recursos y para arranques de proyecto en los cuales no es viable hacer una valoración del mismo a priori, arrancamos que nos paguen un mes del equipo y luego ya veremos cuantos y cuanto tiempo..

Open Source, en Dolares (mejor) ¿para todos?

2008-02-11T20:45:00.000+01:00

Después de leer un nuevo articulo de mis amigos de Piratosa, creo que este articulo refuerza mis pensamientos del gran modelo de negocio que está tras el OS.

Lo único que siento es que esas grandes cifras, no suelen llegar a los programadores que contribuyeron desinteresadamente... y luego nos encontramos con programadores, cobrando lo que cobran.. viendo como alguien se forra con sus donaciones.

Esto es lo que me preocupa, aún así prefiero este modelo que otros, y no he perdido toda la Fe en el mismo.

Dejo un enlace por si alguien quiere continuar estudiando el modelo de negocio del Open Source.. Open Source Business Conference.

Otra cosa, a ojo, me parece que la mayoria de compañias compradas son americanas.. funciona el modelo open en Europa? Tanto a nivel de generación de proyectos interesantes como compras interesantes?? Alguna me dirá que OpenCMS es aleman.. y que no se escribe así..

Si alguien me sabe decir grandes proyectos europeos OpenSOurce que me los diga..

No vale Linux !!! Ese ya lo se.. (aunque minix.. era americano no? y Linus T. lo copió y era mejor la teoria del microkernel de Tanenbaum ) No me meto en ese charco ya que alguin linuxero me betara para siempre.. Es broma.

5 Tecnologías Java

2008-02-11T19:45:00.000+01:00

Tras leer un articulo sobre las 5 tecnologías java, que aprender en 2008. Surge el debate sobre que esta de moda y que realmente aporta. Os dejo opiniones que he recabado..

OSGI. Si está bien, pero verde y en pañales..

JCR. Imprescindible que tu CMS lo tenga... ¿pero para que vale para un proyecto independiente y aislado, sin más pretensiones que distribuir unos contenidos entre sus usuarios? No parece tan impresicindible..

GWT. Está muy bien, parece interesante y puede ser un siguiente paso..quizás complementandolo con algun otro framework.. y JSF?

Groovy. Interesante si no lo sacas de altas, bajas y modificaciones..

Cloud Computing En cuantos proyectos de SWF podemos aplicar esto??? (Ironia).

Como veis desde el punto de vista de la SWF parece que no son tan interesantes, entonces cuales son las 5 tecnologías Java a perseguir dentro de ls SWF? Parece que solo GWT..

y si estas son las las 5 que aprender, no puede ser que 2008 sea un año de parón en la evolución de Java? No hay ninguna tecnología SOA o de ESB, salvo que a OSGI le demos este enfoque, que merezca la pena según este estudio aprender? o es que ya las da por aprendidas? Que al menos en España, seguro que no..