Año: 2005

dadamail

por

Uno de los mayores dolores de cabeza de la web de alanit era la lista de correo. Quería instalar un gestor de listas de correo que llevase la gestión de la lista en modo desatendido, de manera que los propios usuarios gestionasen las altas y bajas de la misma. Estuve mirando por la web y encontré un par de aplicaciones que tenían buena pinta. La primera que elegimos no hubo manera de instalarla, torpe que soy, así que nos quedamos con la segunda opción, que era dadamail.

Dadamail es sencillo de instalar y configurar. Puedes crear varias listas de correo y se pueden personalizar los formularios de alta y baja de la lista, así como los correos de confirmación y todo lo que se utiliza para la gestión de la lista. La personalización de la lista de correo la ha hecho Jaime y la integración con la web la ha hecho fenomenal.

pensando en algo sin pensar

por

Esta fin de semana se publicó en EP[s] un reportaje títulado Corazonadas inteligentes que aborda el tema de la inteligencia inconsciente, a saber: ¿ porqué tomamos decisiones sin elementos de juicio objetivo ? El reportaje contiene una gran publicidad encubierta de un libro titulado Inteligencia intuitiva, cuyo autor es Malcolm Gladwell, el autor de La frontera del éxito y que es uno de mis libros para este invierno. Resulta chocante que en varias ocasiones en el reportaje hablan de Malcolm Galdwell, cuando el apellido correcto es Gladwell, pero eso es cosa de los periodistas.

Creo que existe una relación directa entre la inteligencia inconsciente y la actividad de desarrollar software. De alguna manera cuando eres más productivo, cuando estás en estado de flujo – lo que mucha gente llama programar con el piloto automático -, estás aplicando este tipo de conocimiento. No te paras en cada detalle de tu código porque sabes que lo estás haciendo bien. Depuras rapidamente los errores porque los encuentas enseguida. Tomas decisiones acertadas sin tener que pensar mucho, aunque realmente estás pensando a otro nivel. ¿ Cuantas veces te has levantado por la mañana pensando que tenías la solución de un problema que te tenía amargado ? ¿ O cuantas veces has dejado algo que te parecía imposible para darte cuenta al poco tiempo de que es más fácil de lo que suponías ? ¿ Que hacías en ese lapso de tiempo ?

Del reportaje me llama mucho la atención una cita de Bertrand Russell: Si tengo que trabajar en algún tema difícil, el mejor plan es pensar en ello con intensidad durante un tiempo y después dar la orden de que el trabajo continúe en el subterráneo. Después de algunos meses, vuelvo conscientemente al tema y descubro que el trabajo está hecho.

Algunos meses es mucho tiempo, pero dejar de pensar en algo durante un par de dias muchas veces ayuda solucionarlo.

la camiseta del XAAC

por

Esta semana me ha llegado la camiseta del XAAC, el concurso de programación xHarbour que ganamos. Y nada más llegar la camiseta, van los fenómenos estos y les da por cambiar la web de xHarbour … y el logo. Pero vamos por partes.

La camiseta es muy bonita. Yo ya tenía 2 que compré en Cafepress, pero de mi talla. La que han mandado ahora – o al menos la que me ha llegado a mi – es de talla XXL y me viene un pelín grande. Así que si alguien tiene una de talla L que me lo diga para cambiarlas.

La nueva web de xHarbour está muy bien. Realmente han hecho un trabajo estupendo y se nota el buen hacer y el sentido empresarial de Patrick Mast. Es una web superprofesional, con perlas como el xHDN o el impresionante archiv de Guias Norton.

Pero lo del cambio de logotipo la verdad es que no me ha gustado. Me recuerda mucho al logo de los x-men que leía de joven, cuando el guionista era Claremont y los dibujaba John Byrne. Pero sobre todo es que para mi el logo de xHarbour es verde y azul, como las latas de CocaCola son rojas y las de Pepsi azules. ¿ Alguien se imagina una lata de CocaCola azul ? Pues yo no me hago a la idea del logo de xHarbour amarillo y negro, pero será cosa de acostumbrarse.

tooltips de balón en FWH

por

Muchas veces la diferencia entre un programa y un buen programa está en los detalles. Por eso, un programador debe visitar con asiduidad los foros del lenguaje o herramienta de desarrollo que utiliza y estar al tanto de cualquier comentario que se pueda hacer sobre el mismo.

