Mostrando entradas con la etiqueta programación. Mostrar todas las entradas
Mostrando entradas con la etiqueta programación. Mostrar todas las entradas

11 agosto 2020

VMWare, Windows 10, caracteres no-ASCII y la madre que lo parió

 En mi trabajo es muy normal usar máquinas virtuales. Antes utilizaba principalmente VirtualBox, pero ahora nos ha llegado una orden desde la dirección de la compañía de que solo podemos utilizar VMWare. Supongo que estos cambios se deben básicamente a las cuentas que hayan hecho pagando licencias...

Así que me puse a instalar VMWare en mi PC de trabajo, un flamante e impresionante DELL precission con 32 Gb de memoria y micro Xeon con 4 cores a 3 Ghz. Vamos, que no está nada mal.

El sistema operativo es Windows 10 actualizado (ya me cago en algún pariente de Bill Gates cuando me sale algún inesperado reinicio por actualizaciones o tarda demasiado en iniciarse o pararse por las actualizaciones).

Descubrí que no hay manera de instalar la versión 15.5.6 (la última de VMWare). Da igual como se intente, sale momentáneamente el logo de VMWare y finaliza, sin realizar la instalación ni explicaciones de que ha pasado.

Como eso ya era mosqueante fui probando versiones anteriores, hasta que llegué a la versión 15.5.2, esta sí que pude instalarla sin problemas.

Contento con haber perdido solo media mañana, decidí intentar actualizar la instalación usando la opción de "buscar actualizaciones" del propio VMWare. Tras un rato descargando e intentando actualizar sale un pop-up que finaliza la actualización con error:

Install of VMWare Workstation Pro failed. Contact VMWare support or your system administrator

Así, sin más, ni códigos de error, ni explicaciones... Mire en los ficheros de log que deja el VMWare y ni rastro de posibles errores o explicaciones...

Bueno, no había perdido toda la mañana, así que decido trabajar con esa versión y crearme una máquina virtual. Cuando voy a arrancarla aparece otro error diferente:

Could not get vmci driver version. Try reinstall VMWare Workstation

Como soy muy obediente hice lo que me decia el mensaje de error, reinstalé otra vez el VMWare (la versión que me funcionaba) y llegué a los mismos errores.

Así que perdida casi toda la mañana decidí acudir a los foros de VMWare, incluso me registré y estuve buscando, pero ninguna de las soluciones propuestas me ayudó (salvo un "atajo" que encontré para solucionar el problema con el vmci, mira este enlace)

Al final perdí todo el día, probando soluciones que encontré en diversos foros, o ideas locas de algún administrador de sistemas, pero nada, no hay manera de instalar la última versión de VMWare.

Hoy he vuelto a perder toda la mañana con el problema (y probando más ideas de otro administrador de sistemas), hasta que me fijé en los ficheros de log que deja en el directorio temporal (%TEMP%) durante la instalación, en él se puede ver algo como lo siguiente:

2020-08-11T15:22:32.796+02:00| BootStrapper-build-16341506| I2: Util_IsDirectory: Not a directory: C:\Users\MeyerMañoso\AppData\Local\Temp\

¿Como era posible que ese directorio no exista? Si es el directorio temporal por defecto para el usuario MeyerMañoso, y sí que existe...

