Por azares del destino, un compañero de despido estaba muy metido en la política. Era parte de un nuevo partido de izquierda, el partido de dignidad nacional (PDN) cuyos postulados tenía mucho sentido. Pero sobre todo era el partido con más corazón: estaba dispuesto a elevar los impuestos para distribuir mejor la riqueza, era fiel precursor de la lucha por la educación pública en todos los sentidos, la salud pública y la ayuda al menos favorecidos. Muchas de sus ideas hicieron eco en todo el país. Proponían eliminar la educación y salud privadas de manera que todos comenzaran con las mismas oportunidades y de que las elevadas sumas que la gente pagaba en las instituciones privadas las absorbiera el gobierno para hacer un mejor uso de ellas.

El auge del partido era grande. La población cada vez empobrecía más y las condiciones de vida en el país se deterioraban. Cuando entré no vi mucho lugar para mí. Sin embargo por alguna razón, tal vez ser de los pocos profesionales, me nombraron candidato a diputado. Fue algo que sucedió muy rápido. No estaba acostumbrado a las reuniones públicas, pero me gustaban. Me gustaba el respeto que la gente me daba. Además en el partido comencé a trabajar como asesor legal….y me pagaban! Me pagaban incluso más que en mi anterior puesto. Afortunadamente pude rodearme de gente con corazón que deseaban un bien para el país, y yo era uno de sus representantes.

Vinieron las elecciones. La tensión comenzó a crecer en mí. Lo gocé. Gracias al interior del país logré quedar como diputado. Mi asombro era mucho: era un representante del pueblo. Tenía un encargo que no sabía que podía tener. Sin tan ni son de repente yo, Inocencio Izquierdo, era diputado. De pronto comencé a tener muchos amigos, y muchas fiestas se hicieron a mi nombre. Yo no cabía de felicidad, pero nunca olvidé la responsabilidad que había caído sobre mí: el de representar a mi pueblo. Y digo que fue una responsabilidad que cayó sobre mí, porque yo no la elegí. Desde ese tiempo me volví creyente del destino.

Y así, comencé mi vida política.

Algunas características importantes que pido de la tecnología de presentación:

• Java. Por ahora me quedo con Java, con sus pros y sus contras.
• Web.
• Open, libre, gratis.
• Que las cosas se vean bonitas, out-of-the-box. No soy bueno con el diseño gráfico, y por ahora no tengo interés en enfocarme en él. Por ello es importante que la tecnología que escoja haga cosas fancy que se vean bonitas.
• Que sea sencillo generar código con él.
• La curva de aprendizaje no ha de ser muy elevada.
• Decente integración con Netbeans y/o eclipse.

Ahora, vamos con cosas puntuales.

• Binding inteligente. Mejor si la unión entre el GUI y el resto pueda hacerse con Beans.
• Tablas inteligentes. TableModel, o equivalente que permita hacer pagineos y búsquedas sobre las columnas. Las tablas son muy importantes para mí.
• Ajax….
• Templates o skins ya definidos, y una manera de personalizar un poco la presentación final.
• La menor cantidad de código goma o de plomero. No soy amigo de XML, pero tampoco enemigo: si se usa de manera inteligente puede ayudar mucho, pero hay frameworks que simplemente se pasan con sus implementaciones en xml.
• Documentación, ejemplos, etc.
• Una comunidad grande. Este es uno de los puntos de mayor peso a mi criterio. Una comunidad de mayor tamaño permite corrección rápida de errores, foros, comentarios, etc.
• Algún soporte comercial, o el patrocinio de una(s) de las grandes empresas de software.
• Una expectativa larga de vida. Importante también. La tecnología que escoja será mi caballo de batalla por los siguientes años. Al menos espero que así sea.
• Cantidad de componentes o widgets. Yo no me voy a poner a diseñar calendarios en js o comboboxes que tengan autocomplete.
• Quiero escribir las cosas una vez. Si el framework me deja “deployar” mis aplicaciones en html, flash, mobile, desktop y demás mejor.

Aparte de las mencionadas hay un “me gusta” que una nueva tecnología debe tener. Ese presentimiento interno de que mi relación con la tecnología a escoger será buena.