Hace un par de semanas en el foro de FWH Antonio Linares publicó la manera de cambiar los tradicionales tooltips cuadrados por unos de tipo balón. Los cuadrados son estos:

Para conseguir los tooltips de balón lo único que hay que hacer es ir al código fuente de la clase Window y quitar un comentario que aparece en la linea 2762 – o simplemente buscar ballon en el prg -. Hay que dejar la llamada a CreateTooltip con el último paráametro a .t.

hWnd = CreateToolTip( Self:hWnd, cToolTip, .t. ) // for ballon tooltips !


Luego se recompila la librería y nuestro programa. Ya tenemos tooltips de balón 😉

actualización del blogroll

por

Hoy he estado actualizando el blogroll. Tenía verios enlaces cuya actividad había decaido mucho y he decidido quitar algunos y poner otros.

Se quedan los blogs de Joel Spolsky y Eric Sink, gurus en esto de hacer programas y venderlos. A partir de ahi he añadido varios blogs colectivos que presentan actualizaciones varias veces al día. Con Planeta Código podemos leer los feeds de gran número de blogs dedicados a la programación, mientras que en Versión Cero nos cuentan novedades sobre el mundillo de la programación. Más novedades, pero de productos que siempre es bueno ir conciendo lo que la competencia hace por ahí, las tenemos en Genbeta. Por último Barrapunto es un sitio de visita obligada, aunque no se si vale la pena leer los comentarios de las noticias, que ultimamente las aguas bajan revueltas por allí.

Por último hay dos blogs personales que me están llamando poderosamente la atención. El primero es Najarabá, de Joserra, donde cuenta cosas tan interesantes como la manera de dar el salto de una idea a un software. El otro blog lo he conocido esta semana, y se llama Marzembre, ahí es nada, pero merece la pena.

A Jaime lo he subido a los enlaces, junto a la web de alanit y a los artículos de mi primer blog. Aunque lleva tiempo sin postear, seguro que pronto se le enciende la bombilla.

septiembre, el primer mes de curso

por

Para mi Septiembre es casi siempre el primer mes del año. En verano suelo reflexionar sobre lo que he estado haciendo durante el año anterior y de alguna manera tratar de planificar el próximo. Supongo que ayuda la faceta de docente, que de alguna manera te liga al calendario escolar.

Para este año, la idea es terminar durante el mes de septiembre las nuevas versiones de Cuaderno de Bitácora y el Puchero con la supresión de BtnGet y las altas dinámicas de claves ajenas. Una vez hecho esto intentar queremos jugar en las major leagues: internacionalizar los programas y lanzarnos a vender en el mundo mundial. Antes de eso tenemos que terminar algunas cosas de la web, como la gestión de la lista de correo que se nos está atragantando. Intentamos instalar phplist pero la cosa se complicó, y vamos a probar con dadamail que parece más sencillo aunque menos potente.

Los iconos de los nuevos programas van a ser de iconexperience. Hemos comprado las colecciones Application Basics y Objects & People y estamos adaptando los progamas con los nuevos iconos. Realmente quedan impresionantes… como en esta captura de azeta:

Y para este invierno los libros que tengo en cartera son:

usando TDbf

por

Hasta hace poco nunca había usado nada para manejar DBF que no fueran los comandos y funciones estándar de clipper y luego de xHarbour. Hace unas semanas comencé el desarrollo de una aplicación que tiene que ejecutarse en red y me planteé mirar las distintas clases para manejo de DBF que existen para xHarbour.

Haciendo caso de mi amigo Manolo y de algún otro consejo recibido via messenger me decidí a probar TDbf de Manu Expósito. Me bajé la clase desde su grupo de Yahoo y me puse a probarla. El ahorro de código que se produce al usar esta jerarquía de clases – como a Manu le gusta llamarla – es realmente impresionante. La clase crea automáticamente una data para cada campo del fichero que se manipula, con lo cual no tienes que definir campos ni hacer asignaciones. Además la clase maneja un buffer que es el que contiene estas datas, de manera que puedes cargar el buffer desde tu dbf y guardar los datos con una llamada a un método de la clase. Un mantenimiento básico usando TDbf sigue esta estructura:

IF NUEVO_REGISTRO
   oDbf:Blank() // pongo en blanco el buffer
ELSEIF MODIFICACION
   oDbf:Load() // cargo el buffer desde la dbf
ENDIF

DEFINE DIALOG oDlg RESOURCE "EDIT" OF oParent

