Narciso Cerezo: Software

Estamos en la home de SourceForge

Narciso Cerezo — 2008-01-23T20:36:00+01:00

Genial! El equipo de SourceForge ha elegido la noticia de la publicación de OpenBaseMovil 3.0 como destacada para aparecer en la portada de SourceForge.
Es algo efímero, pero genial.
Por supuesto, hay pantallazo para la posteridad.

OpenBaseMovil 3.0 reflexiones sobre open source

Narciso Cerezo — 2008-01-23T13:08:00+01:00

Hoy hemos liberado la versión 3.0 (estable) de OpenBaseMovil.
Como ya dije, OpenBaseMovil es el resultado de abrir el 90% del código de nuestro proyecto BaseMovil para crear aplicaciones móviles de calidad empresarial con Java Micro Edition (J2ME).
Con esta versión hemos publicado una guía de comienzo rápido, una plantilla de aplicación y una aplicación de ejemplo (que se puede descargar al móvil desde la página de OpenBaseMovil).
La aplicación de ejemplo es sencilla, no muy original, pero si útil y cumple muy bien la misión de mostrar cómo de sencillo y rápido es crear una aplicación con OpenBaseMovil.
Como muestra compararemos PasswordKeeper (nuestra aplicación de ejemplo) con KeePass for J2ME, que hace básicamente lo mismo:

	PasswordKeeper	KeePass for J2ME
número de ficheros	20 (5)	71
tamaño en Kb	94	237
número de líneas de código	2326 (500)	6835

De los ficheros de PasswordKeeper sólo 5 son de código, y el 80% de las líneas corresponden a la plantilla de aplicación, así que realmente se queda en unas 500 líneas frente a 6835.

En cuanto a las reflexiones sobre el Open Source he de decir que no podemos estar más contentos, debimos hacerlo mucho antes.
El proyecto está subiendo cada vez más en descargas y en ranking, las visitas a la web del proyecto van cada vez también más arriba, así como todos los factores importantes (páginas vistas, media de páginas vistas por visita, abandonos, tiempo en el sitio, etc).
Hay ciertos datos curiosos sobre las visitas y la participación de la gente en comentarios de la página.
Tenemos visitas de 88 paises diferentes (algunos que ni sabía que existían), y si atendemos al número de visitantes el ranking es el siguiente:
1. India
2. Spain
3. Germany
4. China
5. Indonesia
6. United States
7. Russia
8. United Kingdom
9. Vietnam
10. Italy
Alemania ha subido ultimamente, antes China estaba por encima.
Está claro que la India y China son los dos mercados más grandes del mundo por habitantes, y también ocurre que son paises relativamente pobres en los que el acceso a un ordenador es más complicado que el acceso a un teléfono, como ocurre en muchos países de África.
Llama la atención Indonesia y Vietnam, sobre este último país he de decir que hace poco en una reunión me contaba Jose Luis Marina que habían estado allí en un evento de open source y que hay un nivel impresionante.
No obstante, no sólo de visitas vive la web, hay que tener en cuenta otros factores importantes, como el tiempo que pasan en la web.
En este caso el ranking queda de otra manera muy diferente:
1. Switzerland
2. Germany
3. Hong Kong
4. Portugal
5. Guatemala
6. Palestinian Territory
7. Kuwait
8. Chile
9. Latvia
10. Peru
Aunque restringinedo al "top ten" de visitas quedaría:
1. Germany (21)
2. China (5)
3. Vietnam (4)
4. Spain (3)
5. United States (3)
6. Italy (3)
7. Russia (2)
8. India (1)
9. United Kingdom (1)
10. Indonesia (<1)
La diferencia entre Alemania y el resto es apabullante.
Esto la verdad es que tiene su reflejo en la participación en la web, son mayoritariamente alemanes y chinos quienes nos preguntan y nos felicitan.

Veremos como evolucionan ahora las visitas una vez que la plataforma está completa para su uso y con todas las herramientas posibles.
Iremos añadiendo secciones (FAQ, por ejemplo) a medida que nos vayan llegando las consultas.