Por mucho tiempo mi plataforma de trabajo se basaba en hibernate, para la persistencia de datos, jsf para la presentación, más específicamente richfaces, junit para los tests. Simple pero funcional. En su momento tuve la disyuntiva richfaces-icefaces, pero decidí irme por richfaces porque me gustó más y por el hecho de que JBoss lo soportaba. Estaba comenzando con SEAM cuando tuve que hacer un deploy de un proyecto con richfaces en un weblogic 8 que costó muchísimo, lo que me hizo quererme hacer más independiente del servidor en el que instalo: que corra en tomcat.

Bueno, hoy me entero que jboss comenzó´a pasar su middleware a GWT. En pocas palabras me dijeron que abandonarán eventualmente el proyecto richfaces. Por ahora richfaces me funcionó bien, salvo algunos problemas de compatibilidad de exploradores. Pero adquirí mucho conocimiento al respecto y las cosas funcionaban como quería.

Ahora, lo más sabio es buscar y casarme con una nueva tecnología lo más pronto posible. Lo que me abruma es la cantidad de propuestas que existen. Los llamados RIAs ahora aparecen por todos lados. Cada framework con enfoques muy diferentes y propuestas más diferentes. Pero hay que elegir uno.

Hace unas semanas hice un poco de investigación. Al final creo que los competidores finales son:

• GWT.
• ZK.
• Echo
• OpenLaszlo.
• Flex.
• Appcelerator.
• AdobeAir
• JavaFx
• Wicket
• SmartClient
• SpringMVC
• OpenXava
• ItMill
• Rialto

Estas han sido mis opciones finales, sin embargo la oferta es considerablemente más amplia. Una búsqueda en google o en wikipedia les puede dar más luces. De todos estos frameworks algunos tienen un enfoque más geek, otro más “javero”, otros mas xml, otros más swing, etc. Lo bueno es que hay mucho de donde elegir. Lo malo es, irónico, que hay mucho que elgir.

Un buen comienzo es ser sincero: ¿Para qué existe una empresa de software? Como cualquier empresa, la primera razón es: hacer dinero. Creo que cualquier empresa que olvide ese principio llegará a tener problemas de subsistencia. No es ser materialista, ni mucho menos, pero al final de los cantares, o como la llamaría Aristóteles, la causa final de una empresa de software es hacer dinero.  Y, siguiendo con Aristóteles, la causa material sería el software.

Un libro que recomiendo es On The Business of Software de Erick Sink. Muchas de las ideas que presentaré vienen del libro, que también tendrá su post especial….cuando tenga tiempo.

Pero siguiendo con el punto. Así como un martillo existe para martillar, una bicicleta para moverse, una guitarra para tocarla, del mismo modo una empresa existe para hacer dinero. Entonces una empresa de software existe para hacer dinero a través del software que hace.

Tipos o divisiones en las empresas de software hay muchos. Hay empresas que se dedican a hacer sistemas operativos, otras a hacer bases de datos, otras a hacer ERPs, otras para hacer páginas web, otras para integrar distintos sistemas, otras para software bancario, otras de telecomunicaciones, otras para restaurantes, otras hacen software a la medida y un gran etc.

Resumiendo, una empresa de software es una organización dedicada a hacer dinero a través de software. El siguiente punto que se debe definir es ¿qué tipo de software hará la compañía?

En el blog hablaré de mi proyecto, con las restricciones y oportunidades que tengo (el famoso FODA). ¿Haciendo qué tipo de software podré hacer negocio? Para ser realistas por el momento han de desecharse las “grandes ligas”. Es irreal suponer, diseñar y demás, una empresa que se dedique a hacer sistemas operativos, o una competencia a MS Office, a SAP, a Oracle o alguno parecido. No digo que no se pueda, lo que digo es que una empresa pequeña NO debe empezar por ahí.

¿Entonces en donde empezar? Bueno, hay nichos, muchos nichos. Hay que elegir un nicho que sea lo suficientemente pequeño que no interese a los grandes, pero que sea lo suficientemente grande para crear ganancias. Creo que una empresa pequeña será generalmente una evolución de consultorías pequeñas o medianas de software hecho a la medida. Este creo que es un buen punto de partida. Por ello hay que elegir cuidadosamente los proyectos en los que un consultor que desea crear una empresa de software se mete.

A la fecha no sé en que nicho de mercado deseo meterme, pero ya les estaré comunicando cuál. También creo que es importante definir un proyecto e intentar separarse un poco del software a la medida ¿por qué? Porque el retorno de un producto que se vende muchas veces es muchas veces mayor que estar haciendo software a la medida.