REDEFINE GET aGet[1] VAR oDbf:TaCodigo  ;
   ID 12 OF oDlg UPDATE           		;
   PICTURE "@!"                        ;
   VALID Clave( aGet[1], nMode )
...
ACTIVATE DIALOG oDlg	;
   ON INIT DlgCenter(oDlg,oApp():oWndMain)</p>

IF oDlg:nresult == IDOK
   lReturn := .t.
   IF NUEVO_REGISTRO
      oDbf:Insert()
   ELSEIF MODIFICACION
      oDBF:Save()
   ENDIF
ENDIF

Además, Manu está preparando una TDbf Pro para antes de que acabe el año y que estará escrita en gran parte el C, con lo cual irá mucho más rápida que la actual clase. Ganas tengo de verla.

xharbour and dotnet

por

La semana pasada participé en un debate en la lista de noticias de xharbour. El tema inicial era un anuncio sobre un lenguaje xbase para la plataforma .Net pero luego se volvió bastante interesante, y trata sobre el porqué de mi interés en mono.

Massimo Belgrano: Seem that vo is near to the dotnet version http://www.vulcandotnet.com/. Any plan for xharbour dotnet version also for commercial distribution?

Marek Paliwoda: It seems they have also a Linux version running under Mono … If that’s true it is very likely that Vo will become a «killer app» for all other xbase products 🙂 .

I do not know about any attempts or plans to make xh for NET at this moment. I am affraid nobody is interested in such a version currently. Maybe something will change in a future …

Till that moment, all xbase developers interested in NET, can choose CuleNET or wait for an upcoming Vulcan.NET 🙂 .

José Luis Sánchez: I apologize.

VO a ‘killer app’ ?

I think that VO was the app who killed the best programming language developed ever for personal computers. And we are lucky that [x]Harbour guy’s returned it to live.

Marek Paliwoda: Not VO – Vulcan.NET

> I think that VO was the app who killed the best programming language developed ever for personal computers.

Maybe – if you are talking about *old* VO. But it is an over-simplification IMO. Look at VO community – seems to be bigger than xh community. How can you explain this taking info account that «VO killed the best language» ?

> And we are lucky that [x]Harbour guy’s returned it to live.
Undoubtly.

However look around – how many *new* developers are deciding to enter the xbase world, either with xharbour or other Clipper like products ? My observations are – very, very few. xbase becames niche – smaler and smaler. And xh did not change much in this trend. Maybe Vulcan.NET or CuleNET (or xh.NET) will ?

Tim Stone: Perhaps … but .NET products are still struggling. I’ve been involved in testing several and performance is very slow. I know a lot of work is going into .NET development, but I’m not sure how many «end products» are being embraced at this time.

I can see it more for document sharing and processing, but true database work relies on fast performance.

Marek Paliwoda: You may or may not believe, but here almost *all* new products from firms I have contacts with, are NET based. I doubt elsewhere is differently.

> I can see it more for document sharing and processing, but true database work relies on fast performance.

This is a very personal point of view. Mine is that true database work depends on a good database engine and a very good database project. NET helps building modern and rich user interface. All the rest (well, almost all) is done on a backend (database engine).

Thanks for sharing your opinion.

José Luis Sánchez: I don’t know which community is bigger, but I’m sure that if CA didn’t buy Nantucket now we would have a big community.

I really think that .Net is comming a mature environment, and with mono you can do development for Windows and Linux. In fact, I’m beginning with .Net framework and my goal is develop with mono in Linux in a couple of years. But I will learn C# for this, once I decided to jump to mono I will play the game with their own cards.

Marek Paliwoda: I went this route years ago. It was an amazing journey and I never regreted. I had to learn *lots* of things about NET : CLR, ASP.NET, assemblies, code security etc. One of the things I’ve learned is that *it doesn’t really matter* what language you choose to write NET apps. Language in NET is mostly «a sugar». That’s NET which gives you the power – not the language. You choose the language you preffer to utilise NET power. That’s why CuleNET and Vulcan.NET are important IMO. They open NET for us using our prefferd xbase syntax. While this does not guarantee that new programmers will choose xbase way to play with NET, it certainly opens new posibilites for those used to «old» Clipper, VO, Xbase++, etc. Xh gave us the hope for a very short amout of time unfortunately, due to amazingly quick technology progress.

The fact is that «old xbase world» is die-ing. And this process happens quicker and quicker. Will CuleNET and Vulcan.NET change this ? I don’t know … but I hope yes.