Un dato interesante también es que a raíz de publicar OpenBaseMovil (antes de tener la versión 3.0 RC1) nos han surgido muchos contactos interesantes, de compañías grandes incluso, aunque en general de fuera de nuestras fronteras.
Aunque es cierto que también van subiendo las visitas a nuestra página principal gracias al proyecto OpenBaseMovil.

Ahora nos queda por ver como evoluciona tanto como "herramienta de marketing" como proyecto y posible generador de ingresos.

¿Qué opinas? ¿Te llama la atención alguno de los datos?

OpenSource

Narciso Cerezo — 2008-01-08T15:19:00+01:00

Como hace tiempo que no escribo, seguro que hay muchos que aún no saben que hemos liberado parte de nuestra plataforma con el nombre OpenBaseMovil.
El proyecto está alojado en SourceForge, y bastante bien posicionado ya tanto en SourceForge como en buscadores, sin haber hecho realmente un esfuerzo en este sentido.
Y a pesar de ello, está siendo una de las acciones más rentables que hemos hecho. Lástima no haberlo hecho antes.
Por lo pronto, y aunque todo lo estamos publicando en inglés, nada más ponerlo en marcha la gente de Xataka Movil se hizo eco, lo cual nos trajo bastantes visitas nacionales, incluso algún que otro lead.
Una vez que pongamos todo el código descargable, con sus manuales completos, ejemplos de aplicaciones, etc, espero que aún tire mucho más, pero no nos podemos quejar.
He de decir que nos ha dado mucha visibilidad, sobre todo internacional.
Hay cosas muy curiosas que se ven con las estadísticas de la web, aunque la que me llama más la atención es cómo las visitas han ido cambiando su procedencia geográfica y siguen evolucionando. España ahora no es el primer lugar, sino que lo són India y China, y también en gran medida Rusia, Estados Unidos y Alemania.
Algo importante sobre la plataforma es lo que viene detraś, en cuanto tengamos todo publicado: OpenMidsets.
Ya he hablado de ello antes aunque brevemente, pero se trata de una aplicación que será portada a todos los sistemas móviles posibles y que abstraerá al desarrollador de aplicaciones. Se podría decir que es parecido a Nokia Widgets, pero en realidad es mucho más potente y ambicioso. Por lo pronto, pretentedemos portarlo de J2ME a BlackBerry y Android, y también a versiones específicas para Symbian y WindowsMobile, aunque todo eso llevará más tiempo.
En la web de OpenBaseMovil hay una presentación que dimos en OpenMovilForum, en la que hablamos más de todo esto para el que tenga interés.
Lo que si he de decir es que hemos recibido feedback muy interesante de desarrolladores de lugares muy diferentes, incluso de grandes compañías, interesados en nuestro software y a los que les ha parecido muy buena la estrategia que hemos pensado para este movimiento Open Source.
Esto, como los premios, de momento no da ingresos directos, es lo que tiene el código abierto. Sin embargo, al contrario que los premios, si que nos está trayendo de forma indirecta ingresos y publicidad gratuita.
¿Dónde terminará? No lo se, francamente, pero hay muchas cosas que me han sorprendido gratamente en esta actuación. Igual de aquí a poco tiempo puedo dar algunos datos más.
Lo que si que sería interesante es empezar a tener gente que quiera hacer OpenMidsets en cuanto tengamos la primera beta. A mi se me han ocurrido unas cuantas aplicaciones interesantes que hacer a modo de ejemplo con OpenMidsets, pero seguro que a todos los que estáis ahí se os ocurren muchas más.
Si alguien se anima a colaborar, no tiene más que decirlo.

Recursos limitados

Narciso Cerezo — 2005-09-27T10:15:00+01:00