En conclusión: una empresa de software pequeña es una organización que se dedica a ganar dinero a través de pequeños proyectos de software, consolidando uno o varios productos de los que puede obtener ganancias en un mercado en el que puede competir.

Claro, esto es una simplificación. Una empresa de software, como cualquier otra empresa, tiene mucho conocimiento, muchos trucos, mucha experiencia que debe adquirir y cultivar. No es sencillo funda una empresa próspera de software: hay muchos riesgos que hay que saber identificar y manejar. Hay metodologías técnicas y administrativas que se tienen que adquirir y refinar. El software es una ciencia-arte y para que una empresa que hace algo así es necesario que se componga de artistas-científicos que la hagan funcionar.

Luis H. Fernandez
luishernan@gmail.com

El término calidad siempre me ha parecido ambiguo. ¿Que hace que un bien o servicio “posea” calidad? No sé. Hay procesos de calidad, chequeos de calidad, y mil cosas con calidad, pero nadie entiende a ciencia cierta qué es calidad, aunque todos comprenden el término. Aunque para algunos es aquel software que no tiene bugs, para otros el que satisface al cliente, para otros es el que optimiza recursos, para otros el que se mira bonito, etc.

Cuando el término entra al contexto del software, la cosa se pone peor. ¿Qué hace que un software sea uno de calidad o no? Claro, debido a lo ambiguo del término, la discusión en este tema no tendrá fin.

Con todo, lo que hacemos es software, y nos gustaría hacer siempre software de calidad. Para poder etiquetar a un software como uno de calidad, debemos definir algunos atributos para poder poner el software en evaluación. Estos atributos, y sus prioridades, cambian cuando cambia el contexto de software: un sistema para hospitales se juzga de una manera distinta a una página web.

En FFSE R. Glass propone siete atributos del software que le confieren lo que llamamos calidad:
+Portabilidad: la portabilidad implica que un programa puede correr en distintas plataformas, no sólo de sistemas operativos sino diferentes versiones, diferentes ambientes y esquemas.
+Fiabilidad o confiabilidad: el software hace lo que debería hacer, y no “truena”.
+Eficiencia: que tanto recursos economiza en tiempo y espacio el software.
+Facilidad de uso: es fácil de usar?
+Evaluable: Es sencillo de examinar? Se le pueden correr fácilmente unit tests?
+Leíble: Es el código expresivo y fácil de comprender?
+Mofificable: Qué tan sencillo es modificar el software.
+Escalibilidad: pueden agregarse funciones de manera rápida y consistente?

Buscando en internet, encontré otros atributos que vale la pena mencionar:

+Compatibilidad: es el software amigable con otros sistemas?
+Seguridad: es el software seguro contra ataques externos?

Todos concordarán que los atributos anteriores son buenos parámetros para medir la calidad de un producto de software. Sin embargo el orden de estos productos varían de proyecto a proyecto. Un proyecto que maneja información confidencial puede que tenga la seguridad muy alta, una página de internet tendrá muy alta la facilidad de uso, un software bancario tomará más en cuenta la fiabilidad que la portabilidad.

El usuario y el código

Al usuario final le viene del norte en qué tecnología corre un programa, o que metodología de desarrollo se utilizó para su creación. Poco le importa si se utilizó un lenguaje de cuarta generación o assembler. El usuario toma por sentado ciertos estándares y cierta funcionalidad. Por ejemplo un usuario espera siempre que en el lugar que aparezca un disquete se grabe su trabajo. Si esto no funciona bien, el usuario tendrá una muy mala percepción del software, y por tanto el software no tendrá mucha calidad.

El otro lado de la moneda es la calidad del código. ¿Es sencillo de encontrar errores? ¿Hay un buen uso del modelo de programación? ¿Se optimiza el uso del hardware? Aquí cada quien tiene un criterio diferente, hay filosofías, metodologías, paradigmas y demás.

Glass expone algo que me llamó mucho la atención: la satisfacción del cliente no es lo mismo que calidad de software. Entre los elementos que evalúa el cliente están cosas como el precio del producto, el diseño, el tiempo de entrega, el soporte y otros. Un mal software puede tener una alta satisfacción (aunque poco probable), y un buen software puede ser mal valuado por el usuario (créanme, sucede). Entonces la política de calidad de la empresa en general es distinta a la política de calidad del software en sí. Pese a muchas opiniones, el software es el código y nada más. Otras cosas le van unidas, pero no son software.