Y de repente vino la inspiración... seguro que en algún sitio tienen una función (posiblemente relacionada en la creación de ficheros temporales) que están usando métodos muy viejos (los 80's atacan de nuevo) y da errores al acceder a un directorio que tenga un carácter no ASCII en el nombre (como es el caso de la tan española "ñ").

Así que cambié en el sistema las variables de entorno TEMP y TMP para que apuntaran a directorios con nombres 100% ASCII (dejé las dos variables apuntando a C:\temp) y volví a intentarlo.

¡Y funcionó!, despues de dia y medio perdido, he conseguido hacer una instalación con la última versión del VMWare, y las máquinas virtuales que he creado ya no dan el error del vmci.

Como conclusión, a partir de la versión 15.5.3 decidieron usar funciones que seguramente alguien desarrollaría en los años 80 que no soportan los caracteres no ASCII.

Así que lo siguiente ha sido abrir mi blog para contar mi historia, por si ayuda a alguien en una situación similar. (he intentado actualizar las entradas en los forum de VMWare, pero llevan todo el dia sin funcionar....).

03 abril 2020

Visual Studio 2008: "Could not locate the .NET Framework SDK"

Hace mucho que no escribia aqui, pero esto tenia que ponerlo en algun lado, puede que a alguien le sea util...

Por motivos de trabajo suelo pelearme con varias versiones de Visual Studio y .NET, no es agradable, pero es así.

Así que tengo una Maquina Virtual WIndows 10 (64 bits) con Visual Studio 2008, para compilar un viejo projecto de mi empresa, y me encontré el siguiente error de compilación:

Error     106       Cryptographic failure while signing assembly 'C:\xxxxx\Debug\xxxxx.dll' -- 'Access is denied. ' 

------ Rebuild All started: Project: xxxxx, Configuration: Debug Any CPU ------
Could not locate the .NET Framework SDK.  The task is looking for the path to the .NET Framework SDK at the location specified in the SDKInstallRootv2.0 value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework.  You may be able to solve the problem by doing one of the following:  1.) Install the .NET Framework SDK.  2.) Manually set the above registry key to the correct location.

Me dediqué a instalar varias versiones de .NET (entre ellas la 2.0 y la 3.0), pero nada, el mismo error...

Así que me dediqué a buscar por foros, y fui encontrando información, aquí y allá, juntando todo eso, y probando bastante llegué a la formula para conseguir compilar mi proyecto, ahí os paso la formula:

  • Cerrar las instancias que tengais abiertas de Visual Studio
  • Crear una entrada de tipo string en el registro de windows, dentro de "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework", con nombre "SDKInstallRootv2.0" y valor "C:\Program Files\Microsoft SDKs\Windows\v6.0A" ( o el directorio que tengais en vuestra maquina para el SDK de windows)
  • Con el explorador de windows ir al directorio "C:\ProgramData\Microsoft\Crypto\RSA", seleccionar la carpeta "MachineKeys", botón derecho del ratón, pestaña "Security" y dar todos los permisos (yo como estaba algo quemado di todos los permisos a "Everyone")

Así conseguí solucionar un problema que me ha estado fastidiando durante varios dias....

Espero que a alguien más le sirva de ayuda.

19 enero 2017

Reutilización del código en las empresas

Todos los que trabajamos en programación conocemos la idea de la reutilización de código. Es sencillo y evidente. Si tienes tu código organizado y bien estructurado, se puede reutilizar desde otro proyecto.

Y evidentemente la mejor forma es mantener esas funciones en sitios comunes que se puedan llamar desde varios proyectos. Eso es lo mejor de lo mejor. Evitamos redundancias de código, optimizamos desarrollo, vamos la leche, ¿a quien no le gusta? 

Pero ahora llegamos a la empresa y veamos que puede pasar:

10 enero 2017

Generar un RPM en windows usando Maven

Quería compartir aquí el resultado de un poco de trabajo de investigación que tuve que hacer hace poco.

Objetivo: Crear un paquete RPM en una máquina Windows, utilizando Maven.

11 septiembre 2014

El extraño caso del compresor y el PIC32

Cuando ya tuvimos el código preparado, todos los componentes hardware conectados, y el desarrollo de la interfaz de usuario terminada, llegó el momento de hacer pruebas.

Fue justo en este momento cuando nos encontramos con un fenómeno curioso, extraño y desesperante a la vez. No siempre pasaba, pero al arrancar o apagar el compresor desde el PIC32, se perdía la sincronización del USB, con lo cual la comunicación entre la interfaz de usuario y el PIC32 se perdía y nos tocaba reiniciar todo el sistema.

Un suceso muy desesperante, pues por mucho que modifiqué el código del USB en el PIC32 no conseguimos ninguna solución.



Lo primero que pensamos fue que debido al alto consumo del compresor teníamos algún efecto (un armónico, o caida/subida de tensión, etc...) que nos llegaba desde la alimentación (ya que al final los dos componentes usan la misma fuente de alimentación). Así que nos liamos a separar las alimentaciones. Pero descubrimos que no, que seguía pasando el mismo fenómeno.

