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.