Hace unos días, mi amigo Sergio de Knowgate me envió un enlace hacia una especie de caricatura en flash para nostálgicos. Como bien decía el, casi se me caen las lágrimas al recordar aquellos míticos "Manic Minner", "Underworld", "Enduro Racer" y otros muchos juegos realmente impresionantes que funcionaban en un pequeño Sinclair Spectrum con 16Kb de RAM y 3,77MHz, parece mentira.
Creo que somos unos cuantos los que aprendimos en aquella época, primero con basic, luego con ensamblador del Zilog Z-80.
Lo cierto es que ahora ando muy liado con un nuevo proyecto muy interesante basado en J2ME, la plataforma de Java para dispositivos móviles, realmente muy limitados con respecto a los ordenadores a los que estamos acostumbrados. No obstante, siguen siendo mucho más que aquellos spectrum, ya que es habitual contar con 512Kb de RAM y la velocidad de proceso suele ser más que esos 3,77MHz.
En cierto modo, es como volver a aquella época, porque hay que hacer las cosas poniendo un énfasis especial en el ahorro de memoria y de ciclos de CPU, algo que aprendí muy bien con el Z-80. El truco de hacer XOR A,A en vez de LD A,0 le gustó mucho a mi profesora de Fundamentos del Material Informático :-p.
Además, hay que hacer cantidad de cosas desde cero porque el sistema no da para más. Por ejemplo, para almacenar datos se tienen unas "cosas" que se llaman RecordStore y que son una especie de tabla de base de datos muy rudimentaria. Lo único que te da es poder crear registros con un autonumérico que gestiona el sistema y cuyos datos son un bloque de bytes, en crudo, tu te las apañas para guardar y leer la información. Sobre esto, he realizado un sistema de base de datos más o menos complejo. Tiene índices que permiten buscar la información muy rápidamente, campos como en una tabla normal de un sistema SQL, se puede filtrar, ordenar, etc. Pero lo mejor de todo es que lleva incorporado un sistema de sincronización contra un servidor central, de forma que es capaz de detectar los cambios en el servidor y bajarlos al dispositivo y al contrario, enviar los cambios producidos en el dispositivo hacia el servidor.

Bueno, a ver si saco un ratito y escribo un poco sobre un tema que salió hace una o dos semanas en el blog de Enrique Dans sobre temas de recursos humanos, en concreto sobre el horario de trabajo y las recompensas. Es un tema que me enciende debido a las experiencias pasadas.

Hasta entonces.

Fedora Core 4, SELinux vs. Java, Apache, Jboss

Narciso Cerezo — 2005-08-12T09:34:00+01:00

Recientemente he actualizado mi equipo, de Fedora Core 3 a Fedora Core 4. Ciertamente el salto ha sido mayor que en ediciones anteriores. El look and feel está más conseguido; detecta, monta y crea enlaces temporales en el escritorio para cualquier dispositivo removible (CD/DVD, USB disk, etc); tiene algo muy util pero que requiere una muy buena tarjeta gráfica: transparencia para ventanas en segundo plano. Esto último está muy bien porque elimina esa sensación de escritorio lleno. También tiene soporte para bluetooth integrado y otras cuantas cosas más que hacen ver como se acerca más a Window$.
Pero no todo iban a ser alegrías, de hecho me ha traído loco con ciertas cosas, casi todas de la mano de SELinux. La verdad es que me fijé que en versiones anteriores ya estaba SELinux, pero por defecto venía desactivado y nunca le presté mucha atención. Ahora en cambio, SELinux viene activado por defecto, lo cual implica una serie de restricciones importantes de seguridad para el sistema de ficheros y las comunicaciones. Que no es que estén mal, porque de hecho es buena la seguridad, pero hasta que no aprenda mejor como usarlo lo he desactivado.
Así que por si a alguno le pasan cosas como estas, ahí va la lista de "incidentes":