Lo siguiente fue cambiar el compresor (a ver si eso...), pero no, seguía pasando, incluso peor, con el nuevo compresor en el 100% de los casos, al arrancar el compresor, se perdía la comunicación USB.

También intentamos proteger el USB, pero sin ningún resultado.

Haciendo pruebas llegamos a desconectar completamente el compresor, tanto la alimentación como las señales, y lo arrancábamos/parábamos manualmente con un interruptor aislado, pero nada, seguía pasando lo mismo, al arrancar el compresor, se queda dañada la comunicación USB...

Así que acudimos a preguntar en foros, y a consultar a expertos. Ya teníamos un sospechoso, las emisiones electromagnéticas que se tienen que estar produciendo en el arranque del compresor. Las consultas confirmaros nuestras sospechas.

Lo que nos aconsejaron fué utilizar un filtro RC en la alimentación del compresor para absorber las radiaciones. Y trenzar todos los cables (en especial los de alimentación y señales del compresor) ya que el cableado podía estar haciendo un efecto de antena.

Y parece que esa es la solución, en nuestras últimas pruebas, ya no se ha vuelto a producir el maligno efecto "compresor-caida del USB".

04 septiembre 2014

Desarrollando el programa para el PIC32

Al principio del proyecto, mientras estuve en Alemania e Italia, no tenía ningún dispositivo físico para poder probar lo que iba desarrollando. Así que tan sólo pude hacer algunas pruebas sobre el simulador, para aclarar los conceptos y preparar código de algunos temas básicos como las interrupciones (sumamente importantes para los PIC).

Así que en Alemania hice el corazón del programa, desarrollando la estructura, planteando todas las funciones y dejando establecida la lógica que regirá el funcionamiento de mi proyecto.

El entorno de trabajo (MPLAB X) no es complicado de usar, tiene muchos pequeños detalles muy de agradecer por los desarrolladores, aunque a veces tiene funcionamientos extraños (a veces muestra errores donde no los hay, o dice que el proyecto no tiene ficheros, cuando está lleno de código....) que supongo irán depurando y solucionando.



En Junio. y ya en España, insistí mucho en que necesitaba una placa de pruebas para poder seguir con el desarrollo, y me proporcionaron el Ethernet Startet Kit de Microchip. Esta es una interesante placa de pruebas, tiene conexiones Ethernet y USB, y para poder trabajar con entradas/salidas estandard, tiene 3 pulsadores y tres led con los que trabajar. El PIC que monta es un PIC32MX795F512L, más avanzado que el que vamos a utilizar en el proyecto, pero como punto de partida (y hasta que tenga la placa real para poder probar), me vale.

Con eso ya pude completar el desarrollo, por fín pude comprobar como se trabaja con las interrupciones y pude ajustar bien el tema de tiempos (con los simuladores no se puede). Y lo más importante, pude empezar con el desarrollo de las comunicaciones USB.

La placa de control (con el PIC32) hará las funciones de un dispositivo USB, así que tuve que buscar información y ejemplos de como implementar el USB. Por suerte Microchip distribuye una amplia colección de ejemplos con su librería Harmony (y muchos otros en su propia web), y como todo el tema corría prisa, decidí partir del ejemplo de dispositivo USB CDC (en el PC se ve como un dispositivo Serie), e ir avanzando.

Por desgracia la mayoría de la información que se puede encontrar en internet se refiere a la antigua librería de Microchip (deprecada y retirada para los PIC32), así que hay que usar solamente lo que proporciona el fabricante (Microchip Harmony).

Como ya comenté estas librerías han sufrido muchos cambios en poco tiempo (espero que la recién publicada versión 1.00 sea más estable que las anteriores), y me ha tocado rehacer varias veces parte del código para utilizar una versión más actualizada (y todo esto un poco a ciegas, puesto que Microchip no publica los cambios entre versiones, ni cuales son los errores corregidos entre una y otra).

Pero lo conseguí, finalicé el código del proyecto, incluyendo las comunicaciones USB, y otros temas delicados como el conversor analógico digital (ADC), y las comunicaciones I2C (aunque con este último me tuvieron que echar una mano, lo reconozco).

(continuará)


03 septiembre 2014

Iniciando un proyecto con un PIC32

