septiembre 29, 2005

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.

septiembre 28, 2005

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.

septiembre 26, 2005

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?

septiembre 23, 2005

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.

septiembre 22, 2005

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.

septiembre 20, 2005

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.

septiembre 19, 2005

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?

septiembre 16, 2005

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.

septiembre 14, 2005

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:

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!

septiembre 13, 2005

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.

septiembre 12, 2005

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.

septiembre 07, 2005

Los casos de uso no son "funciones"

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


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

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

septiembre 06, 2005

Desarrolladores y arquitectos

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


Dos notas aparte:
  • No os perdais en Navegapolis el
    Tomo II del Compendio de la Ingeniería del Software

  • Argumentaciones sobre Usabilidad en Alzado

  • septiembre 01, 2005

    Retomar una aplicación de otros

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


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

    Y ahí te quedas.
    Generalmente se da esta situación de dos maneras: O bien para crear nuevas funcionalidades a un proyecto que ya está funcionando, o bien para terminar un desarrollo en que te incorporas en medio del proyecto (o a solucionar bugs o problemas de eficiencia). En cualquier caso, los primeros días suelen ser intensos, y a veces divertidos!
    • Intenta conocer el dominio de la aplicación a nivel general. Ten una visión general de TODO el dominio, y más en particular de lo que te vaya a tocar trabajar. O sea, que te expliquen un poco el análisis funcional

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

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

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

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

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

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