Si traes una copia de seguridad de ficheros (hecha con tar, por ejemplo) desde un equipo con SELinux desactivado (como mi instalación con Fedora Core 3), al desempaquetarlo no tiene los descriptores de SELinux correctos, por lo que hay que reaplicarselos o bien hacer el "truco" (copiar a otro directorio, borrar y mover desde el directorio copiado, ya que al copiar son ficheros nuevos y se les dan los atributos correctos). Cosas que pueden ocurrir si no lo haces es que en el caso de que los ficheros sean los de una web, como era mi caso, Apache te dirá todo el rato que 403 Forbidden, por más que los permisos y grupos parezcan correctos.
Si tienes un Tomcat/JBoss y quieres conectarlo con Apache usando mod_jk o mod_jk2, el mod_jk se quejará hagas lo que hagas diciendo que
[jk_ajp_common.c (1477)]: Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=ajp13 failed errno = 13
Para esto lo único que me ha funcionado es desactivar SELinux o ponerlo en modo permisivo, al menos de momento.
Aunque lo cierto es que no uso mucho el Window$, lo tengo instalado para esas pocas ocasiones, total hay que aprovechar la licencia que venía con el portátil. Así que tengo el disco con una partición NTFS para Window$, una FAT32 para compartir datos entre ambos sistemas, y luego las particiones Linux. Pues bien, para ahorrar espacio, en lugar de tener una partición para swap en linux y el dichoso fichero de intercambio de Window$, lo que hago es poner el fichero de intercambio de en la partición FAT32 y desde linux usarlo como swap, así sólo pierdo 2Gb de disco en vez de 4Gb (tengo 1Gb de RAM). Con Fedora 3 no había problema alguno, pero con este me salta todo el rato con "permission denied" al hacer el swapon.

Bueno, la verdad es que tuve otro incidente más, este mucho más suerrealista y difícil de encontrar, gracias a Internet al final pude solucionarlo. Es una conjunción curiosa que ocurre con Fedora Core 4 y JDK 1.4. Fedora 4 usa IPv6 junto a IPv4, y resulta que JDK 1.4 por defecto usa IPv6 si está disponible, lo cual resulta en una imposibilidad casi total de conseguir conectar desde java a cualquier servicio de red. Para solucionarlo, pues si puedes usar JDK 1.5 mejor, pero si no, tienes que ejecutar el comando java pasando una constante que hace que use IPv4: -Djava.net.preferIPv4Stack=true.
Bueno, espero que si alguien topa con estos problemas esto le sirva de ayuda. Cuando aprenda a usar SELinux ya contaré la solución ¿o se anima alguien a iluminarnos?
Como última pincelada, os diré como deshabilitar SELinux: para hacerlo temporalmente podemos usar el comando setenforce permissive, siempre como usuario root; para hacerlo permanentemente debemos editar el fichero /etc/selinux/config y donde pone SELINUX=enforce ponemos SELINUX=permissive.
Gracias a Technorati he encontrado algo que puede servir, habrá que probarlo un poco más adelante.

Technorati: Fedora, SELinux, Java, JDK, JBoss, Tomcat, mod_jk

Contenedores Ligeros y Arquitecturas de Plugins: Inyección de Dependencias y Localizadores de Serv

Narciso Cerezo — 2004-06-26T00:45:00+01:00