En Pragmatic Programme Hunt y Thomas exponen un punto importante: software lo suficientemente bueno. En ocasiones, especialmente cuando no hay restricciones de calendario, el desarrollador quiere siempre mejorar su software. Irónicamemte un software puede ser siempre mejorado. Hay que aprender cuando un software es lo suficientemnete bueno, porque agregarle funcionalidad o mejoras puede ser hasta contraproducente si no se sabe donde parar. Al final esto es ingeniería de software, y como todas las ingenierías nuestro objetivo es calcular. Si voy a comprar alambre para cercas las plantas de mi casa puedo calcular la circunferencia usando 3 en vez de pi, si voy calcular los materiales necesarios para un edificio redondo seguramente usaré 3.14159 o tal vez más dígitos, y si estoy calculando la órbita de una nave espacial definitivamente usaré más decimales. Hay que saber cual me conviene más. Lo mismo en el software.

Existe un ISO, el 9126 que se dedica a la calidad de software tiene puntos muy interesantes. Especialmente me gustó la división que hacen para medir la calidad: la calidad del modelo, la calidad de la métrica externa, la de la métrica interna y la calidad en el uso de las métricas. Está también CMMI que se dedica a la calidad estandarizar la calidad del software y la calidad del proceso productivo de éste.

En fin la calidad de software es algo que radica entre lo objetivo y lo subjetivo. Hay mucha leña por ahí para partir, porque el universo del software es también dinámico y los parámetros también cambian. Cada equipo de trabajo tiene sus propios parámetros. Lo que quiero recalcar es que cada equipo debe definir cuales son sus parámetros para medir la calidad de su software. Luego modelar, diseñar, implementar y mantener el software apegado a esos claves. En cada proyecto el orden de prioridades cambian también y hay que tenerlo presente, porque al final de los cantares lo que queremos es que nuestro software funcione, le guste al usuario y se acerque lo más ppsible a hacer lo que tiene que hacer.

Luis H. Fernandez
luishernan@gmail.com

Algunos links.

http://synergix.wordpress.com/2008/07/02/modelo-de-calidad-tradicional-del-software/
http://blog.xebia.com/2008/11/05/what-exactly-is-software-quality/
http://en.wikipedia.org/wiki/Software_quality
http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.PDF
http://en.wikipedia.org/wiki/ISO_9126
http://www.bth.se/tek/besq.nsf/(WebFiles)/CF1C3230DB425EDCC125706900317C44/$FILE/chapter_1.pdf

Hay un nuevo proyecto que deseo comenzar. Es sumamente agradable poder elegir la tecnología a usar, pero a la vez puede causar un gran dolor de cabeza debido a la gran, inmensa, gigantesca, cantidad de opciones que se abren. ¿Qué tecnología uso? ¿Web o no web? ¿Java, C++ o .net? ¿Qué DBMS?

Cuando un cliente pone las reglas, el rango de acción disminuye: nosotros trabajamos IIS en Windows, o nosotros MySQL en Linux, con PHP, o nosotros una opción barata de hosting, y un gran etc. Pero cuando pensamos en desarrollar un nuevo producto ¿qué tecnología usar?

En principio, debido a mi experiencia anterior y mi área de conocimiento, siempre tiendo a ver todas las soluciones bajo la lupa  web. Creo que en un futuro no muy lejano las aplicaciones de desktop irán desapareciendo. Hace más de diez años teníamos ya los applets, y es irónico como las nuevas tecnologías comienzan a tener ese punto de vista.

Hay aplicaciones que son de naturaleza web, y tendrían poco sentido hacerlas desktop, por ejemplo las redes sociales, buscadores, sitios de noticias, etc. Hay aplicaciones que son de naturaleza desktop y que no tendría sentido volverlas web: compiladores, aplicaciones de oficinas, IDEs, etc. Sin embargo las cosas han cambiado y muchas de estas aplicaciones están migrando al mundo web. Hay una intersección cada vez mayor entre las aplicaciones web y las desktop.

Web o desktop. La mayor parte de aplicaciones empresariales (tema para otro post) pueden perfectamente ser desarrolladas en ambas tecnologías, con las ventajas y desventajas de cada una. A mi opinión la decisión en cuánto al enfoque que se debe tomar depende de dos cosas: costo y tiempo.

Creo que una aplicación desarrollada bajo el paradigma web o bajo el paradigma de escritorio debería poder ser compilada o “deployada” en cualquiera de los dos contextos. Todavía no he encontrado muy asentado este concepto pero creo que debería comenzar a predominar. Pero el mundo no es color de rosa, y las cosas no funcionan así.