Hace mucho que no escribo aqui, y la verdad es que es imperdonable por mi parte, y más cuando estoy metido en un proyecto que da para muchas entradas...

Por medio de una amiga he entrado en un proyecto de desarrollo de una máquina más o menos compleja, con varios componentes hardware como una bomba, un compresor, sistemas de refrigeración, sondas de temperatura, controles de drivers externos, etc...

La parte que verá el usuario es una interfaz gráfica hecha en Java que corre en una placa Nitrogen (que al final es como un pequeño ordenador), y el control de todos los dispositivos hardware se realiza desde un microchip PIC32 (concretamente un PIC32MX575F256H) montado en una placa que otra gente del equipo ha diseñado para ello.

La parte de la que me encargo yo es de la programación del PIC32. Esto supone un reto, y una forma de volver a acercarme a la parte "hardware" de la informática, aunque como la programación se realiza en C (mejor dicho, un "C" adaptado por el fabricante) no me ha costado demasiado realizarlo.



Ya habíamos hecho algunas reuniones para ir aclarando puntos, pero no recibí las primeras especificaciones hasta finales de Mayo, cuando me tocó ir a Alemania e Italia por cosas de trabajo.

Así que acudí a la página de Microchip (el fabricante de los PIC) para bajarme el entorno de desarrollo (el MPLAB X). Y descubrí, con alivio, que este entorno de trabajo proporciona un simulador que viene muy bien para las tomas de contacto con la herramienta. Evidentemente me bajé toda la documentación que encontré sobre estos micros, así como códigos de ejemplo, librerías, etc...

Y ahí empezaron mis problemas. Descubrí que las librerías que la mayoría de desarrolladores utilizan en sus proyectos con los PIC están descatalogadas para los PIC32, y me tocó acudir a unas librerías de Microchip denominadas  Harmony. Estas librerías aún no se encuentran en una situación estable, e incluso cambian bastante entre una release y la siguiente. Lo que me ha obligado a quedarme atado a una versión en concreto para evitar problemas (hasta hace unas semanas no han sacado la versión "1.0", y cuando empecé con todo esto la versión disponible era la "0.7").

(continuará)


20 marzo 2009

Visual Basic vs. Java

Hace mucho tiempo escribí un pequeñito articulo donde comentaba mis problemas al pasar a Java un viejo programa realizado en Visual Basic. Curiosamente es uno de los artículos más leídos del blog (pese a que no dice nada interesante y lo escribí hace casi 3 años). Por ello he decidido completar el artículo, haciendo una comparación entre estos dos lenguajes de programación.

El Visual Basic tiene su punto fuerte en Microsoft, durante mucho tiempo fue el abanderado en la sección de programación de esta compañía. Permite realizar, en poco tiempo, una aplicación basada en ventanas, que se podía integrar, de una manera más o menos sencilla, con otros componentes como Access, Word, Excell, etc... Y ahí viene su primer problema, es totalmente microsoft, sólo funciona en plataformas Windows. Aunque ahora hay proyectos como Momo que permiten correr aplicaciones Visual Basic en Linux.

Java, en contra, tiene una orientación multiplataforma desde sus inicios, y en general los programas Java pueden correr en una gran variedad de plataformas, normalmente sin tener que realizar cambios. La gran expansión de Java se debe a que se ha vinculado a los desarrollos distribuidos, ampliando las aplicaciones y funciones, está presente en la gran mayoría de desarrollos web de empresa (web services, applets, servlets, java beans, etc...).

Java es un lenguaje orientado a objetos y tiene una inmensa biblioteca de funciones que va creciendo sin parar, tanto por las ampliaciones que realiza Sun (los padres de Java), como por desarrollos de otras empresas, organismos, o particulares que liberan su desarrollo. Visual Basic no es orientado a objetos (permite trabajar con ellos, pero no definirlos), y su librería de funciones está limitada a las proporcionadas por Microsoft.

Java es un lenguaje organizado y estructurado, muy flexible, pero sencillo de manejar incluso por los noveles en programación, existen multitud de entornos para trabajar con él, siendo el más popular el Eclipse, que es un desarrollo abierto con multitud de plugins que ayudan mucho en el desarrollo.