Durante muchos años he ido de un proyecto con tecnologías Microsoft a otro en entornos Java/Unix, jugando en ambos campos casi simultáneamente. De hecho, la compañía en la que pasé la mayor parte de esos años (Digital / Compaq) me certificó nada mas empezar como MCSE + Internet, así que estaba algo más atraido por el entorno Microsoft.
Sin embargo, debo admitir que entonces Java y J2EE presentaban una aproximación más atractiva hacia las soluciones orientadas a objetos, tanto desde el desarrollo como desde la arquitectura. Durante los últimos tres años he estado muy centrado en este enotrono Java y J2EE, adquiriendo un buen nivel de conocimientos, pero dejando atrás las soluciones .NET que surgieron justo al principio de este periodo.
En estos últimos meses he estado jugando con .NET, básicamente aprendiendo C# que creo que es el mejor de los lenguajes en .NET para desarrollo orientado a objetos. C# tiene toda la facilidad que antes sólo tenía VB, pero con una verdadera orientación a objetos nativa.
Creo que desde hace algún tiempo C# se está llevando a bastantes desarrolladores Java a su propia arena, y muchos de ellos tratan de llevar a .NET las soluciones que se han desarrollado en Java durante todos estos años. Esto ocurre con muchas soluciones Open Source, como Ant (NAnt) o JUnit (NUnit), por nombrar un par de ellas.
Creo además que este fenómeno está llevando muchas buenas cosas a la comunidad .NET, y es genial.
Pero no hemos de olvidar que Microsoft diseñó .NET con el conocimiento de las cosas que no estaban bien o faltaban en Java y J2EE, y que además lo hizo con el potencial de una gran cantidad de cabezas pensantes e innovadoras. Esto significa que muchas de las cosas resultas por terceros en Java y J2EE lo están de forma nativa en .NET.
Un buen ejemplo: Actualmente hay mucho esfuerzo y discusión entorno al patrón de Inyección de Dependencias o Inversión de Control y los contenedores ligeros. Sabemos que hay frameworks como Spring en Java, que ahora se están portando a .NET y C#, cuando resulta que .NET ya proveé una solución para todo esto.
Lo mejor del hecho de que esto esté implementado en el propio corazón de .NET es que es algo sobre lo que puedes construir, sabiendo que es algo soportado y que todo el mundo puede usar desde el principio sin tener que descargar e instalar nada.
Daniel Cazzulino explica en su blog cómo funciona todo esto en .NET, y discute por qué hay ciertas desventajas apuntadas por Fowler que quedan solucionadas por el hecho de ser una parte integral de .NET.

Lightweight Containers and Plugin Architectures: Dependency Injection and Dynamic Service Locators in .NET

Herramientas de modelado de Microsoft

Narciso Cerezo — 2004-05-29T01:37:00+01:00

La verdad es que estoy muy contento por el hecho de que herramientas como estas vayan a llegar a nuestra comunidad.
Creo que es un buen acercamiento hacia el diseño, hacia la mejora de los procesos de RAD y la calidad del software, y además, alineado con las metodologías ágiles.
Por favor, tómate un rato y lee este post en TheServerSide.NET, y no te olvides de leer los enlaces que pone Dion, merece la pena leerlos.

JetBrains ReSharper

Narciso Cerezo — 2004-05-27T13:20:00+01:00

Hay muchos editores y entornos de desarrollo en el mercado. He tenido la oportunidad de probar muchos durante estos años, pero hay uno que me conquistó inmediatamente. Se trata de IntelliJ Idea, del cual puedes bajar una versión de evaluación o mejor aún, participar en el programa EAP (Early Access, Acceso Temprano) y probar la versión en la que trabajan actualmente.
Probablemente hay otros entornos con mejores capacidades para el diseño de interfaces gráficas swing, pero no hay ninguno con las capacidades de edición avanzadas de Idea, ni con su integración con las nuevas tendencias en el desarrollo, tales como el refactoring, ant, JUnit, AspectJ, y muchas otras.
Pero ahora, los chicos de JetBrains nos van a sorprender con otra maravilla, se trata de ReSharper, un plugin para Visual Studio .NET 2003 que aporta una parte de las capacidades de Idea al entorno de Microsoft. De momento, las capacidades son reducidas y está en beta, pero puedes probarlo participando en el EAP.

JetBrains ReSharper

Nomenclatura y estilo (II)

Narciso Cerezo — 2004-05-26T10:27:00+01:00

Bueno, vamos con la diversión.

Antes de comenzar he de decir que debes tener una guía de estilo para tu empresa o proyecto, y que esa será tu guía. Hay muchas cosas acerca de las guías de estilo que se pueden considerar subjetivas, y variarán dependiendo del lector.

Pongo un enlace a una guía bastante completa de Philips para C#, que es muy específica de C# pero que tiene muchas cosas aplicables a cualquier lenguaje orientado a objetos. Tengo que decir que no estoy de acuerdo con todos los puntos de esta guía, y que echo de menos algunas explicaciones en ella, aunque es algo razonable teniendo en cuenta de que se trata de una guía impuesta a un grupo de desarrollo, y no una discusión como la que hacemos aquí.
Creo que este documento mezcla conceptos de nomenclatura, formato de código y estilo de código, que son diferentes para mí. Ya he hablado de nomenclatura, y volveré a hacerlo más adelante. El formato de código hace referencia a la apariencia del código, y cómo hacer para que sea más legible, y además es menos específico del lenguaje. El estilo de código por el contrario, se refiere a técnicas de codificación y cómo escribir mejor código. Las tres cosas son esenciales, y en casos concretos como la guía Philips puede tener sentido mezclarlas, pero yo prefiero mantenerlas apartadas (juntas pero no revueltas).