Hay ya muchos frameworks que permiten programar aplicaciones web como si fueran de escritorio (Wicket por ejemplo), pero todavía están un poco verdes en su desarrollo. Cada aplicación tiene un contexto definido y unas restricciones que deben respetar, pero considero que es mejor idea hacer las aplicaciones web, aunque al decirlo todavía hay algo que siento no me deja aconsejarlo tranquilamente.

Ventajas de web.
+Multiplataforma para el cliente.
+No hay necesidad de actualizaciones.
+Centralizado.

Ventajas de escritorio.
+El usuario está más acostumbrado.
+No se necesita un server.
+Aplicaciones muy pesadas deben correr en el cliente.

Luis H. Fernandez
luishernan@gmail.com

De las buenas prácticas de desarrollo de software que quiero sacar a discusión, comenzaré con el manejo de fuentes. Sorprendentemente el manejo de fuentes y de versiones no se toma tan en serio como debería. Muchas veces he estado en proyectos, o los he visto, en los que muchos, muchísimos problemas surgen debido a espaguetis de código mal unidos, versiones que se creían diferentes, trabajo que se pierde.

Sobre la teoría del manejo de versiones se ha hablado mucho ya. No es algo sencillo en lo más mínimo, a mí me sigue asombrando lo eficientes que SVN o CVS son a pesar de lo complejo de su funcionamiento. Muchos buenos manuales existen para aprender a usar SVN o CVS. Yo en general me iría con alguno de ellos dos, aunque a la gente del entorno MS le podría servir más aprender sourcesafe.

Independientemente, mi punto es el siguiente: SIEMPRE hay que usar algún manejador de versiones. Es la primera cosa que un proyecto serio requiere. Es algo que ni siquiera debe ser apuntado, sino que siempre entendido que habrá un manejo de versiones.

¿Por qué? En lo personal las siguientes razones son los motivos por los qué uso un manejador de veriones.
+Backup. Son una manera muy sencilla para hacer copias de respaldo. Aunque sea una diaria.
+Cambios. Cuando quiero hacer un cambio peligroso, me quita el miedo de pasarme llevando algo por delante. Si eso pasara, simplemente vuelvo a una versión anterior.
+Manejo de versiones en sí. Un cliente quiere unas cosas, el otro otras, pero la base es la misma. Puedo mantener las fuentes exactas de cada instalación, añadir nuevas cosas y luego unirlas. Es una maravilla.
+Trabajo en equipo. El manejo de una manejador de versiones facilita enormemente el trabajo en equipo. Al final del día siempre hay una versión, igual para todos, y los cambios de cada uno los ve el otro. OJO un error común es es tratar al manejador como el que solucionará todos los problemas y no es cierto. La comunicación entre el equipo es siempre vital.
+Es sencillo. Cualquier IDE te permite importar tus fuentes a un repositorio y trabajar a partir de él sin mucho trabajo, incluso si estás comenzando a usar una manejador.

En resumen, en cualquier proyecto lo primero que deben hacer SIEMPRE es utilizar una manejador de versiones. Mis consejos son utlizar SVN o CVS, son sencillos, son libres, la mayoría de IDEs tiene extensiones para ellos y sobre todo les van a hacer la vida más sencilla.

Luis H. Fernández
luishernan@gmail.com

De hecho creo que la comunidad Java debía proponer un JSR pronto para la organización de proyectos en los IDEs, de tal manera que al crear un proyecto en netbeans, lo pueda abrir en eclipse, intelliJ, JDeveloper, o cualquier otro que se ponga enfrente, creo que sería de mucha utlidad.

luishernan@gmail.com

Y no sólo las palabras claves se escriben en inglés. Los foros, las comunidades se construyen en inglés. Las documentaciones y los bugs, todo se hace en inglés. Cuando nos topamos con algún problema extraño, llegaremos con foros en los que muchas veces ninguno de los participantes habla inglés como lengua materna, pero todos hablan inglés para intercomunicarse. Me causa gracia cuando en un foro me comunico con personas de Irlanda, India, Brasil, Rumania, México, Alemania, Rusia y etc. Me asobmra que todos nos podamos comunicar. De no existir el inglés simplemente no habría un medio de comunicación. Cuando busco un software nuevo, o alguna herramienta por ahí, espero que la página esté en inglés. Incluso cuando la página tiene una versión española, prefiero batirme con la que está escrita en la lengua de shakespeare. Sin duda el inglés permite la existencia y el crecimiento de una comunidad muy grande de desarrolladores.

