Si has cambiado de placa o procesador y tienes una licencia digital de Windows 10, definitivamente tendrás problemas. Si bien Microsoft te da la opción con el solucionador de problemas de corregir el error 0xC004C003 y poder reactivar Windows, esta no funcionará.
La opción del Solucionador de problemas indicando "Cambio de Hardware", podrás indicar en la lista de equipos cual es el indicado (Debes tener una cuenta Outlook.com). Posterior a ello volverá aparecer el error 'xC004C003 y Microsoft te indicará que lo vuelvas a intentar luego. Si has leído o te han contado que es por saturación en su servicio y que posteriormente te activará Windows de forma automática, es incorrecto.
No intentes bajar un KEY de Internet, este no funcionará, recuerda que tienes una licencia digital, ello no es aplicable. No intentes instalar un crack, es una solución temporal que se des-habilita en una actualización de Windows; salvo que nunca actualices tu sistema operativo (No recomendado).
Esto es lo que debes hacer:
1.- Si has actualizado Windows de una versión previa, tal como Windows 7, Windows 8 o Windows 8.1, busca la clave. Recuerda, estamos asumiendo que no es pirata y debe ser una licencia firme.
2.- Si tienes la clave, esta te servirá para llamar al servicio de atención al cliente. Alcanzo el Url de la lista de atención de Microsoft, verifica tu país:
https://support.microsoft.com/en-us/help/4051701/global-customer-service-phone-numbers
3.- En el Call Center selecciona la opción de atención Windows Hogar. Si eres una empresa que compró licencias corporativas, lo seleccionarás.
4.- El personal técnico de Microsoft te hará unas preguntas referente a tu PC o Laptop. Por ejemplo la versión de Windows 10 que tienes instalado.
5.- Te indicará que proporciones el código de la clave de tu Windows previo, el punto 1. Si no lo tienes debes indicar que lo perdiste.
6.- Te preguntaran por un correo que tengas, si tienes uno de Outlook.com, seria bueno pero no obligatorio (Crear una cuenta de Outlook.com es recomendada para que gestiones tus equipos con las licencias digitales asignadas a dichos equipos). Luego te envían un correo a la cuenta para validarla.
6.- El personal técnico te indicará que debes pagar una penalidad de 40 US$. Esta transacción lo harás con una tarjeta de crédito. Si has comprado algo en Microsoft, el te hará la validación con los últimos 4 dígitos de tu tarjeta de crédito.
7.- Una vez que pagues, te llegará un correo indicando la transacción. Todo se hace mientras estas en linea con el soporte de Microsoft.
8.- Confirmado, te envía 2 correos, el primero es el enlace para que puedas descargar la clave, el segundo es una contraseña que te permitirá acceder a ver la nueva clave de Windows 10.
9.- Con la clave lista, vas a activación de Windows y seleccionas cambiar de clave. Introduces esta nueva.
10.- Esperas unos segundos y LISTO.
11.- Te despides como debe ser. Recuerda, esta nueva clave no la debes perder la podrás usar aun si cambias en un futuro el Hardware. La clave.
Pagar 40 US$ es mejor que pagar 270 US$ que es lo que cuesta una licencia de Windows 10 Pro. Además ya no tendrás problemas de futuros cambios en el Hardware.
Publicación de Factura Boletas y Notas electrónica Sunat
El proceso de publicación de documentos electrónicos para los Sistemas de Emisión Desde el Contribuyente (SEE) debe contemplar un flujo con control de errores, no solo desde el punto de vista del sistema, también del retorno que envían los servicios de la SUNAT.
Desde el punto de vista del sistema cliente, pueden ocurrir errores de conexión a Internet y errores de disponibilidad del servicio SUNAT. En estos casos todo ocurre en el lado del cliente y debemos llevar un control de errores del sistema e informar el estado del registro o documento electrónico que queremos enviar.
Asumiendo que estamos con la disposición de conexión a Internet y el servicio SUNAT responde adecuadamente, debemos contemplar los errores que el servicio pueda retornar antes del procesamiento del lado del servicio. La SUNAT tiene los códigos de error menor a 1000 que indican problemas de atención al cliente, estos nos permiten poder en estos casos poder reenviar los documentos.
El diagrama de flujo se ha tratado se hacer muy simple, no contemplando procesos paralelos y mostrando solo decisiones booleanas. Este diagrama por su simplicidad solo es un alcance del proceso de publicación de documentos electrónicos SUNAT. En el diagrama estamos asumiendo que existe disponibilidad de conexión a Internet y de los servicios SUNAT. Las notas adjuntas al diagrama pueden ser tomadas como procesos que se pueden explotar.
No pensemos que los servicios SUNAT son muy eficientes, estos tienen errores no controlados por el servicios que ocasiona no terminar el ciclo de publicación. Generalmente pasa con la respuesta SUNAT (CDR), estos pueden venir corruptos o no llegan al cliente; en ambos casos debemos estar preparados para ello.
Cuando el ciclo de publicación terminar con retorno del CDR, tiene un código de retorno y un mensaje de respuesta. En el caso de rechazo de un documento viene con código de error mayor 1000 y menor a 4000. En el caso de un código de retorno mayor a 4000 indica que el sistema debe tomar nota de ello, es una advertencia o recomendación que debemos tomar en cuenta. En el caso de un rechazo, no tenemos una nueva oportunidad de enviarlo, el registro formara parte de los documentos anulados. Si tenemos error menor a 1000, la SUNAT nos da la oportunidad de volver a enviar el documento electrónico.
Los documentos que tienen oportunidad de volver a enviarse, deben estar en un repositorio de documentos por reenviar. El sistema debe brindar al usuario la opción de un nuevo envío de estos registros. Este proceso de reenvío debe realizar el ciclo desde el punto que cuenta con el archivo XML firmado y comprimido en formato ZIP; ademas, debe estar ya en la Base de datos con estado por reenviar. El diagrama iniciaría con el proceso "Envio a Sunat".
Los documentos que están por reparar, deben solo descargar el CDR para comprobar el código de retorno y el mensaje Sunat. En caso que tuviéramos un rechazo (Error >1000 y Error <4000), el sistema debe actualizar los estados del registro para indicar que el documento fue rechazado. Si tiene un retorno mayor a 4000, solo actualizamos el registro en OK , pero indicando el mensaje y el código que ha retornado en el CDR descargado.
En el diagrama se muestra que se envía el correo al cliente con el archivo PDF y el XML adjunto en 2 casos: Si el documento ha tenido éxito o si no hemos obtenido el CDR (Por reparar). Esto lo indico porque asumimos el beneficio de la duda. Si bien no tenemos el CDR, asumimos que el documento ha sido aprobado por la SUNAT. Bueno, en el caso que al reparar el documento nos enteremos que ha sido rechazado, es necesario volver a generarlo e informar al cliente que el documento electrónico volverá a ser generado por el problema anterior explicado. Alguien puede tener una alternativa a este flujo, pero el error potencial esta fuera de nuestras manos en el ciclo de publicación; o puede ocurrir que se corte la conexión en la espera de la respuesta SUNAT (CDR), es un escenario que igual se presenta y se puede resolver enviando el correo electrónico al cliente con los adjuntos.
En un sistema de generación de documentos de venta estándar, todos los procesos están bajo control del sistema, los tratamientos de errores nos permite poder cumplir con el ciclo de emisión de un documento de venta. En el caso de una emisión electrónica, existen procesos que están fuera de nuestro control, la SUNAT como ente regulador valida la emisión de un documento, este puede ser aprobado o rechazado. Ademas, existen procesos de comunicación remota que forma parte de la transacción de publicación del documento. Estamos hablando que en la emisión electrónica participan la SUNAT como una entidad en el modelo de procesos del sistema. Además, existen procesos desconectados como los procesos de baja de un documento electrónico, del cual solo obtenemos un Ticket de atención desde los servicios SUNAT que posteriormente el sistema debe validar para obtener la respuesta si el documento solicitado ha sido dado de baja con éxito.
Voy a en unas próximas publicaciones haré hincapié otros procesos importantes en la emisión y gestión de documentos electrónicos. En todos los casos hablaremos de sistemas de emisión desde el contribuyente.
Emisión electrónica. Las OSE y los PSE
La SUNAT lanzó a producción en Agosto del 2018 de forma opcional las OSE. Bueno, esto suena a que el ente regulador libera la sobre carga que tienen actualmente sus servidores. Esto lo vemos en el decrecimiento de la calidad de servicio que actualmente esta mostrando la SUNAT. No se si es coincidencia, pero estos últimos meses los servicios de la SUNAT tienen muchos problemas. Las horas de mantenimiento de sus servicios han aumentado de forma considerable, afectando no solo a la emisión, también a los procesos de consulta de documentos.
Pero en que nos beneficia trabajar con las OSE, quienes son ellos?. Estos operadores de servicios electrónicos son en realidad los mismos Proveedores de Servicios Electrónicos (PSE), con un adicional, ampliar la cartera de clientes. Ahora estamos hablando que abarcaran a las empresas que desarrollaron sus sistemas o adquirieron un Sistema de Emisión Desde el Contribuyente (SEE).
Las empresas que contratan un OSE esperan tener el mismo servicio que ofrece la SUNAT, pero eso no es correcto, o mejor dicho no es la realidad. Una OSE solo es un intermediario, que tiene una validación parcial de un documento electrónico, a fin de cuentas, la SUNAT siempre será la que dará la aprobación final.
Las empresas que cuentas con sistemas SEE, esperan tener la respuesta inmediata a la emisión de un documento electrónico. Con los problemas que existen en la SUNAT, muchas empresas acceden generalmente al portal de la SUNAT a chequear si el documento está correctamente emitido, esto sucede cuando el ciclo de la emisión electrónica no se ha cumplido; por ejemplo, cuando el CDR no ha sido recibido por los sistemas de la empresa o cuando el CDR llega corrupto.
Si la SUNAT con los años de experiencia aun tiene problemas de servicio, queda esperar que problemas tendremos con las OSE; estas son empresas con poca o ninguna experiencia en el servicio de validación y aprobación de documentos electrónicos. No me imagino que pasará en estos momentos entre ellos, pero seguro están haciendo muchos jales de profesionales que trabajan en la SUNAT para suplir su falta de experiencia.
Los documentos técnicos que la SUNAT brinda a las OSE indican que existirán periodos de tiempo en los cuales la información almacenada por las OSE deben sincronizarse con los sistemas de la SUNAT. Estamos viendo un escenario muy similar a un PSE.
Al final de cuentas, beneficia tener que contratar un OSE y pagar por cada emisión de un documento?, valió la pena desarrollar un sistema de emisión SEE?, Bueno, por lo pronto es opcional contratar los servicios de un OSE. Un OSE solo será considerado como opción a los servicios de la SUNAT cuando ejecute todo el ciclo de la validación de un documento electrónico tal cual la SUNAT lo realiza actualmente, pero creo que es imposible.
Pero en que nos beneficia trabajar con las OSE, quienes son ellos?. Estos operadores de servicios electrónicos son en realidad los mismos Proveedores de Servicios Electrónicos (PSE), con un adicional, ampliar la cartera de clientes. Ahora estamos hablando que abarcaran a las empresas que desarrollaron sus sistemas o adquirieron un Sistema de Emisión Desde el Contribuyente (SEE).
Las empresas que contratan un OSE esperan tener el mismo servicio que ofrece la SUNAT, pero eso no es correcto, o mejor dicho no es la realidad. Una OSE solo es un intermediario, que tiene una validación parcial de un documento electrónico, a fin de cuentas, la SUNAT siempre será la que dará la aprobación final.
Las empresas que cuentas con sistemas SEE, esperan tener la respuesta inmediata a la emisión de un documento electrónico. Con los problemas que existen en la SUNAT, muchas empresas acceden generalmente al portal de la SUNAT a chequear si el documento está correctamente emitido, esto sucede cuando el ciclo de la emisión electrónica no se ha cumplido; por ejemplo, cuando el CDR no ha sido recibido por los sistemas de la empresa o cuando el CDR llega corrupto.
Si la SUNAT con los años de experiencia aun tiene problemas de servicio, queda esperar que problemas tendremos con las OSE; estas son empresas con poca o ninguna experiencia en el servicio de validación y aprobación de documentos electrónicos. No me imagino que pasará en estos momentos entre ellos, pero seguro están haciendo muchos jales de profesionales que trabajan en la SUNAT para suplir su falta de experiencia.
Los documentos técnicos que la SUNAT brinda a las OSE indican que existirán periodos de tiempo en los cuales la información almacenada por las OSE deben sincronizarse con los sistemas de la SUNAT. Estamos viendo un escenario muy similar a un PSE.
Al final de cuentas, beneficia tener que contratar un OSE y pagar por cada emisión de un documento?, valió la pena desarrollar un sistema de emisión SEE?, Bueno, por lo pronto es opcional contratar los servicios de un OSE. Un OSE solo será considerado como opción a los servicios de la SUNAT cuando ejecute todo el ciclo de la validación de un documento electrónico tal cual la SUNAT lo realiza actualmente, pero creo que es imposible.
Facturación electrónica SUNAT
Han pasado algunos años desde el lanzamiento del servicio de Emisión electrónica de la SUNAT, esto ha servido para que las empresas que desarrollaron los Sistemas de Emisión Desde el Contribuyente (SEE), mejoren los procesos de gestión de la información. Con la Versión 2.0 de UBL abrió el camino a un continuo mejoramiento en la gestión de información de los sistemas. Este estándar de estructuración de la información ha permitido mejorar el intercambio de información entre las empresas y el ente regulador.
Las empresas que iniciaron con los Sistemas de Emisión desde el Contribuyente (SEE) se han visto beneficiadas con estos procesos de gestión, las empresas que optaron por los servicios de los PROVEEDORES DE SERVICIOS ELECTRÓNICOS (PSE) solo modificaron los procesos de envío de información con estos proveedores, pero no reestructuraron sus sistemas; estos procesos de conversión de equivalencias de datos ha creado duplicidad de procesos para poder adecuar la información a las exigencias de una emisión electrónica con UBL.
Los sistemas SEE mejoran los procesos desde la fuente, permite poder desarrollar nuevos procesos de gestión comercial que se integran de forma natural con otros procesos de la empresa, por ejemplo el proceso de compra (UBL-ORDER-2.1.XSD, UBL-ORDERCANCELLATION-2.1.XSD, UBL-ORDERCHANGE-2.1.XSD, UBL-ORDERRESPONSE.XSD), el proceso de carga de las facturas y notas electrónicas que las emiten los proveedores. Estamos hablando de procesos que se integran en la venta y la compra.
Actualmente con la nueva Versión UBL 2.1, han cambiado las características exigidas para la emisión electrónica; se ha mejorado la forma como se compilan los totales de una Factura y es consistente con el detalle del documento, se ha fortalecido la definición de los tipos de operación con el contenido del documento electrónico y manejan de forma mas eficiente la clasificación de los tipos de tributo y las afectaciones al IGV. Los tipos de operación de exportación se ha desagregado, ahora es detallado entre exportación de bienes y de servicios. Se ha dado mas fuerza a las exportaciones y a los servicios de paquetes turísticos. Las ventas de servicios como boletos y paquetes por agencias de viaje es muy detallado, beneficia a los operadores como AMADEUS, estos pueden integrar fácilmente la venta o reserva de pasajes aéreos con una Factura o Boleta electrónica. Estamos hablando que estos operadores se convierten en unos seudo PSE.
El UBL 2.1 no esta personalizado como ocurrió con la versión 2.0 que lanzó la SUNAT. La facturas de exportación pueden ser fácilmente digeridas por sistemas de otros países porque no existen definiciones personalizadas. Las extensiones (UBLExtensions) son estrictas, esto beneficia el intercambio de datos con sistemas de otros países. Los códigos de errores han cambiado conforme a las nuevas exigencias.
La nueva versión exigida por la SUNAT (UBL 2.1) será mucho mas estable, permitirá disminuir las versiones de cambio que tuvieron con UBL 2.0. Las empresas tendrán menores costes de mantenimiento de los sistemas de venta y compra. El futuro es integrar la información generada por las ventas y la compras con los libros electrónicos, pero aun la SUNAT debe mejorar la generación de libros electrónicos con los estándares UBL 2.1.
Si bien existe una versión nueva UBL 2.2, aun tiene que madurar, pero siempre llevará a mejoras en los procesos empresariales. El objetivo es mejorar el intercambio de información entre las empresas.
Las empresas que iniciaron con los Sistemas de Emisión desde el Contribuyente (SEE) se han visto beneficiadas con estos procesos de gestión, las empresas que optaron por los servicios de los PROVEEDORES DE SERVICIOS ELECTRÓNICOS (PSE) solo modificaron los procesos de envío de información con estos proveedores, pero no reestructuraron sus sistemas; estos procesos de conversión de equivalencias de datos ha creado duplicidad de procesos para poder adecuar la información a las exigencias de una emisión electrónica con UBL.
Los sistemas SEE mejoran los procesos desde la fuente, permite poder desarrollar nuevos procesos de gestión comercial que se integran de forma natural con otros procesos de la empresa, por ejemplo el proceso de compra (UBL-ORDER-2.1.XSD, UBL-ORDERCANCELLATION-2.1.XSD, UBL-ORDERCHANGE-2.1.XSD, UBL-ORDERRESPONSE.XSD), el proceso de carga de las facturas y notas electrónicas que las emiten los proveedores. Estamos hablando de procesos que se integran en la venta y la compra.
Actualmente con la nueva Versión UBL 2.1, han cambiado las características exigidas para la emisión electrónica; se ha mejorado la forma como se compilan los totales de una Factura y es consistente con el detalle del documento, se ha fortalecido la definición de los tipos de operación con el contenido del documento electrónico y manejan de forma mas eficiente la clasificación de los tipos de tributo y las afectaciones al IGV. Los tipos de operación de exportación se ha desagregado, ahora es detallado entre exportación de bienes y de servicios. Se ha dado mas fuerza a las exportaciones y a los servicios de paquetes turísticos. Las ventas de servicios como boletos y paquetes por agencias de viaje es muy detallado, beneficia a los operadores como AMADEUS, estos pueden integrar fácilmente la venta o reserva de pasajes aéreos con una Factura o Boleta electrónica. Estamos hablando que estos operadores se convierten en unos seudo PSE.
El UBL 2.1 no esta personalizado como ocurrió con la versión 2.0 que lanzó la SUNAT. La facturas de exportación pueden ser fácilmente digeridas por sistemas de otros países porque no existen definiciones personalizadas. Las extensiones (UBLExtensions) son estrictas, esto beneficia el intercambio de datos con sistemas de otros países. Los códigos de errores han cambiado conforme a las nuevas exigencias.
La nueva versión exigida por la SUNAT (UBL 2.1) será mucho mas estable, permitirá disminuir las versiones de cambio que tuvieron con UBL 2.0. Las empresas tendrán menores costes de mantenimiento de los sistemas de venta y compra. El futuro es integrar la información generada por las ventas y la compras con los libros electrónicos, pero aun la SUNAT debe mejorar la generación de libros electrónicos con los estándares UBL 2.1.
Si bien existe una versión nueva UBL 2.2, aun tiene que madurar, pero siempre llevará a mejoras en los procesos empresariales. El objetivo es mejorar el intercambio de información entre las empresas.
Evolución de la tecnología de Software parte 2
Los años 90 fueron de grandes cambios. Se comenzó a difundir la INTERNET en el Perú por el año 1991, lo cual causo un gran revuelo en los círculos académicos de informática. Lo comenzamos a ver como una gran RED metropolitana; no podíamos verlo de forma distinta dado que recién se iniciaba y muy pocos en el Perú tenían conocimiento del potencial que llevaba consigo. En países europeos y asiáticos, solo las instituciones académicas contaban con un mayor conocimiento. Pero muchas empresas comerciales e industriales, no tenían conocimiento de esta nueva tecnología. Me costó convencer a los directivos de la empresa donde laboraba, adquirir INTERNET. Fue una apuesta que bien podía costarme el puesto; pero valió la pena.
Las herramientas para desarrollar páginas Web eran primitivas, tenía que programar con lenguaje C y usar la arquitectura CGI y FASTCGI. Era distinto ver el nuevo lenguaje de marcas llamado HTML en sus primeras versiones. Recuerdo que tener INTERNET era todo un lujo que pocos podían darse. Comprar un MODEM con una velocidad aproximada de 9 KBS era algo increíble; el precio era aproximadamente de 1000 US$. Y ni que hablar del contrato con el operador de telefonía.
Por el año 1993, más que desarrollar páginas Web, el potencial que vimos era la transferencia de archivos con el protocolo FTP. Convencimos a nuestros proveedores de implementar INTERNET y poder intercambiar archivos. Antes, el intercambio de información se hacía de forma impresa, con equipos de Fax, pero era muy complicado pasar la información impresa a nuestros sistemas. Esto fue toda una revolución tecnológica, podíamos enviar un recibir información digital y transferirla de forma directa a nuestros sistemas. Podíamos digitalizar una imagen con un escáner y enviarla por FTP a nuestro proveedor por alguna falla de fábrica de un producto. En aquellos años fuimos los precursores de INTERNET en el Perú, la empresa donde laboraba estaba a la vanguardia en tecnología de información. Se enlazaron nuestros sistemas a fuentes de información externa, utilizando tecnología barata de comunicaciones (Comparado con otros sistemas que usaban redes metropolitanas con líneas dedicadas).
Algo que valoraron los directivos de la empresa fue la disponibilidad de información. Se podía planear políticas de precios y disponibilidad de stock de nuestros productos. Solo nosotros contábamos con esa ventaja comparativa respecto a nuestros competidores. Esto nos permitió crecer muy rápido en el mercado y llegamos a ser el número uno en el rubro.
Uno de los principales cambios en la tecnología fue con el lanzamiento de Windows 95. Fue extraordinario ver un sistema operativo totalmente gráfico. Con las versiones anteriores de Windows, la consola gráfica era opcional, y muchos utilizaban solo interface modo texto. Pero todo cambió; ver el arranque directo en modo gráfico fue una experiencia totalmente nueva. La consola modo texto debía ser solo opcional, los usuarios ya no volverían a una interface modo texto. Teníamos que pensar en desarrollar sistemas de un modo totalmente distinto. Ya no habría más programación directa en la memoria de pantalla, ya no habría más programación directa del teclado – No se programaría más las interrupciones del sistema. Esto realmente si cambio todo. Microsoft implementaba los SDK, y se tendría que programar sobre ello.
Con la Suite de desarrollo de Microsoft, tomó fuerza el lenguaje Visual Basic; si, el lenguaje legendario de muy larga trayectoria era la herramienta que los desarrolladores promedio podrían utilizar para desarrollar sistemas en Windows 95. Los más duros tenían el lenguaje C (Microsoft C Compiler) y Visual C++ para ser utilizado. Si deseabas programar controladores, Microsoft tenía en lenguaje Macro Assembler como alternativa para las empresas que se dedicaban a ello.
Era totalmente distinto programar en una nueva plataforma. Recuerdo que migrar sistemas en modo texto no tenía sentido, lo mejor era volver a construirlo. Mucho se promovió las librerías MFC (Microsoft Foundation class) para C++. Fue un gran aporte de Microsoft para los desarrolladores que venían de un lenguaje estructurado como el ANSI C. Además, proveía muchas clases que ahorraban trabajo.
Recuerdo que el cambio de lenguaje estructurado a un lenguaje basado en objetos fue un poco duro. Se tenía que pensar de otra forma. Algo que me ayudo fue haber programado en Pascal; este lenguaje ya tenía implementado la tecnología de objetos, pero solo lo usaba con fines académicos.
Lo más complicado era tomar la decisión como plantear la solución en un sistema empresarial; definitivamente era distinto. Tenías 2 opciones, diseñar las clases basado en procesos o diseñar las clases basado en entidades. Finalmente la decisión fue el diseño por procesos, era algo más afín a los procesos empresariales y por los antecedentes de los sistemas, era lo conveniente para mantener la línea del conocimiento adquirido con los sistemas anteriores.
Desde el año 1993 utilizaba el Compilador Borland C, una herramienta fabulosa, extremadamente flexible y muy robusta. Pero con los cambios de 1996, era necesario tener una nueva herramienta acorde con los nuevos requerimientos. A finales de 1995 me llego el nuevo compilador Borland C++, impresionante, mucho mejor que Visual C++. Algo que me obligo a mantener ambas herramientas como fundamentales en mi trabajo.
Borland marco gran parte de mi vida, desde sus versiones de Turbo Pascal, Turbo C, Turbo Assembler y Turbo Basic, siempre lo considere como la empresa que revoluciono toda la tecnología de desarrollo. Aun veo con nostalgia todas esas herramientas.
En el año 1997 tuve la oportunidad de programar en Borland Delphi, era Pascal por objetos. Era desarrollar para entornos gráficos. Quedaba atrás Pascal como lenguaje estructurado y venia este lenguaje 100% por objetos y totalmente implementado para el desarrollo de entorno gráfico. Lo utilice mucho en la parte académica. No había nada que hacer, Borland era un genio. Era tan potente que las librerías para C++ de Borland eran creadas con Delphi. Si querías modificar los componentes desde la fuente, debías programar en Delphi Pascal. Todas las librerías graficas de Borland C++ estaban desarrolladas en este lenguaje.
Desde 1995, con el lanzamiento de Windows 95, fue todo un cambio. Esto afecto a las bases de la tecnología de desarrollo. Surgían los nuevos modelos de desarrollo de Software. Si querías ser un programador seria, debías programar en estos lenguajes. Debías crear tus librerías, no había otra manera. Actualmente existen muchas fuentes de donde puedes obtener esto, lo cual te ahorra mucho trabajo. Cada librería que desarrollabas debías hacer tu mismo las pruebas de carga y las validaciones de resultados antes de ponerlo en producción.
A finales de los 90 la programación por objetos maduró mucho y se asentó como la forma ideal de crear sistemas. Había quedado atrás la programación estructurada. Los nuevos patrones de desarrollo se debían formar basado en esta forma de programar. Los nuevos conceptos de encapsulamiento, herencia y polimorfismo debían ser parte inherente a la hora de plantear un desarrollo de Software.
Las herramientas para desarrollar páginas Web eran primitivas, tenía que programar con lenguaje C y usar la arquitectura CGI y FASTCGI. Era distinto ver el nuevo lenguaje de marcas llamado HTML en sus primeras versiones. Recuerdo que tener INTERNET era todo un lujo que pocos podían darse. Comprar un MODEM con una velocidad aproximada de 9 KBS era algo increíble; el precio era aproximadamente de 1000 US$. Y ni que hablar del contrato con el operador de telefonía.
Por el año 1993, más que desarrollar páginas Web, el potencial que vimos era la transferencia de archivos con el protocolo FTP. Convencimos a nuestros proveedores de implementar INTERNET y poder intercambiar archivos. Antes, el intercambio de información se hacía de forma impresa, con equipos de Fax, pero era muy complicado pasar la información impresa a nuestros sistemas. Esto fue toda una revolución tecnológica, podíamos enviar un recibir información digital y transferirla de forma directa a nuestros sistemas. Podíamos digitalizar una imagen con un escáner y enviarla por FTP a nuestro proveedor por alguna falla de fábrica de un producto. En aquellos años fuimos los precursores de INTERNET en el Perú, la empresa donde laboraba estaba a la vanguardia en tecnología de información. Se enlazaron nuestros sistemas a fuentes de información externa, utilizando tecnología barata de comunicaciones (Comparado con otros sistemas que usaban redes metropolitanas con líneas dedicadas).
Algo que valoraron los directivos de la empresa fue la disponibilidad de información. Se podía planear políticas de precios y disponibilidad de stock de nuestros productos. Solo nosotros contábamos con esa ventaja comparativa respecto a nuestros competidores. Esto nos permitió crecer muy rápido en el mercado y llegamos a ser el número uno en el rubro.
Uno de los principales cambios en la tecnología fue con el lanzamiento de Windows 95. Fue extraordinario ver un sistema operativo totalmente gráfico. Con las versiones anteriores de Windows, la consola gráfica era opcional, y muchos utilizaban solo interface modo texto. Pero todo cambió; ver el arranque directo en modo gráfico fue una experiencia totalmente nueva. La consola modo texto debía ser solo opcional, los usuarios ya no volverían a una interface modo texto. Teníamos que pensar en desarrollar sistemas de un modo totalmente distinto. Ya no habría más programación directa en la memoria de pantalla, ya no habría más programación directa del teclado – No se programaría más las interrupciones del sistema. Esto realmente si cambio todo. Microsoft implementaba los SDK, y se tendría que programar sobre ello.
Con la Suite de desarrollo de Microsoft, tomó fuerza el lenguaje Visual Basic; si, el lenguaje legendario de muy larga trayectoria era la herramienta que los desarrolladores promedio podrían utilizar para desarrollar sistemas en Windows 95. Los más duros tenían el lenguaje C (Microsoft C Compiler) y Visual C++ para ser utilizado. Si deseabas programar controladores, Microsoft tenía en lenguaje Macro Assembler como alternativa para las empresas que se dedicaban a ello.
Era totalmente distinto programar en una nueva plataforma. Recuerdo que migrar sistemas en modo texto no tenía sentido, lo mejor era volver a construirlo. Mucho se promovió las librerías MFC (Microsoft Foundation class) para C++. Fue un gran aporte de Microsoft para los desarrolladores que venían de un lenguaje estructurado como el ANSI C. Además, proveía muchas clases que ahorraban trabajo.
Recuerdo que el cambio de lenguaje estructurado a un lenguaje basado en objetos fue un poco duro. Se tenía que pensar de otra forma. Algo que me ayudo fue haber programado en Pascal; este lenguaje ya tenía implementado la tecnología de objetos, pero solo lo usaba con fines académicos.
Lo más complicado era tomar la decisión como plantear la solución en un sistema empresarial; definitivamente era distinto. Tenías 2 opciones, diseñar las clases basado en procesos o diseñar las clases basado en entidades. Finalmente la decisión fue el diseño por procesos, era algo más afín a los procesos empresariales y por los antecedentes de los sistemas, era lo conveniente para mantener la línea del conocimiento adquirido con los sistemas anteriores.
Desde el año 1993 utilizaba el Compilador Borland C, una herramienta fabulosa, extremadamente flexible y muy robusta. Pero con los cambios de 1996, era necesario tener una nueva herramienta acorde con los nuevos requerimientos. A finales de 1995 me llego el nuevo compilador Borland C++, impresionante, mucho mejor que Visual C++. Algo que me obligo a mantener ambas herramientas como fundamentales en mi trabajo.
Borland marco gran parte de mi vida, desde sus versiones de Turbo Pascal, Turbo C, Turbo Assembler y Turbo Basic, siempre lo considere como la empresa que revoluciono toda la tecnología de desarrollo. Aun veo con nostalgia todas esas herramientas.
En el año 1997 tuve la oportunidad de programar en Borland Delphi, era Pascal por objetos. Era desarrollar para entornos gráficos. Quedaba atrás Pascal como lenguaje estructurado y venia este lenguaje 100% por objetos y totalmente implementado para el desarrollo de entorno gráfico. Lo utilice mucho en la parte académica. No había nada que hacer, Borland era un genio. Era tan potente que las librerías para C++ de Borland eran creadas con Delphi. Si querías modificar los componentes desde la fuente, debías programar en Delphi Pascal. Todas las librerías graficas de Borland C++ estaban desarrolladas en este lenguaje.
Desde 1995, con el lanzamiento de Windows 95, fue todo un cambio. Esto afecto a las bases de la tecnología de desarrollo. Surgían los nuevos modelos de desarrollo de Software. Si querías ser un programador seria, debías programar en estos lenguajes. Debías crear tus librerías, no había otra manera. Actualmente existen muchas fuentes de donde puedes obtener esto, lo cual te ahorra mucho trabajo. Cada librería que desarrollabas debías hacer tu mismo las pruebas de carga y las validaciones de resultados antes de ponerlo en producción.
A finales de los 90 la programación por objetos maduró mucho y se asentó como la forma ideal de crear sistemas. Había quedado atrás la programación estructurada. Los nuevos patrones de desarrollo se debían formar basado en esta forma de programar. Los nuevos conceptos de encapsulamiento, herencia y polimorfismo debían ser parte inherente a la hora de plantear un desarrollo de Software.
Evolución de la tecnología de Software parte 1
Han pasado muchos años desde inicie con mi primer sistema. La tecnología de Software ha evolucionado muy rápido. Desde que comencé programando en las consolas de una PC con un procesador 8086, nunca imagine que todo explotaría con el desarrollo de la INTERNET.
Cada cambio en la forma de desarrollar un sistema fue un poco duro entender los beneficios. Creo que desde esa época (en los 80), se tomaba en broma “Si funciona, no lo toques”. En 1983 eran los años de los sistemas para microcomputadoras. Se distinguían 2 grupos de desarrolladores; los que programaban para Mainframe y los que programaban para PC. Dos mundo muy separado interestelarmente. Muchos de mis amigos programaban en MainFrame y veían la programación en PC como algo no dado para su nivel intelectual; claro, pero era solo cuestión de orgullo.
Desarrollar un sistema para una PC era un camino un poco rudo. Se utilizaba un editar de texto ANSI y el compilador era independiente, así como el proceso de enlace para generar un ejecutable. En aquella época programaba en Assembler con el compilador de Microsoft Macro ensamblador y el proceso de enlace lo hacía con el programa link.exe. Era el enlazador para generar un ejecutable.
Todo se aceleró cuando llegó a mis manos el primer compilador y enlazador en un solo proceso, se llamaban Turbo Assembler y Turbo Pascal. Era una maravilla, pensaba que no existiría nada mejor en muchos años. Cosa que me equivoqué. No solo era un cambio de funcionalidad, era el inicio de la simplicidad. Algo muy importante que llevaría a todo un cambio generacional de las herramientas de desarrollo. Considero que Borland, el creador de esos compiladores, fueron visionarios del futuro de la tecnología de desarrollo. Actualmente, ni nos damos cuenta todo lo que un compilador hace para generar un ejecutable.
La generación de los 80 crearon los fundamentos de los sistemas modernos que tenemos actualmente. Cuando en 1985 programe por primera vez DBASE II y luego DBASE III, era lo que le faltaban a los sistemas para tener el poder de datos persistentes. Bajo un modelo relacional, la tecnología XBASE evoluciono hasta lo que conocemos actualmente. Vaya que si es importante, surgieron los intérpretes DBASE III y DBASE IV, así como FOXPRO. Fueron los años maravillosos para los desarrolladores de Software, podía mirar a las empresas y ofrecer productos que eran rápido de construirse y ofrecerlos a clientes con pocos recursos, los cuales no tenían dinero de comprar un Mainframe.
Aquellos años de innovación, requería de una herramienta que permita generar un ejecutable a partir de un Script de DBASE III. El año 1986 la empresa Nantucket Corporation lanzó CLIPPER, una herramienta que permitía generar un ejecutable a partir de un Script DBASE III. Estos genios permitieron ahorrar ciclos de desarrollo y mayor velocidad en la ejecución de los sistemas orientados a acceso a Base de datos. Ellos crearon 2 compiladores, la versión llamada AUTUMN 86 y SUMMER 87. Esto hizo que los requerimientos de sistemas especializados en procesamiento de datos empresariales, creciera de forma sorprendente. Fue una maravilla, las pequeñas empresas se beneficiaban con sistemas de bajo costo, causando una masificación de las redes de computadoras personales.
Gran parte de la explosión de los procesos automatizados en las empresas conllevo a la necesidad de sistemas operativos de RED. Una empresa que se consolido en el mercado fue Novell, con su sistema operativo Novell NetWare. Las empresas podían acceder a los datos y archivos en RED. Con un servidor central y clientes con sistemas operativos Microsoft DOS. Me acuerdo que teníamos problemas cuando una PC se malograba, esta causaba en una RED lineal que las demás estaciones pierdan conexión. La topología de RED usaba cable coaxial.
Los 90 fue una consolidación de las microcomputadoras en las empresas. Creo que el inicio de esa década avistaba la decadencia de los grandes sistemas que se ejecutaban sobre los MainFrame. Los lenguajes de programación legendarios como ASSEMBLER, COBOL, FORTRAN y RPG iniciaron un proceso de estancamiento. Las microcomputadoras mejoraron ostensiblemente el rendimiento con los nuevos procesadores. Ya comenzamos a pensar en procesadores de 32 Bits. Había pasado la época de los procesadores de 8 y 16 bits. Mis libros de sobre procesadores de 16 bits, estaba quedando en el olvido. Esta nueva época trajo consigo una nueva forma de programación; ya no era necesario pensar programar en ensamblador, o generar rutinas en ANSI C. Los nuevos procesadores eran tan rápidos, que ya no era necesario enterrarse para obtener tiempos de respuesta rápido.
Cuando comencé a programar la primera vez el lenguaje ANSI C, era finales de los 80, creo que fue en 1988. Llego a mis manos el compilador Turbo C. Me quede maravillado por este lenguaje. Era una alternativa a programar en Macro Ensamblador. Era más simple y menos engorroso; con algo adicional muy importante, programabas en modo estructurado y era entendible. Siempre me acuerdo del primer programa: “Hola mundo”. Estaba en los manuales básicos que venían con el compilador. Considero que es el mejor lenguaje de programación que ha existido e inclusive, mejor que los presentes. Es un lenguaje legendario que perdura en el tiempo. Actualmente es usado para el desarrollo de sistemas en tiempo real; es un lenguaje ideal para crear sistemas embebidos dado que no tiene entradas ni salidas, no tiene librerías que necesites ejecutar; todas las librerías son externas al lenguaje. Si necesitas implementar una entrada y una salida de datos, es abstracto, cualquier cosa puede ser una entrada o salida. El compilador te permitía poder declarar funciones en código ensamblador puro dentro del código ANSI C.
Después de cinco años de manejar ANSI C, vino lo mejor, implementar sistemas comerciales totalmente en lenguaje C. Comencé a construir sistemas para la empresa donde trabajaba como Jefe de sistemas. Pero necesitaba algo para dar el impulso que se requería en un sistema empresarial, el acceso a los datos. En esa época, en los años 1993, se manejaba la tecnología XBASE. Compramos una librería para acceder a las bases de datos DBF, era un conjunto de librerías llamada CODE BASE. Desarrollado por una empresa Canadiense llamada Sequiter Software, estas librerías estaban desarrolladas en lenguaje ANSI C. Extremadamente potentes en procesamiento, perfecto para lo que buscaba. Los sistemas desarrollados en lenguaje C, eran potentes para procesamiento en memoria, y, con el complemento de acceso a Base de datos XBASE, nuestros clientes estaban muy satisfechos con los resultados. Estos años fueron increíbles, formé programadores de una gran capacidad técnica. En aquellos años, los programadores en lenguaje C eran de un grupo elite y muy respetados. El lenguaje C era considerado un lenguaje muy complejo de aprender (Cosa que no era muy cierta, desde mi punto de vista).
A inicios de los 90, si bien se usaba Windows, creo que no era una herramienta confiable; muchas empresas aun mantenían el DOS como sistema operativo empresarial. Pero cuando Microsoft lanzo la versión Windows 3.1, cambió radicalmente la forma como las empresas vieron a Windows. Ahora, era posible poder tenerlo como un sistema operativo que podía formar parte de las estaciones de trabajo empresarial. Microsoft tuvo que trabajar duro para hacerlo compatible con las Redes Novell Netware. Microsoft tenía su protocolo de RED, incompatible con Novell. Pero con suma habilidad, permitió poder instalar el Software cliente de Novell en la versión de Windows 3.1. Novell NetWare era de lejos un mejor sistema operativo de RED.
Aun muchos desarrollares se especializaban en el desarrollo sobre plataformas Novell NetWare. En esos años no se implementaba el protocolo TCP/IP en redes de microcomputadoras. Era si, muy utilizado en grandes redes. Esta falta de estandarización obligaba a tener que programar los sistemas considerando muchos componentes de redes disímiles. Cada vez que teníamos que configurar una RED Novell NetWare, era toda una faena de 9 horas de trabajo.
Espero que este primer artículo sea de su interés, tratare de ser más conciso en la segunda parte.
Cada cambio en la forma de desarrollar un sistema fue un poco duro entender los beneficios. Creo que desde esa época (en los 80), se tomaba en broma “Si funciona, no lo toques”. En 1983 eran los años de los sistemas para microcomputadoras. Se distinguían 2 grupos de desarrolladores; los que programaban para Mainframe y los que programaban para PC. Dos mundo muy separado interestelarmente. Muchos de mis amigos programaban en MainFrame y veían la programación en PC como algo no dado para su nivel intelectual; claro, pero era solo cuestión de orgullo.
Desarrollar un sistema para una PC era un camino un poco rudo. Se utilizaba un editar de texto ANSI y el compilador era independiente, así como el proceso de enlace para generar un ejecutable. En aquella época programaba en Assembler con el compilador de Microsoft Macro ensamblador y el proceso de enlace lo hacía con el programa link.exe. Era el enlazador para generar un ejecutable.
Todo se aceleró cuando llegó a mis manos el primer compilador y enlazador en un solo proceso, se llamaban Turbo Assembler y Turbo Pascal. Era una maravilla, pensaba que no existiría nada mejor en muchos años. Cosa que me equivoqué. No solo era un cambio de funcionalidad, era el inicio de la simplicidad. Algo muy importante que llevaría a todo un cambio generacional de las herramientas de desarrollo. Considero que Borland, el creador de esos compiladores, fueron visionarios del futuro de la tecnología de desarrollo. Actualmente, ni nos damos cuenta todo lo que un compilador hace para generar un ejecutable.
La generación de los 80 crearon los fundamentos de los sistemas modernos que tenemos actualmente. Cuando en 1985 programe por primera vez DBASE II y luego DBASE III, era lo que le faltaban a los sistemas para tener el poder de datos persistentes. Bajo un modelo relacional, la tecnología XBASE evoluciono hasta lo que conocemos actualmente. Vaya que si es importante, surgieron los intérpretes DBASE III y DBASE IV, así como FOXPRO. Fueron los años maravillosos para los desarrolladores de Software, podía mirar a las empresas y ofrecer productos que eran rápido de construirse y ofrecerlos a clientes con pocos recursos, los cuales no tenían dinero de comprar un Mainframe.
Aquellos años de innovación, requería de una herramienta que permita generar un ejecutable a partir de un Script de DBASE III. El año 1986 la empresa Nantucket Corporation lanzó CLIPPER, una herramienta que permitía generar un ejecutable a partir de un Script DBASE III. Estos genios permitieron ahorrar ciclos de desarrollo y mayor velocidad en la ejecución de los sistemas orientados a acceso a Base de datos. Ellos crearon 2 compiladores, la versión llamada AUTUMN 86 y SUMMER 87. Esto hizo que los requerimientos de sistemas especializados en procesamiento de datos empresariales, creciera de forma sorprendente. Fue una maravilla, las pequeñas empresas se beneficiaban con sistemas de bajo costo, causando una masificación de las redes de computadoras personales.
Gran parte de la explosión de los procesos automatizados en las empresas conllevo a la necesidad de sistemas operativos de RED. Una empresa que se consolido en el mercado fue Novell, con su sistema operativo Novell NetWare. Las empresas podían acceder a los datos y archivos en RED. Con un servidor central y clientes con sistemas operativos Microsoft DOS. Me acuerdo que teníamos problemas cuando una PC se malograba, esta causaba en una RED lineal que las demás estaciones pierdan conexión. La topología de RED usaba cable coaxial.
Los 90 fue una consolidación de las microcomputadoras en las empresas. Creo que el inicio de esa década avistaba la decadencia de los grandes sistemas que se ejecutaban sobre los MainFrame. Los lenguajes de programación legendarios como ASSEMBLER, COBOL, FORTRAN y RPG iniciaron un proceso de estancamiento. Las microcomputadoras mejoraron ostensiblemente el rendimiento con los nuevos procesadores. Ya comenzamos a pensar en procesadores de 32 Bits. Había pasado la época de los procesadores de 8 y 16 bits. Mis libros de sobre procesadores de 16 bits, estaba quedando en el olvido. Esta nueva época trajo consigo una nueva forma de programación; ya no era necesario pensar programar en ensamblador, o generar rutinas en ANSI C. Los nuevos procesadores eran tan rápidos, que ya no era necesario enterrarse para obtener tiempos de respuesta rápido.
Cuando comencé a programar la primera vez el lenguaje ANSI C, era finales de los 80, creo que fue en 1988. Llego a mis manos el compilador Turbo C. Me quede maravillado por este lenguaje. Era una alternativa a programar en Macro Ensamblador. Era más simple y menos engorroso; con algo adicional muy importante, programabas en modo estructurado y era entendible. Siempre me acuerdo del primer programa: “Hola mundo”. Estaba en los manuales básicos que venían con el compilador. Considero que es el mejor lenguaje de programación que ha existido e inclusive, mejor que los presentes. Es un lenguaje legendario que perdura en el tiempo. Actualmente es usado para el desarrollo de sistemas en tiempo real; es un lenguaje ideal para crear sistemas embebidos dado que no tiene entradas ni salidas, no tiene librerías que necesites ejecutar; todas las librerías son externas al lenguaje. Si necesitas implementar una entrada y una salida de datos, es abstracto, cualquier cosa puede ser una entrada o salida. El compilador te permitía poder declarar funciones en código ensamblador puro dentro del código ANSI C.
Después de cinco años de manejar ANSI C, vino lo mejor, implementar sistemas comerciales totalmente en lenguaje C. Comencé a construir sistemas para la empresa donde trabajaba como Jefe de sistemas. Pero necesitaba algo para dar el impulso que se requería en un sistema empresarial, el acceso a los datos. En esa época, en los años 1993, se manejaba la tecnología XBASE. Compramos una librería para acceder a las bases de datos DBF, era un conjunto de librerías llamada CODE BASE. Desarrollado por una empresa Canadiense llamada Sequiter Software, estas librerías estaban desarrolladas en lenguaje ANSI C. Extremadamente potentes en procesamiento, perfecto para lo que buscaba. Los sistemas desarrollados en lenguaje C, eran potentes para procesamiento en memoria, y, con el complemento de acceso a Base de datos XBASE, nuestros clientes estaban muy satisfechos con los resultados. Estos años fueron increíbles, formé programadores de una gran capacidad técnica. En aquellos años, los programadores en lenguaje C eran de un grupo elite y muy respetados. El lenguaje C era considerado un lenguaje muy complejo de aprender (Cosa que no era muy cierta, desde mi punto de vista).
A inicios de los 90, si bien se usaba Windows, creo que no era una herramienta confiable; muchas empresas aun mantenían el DOS como sistema operativo empresarial. Pero cuando Microsoft lanzo la versión Windows 3.1, cambió radicalmente la forma como las empresas vieron a Windows. Ahora, era posible poder tenerlo como un sistema operativo que podía formar parte de las estaciones de trabajo empresarial. Microsoft tuvo que trabajar duro para hacerlo compatible con las Redes Novell Netware. Microsoft tenía su protocolo de RED, incompatible con Novell. Pero con suma habilidad, permitió poder instalar el Software cliente de Novell en la versión de Windows 3.1. Novell NetWare era de lejos un mejor sistema operativo de RED.
Aun muchos desarrollares se especializaban en el desarrollo sobre plataformas Novell NetWare. En esos años no se implementaba el protocolo TCP/IP en redes de microcomputadoras. Era si, muy utilizado en grandes redes. Esta falta de estandarización obligaba a tener que programar los sistemas considerando muchos componentes de redes disímiles. Cada vez que teníamos que configurar una RED Novell NetWare, era toda una faena de 9 horas de trabajo.
Espero que este primer artículo sea de su interés, tratare de ser más conciso en la segunda parte.
Suscribirse a:
Entradas (Atom)