Visual Basic es más desorganizado, obliga a utilizar aberraciones de programación como saltos incondicionales tipo Goto, variables globales, etc.. Prácticamente el único entorno que existe para trabajar con Visual Basic es el Visual Studio, bastante pesado y muy poco flexible.

La gran ventaja con la que contaba Visual Basic era la sencillez para poder realizar programas windows e interfaces de usuario. Pero ahora mismo, con los plugins de Eclipse, y algunos otros entornos de programación, Java está al mismo nivel de sencillez para la programación gráfica.

En empresas el gran ganador es Java, por su orientación multiplataforma, por que está ampliamente utilizado en el mundo web, y desarrollos distribuidos, y por la enorme cantidad de herramientas, librerías de utilidades, etc... que permiten conectar con bases de datos, documentos, aplicaciones gráficas, etc... de cualquier sistema, así como facilitar el trabajo de programadores.

Visual Basic se ha quedado reducido a utilizaciones más o menos puntuales, por lo intrísecamente ligado que está a los demás productos Microsoft, pero no es un lenguaje serio, pese a todos los intentos de microsoft, y se ve reducido a pequeñas y sencillas aplicaciones, scripts para programas Microsoft y poco más.

Pedazo charla que he metido... Espero que a los que buscan ese artículo les sirva de inspiración.


Actualización (2014-09-05)

Oracle se hizo con Java en el 2009, al hacerse con la empresa Sun. Desde entonces ha habido varios "enfrentamientos" entre Oracle y la comunidad de programadores (por los cambios que han añadido a Java, o el intento de modificar la licencia de uso).

Desde que escribí esta entrada han cambiado muchas cosas, y cabe destacar que han desaparecido algunos de aquellos plugins de eclipse que comentaba, aunque han salido otras posibilidades para la programación gráfica, y otros entornos interesantes (como net beans).


Actualización (2016-08-19)

Con el paso de los años he visto más usos en empresas de Visual Basic, pero siguen siendo aplicaciones de uso local, desarrollos a medida y de manera no muy extendida. Pero estoy seguro que hay empresas que tienen grandes desarrollos en Visual Basic. No he usado las últimas versiones del VB para las que ya me han dicho que se ha mejorado la orientación a objetos, aunque sigue sin ser case sensitive ("AA" "aa" "Aa" y "aA" serian los nombres de una misma variable, ¿no os parece lioso?).

En cuanto al Java, ya hay algún comentario donde inciden en el hecho que el Java no es un lenguaje compilado, si no que es interpretado, y tienen razón. Normalmente se llama "compilar el codigo java" a generar los .class que son interpretados por la máquina virtual java en cada entorno, eso es algo que no hay que perder de vista.

Y como nota, fijaros que hay plataformas que trabajan practicamente sólo con Java (como Android), y la programación gráfica (tanto en Java como en VB) ha mejorado muchísimo.

Nota: en las empresas en las que he trabajado, con las que he colaborado, y con las que mantengo algún tipo de relación, los lenguajes que se usan son, en su amplia mayoría Java y C/C++, y, de forma minoritaria, algunas siguen usando admás Cobol, y otras hacen pequeñas aplicaciones con VB.

06 agosto 2008

Trabajo y programación: C y C++

El lenguaje de programación C fué creado por Thompson y Ritchie como evolución de otro lenguaje denominado "B". Es un lenguaje muy ligado a los sistemas operativos, en especial al Unix. Tiene muchas caracterísiticas de bajo nivel, y es el lenguaje ideal para desarrollar aplicaciones críticas.

Es un lenguaje compilado, estructurado, básico, y quizás demasiado minimalista. El C standard tiene un número de bibliotecas relativamente pequeño (muy pequeño si lo comparamos con el Java), y requiere cierto esfuerzo por parte de los principiantes (mayor que con el Java o el Basic, por ejemplo).
Quizás una de sus caracterísiticas principales, el manejo de memoria mediante punteros y su reserva/liberación, sea tambien la que más asusta a los no "iniciados" en la programación en C.

Es un lenguaje muy popular, y hay compiladores de C en gran cantidad de sistemas. Con no demasiado esfuerzo se puede realizar código portable entre diferentes plataformas.

