Lo que hacía hace 14 años

En 1994, mientras estaba en el servicio militar en Lleida me dediqué a programar un poco. En la carrera había hecho tres asignaturas de informática y me puse manos a la obra en la informatización de la tienda de mi primo. Hice un programa de gestión de clientes, presupuestos, facturación, almacen, contabilidad y libros que funcionó bastantes años pese a que nunca había trabajado en informática y no sabía ni lo que era una base de datos.

Hoy haciendo un poco de limpieza en mi ordenador me he topado con el código fuente en C de la aplicación que desarrollé y que corría en MS DOS. No he podido evitar la tentación de colgar dicho código por si hay alguien interesado en inspeccionarlo…

control2.C
control3.C
control4.C

Me he pasado a Linux

Cansado de las estrellitas de Windows y de Office; que si puedo ser víctima de una falsificación, que si mi ordenador está en peligro, etc… Decidí probar un poco más en serio Ubuntu.

xubuntu_logo.jpg

 El fin de semana pasado me compré un disco duro interno de 320GB, lo instalé en mi viejo PC con 512 de RAM y procedí a instalar Ubuntu, una distribución bastante extendida de Linux. Después de equivocarme un par de veces con esto de las particiones y demás, conseguí que funcionará y… sorpresa, iba más lento que Jordi, Vicenç y José Luis subiendo la peña montañesa. De hecho iba muchísimo más lento que Windows XP en el mismo ordenador.

Después de investigar un poco, me di cuenta de que no habia nada a hacer, que Ubuntu es lentorro y cuando ya iba a volver a Windows XP, descubrí que existía la posibilidad de utilizar la interfaz gráfica XFCE para linux, en la llamada distribución Xubuntu. Después de instalarla (tarea nada fácil para lo que es necesario ser prácticamente ingeniero de la NASA), la velocidad ha aumentado considerablemente y ya ha superado a Windows XP. Además el ordenador arranca muy rápido.

De momento, todo funciona bien y eficientemente. El único problema es que Xubuntu (ni ninguna distribución linux) tiene MS Access por lo que me tendré que acostumbrar a vivir sin él.

La Respuesta al Concurso

Pues efectivamente, la respuesta al concurso «Qué es esto?» que planteé el pasado miércoles, fue acertada por Pedro.

Se trataba de una QSL o tarjeta de confirmación de comunicado entre estaciones de radioaficionado. Concretamente, correspondía a una comunicación que mantuve el 8 de julio de 1995 a las 11:20 UTC, con el amigo David Fisher, KA2CYN, que vivía y transmitía desde Estados Unidos. La banda frecuencial utilizada se encontraba alrededor de los 28 MHz (10 metros) y el tipo de modulación fue banda lateral superior (USB). La fuerza de la señal con la que fui captado fue de 4 sobre 5 y la claridad del audio de 1 sobre 5.

neptune.jpg

En la actualidad y pese a que sigo conservando la licencia e indicativo oficial EA3GIW, estoy muy poco activo y es realmente muy difícil toparse conmigo. Eso sí, tengo mi emisora de 5 watios de potencia instalada y en perfecto estado junto con la antena dipolo que me construí en su día.

Ahora sólo falta saber quien es Pedro para poder hacerle un especial. Tengo algunas ideas sobre su identidad pero no es cuestión de andar con dudas…

¿ Que debo hacer si Microsoft se hace con Yahoo ?

Hace unas semanas, Microsoft propuso a Yahoo la compra de la compañía, ofreciendo una suma de dinero nada despreciable. Solicitaba una mesa de negociaciones entre ambas empresas para cerrar un acuerdo.

Ante la negativa de los directivos de Yahoo, el pasado viernes, Microsoft envió una nueva carta en la que anunciaba (amenazaba !) que les daba tres semanas para la aceptación de la oferta inicial o el inicio de conversaciones . En caso contrario, lanzaría una OPA hostil acudiendo directamente a los accionistas.

Con todo este panorama, doy ya por hecho que Microsoft se va a hacer con el control de Yahoo… y aquí es donde comienzan a aparecer mis primeras dudas.