I wish I am wrong in my opinions.

Thanks for taking your time in this discussion.

José Luis Sánchez: I don’t think xbase world is die-ing. I develop shareware and for me xHB is the perfect lenguage, but I want to learn a new framework that give me new perspectives about my profession. I’ve decided learning mono but I will not leave xHB. I want to try for myself things like NAnt, NUnit that I can’t use with xHB.

Ron Pinkas: Can you please explain, what in your opinion is standing in the way of the xHarbour developers, prohibiting the support any new technologies?

IOW, what makes it so much easier, for the developers of any other development product, to support that «quick technology progress», to the point that xHarbour will simply not able to compete, beyond a «very short amount of time»?

I for one, see xHarbour as an amazingly powerful, modern, open, development tool, which has a track record, showing how quickly it can embrace and support, new technologies, platforms, etc..

Marek Paliwoda: Complete lack of interes from those who would be able to keep xh «up to date» due to their enough knowledge and desire. Sorry Ron, xh is descendant of hb. Hb had around 30 developers (AFAIK), xh has around 50 developers. How many of them *really* develop xh ? How many of them can devote all their time for xh ? How many of them are familiar with
new technologies and with xh internals (I am talking about *deep* knowledge here) ?

Before you will try to answer, please consider the fact that lately you were looking for voluntiers to take care of orphan xh modules like regex, hashes, network funcs, etc … without success so far 🙁 (hope this will change).

It seems to me those from other products had found talented individuals from which they created a development teams which work full time on their products. This is different than in xh.

Long ago I was conviced that OpenSource model of development is better than comercial. Now I think quite the oposite way. It is much easier for comercial companies to find talented individuals. This is a simple matter of economy 🙂

> I for one, see xHarbour as an amazingly powerful, modern, open, development tool, which has a track record, showing how quickly it can embrace and support, new technologies, platforms, etc..

Yeah … , like COM/OLE for example … This technology is more than 10 years old. I couldn’t call xh support for it even «basic» 🙂 . No type information, no support (or wrong support) for some COM types (like SAFEARRAY’s), no support for parameters by ref, no support for events/callbacks, no activex support, no support for DCOM, etc.

Sure, You couldn’t write anything other than that. Besides everything, you sell xh 🙂 .

Ron Pinkas: Marek,

People may be slow to take responsability, yet they are more than happy to contribute, as you well know. Additionaly, primary contributions seem to come from NEW Individuals, as they step forward to take advantage for new technologies that THEY NEED. This is how most great contributions arrived to xHarbour, and why we have some 50 developers.

Maybe you should ask yourself WHY is it, that I sell xHarbour, why are you here, and why are so many other tremendously creative developers [of
«main-stream» languages] here?

Marek: I mentioned about COM/OLE not because it’s something new (in fact I wrote it’s an old technology), but because having a working COM/OLE support would allow as at least using NET components thru NET/COM interoperability. Much like VFP and VO do. Sure it would be some kind of «hack» but better than nothing 🙂 – I am not sure if you realise that having xh for NET will reguire to rewrite xh almost from *scratch* if you want to have pure NET solution … Taking into acount that even an old technology is not well supported in xh I think it’s quite resonable to assume that the new one will have similar problems. You may or may not agree with this. Please note I am not against xh – I am still going to play with it 🙂 . But this does not mean I do not see xh problems (IMO),
and I am looking at other options also (CuleNET, Vulcan.NET).

…

El hilo completo se puede seguir en news://news.harbour.com

entrevista con Roberto López

por

Hace unas semanas se produjo un gran revuelo con el anuncio por parte de Roberto López de que MiniGUI pasaba de tener una licencia GPL a ser freeware, aunque posteriormente hubo una rectificación dejando de nuevo la licencia como GPL pero con la advertencia de su creador de que no aceptaría colaboraciones. Este hecho produjo un cierto revuelo, llegando el tema a ser barrapunteado.

Ante esto decidí ponerme en contacto con Roberto, quien amablemente respondió a mis preguntas.

La primera pregunta es obvia: ¿ que ha pasado con MiniGUI ? ¿ Porqué el cambio de licencia GPL a Freeware y vuelta atrás a GPL ?

Es lo que he explicado en dos comunicaciones a través de mi sitio el 16 y 23 de Julio.