Un ejemplo, un programa "hola mundo" en C tendría un aspecto como el siguiente:

#include <stdio.h>

int main (int argc, char *argv[])
{
  printf ("Hola mundo\n");

  return 0;
}

El lenguaje C es sin duda uno de los más utilizados, prueba de ello es que los sistemas operativos siguen estando realizados en C (u otros lenguajes derivados del C). Las aplicaciones críticas siguen estando en C, así como las más cercanas a la máquina o que precisen una mayor interacción con el nivel hardware (como los drivers).

Como una extensión del C, apareció el C++, lenguaje de programación orientado a objetos. Así el C++ heredó toda la versatilidad y capacidad del C, añadiendo el paradigma de la programación orientada a objetos. En el fondo sigue siendo C, pero proporciona una nueva y diferente forma de programar.

El C++ aunque tambien se utiliza bastante parece haberse quedado algo más reservado para los expertos en programación, a la sombra de su predecesor C.

En el 2000 apareció una nueva versión del C (o del C++), el C#, que parece un extraño hibrido entre C y Java, desarrollado en principio para plataformas Windows. El C# es como más "cool" que el C++ para algunas empresas.

Si se quisiera realizar programación gráfica, tanto el C++ como el C# (e incluso el C) tiene bibliotecas de diferentes proveedores que facilitan la labor, aunque sigue siendo laborioso. Ni el C ni el C++ están pensados para usar en web (aunque se suelen utilizar para implementar CGI), el C# si está pensado para utilizarlo en servicios web.

Entradas sobre Trabajo y programación:

15 mayo 2008

Trabajo y programación: COBOL

El COBOL es un viejo dinosaurio de los lenguajes de programación. Fue creado en los 60 y ha sufrido continuas revisiones (en la wikipedia indican que se está preparando una revisión para el 2008).

Se diseñó para ser usado en los ambientes financieros, y actualmente las grandes empresas siguen usando COBOL para manejar los datos de clientes y servicios, mediante procesamiento por lotes..

La sintaxis del COBOL recuerda al ingles y utiliza unos particulares tipos de datos estructurados. Con los años ha ido intentando adaptarse a los nuevos tiempos (nuevos paradigmas de programación, nuevos lenguajes, la web) sufriendo cambios y versiones respecto al COBOL original.

Un ejemplo, un "hola mundo" en cobol tendría un aspecto como el siguiente:


IDENTIFICATION DIVISION.
PROGRAM-ID. HOLAMUNDO.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. RM-COBOL.
OBJECT-COMPUTER. RM-COBOL.

DATA DIVISION.
FILE SECTION.

PROCEDURE DIVISION.

MAIN-LOGIC SECTION.
BEGIN.
   DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
   DISPLAY "Hola mundo" LINE 15 POSITION 10.
   STOP RUN.
MAIN-LOGIC-EXIT.
   EXIT.

Personalmente creo que es un lenguaje difícil y farragoso para trabajar con él. Los entornos de trabajo con los que me he encontrado para usar el COBOL son bastante duros y toscos, y el trabajo termina siendo un tedioso ajuste de los tipos de datos y los chorros de caracteres de información.

Y pese a su caracter duro y anticuado es utilizado mucho más de lo se podría pensar. Aunque su uso se queda reducido a esos grandes sistemas mainframe.

Entradas sobre Trabajo y programación:

20 mayo 2006

Visual Basic vs. Java

Hace bastante tiempo, mientras dedicaba mi tiempo a una beca en Iberdrola, aproveché los conocimientos que iva adquiriendo en Visual Basic para hacerme un pequeño programilla para llevar la gestión de mis gastos.

Ahora, pensé, ha llegado el momento de actualizar este programilla y hacer una nueva revisión, pero en java.

Si, muy bonita la idea, pero hay que ver lo sumamente jod... que es hacer programación gráfica utilizando el eclipse... Y me niego a instalar algún producto "visual..." de Microchoft...

Con lo bueno que me parecía el entorno de programación del Eclipse... y el duro escollo que he encontrado en mi camino....

Es que hasta estoy hechando de menos la sencillez del visual basic para la programación java.... ¿me estará tentando "el lado oscuro"?

-->> Segunda parte