Actualmente este blog está hospedado en los servidores de Yahoo (en la antigua Geocities) en algún sitio de California (hace ya unos 8 o 9 años). En todo ese tiempo el funcionamiento ha sido excepcional y sólo recuerdo problemas en una ocasión hace un año y medio cuando se crearon nodos directos de acceso en Europa para clientes de la zona y desde España no era posible acceder a mi espacio (ya se que la explicación técnica no ha sido la mejor…). Y no hablemos ya del precio, que gracias al dollar, cada día me resulta más económico !.

Pues bién, sucede que mi web y blog están basados en mySQL y PHP (los instalé hace apenas 3 meses) y no utilizo ninguna herramienta de Microsoft. Es decir, que si Microsoft aterriza en Yahoo, quizás lo primero que haga sea montar su propia infrastructura y pasar todos los clientes a MSN (horror !!!).

En previsión de lo que pueda ocurrir, quizás deba comenzar a buscar nuevo proveedor.

¿ Encontré el Despertador de mis Sueños ?

Llevo más de 2 años (no es broma) buscando el despertador ideal. Lo hemos buscado por Internet, en España, en Japón, en Inglaterra, en Alemania, en Italia,… y nada. No había forma de encontrar el radio despertador perfecto: doble alarma, MP3 a través de USB/SD Card, sin CD, hora visible durante toda la noche, volumen ascendente, radio digital,…

Hace unos días en un Media Markt vi el que puede convertirse en mi radiodespertador para los próximos años. Se trata del Philips AJL308 y cuesta alrededor de 127€. Es todo digital y cuenta con un display grande donde se pueden visualizar fotografías. Si decido comprarlo, informaré.

Radio Despertador

Cambiando el Blog…

Que nadie se alarme. Finalmente he iniciado la actualización de mi página web y blog utilizando el motor de WordPress 2.3.2. (gracias a Carlos Guadian que me aconsejó esta solución). Iré migrando los contenidos tranquilamente así que espero que cada día aparezca algo nuevo.

También espero que termine de aclararme a ver como demonios van todas las opciones y gadgets que tiene el programa y que alguien me diga que plugins me tengo que instalar, por ejemplo para poder subir fotos a los posts sin tener que ir vía ftp (ya se que en versiones anteriores estaba pero en el 2.3.2, no).

Que hacer si estás enfermo

Este fin de semana largo, en el que no he podido ir a Italia como tenía previsto, por culpa de un catarro algo más fuerte de lo normal me he tenido que quedar encerrado en casa jugueteando compulsivamente con el ordenador. Entre otras cosas, me he instalado Ubuntu, una distribución de software libre de linux que me ha maravillado por la sencillez de instalación y utilización, así como la velocidad de ejecución. He descubierto, además, cuatro subversiones del famoso Ubuntu que son Xubuntu (para ordenadores viejos y lentos), Gobuntu, Edubuntu y Kubuntu. Además también he actualizado Firefox con algunos complementos y he cambiado mi cliente de correo de Microsoft Outlook a Thunderbird (de Mozilla).

El hecho de que todo lo que he instalado y probado (incluido OpenOffice) sea Open Source me ha dado que pensar que estamos cada vez más cerca de poder prescindir de aplicaciones comerciales y de Microsoft para el usuario final y olvidarse de una vez por todas del «Podría ser víctima de una falsificación de software».

El Nacimiento de Arvisa

En 1992 Víctor, José Miguel y yo creamos Arvisa (cuyas siglas eran las iniciales de nuestros apellidos: ARoca-VIcente-SAmpietro). La idea era ganar dinero con lo que habíamos aprendido en la universidad (?!). Planeamos muchas cosas, entre ellas el sistema de conexión de calculadoras a ordenador por un 10% de coste que tenían las interfaces comerciales, pero hicimos muy pocas: sistemas electrónicos «a medida» para estudiantes (quizás para sus prácticas y proyectos de fin de carrera…) y tres decodificadores de datos para emisoras de radio que permitían la recepción directa de imágenes de satélite, RTTY y televisión de barrido lento. Hoy, me he deshecho de un montón de trastos «electrónicos», entre ellos, un prototipo digital increible que permitía transmitir un código de llamada DX de forma automática y repetitiva conectado a un emisor de rádio (ver fotografía).

