Uno de los artículos que más me gustan de Joel on Software es Los big mac contra el chef desnudo, donde expone que es más importante el talento innato que seguir un manual de instrucciones. Cuando leí el artículo lo del chef desnudo me pareció una historia cool de Nueva York, o que se yo. Cual fue mi sorpresa cuando en la revista El Pais Semanal del día 20 de Abril venía un reportaje sobre… Jamie Oliver, el chef desnudo. Pues no era una invención, habrá que tomarse más en serio las historias que cuenta Joel…
José Luis Sánchez
retocando el blog
He estado retocando el blog. He puesto la barra de navegación a la izquierda y he añadido algunos detalles estéticos. ¿ Te gustá más ahora ? Realmente MT es una pasada, si haces un blog a mano… ve enseguida a descargarlo.
Viniendo de trabajar iba dándole vueltas a la cabeza a un viejo tema: ¿ donde se debe poner una barra de navegación, a la izquierda o a la derecha ? ¿ Y en un formulario de un programa ?
xbrowse con oCol:tooltip y oCol:bLDClickHeader
Ignacio Ortiz de Zúñiga ha realizado una actualización de su xBrowse en que ha incluido dos nuevas funcionalidades en su control.
La primera es la asignación un tooltip a la cabecera de la columna y la segunda la posibilidad de evaluar un codeblock haciendo dobleclick sobre la cabecera de una columna. Necesitaba esto para implementarlo en mi programa de contraseñas, pues quería que se pudiera ordenar las columnas de la rejilla de datos directamente sobre ella. La manera habitual de esto es con click o dobleclick sobre la cabecera, pero el click está asociado en xbrowse al drag & drop de columnas para reordenar, con lo que era necesario tener tambien la posibilidad de usar doble clicl. El click con el botón derecho del ratón sobre la cabecera está asociado a un menú popup que permite mostrar y ocultar las columnas.
Creo que con estas dos nuevas funcionalidades, xbrowse es la rejilla de datos más potente y versatil que existe ahora mismo para usar con xHarbour/FWH.
conocimientos básicos para desarrollar software
En su artículo Computer Science: the discipline, Peter Denning hace una interesante descripción de lo que constituye el cuerpo de conocimiento de la Informática. Uno de los puntos que considero más acertados del artículo es el que se refiere a las habilidades básicas que deben tener los integrantes de la profesión y que es especialmente adecuado a los que nos dedicamos a desarrollar software. Estas habilidades son las siguientes:
- pensamiento algorítmico: interpretación del mundo reformulada en acciones paso a paso para resolver un problema.
- representación: manera en la que los datos son almacenados para ser recuperados eficientemente.
- programación: permite tomar el pensamiento algorítmico y la representación para expresarlos en forma de software ejecutable en un ordenador.
- diseño: conecta las anteriores capacidades con los problemas de la gente para resolver sus problemas particulares.
¿ Imaginas desarrollar software sin contar con estos conocimientos básicos ?
comercializar shareware: una carrera de obstáculos
En el número del mes de abril de la revista PcPlus viene un interesante artículo dedicado a la comercialización de software. Abarca algunos aspectos referidos a esta actividad como el registro de la propiedad intelectual de la obra, canales de comercialización, originalidad del software, etc. Sin embargo el artículo se queda corto para alguien que realmente quiera dedicarse a comercializar su propio software bajo la modalidad de shareware.
Por shareware entiendo un determinado tipo de software que tiene unas características muy concretas:
- el software ha sido desarrollado originalmente por su autor para su uso personal
- es el propio desarrollador quien ofrece y comercializa este software
- existen versiones de evaluación para que el potencial usuario pueda probar el programa y decidir si es lo que busca
- la versión completa del programa se puede registrar por un bajo precio, normalmente entre 20 y 50 €
El shareware ha contagiado de algunas de sus características a otros tipos de software. Actualmente casi todos los programas del mercado ofrecen versiones de evaluación y muchos programas comerciales han bajado los precios ante la competencia de aplicaciones shareware, sin embargo no son – desde mi punto de vista – aplicaciones shareware.
La comercialización de shareware obliga al desarrollador a enfrentarse con temas que antes nunca habia considerado. Partiendo de que ya contamos con un programa terminado y registrado, veamos cual es el camino a seguir.
En primer lugar se debe realizar la documentación adecuada del programa, aspecto que no suele agradar mucho a los programadores. Una buena documentación en formato electrónico es imprescindible, si bien una gran parte de usuarios jamás la leerá y preferirá preguntar directamente al autor cualquier duda que tenga sobre el mismo.
La promoción del programa se debe intentar por todos los medios al alcance del desarrollador. Una posibilidad es enviar el programa a todas las revistas conocidas con la esperanza de que publiquen una referencia o una versión de evaluación sobre la misma. Aquí la suerte es dispar, mientras que hay revistas que tienen buena disposición a la publicación de shareware hay otras en que es practicamente imposible conseguirlo. El siguiente paso suele ser contactar con empresas editoras de software, pero es muy difícil entrar en ese mercado. Si el programa no es muy bueno lo rechazarán sin tan siquiera contestar y si es bueno habrá que entrar a negociar la venta. Esta negociación será muy dura pues las empresas editoras querrán normalmente cerrar un precio para hacerse con los derechos del programa.
Dejo para el final la obligatoria creación de la página web del programa. El desarrollador tendrá que enfrentarse a elegir su nombre de dominio, diseñar su página web, contratar alojamiento, ofrecer multiples modalidades de pago y promocionar su web en los portales dedicados a shareware compitiendo con software comercial.
En la mayoría de casos que conozco de desarrolladores de shareware, toda esta actividad la realiza una única persona y ahi es donde radica el problema. La mayoría de programadores son buenos o muy buenos programando, pero no son capaces de recorrer todo el camino para llegar a comercializar su software. El bajo precio del shareware hace que unicamente se obtengan beneficios si el volumen de ventas es grande, cosa que por otra parte es muy dificil que llegue a suceder.
Una vez hecho todo esto es cuando realmente comienzan los dolores de cabeza: correos preguntando lo que está en la documentación, preguntando lo que vale el programa o como pagarlo, errores que les surgen a potenciales usuarios,… Este es el momento en hay que trabajar y ganarse a cada usuario en cada correo y en cada llamada. Y sobre todo no desfallecer y mandarlo todo a paseo.
He dejado al margen los temas laborales y fiscales de la actividad económica, pero al inicio de la actividad hace falta darse de alta en la seguridad social, registro de actividad económica, IVA,…
En el artículo que mencionaba al principio se alude a la escasez de buen software en castellano. Creo que después de lo expuesto es más facil de entender.
la elección de un nombre
Una de las cosas más complicadas que se han de decidir cuando se aborda el desarrollo de un sitio web es la elección de un nombre. A esta actividad los americanos, que tienen nombre para todo, le llaman naming. Hay incluso empresas que se dedican a hacer naming para terceros, el caso más llamativo quiza sea HundredMonkeys.
En uno de los últimos post de mi antiguo blog decía que el dominio para este blog era uno muy bueno. ¿ Es el nombre avemundi adecuado para un blog sobre desarrollo de software ? Desde mi punto de vista si. El primer programa que se hace en casi todos los libros de programación es Hola mundo que en latín es … avemundi.
inauguración del blog
Hoy se inaugura este blog. Hasta ahora he estado instalando movabletype y configurándolo hasta tener algo medianamente presentable. Queda mucho por hacer, pero creo que es oportuno abrir las puertas.
Acabo de colgar el cartel de cerrado en software*, mi anterior blog.
¡ Bienvenidos a avemundi !
blog en pruebas
Hoy inauguro este blog. La temática principal va a ser desarrollo de todo tipo de software, desde aplicaciones shareware – el segmento en que desarrollo mis aplicaciones – al desarrollo web – en el que estoy comenzando. Este blog va a ser continuación de software*, pero posiblemente sea un blog colectivo.
Mis preferencias dentro del desarrollo son los lenguajes xBase, actualmente uso Clipper/Fivewin y estoy migrando mis aplicaciones a xHarbour/FWH. También me interesan mucho los gestores de contenidos para sitios web, y estoy utilizando MovableType para hacer este sitio. En cuanto al desarrollo web, utilizo PHP y MySQL.
Mi intención no es hacer un weblog técnico, sino comentar otros temas relacionados con el proceso de desarrollo del software a las que muchas veces no se le presta la debida atención. Quiero incluir enlaces a sitios web interesantes, recomendaciones de artículos y libros, experiencias personales,… un poco de todo.
Gracias por visitarme.
Refactorizando con arrays de controles
La refactorización en Programación Extrema consiste en la revisión continua del código para mejorar su legibilidad, evitar duplicaciones, hacerlo más eficiente y más facilmente modificable. Para una introducción a la Programación Extrema ver el post de 30.ago.2002 de este weblog.
Estos dias estoy migrando Guardian a Harbour y mi buen amigo Manuel Calero me explicó la técnica del uso de arrays de controles en dialogos de edición de datos. La idea es que en vez de tener un montón de objetos GET, meterlos todos dentro de un array de get’s de manera que sea más fácil su manipulación.
código a refactorizar
En mis programas uso una indicación de que el registro que está en edición se ha modificado. Esta indicación se realiza mediante un bitmap colocado en el extremo inferior del dialogo que cambia de color cuando se modifica cualquier campo del dialogo. Al entrar a editar el dialogo el bitmap se encuentra atenuado y en cuanto se modifica cualquier campo el bitmap cambia y muestra un color más vivo.
Para ello, en cada GET tenía definida el evento bChange de manera que llamaba a una función que cambiaba el bitmap a mostrar. Algo asi:
REDEFINE GET oGet05 VAR cClUsuario ID 105 OF oDlg
oGet05:bChange := { || HaCambiado( oBmp ) }
y luego la función que cambiada el bitmap:
Function HaCambiado(oBmp)
oBmp:Reload( 'CLIP_ON' )
oBmp:refresh()
Return NIL
El problema de esto era que si el dialogo tenía 20 gets, tenía que tener 20 veces el dichoso oGet:bChange definido.
Refactorización
Lo primero que hice para refactorizar fue definir un array vacio de 20 elementos, tantos como GET tenía mi dialogo. Después redefiní los get a la manera habitual, pero cada get no era un objeto sino un elemento del array de GET:
LOCAL aGet [20]
...
REDEFINE GET aGet[02] VAR cClUsuario ID 102 OF oDlg
La gracia está en la manera de hacer el cambio del bitmap cuando cualquier objeto GET cambia. Ahora esto se hace en una sola linea de código usando AEVAL:
AEval(aGet,{|oGet| oGet:bChange:={||(oBmp:Reload('CLIP_ON'),oBmp:refresh())}})
Con esto he conseguido:
- Reducir el tamaño de mi código fuente – he quitado todas las sentencias oGet:bChange y he puesto un sólo AEVAL.
- Suprimir una función, con lo que mejoro el acoplamiento del programa.
- Hacer el código más legible y más fácil de mantener.
Gracias, Manuel.