Pero hablar español nos cuesta plata. Hacer programas en español nos cuesta más plata y tiempo que hacerlos en inglés. Usar ñ,á,é,í,ó,ú,ü,¿,¡ y alguno que otro por ahí es sumamente caro. Nuestro idioma tiene poco o ninguna influencia en el mundo del software. Tanto así que la misma palabra “software” la tuvimos que traer del inglés tal y como estaba. Sí, el inglés nos ayuda a aprender, pero nuestras aplicaciones las escribimos en español. Y eso no siempre es tan sencillo como parece.  Muchos de los que leen estas letras sin duda han tenido más de alguna rabieta cuando ven que en su software aparecen í,á�,é,à y otro buen montón de simbolitos raros. O cuando uno tiene que hacer maravillas para hacer que funcione una base de datos con encoding latin-1, un server con ISO-8859-1 y una aplicación con UTF-8. Alguien, con un toque de sátira, dijo una vez “lo bueno de los estándares es que hay muchos”. Más de alguno se ha puesto a llorar cuando hace un pequeño cambio y ve que cambia al charset que. Todos estamos acostumbrados a términos de charset, asdfasd, asdfasd.

En lo personal intento tratar de usar siempre UTF8, pero no siempre es posible debido a que en ocasiones no tengo el control sobre la plataforma en la que instalaré. Este es el primer post sobre el español y el inglés que haré. Hay muchos libros y muchos lugares en los que se puede obtener información sobre como hacer mejor software, pero esos siempre son en inglés (ironías), así que pienso comenzar la discusión para aquellos que hablamos español….¿cómo podemos mejorar el software en español? Lo gracioso es que siempre estaremos escribiendo aplicaciones en español definiéndolas en inglés.

]]> http://software.guisho.com/archives/7/feed/ http://software.guisho.com/archives/3 http://software.guisho.com/archives/3#comments Wed, 19 Nov 2008 17:39:41 +0000 admin http://software.guisho.com/?p=3 Abro este espacio para lograr un poco de discusión y para exponer mis ideas sobre el desarrollo de software. Si estás leyendo estas letras es porque te gusta programar, porque de otra manera no te interesa mucho lo que diré.

Creo que el desarrollo de software sufre un estancamiento severo. Hemos desarrollado nuevas e interesantes técnicas, modelos de manejo de datos, metodologías de desarrollo, y un sin fin de formas para hacer las cosas. La nuestra es una tarea altamente intelectual y hemos estado viendo como hacernos la vida más sencilla.

Sin embargo los tiempos y costos de desarrollo permanecen iguales, sino es que han crecido más. El estallido de GUIs con mucho entorno gráfico han añadido dificultad a nuestra tarea. El desarrollo en web se ha tornado altamente dominante, y los usuarios esperan webs bonitas, pero a nosotros, por lo general, no nos gusta hacer cosas bonitas, nos gusta hacer cosas que funcionen. Han aparecido los diseñadores gráficos, cosa que no es mala en sí, pero no han aparecido formas de lograr una simbiosis entre programadores y diseñadores gráficos.

Todos aprendemos nuevas tecnologías y frameworks constantemente. Aparecen, y queremos usarlos. Algunas de estas ideas fructifican y se convierten en estándares de facto. Muchas otras crean un gran alboroto pero terminan quedando en lo que algunos llaman shelfware, es decir en la librera guardados y considerados como ideas interesantes pero que no aplican.

Finalmente, creo que el software es una gran oportunidad de desarrollo para Latinoamérica. La inversión en software es relativamente pequeña: una computadora y alguien que sepa usarla. No se precisan de multimilonarias fábricas ni materias primas. Necesitamos personas educadas que sepan manejar y crear y software. Siempre me he preguntado: ¿por qué de los miles de frameworks que aparecen, hay tan pocos latinoamericanos? Y cuando de casualidad me encuentro con uno de origen latinoamericano, generalmente es brasileño. Este blog tambien quiero que sea una invitación, que lance una espinita, para que desarrolladores hispanos nos pongamos las pilas y creemos. Tenemos la capacidad, aunque nos hemos dormido.

Así que bienvenidos, ojalá aparezca pronto la crítica y las ideas. El nuestro es un mundo precioso, así que démosle un toque con ñ.