La PYME entra en el B2B de la mano de XML y de EDIWeb

Aun recuerdo la sensación que me produjo, hace dos años, ver la primera valla publicitaria en la que únicamente se anunciaba una dirección web de un periódico exclusivamente on-line; por fin, Internet había cobrado la suficiente importancia como para que algún responsable de marketing creyera que no se estaba dirigiendo a un segmento excesivamente específico si anunciaba Internet en una valla exterior en plena calle.

Posiblemente el hecho de que la publicidad sobre portales (y webs en general) aparezca en todas partes y en cualquier momento, está llevando a mucha gente a una confusión importante y es pensar que Internet es solo WWW y que todo lo que se tiene que hacer en Internet pasa por un navegador.

Afortunadamente eso no es así y el éxito de Internet va más allá de las simples (y complejas) aplicaciones gráficas. Ni siquiera el comercio electrónico o el B2B (Business to Business) es un invento de Internet…

Hace casi 2 décadas que se están utilizando sistemas transaccionales de comercio electrónico entre empresas (B2B) basados en EDI (Electronic Data Interchange) y desde hace 5, con la aparición de Internet, esos mismos sistemas están cobrando más protagonismo que nunca al comenzarse a abrir camino en la pequeña y mediana empresa.

El modelo de negocio basado en Intercambio Electrónico Documental

Muchos son los sectores de la empresa española que llevan utilizando EDI desde hace ya bastantes años:

  • Distribución comercial.
  • Logística y transporte.
  • Banca y Servicios Financieros.
  • Industria.
  • Administración Pública.

En todos ellos existe una necesidad básica y es la de automatizar algún tipo de transacción entre dos empresas. Dicha automatización debe realizarse entre dos sistemas o máquinas que en cada una de las dos (o más) empresas realizan funciones concretas de facturación, control de stocks, etc… El problema principal residía en que si el ordenador de la empresa 1 quería solicitar un pedido concreto de material (por ejemplo) al ordenador de la empresa 2 sin intervención humana, era necesario definir un formato de fichero o mensaje específico que definiera las características de dicho pedido. Los estándares EDI se encargaron de definir dichos formatos y de asegurar la interoperabilidad de sistemas de gestión propietarios a través de un único interfaz.

Imaginemos, por ejemplo, un gran centro comercial (con un stock presencial de productos muy importante) al que cada día acuden miles de consumidores y donde existen aspectos críticos como:

  • La gestión de stock tiene que ser perfecta para mantener solamente el número mínimo imprescindible de producto y reducir costes de almacenaje.
  • El tiempo de reposición de producto presencial tiene que ser mínimo.
  • El control de facturación tiene que ligarse directamente al paso por caja del cliente de tal forma que coincida la necesidad de reposición con la facturación directa producida.
  • Deben coordinarse adecuadamente los pedidos y facturación de la multitud (miles) de proveedores del centro comercial.

La única solución para controlar eficientemente todos estos factores pasa por la introducción de un software de gestión integrada que permita la interconexión, entre otros, del stock de almacén, del stock en tienda, de la lista de reposiciones almacén-tienda, del control de caja en tienda, del control de caja en almacén, de la contabilidad y del control y gestión de pedidos a los diferentes proveedores (posiblemente la tarea más crítica).

Si se requiere la automatización total para alcanzar la ECR (Efficient Consumer Response) en todo el proceso, será necesario que toda la comunicación con los proveedores (en otros casos, clientes) se encuentre libre de actuación humana. Para ello, EDI define toda una serie de formatos de mensajes, cada uno de los cuales es utilizado para «comunicar» algo de una empresa 1 a una empresa 2, permitiendo a los diferentes proveedores y al centro comercial adaptar sus sistemas de gestión (por ejemplo, SAP) a un único interfaz de comunicación definido de manera internacional. Algunos ejemplos de mensajes EDI estándar son:

Orden de transporte. Utilizado para la expedición y transporte de mercancías desde un origen a un destino. Por ejemplo, este mensaje es utilizado por empresas exportadoras / importadoras, para comunicar a las empresas de transporte la descripción del envío.

Estado del envío. Puede utilizarse como confirmación de recepción, albarán de entrega, etc.

Coste del flete. Para notificar los costos del flete o de la carga.