En pocas palabras, lo que sucedió, es que algunos usuarios muy cercanos al proyecto (moderadores del foro de discusión en Inglés) decidieron publicar una versión alterna de MiniGUI, conteniendo contribuciones de código que habían sido rechazadas por diversos motivos. Los más notorios fueron, incapacidad o falta de interés de sus autores para solucionar problemas en su código, no preservar la compatibilidad con versiones anteriores de sus propias contribuciones, no respetar reglas básicas que permitan mantener la consistencia con el diseño general de la librería, etc.

La primera publicación de esta versión alternativa llevó la denominación 107, presentándose como una continuación de mi trabajo (mi última publicación hasta ese momento había sido la 106a).

Cuando tomé conocimiento de esto, supe, que como autor de la librería, tenía el derecho y el deber, de proteger mi trabajo y a los usuarios que confiaron en él, de acciones de este tipo.

Mi primera iniciativa fue la de publicar la librería (a partir de la versión 2.0) como Freeware, lo cual protegería el código de modificaciones inadecuadas, manteniéndola libremente disponible y gratuita.

Una parte importante de los usuarios, consideró que la no disponibilidad del código fuente, podría llevarlos a tomar la decisión de no continuar usando MiniGUI a partir de la versión 2.0.

Los motivos que expusieron, fueron, en algunos casos muy atendibles, por lo cual decidí tomarme un tiempo para considerarlos.

Finalmente, decidí volver a publicar la versión 2.0, ahora, de la misma forma que siempre (GPL+’Harbour Exception’), pero sin aceptar nuevas contribuciones de código.

En un mensaje reciente en tu página web dices «dejaré de aceptar nuevas contribuciones de código en todas sus formas». ¿ Has tenido problemas con las contribuciones de código ? ¿ No crees que de esta manera vas a reducir tu comunidad de usuarios ?

La primera parte de la pregunta la he respondido en el punto anterior.

En cuanto a los usuarios, si algo he aprendido en estos años, es que no es posible tomar decisiones que satisfagan a todos.

Algunos considerarán que mi punto de vista es el más acertado y continuarán usando mi versión de MiniGUI, otros creerán que alguna otra alternativa les es más conveniente y ya no contaré con ellos como usuarios. No está mal que sea así y no estoy preocupado por ello.

En la versión 2.0 incluyes en el paquete Harbour y el compilador MingW. ¿ Puedes explicarnos porque Harbour y no xHarbour y el motivo del cambio de compilador C ?

En cuanto a Harbour, cuando el proyecto se dividió, me pareció más razonable la posición de quienes opinaban que debían concentrarse los esfuerzos en completar el trabajo y hacerlo lo más estable y confiable que fuera posible, en lugar de extenderlo, cosa que debía hacerse en el futuro, eventualmente, una vez finalizada la primera versión.

Esta es solo una opinión de usuario y no pretendo influenciar ni molestar a nadie con ella.

Respecto del compilador de C, hace algún tiempo, un usuario de las primeras épocas de MiniGUI (Lorenzo Fiorini) me llamó la atención sobre la licencia de BCC (que hasta ese momento yo creí completamente gratuito).

No soy un especialista en licencias, pero, es bastante claro que BCC tiene serias restricciones en cuanto al uso que puede hacerse del compilador y de los ejecutables generados con él, lo cual es claramente contrario al espíritu de Harbour y al de MiniGUI.

Desde entonces, MingW, surgió como la alternativa ideal, ya que puede distribuirse libremente y los ejecutables generados con él no están sujetos a restricción alguna.

Yo realmente soy un profano en el uso de MiniGUI, ya que he usado Fivewin desde casi sus inicios. He probado MiniGUI y me ha sorprendido la facilidad de
su sintaxis y que está todo perfectamente ensamblado para comenzar a programar en 1 minuto. ¿ Que ofrece MiniGUI a gente como yo ? ¿ Crees que MiniGUI puede competir con los GUI visuales de última generación como Xailer o VXH ?

MiniGUI comenzó como un experimento en Diciembre de 2001, cuando la
crisis aquí, me dejo con mucho tiempo libre que decidí usar para iniciarme en el uso de la interfase Harbour-C.

Nunca fue pensado como un producto que pudiera competir con algún otro.

Yo solo quería una herramienta, que tal como el Clipper original, me permitiera, como programador, concentrarme en el problema a resolver y no en las complejidades del lenguaje utilizado para resolverlo.

Eso es todo lo que MiniGUI ofrece.

Muchas gracias Roberto, y mucha suerte en esta nueva etapa de MiniGUI.