Voy a comenzar hablando sobre el Formato de Código, exponiendo primero las cosas objetivas y explicando su razón. Luego seguiré con las subjetivas, relacionadas fundamentalmente con espacios y longitudes. Por último hablaré sobre el Estilo de Código, dividiéndolo de igual manera.

Debes recordar que este es mi blog y, por tanto, escribo aquí mis propios pensamientos y preferencias, que pueden ser diferentes de los tuyos. Generalmente estoy a cargo de definir todo este tipo de políticas en el trabajo, y de obligar su cumplimiento. Si, obligar; cuando trabajas para una compañía debes seguir sus guías de trabajo, aunque sean diferentes de las tuyas. Cuando estés desarrollando en casa, o dejes la compañía, podrás usar tus propias reglas.

Comencemos.

Declaración de variables
Estoy de acuerdo con la guía en que las variables deben ser declaradas allí donde se usen, en lugar de ponerlas todas juntas al comienzo del método. Esta es una de las capacidades añadidas en C++ respecto a C, y una buena. Si declaras una variable junto al bloque en que se usa estás facilitando el refactoring del código, porque puedes tomar todo el bloque y llevarlo a otro método, por ejemplo; y si resulta que quieres borrar el bloque no corres peligro de dejarte olvidada la variable. Además, al poner la variable junto al bloque en que se usa mejoras la comprensión sobre su cometido.

Bloques de control
De nuevo estoy de acuerdo. Toda sentencia de control (if, while, etc.) debe estar seguida de un bloque de control, aunque esté vacío. A pesar de que C++, C# y java te permiten no utilizar llaves para bloques simples (de una línea) es algo muy propenso a errores: si después añades una línea al bloque, es fácil que olvides poner las llaves, con lo cual el programa compilará pero no funcionará correctamente. Este tipo de errores suelen ser muy difíciles de encontrar.

Usa espacios, no tabuladores
Muchos dirán que esto es algo subjetivo, pero yo digo que no lo es. La razón es simple: los espacios son la única forma de garantizar que la intentación permanece consistente independientemente del sistema. Usualmente, diferentes sistemas muestran los tabuladores de forma distinta, y no sólo aplica a pasar de Windows a Unix, por ejemplo, sino entre diferentes programas en un mismo sistema operativo. La parte subjetiva es cuantos espacios utilizar para la indentación. Yo uso cuatro, pero es subjetivo.

Indentación
Debes usar un estilo de indentación bueno y consistente. Eso es objetivo. El resto del asunto es subjetivo, y creo que haré un post al respecto con mis propias preferencias. La indentación está muy relacionada con la máxima longitud de línea, cosa de la que hablaré en el siguiente post.

Y esto es lo poco que puedo considerar objetivo acerca del Formato de Código.

Philps' C# Coding Guidelines

Nomenclatura y estilo (I)

Narciso Cerezo — 2004-05-25T11:37:00+01:00

Por fortuna ya son muchos los que utilizan nomenclaturas y estilos de programación bien definidos. Aún así, durante mi trayectoria profesional, he tenido el dudoso privilegio de toparme con muchos más que no lo hacen.
He de decir que esto no ocurre sólo en ambientes que pudiéramos llamar de bajo perfil tecnológico, sino en empresas de consultoría de primer nivel. Desde mi punto de vista, debido a la contratación indiscriminada de la época .com.
Este es uno de los factores imprescindibles para conseguir código de calidad, primer paso de una cadena en la que aparece el refactoring de Kent Beck y Martin Fowler, y su importancia es mayor cuanto mayor es el proyecto y el equipo.
Durante los incontables años que llevo programando, mi estilo y nomenclatura han ido variando, adaptándose a los entornos y lenguajes, y mejorando con la experiencia adquirida, y tengo claro que seguirán cambiando como algo vivo.
Hoy hablaré sólo de nomenclatura, próximamente seguiremos con el estilo (mucho más interesante), y me centraré en los entornos más extendidos hoy en día: Java y .NET.