Uno de los grupos de estandarización EDI más utilizados es EDIFACT (Electronic Data Interchange For Administration, Commerce and Trade), pensado para su uso en logística y administración pública. Para el caso de los mensajes anteriores, por ejemplo, se han definido los formatos IFTMIN, IFTSTA y IFTFCC (http://www.unece.org/trade/untdid/welcome.htm).

Las empresas (por ejemplo, el gran centro comercial) receptoras de mensajes EDI, tienen que poder asegurar que todos los mensajes cumplen un formato predefinido para que no se produzcan errores de ningún tipo en los sistemas de gestión propios. Para asegurar este hecho, se recurre a los Centros de Compensación EDI (VANs – Value Added Networks o Redes de Valor Añadido), donde además de esta tarea son utilizados para guardar (típicamente por 5 años) copia de todos los mensajes que son enviados y recibidos.

Quizás ahora resulte más fácil entender que el B2B no es un invento de nuestros días sino que se lleva utilizando desde hace casi 2 décadas para gestionar pedidos y pagarlos, entre otros.

Las barreras del EDI

Sin embargo, el uso de EDI (antes de la aparición de Internet) presenta fuertes barreras económicas que hace su uso prohibitivo para las PYMEs, restándoles competitividad frente a los grandes gigantes. Algunas de estas barreras son:

Los costes de comunicación son elevados ya que generalmente es necesario la contratación de una línea punto a punto entre la empresa y la VAN.

El desarrollo de la interfaz es muy costosa dada la complejidad de las estructuras EDI. El hecho es especialmente crítico cuando se tiene que modificar alguna variable o característica del formato (en ese caso será necesario reprogramar la interfaz).

Muchas empresas grandes optan por utilizar formatos propietarios con lo que los proveedores están obligados a adoptar dichos formatos si quieren entrar en la cadena de negocio (por ejemplo, en las comunidades portuarias europeas, en 1999, el 60 % utilizaban formatos propietarios EDI) . El coste de implementación de varios formatos propietarios simultáneamente (si deciden trabajar con más de un cliente) es totalmente inalcanzable para la mayoría de PYMEs.

Con estos datos en la mano es sencillo entender el porqué solo utilizan EDI las grandes empresas.

Las aportaciones de Internet

La llegada de Internet ha revolucionado el mercado EDI en tres aspectos clave:

  • Comunicaciones. Ya no es necesaria la utilización de líneas dedicadas para la transmisión de los mensajes (una con cada VAN o cliente final). Simplemente es necesario que las dos empresas tengan conexión a Internet y que puedan enviar y recibir por email, FTP, etc.
  • Interfaz gráfico. En el caso de pequeñas empresas en las que no se enlazan directamente sistemas de gestión propios con interfaz EDI, se recurre a aplicaciones «independientes» que a partir de formularios construyen el mensaje EDI y lo envían y que son capaces de recibir los mensajes entrantes, procesarlos y mostrarlos de forma inteligible para el usuario. El principal problema de este tipo de aplicaciones EDI reside en que requieren de un mantenimiento constante para adaptar los formatos a los diferentes clientes y hacer frente a las evoluciones en las guías EDI (por ejemplo, EDIFACT genera dos versiones por año). Con Internet, es posible mantener la aplicación a través de web o si se requiere mayor velocidad, utilizar una aplicación local con actualización automática (smart update).
  • XML. Pero la verdadera revolución ha aparecido con XML. No solo se ha introducido el concepto de EDIXML (con separación de campos por tags), sino que el simple envío del DTD y del XSL de un mensaje puede ser suficiente para que la aplicación cliente adopte un nuevo mensaje.

El interfaz gráfico de la aplicación EDI

Abandonemos, de momento, la gran empresa (por ejemplo un gran centro comercial) y centrémonos en una PYME que debe recibir 4 pedidos semanales, procesarlos y servirlos.

Está claro que si dicha empresa solo debe atender 4 pedidos semanales (obligatoriamente a través de EDI) no será rentable implementar un interfaz EDI para el sistema de gestión de la empresa porqué será más económico que la respuesta a los pedidos se haga manualmente a través de un formulario que alguien deberá rellenar para responder al mensaje recibido por parte del cliente.

Ilustrará lo dicho anteriormente un ejemplo real: en las comunidades portuarias (Port Community Systems – PCS) los transitarios son los responsables de la organización del transporte de la mercancía a nivel internacional entre un importador y un exportador. La mayoría de la información que se maneja es enviada y recibida a través de EDI y para ello disponen de interfaces EDI conectados directamente a sus sistemas propietarios de gestión y control. Sin embargo, en alguna ocasión (imaginemos una vez al mes), puede ser necesario realizar algún enlace de mercancía a través de avión. Para ello, será necesario solicitar disponibilidad de vuelo, de espacio, reservar plaza de mercancía, contratarla, etc., obviamente a a través de EDI (exclusivamente). Para el caso de Europa, lidera el mercado el sistema alemán Traxon que agrupa a más de 30 aerolíneas (Lufthansa, British Airways, Air France,…) y desde el cual es posible realizar cualquier transacción de reserva, petición de estatus, etc. utilizando el estándar CARGOIMP encapsulado en EDIFACT.

Volviendo al transitario que nos ocupaba, posiblemente este no tendrá implementado el interfaz EDI para transporte aéreo en su sistema de gestión a no ser que haga un uso intensivo de el. Sin embargo, sino se envía su solicitud de reserva de espacio por EDI, no va a poder transportar su carga. Con la llegada de Internet, se ha abierto un campo de posibilidades que permite a este tipo de empresas que hacen un uso «marginal» de EDI poder utilizar servicios de alto valor añadido a un coste bajo.

Comienzan a proliferar las empresas que ofrecen servicios EDIWEB en comunidades logísticas concretas. Esto significa que cualquier empresa con un mero navegador puede acceder a servicios EDI complejos a través de web.

Sin embargo, cabe no sobrevalorar el EDIWEB, porque solo ofrece una solución para casos muy concretos: PYMEs con bajo uso de EDI y automatización de mensajes sencilla.

El principal problema de EDIWEB reside en la dificultad de implementar formularios potentes y rápidos por la simple limitación de velocidad que tiene la red Internet hoy en día. Si se aspira a disponer de formularios para la introducción de complejos mensajes (por ejemplo un manifiesto de carga con cientos de campos) con validaciones muy pesadas deberá descartarse el uso de una aplicación remota basada en web. La solución, cada vez más utilizada, consiste en desarrollar una aplicación (cada vez más en JAVA nativo) que se comunique con el servidor de la VAN a través de Internet y que permite realizar acciones de interfaz gráfico de forma rápida.

La revolución XML

El XML, lenguaje extensible de etiquetas (extensible por que no es un formato prefijado como HTML), describe una clase de objetos de datos llamados documentos XML y describe parcialmente el comportamiento de los programas que los procesan.
Antes de proseguir conviene definir algunos conceptos básicos:

Fichero XML. Conteniendo la información que se quiere transmitir.

Fichero DTD. Conteniendo la forma en que se tiene que estructurar dicha información (estructura del mensaje XML).

Fichero XSL. Conteniendo las reglas de transformación de un mensaje XML a otro formato de fichero o de presentación (XML, HTML, PDF,…).

La revolución XML en el intercambio documental se fundamenta en lo siguiente:

  • Nueva estructura de mensajes EDI. Ha aparecido una variante del EDI que es el EDIXML donde la identificación de campos se realiza a través de tags, permitiendo a las aplicaciones su procesamiento sencillo.
  • Interpretación automatizada de formato. Trabajando con EDI clásico la descripción del formato para un tipo determinado de mensaje se realiza a través de la llamada «guía del mensaje». Dicha guía no es más que un documento de texto en el que se describe cada uno de los campos que componen el mensaje y sus características y que tiene que ser leído, entendido y codificado (programado) manualmente por alguien para disponer del interfaz con el sistema de gestión o de un formulario para «rellenar» los campos.

La novedad reside en que para definir un mensaje EDIXML solo es necesario disponer del DTD (indicando la estructura del mensaje), un XSL (indicando la forma en que deberá codificarse en pantalla o traducirse a un sistema de gestión determinado) y un XML de validaciones (indicando que validaciones deberán aplicarse para cada campo) que pueden ser interpretados automáticamente por una aplicación capaz de construir un formulario, realizar las validaciones, etc…

  • Interoperabilidad. La construcción de una aplicación de procesamiento y gestión de EDIXML, desarrollada en XML permite un alto grado de interoperabilidad con plataformas y aplicaciones preparadas para soportar este estándar.

En definitiva, la ventaja del EDIXML frente al EDI convencional radica en su flexibilidad a la hora de realizar los frecuentes cambios de formato que sufren los mensajes de intercambio documental.

Conclusiones

Durante más de dos décadas muchas empresas disponen y utilizan sistemas transaccionales de comercio electrónico basados en el B2B a través de EDI. Los grandes centros comerciales, por ejemplo, solo admiten entre sus proveedores a aquellos que disponen de sistemas EDI capaces de atender sus pedidos electrónicamente a través de VANs (Redes de Valor Añadido). Nadie puede pensar que un gran establecimiento (con más de 100.000 millones de facturación anual) va a utilizar sistemas de solicitud de pedidos basados en páginas web ya que sería económicamente muy costoso (piénsese en un departamento de personas rellenando formularios).

Con Internet, la forma de trabajar de estas grandes empresas del comercio no va a variar porque incluso sus líneas de comunicación EDI no salen a Internet. La auténtica revolución reside en que la pequeña y mediana empresa ahora si que puede comerciar con los grandes establecimientos (B2B) a través de los servicios que pueda prestarle una VAN que disponga de aplicaciones EDIWEB.

Dichos servicios se basan en la posibilidad de enviar y recibir mensajes EDI, tanto a través de email y FTP (los dos sistemas más eficientes y rápidos) como de formularios en web (EDIWEB). Si una empresa necesita procesar y servir pedidos con una cierta asiduidad, lo más normal es que utilice, por ejemplo, sistemas basados en email para enviar los mensajes EDI y que acuda al web para conocer el «status» de los pedidos, envíos o simplemente de los pagos. Si por otro lado, la empresa es pequeña, no necesitará ni tener generadores EDI propios ya que podrá servir pedidos atendiendo directamente la solicitud a través de web (podrá enviar el mensaje de confirmación -APERAK- desde un formulario).

Con la llegada de XML, el panorama mejora aun más. El costoso problema de los cambios de estándar EDI que obliga a la realización de cambios en los generadores de documentos con una periodicidad más que elevada se soluciona con la introducción del EDIXML ya que con el procesamiento automático de los ficheros DTD (esquema del documento) y XSL (presentación/traducción), se puede actualizar la generación y recepción del mensaje que ha variado sin tener que reprogramar la aplicación.

El EDI está mucho más presente en nuestras vidas de lo que creemos y gracias a Internet y a XML, cada vez serán más las empresas, PYMEs, que se podrán apuntar a el y participar del comercio B2B.

The «Hello World» Applet in Java

You have been listening a lot of things about Java for several years, but suddenly you have discovered that not even you know just produce a simple «Hello World». No problem… you are in the good way to become a Java Discover.

In order to implement a «Hello World» applet you need to download the Java 2 Software Development Kit (SDK) from http://java.sun.com/. This kit allows you to compile and debug your Java software.

Follow next steps in order to become a succesfull appleter:

1) Install the Java 2 SDK in your computer (i.e. NT Workstation 4.0).

2) Write a source file in Java named «Hola.java» using the WordPad editor. This file must contain:

import java.awt.*;

public class Hola extends java.applet.Applet {

public void paint(Graphics g) {

g.drawString(«Hello World», 5, 50);

}

}

and must be placed in the ../SDK Directory/bin/ directory where you have installed the SDK.

3) Compile the file through the Java Compiler (javac) using next sentence from ../SDK Directory/bin/ directory in the MS DOS prompt:

javac Hola.java

This action creates an executable file named Hola.class

4) Now, you have to create the HTML page that calls the applet Hola.class. In this way, edit a file called «Test.html» that contains:

<HTML><APPLET CODE=Hola.class></APPLET> </HTML>

5) And it’s all !. Assure that the .HTML and .CLASS files are in the same directory and execute the web page (Test.html) with Netscape Navigator or Internet Explorer.