Nombres de clase
En este ámbito caen tanto las clases como los interfaces.
Durante bastante tiempo utilicé prefijos para nombrar clases e interfaces, anteponiendo una C o una I, respectivamente. En .NET se utiliza de hecho esta convención para con los interfaces, mientras que en Java no se hace distinción. Personalmente creo que la I no aporta nada y por eso he dejado de utilizarla. No aporta nada porque los interfaces son nuestra cara al exterior (buena práctica: codificar hacia interfaces), y al usuario de nuestros interfaces poco le importa si aquello que usa es un interfaz o una clase, su uso no varía, por tanto la I creo que añade datos innecesarios y con ello empeora el estilo. No obstante, en .NET puede ser recomendable utilizarla para mantener la coherencia con el entorno.
En general, los nombres de clase o interfaz deben constar de una o más palabras representativas, completamente escritas salvo que sean abreviaturas ampliamente extendidas, capitalizadas en su primera letra y sin guiones bajos u otros artefactos entre ellas. Ejemplo: DataObject.
Como extensión, creo que es buena práctica añadir al nombre de clase el patrón de software que representa en caso de representar alguno. Ejemplo: DataObjectFactory.

Nombres de métodos y propiedades públicas
Mi consejo en este sentido es utilizar las normas expuestas en las diferentes guías de estilo de los entornos.
Por ejemplo, en Java el nombre está compuesto de la misma forma que hemos explicado para los nombres de clase, pero con la primera palabra completamente en minúsculas. Ejemplo: provideSomeInfo().
En .NET la nomenclatura es idéntica a la del nombre de clase, siguiendo el ejemplo: ProvideSomeInfo().

Nombres de variables y propiedades privadas o protegidas
La nomenclatura propuesta en Java o .NET es similar, e igual a la propuesta para los métodos y propiedades públicos.
Durante mucho tiempo he empleado mi propia variación de la notación húngara propuesta por Charles Simonyi, fruto de mi herencia de C/C++, pero ciertamente en los lenguajes más puramente orientados a objetos como Java o C# tiene menos sentido y es un tema sobre el que se podría debatir

Algunas normas básicas
Es imprescindible que los nombres sean siempre representativos, y expliquen bien el cometido de un método o variable, no os importe tener que escribir más porque el incremento en la calidad y legibilidad del código os pagará cuando tengáis que revisarlo.
Únicamente puede saltarse la excepción de utilizar nombres genéricos, de una letra, en el caso de contadores enteros usados en bucles, restringiendo estos a los tradicionales en matemáticas: i, j, k, m, n. Y además en este orden suponiendo bucles anidados. Esto último es importante para mantener la coherencia y prevenir errores en zonas muy anidadas (que no deberían ocurrir, pero eso pertenece al estilo).

Closing the Gap, part 2

Narciso Cerezo — 2004-05-24T17:07:00+01:00

En la segunda parte de este interesante artículo, Eric Sink nos da unos consejos de inapreciable valor si queremos dedicarnos al desarrollo de software como "pequeños ISV". Para los que no lo sepan, ISV viene del inglés "Independent Software Vendor" o "Proveedor de Sofware Independiente".
Eric nos enseña cómo saber si nuestro producto tiene interés, y como hacerlo llegar al consumidor utilizando los recursos a nuestro alcance, como los blog, donde podemos comunicarnos con nuestros posibles usuarios y conocer sus intereses o inquietudes. La estrategia se basa en dejar que el cliente sea el que lleva el control, el que decide qué compra y cuando lo hace. Sinceramente creo que es un artículo que no debes dejar de leer.

Closing the Gap, Part 2