Cálculos estadísticos en Python

Publicada el 4 diciembre 2022 por Chuidiang

pythonSiguiendo con mis aprendizajes y tutoriales de Python, me ha tocado la parte de cálculos estadísticos.

Me ha parecido bastante increible la cantidad de cálculos estadísticos que vienen por defecto con la instalación de python. No solo cálculos más o menos habituales como la media o la desviación estándar, sino todo tipo de cálculos estadísticos algo más avanzados: percentiles, distintos tipos de distribuciones e incluso interpolación lineal. Al escribir el tutorial he tenido que buscar muchos de los conceptos de estos cálculos que no conocía.

Como vengo de Java, me ha llamado la atención porque en Java no hay nada de esto, ni siquiera la media de una lista de números. No es complejo calcularla, pero tienes que hacerlo. Pero sí es más complejo de calcular cosas como los percentiles, distribuiciones o interpolación lineal. En java no te queda más remedio que currartelo o buscar alguna librería que lo haga.

Sé que el uso de Python ha crecido mucho últimamente, llegado a superar a Java. He leído por ahí que se debe sobre todo al tema de machine learning, porque las librerías que tiene python que son útiles para esta disciplina no las tienen otros lenguajes de programación. Lo que tiene de base para cálculos estadísticos, así como que de forma nativa trate con números complejos, parece dar la razón a este argumento. Y librerías adicionales como Numpy le dan más peso todavía.

Ahora sólo queda decidir el siguiente tema de python que estudiar y escribir.

Publicado en python | Etiquetado , | Deja un comentario

Aprendiendo Solidity

Publicada el 2 octubre 2022 por Chuidiang

Solidity — documentación de Solidity - UNKNOWNAunque es poco conocido en general, sí es muy conocido dentro de los programadores de la blockchain de criptomonedas, del mundo de Ehterum en concreto. Es el lenguaje de programación Solidity.

Y precisamente como todo el tema de blockchain está muy de moda, maneja mucho dinero y este lenguaje de programación es relativamente nuevo y poco conocido, si estudias solidity dicen las malas lenguas que encuentras trabajo seguro con sueldos muy por encima de la media de lo que cobra un programador.

Así que me puse a investigar y juguetear. No es que quiera cambiar de trabajo, pero en este mundillo de la programación, nunca está de más actualizarse y aprender cosas nuevas. El lenguaje en sí no es complejo, en vez de clases tiene contract o contratos. Estos contract tienen constructores, variables y funciones (métodos). Hay herencia, etc, etc. Poca cosa que a un programador extrañe.

Sin embargo, sí hay conceptos, no de la sintaxis en sí, que llaman la atención y que hacen que programar correctamente pueda ser más complejo que en otros lenguajes.

El primero es que el contrato, una vez hecho, se sube a la blockchain. Esto cuesta dinero. Y la blockchain es inmutable, es decir, una vez subido nuestro código a la blockchain, si detectamos un bug, no podemos editarlo para corregirlo ni borrarlo para reemplazarlo por otro nuevo. No queda más remedio que corregirlo en nuestro fuente original, volver a subirlo pagando y tratar de eliminar todas las referencias al contrato antiguo en las aplicaciones públicas que tengamos. El código con errores sigue subido y «vivo» en la blockchain, público y accesible. Así que el proceso de depuración de nuestro código cobra especial importancia.

Sí, es cierto que otras aplicaciones como las de bancos o en las que haya vida de personas en juego también requieren una depuración y testeo muy exhaustivo del código antes de ponerlo en producción. Pero en estos casos, si el código está en producción y detectas un bug, puedes retirarlo y reemplazarlo por código nuevo con el bug corregido. En la blockchain no es posible. Tu código erróneo sigue vivo y accesible para que alguien malintencionado pueda explotar ese bug.

Y el segundo punto llamativo. Nuestros contratos trabajan con la blockchain y guardan datos en la misma. Acceder a esos datos es gratis, pero modificarlos a añadirlos cuesta dinero, las tasas de las transacciones. Y si nuestro código se lía a hacer transacciones, la llamada a una función o método puede ser cara. Y el lenguaje no te deja claro, al menos para un novato que empieza, qué variables están en la blockchain por lo que cambiar su valor implica coste.

Y pongo un ejemplo tonto, un array declarado en el contrato se guarda en la blockchain. Si eliminamos un elemento del array y desplazamos los siguientes una posición antes por aquello de no dejarlos huecos, cada escritura en el array cuesta dinero. Así que la forma correcta es copiar el array en un array en memoria, modificarlo totalmente en memoria y luego, de una sola transacción, meterlo en la blockchain.

Así que en eso ando entretenido estos días, aprendiendo algo de solidity. El curso que estoy siguiendo es de zombies y gatitos 🙂

Publicado en varios | Etiquetado , , , | Deja un comentario

Ficheros en python

Publicada el 11 septiembre 2022 por Chuidiang

Aunque ya había mirado como leer y escribir ficheros en python hace tiempo, con el tema del curso de python con el que estoy entretenido en la chuwiki, lo he estado revisando. Y ¿cómo no?, he encontrado un par de cosas que me han llamado la atención sólo porque son diferentes en java.

La primera es cómo saber si hemos llegado al final del fichero cuando hacemos un bucle para leerlo. En java, el método readLine() devuelve un null y hay que poner un if del estilo

while (null != linea) {
…
}

En python, devuelve una cadena vacía. Esto es así porque el método readLine() de python devuelve los retornos de carro, así que una línea en blanco devolvería ‘\n’, mientras que en java devolvería una cadena vacía ». Y en python, para el bucle, tienes otra forma de hacerlo

while linea:
…

No hace falta compararlo con nada. Los condicionales de python son listos y si la cadena está vacía o es None, devuelve false. Aunque es diferente de java y me ha llamado la atención, este tipo de condicionales que dan false si la cadena está vacía o es None, no me ha llamado tanto la atención, puesto que javascript también funciona así.

Aquí sólo un apunte. En python me parece engorroso que al leer una línea me devuelva también el retorno de carro final. Java se lo come y no te lo devuelve. No sé qué es más útil, pero me da la impresión de que si la línea contiene campos que quieres extaer, estilo fichero CSV, el retorno de carro al final  vas a tener que eliminarlo con código.

Y lo segundo que me ha llamado mucho más la atención es que el descriptor de un fichero abierto de python es un iterator. Por lo que iterando sobre él vamos leyendo.  Podemos incluso meterlo en un bucle. En java, para leer un fichero hasta el final necesitamos algo tan engorroso coom esto

String linea = bufferedRead.readLine();
while (null!=linea) {
// tratar la línea
linea = bufferedReader.readLine();
}

es decir, dos lecturas, una antes de entrar en el bucle para tener la variable línea inicializada con la primera línea del fichero y luego, dentro del bucle, como última línea, otra lectura. Este tipo de estructuras siempre me ha parecido poco elegante por lo de hacer dos lecturas. Con un do-while tampoco podemos hacerlo con una lectura.

Sin embargo, en python, como el fichero abierto es un iterator, podemos hacer esto

f = open (‘fichero.txt’)
for linea in f:
# Tratar la línea.

Mucho más claro. Funciona igual con ficheros de texto o binarios. Si lo abres como texto devuelve líneas, si lo tratas como binario devuelve bytes. Y ni siquiera hace falta la comparación para saber si hemos llegado a final de fichero.

Punto para python 🙂

Publicado en java, python | Etiquetado , , | Deja un comentario

Anti spam en mediawiki

Publicada el 31 agosto 2022 por Chuidiang

Desde hace mucho tengo en marcha una wiki de programación que es una instalación de mediawiki. La idea original, como toda wiki que se precie, es que la gente pudiera colaborar, añadiendo o corrigiendo artículos, comentando en la pestaña discusión, etc, etc.

Pero el spam empezó a hacer de las suyas. Tuve primero que obligar al registro de usuarios para poder crear/modificar y luego tuve incluso que quitar la posibilidad de auto-registrarse como usuario. Había diariamente, incluso a pesar de la obligación de registrarse como usuario, varias páginas de spam muevas. Y pasaba todos los días un rato borrando estas páginas.

Hace unos días decidí volver a meter mano a esto. Estaba bastante seguro que una herramienta como mediawiki tenía que tener mecanismos antispam. Y efectivamente, encontré esta guía de combate contra el spam. Esa guía comenta que hay un  montón de posibilidades y que se pueden poner más o menos todas, pero que se puede reducir drásticamente con solo tres o cuatro plugins.

Dicho y hecho, me entretuve instando esos plugins y configurándolos. Hasta ahora, un mes después, y con posibilidad de modificar sin necesidad de registrarse como usuario, cero spam. A ver si sigue así.

Los cuatro plugins son los siguientes:

  • StopForumSpam. Este plugin abre la posibilidad de descargarse una lista de IPs que habitualmente se usan para publicar spam en webs de terceros, como mi wiki. La lista se actualiza periódicamente, por lo que tienes que descargarla periódicamente. Pero en tu servidor web puedes automatizar este proceso con un script y despreocuparte.
  • ConfirmEdit. Se configura para que si un usuario no registrado modifica algo, tenga que rellenar un captcha antes de salvar las modificaciones. En mi caso puse preguntas a las que hay que dar una respuesta. Aquí tienes cómo hacer correctamente las preguntas antispam.
  • QuestyCaptcha, forma parte de ConfirmEdit. Permite que ConfirmEdit pueda hacer preguntas como las que he mencionado en el punto anterior y ante qué acciones concretas debe pedirlas (creación, edición, si se añaden URLs, etc).
  • wgDnsBlackListUrls no lo he configurado. Una lista negra de DNS que suelen usarse para spam. Hay también una base de datos con un listado de estas DNS.

Lo único de momento que no puede hacerse sin registrarse como usuario es la creación de páginas nuevas. Si se pueden modificar o discutir. Si veo que va bien todo esto, habilitaré esos permisos también.

Publicado en web | Etiquetado , , , | Deja un comentario

Comparación de constructores en Java y en Python

Publicada el 7 agosto 2022 por Chuidiang

En el curso de python me he liado a explicar cómo construcir excepciones propias de la aplicación. Para ello hay que hereadar de la clase Exception. La clase Exception tiene un constructor que admite n parámetros cualesquiera y se los guarda. Es una forma de guardar información adicional al levantar una excepción.

Pues me encontré una sorpresa. Cree mi propia excepción heredando de Exception de la forma más simple posible

class MyException(Exception):
pass

y resulta que sólo con eso puedo hacer cosas como

error = MyException(param1, param2, param3,…)

es decir, puedo añadir los parámetros que quiera usando el constructor de la clase padre.

Como vengo de Java, donde esto no es así, me llamó poderosamente la atención y me puse a investigar.

En Java sólo puedes llamar a constructores que hayas declarado explicitamente en la clase hija, o al constructor por defecto sin parámetros si no has declarado ninguno. Esto es así porque Java obliga a llamar a un constructor de la clase hija y este a su vez y de forma automática llama a un constructor de la clase padre. Al de defecto si no le hemos indicado explícitamente que haga otra cosa

En Python la resolución de constructores no es así. Si tu instancias una clase hija con un constructor (unos parámetros concretos), Python busca ese constructor en la clase hija. Si lo hay lo llama y no va a llamar de forma automática al de la clase padre. Si no lo hay en la clase hija, busca ese constructor en la clase padre (o en las clases padre en determinado orden, porque Python admite herencia múltiple) y si lo encuentra lo llama.

Así que en Python es perfectamente posible construir una clase hija sin que se llame a ningún constructor de la clase padre o que se se instancia una clase hija sin que se llame a ningún constructor de la clase hija.

En Java esto es más rígido. Si instancias una clase hija, obligatoriamente se tiene que llamar a un constructor de la clase hija y este llamará de forma automática a un constructor de la clase padre.

Sin embargo, para métodos normales y atributos el comportamiento de ambos lenguajes es más similar. Si en una instancia de una clase hija llamas a un método, ambos lenguajes buscan el método en la clase hija y lo llaman si existe. Si no existe, lo buscan en la clase padre y lo llaman si existe.

La diferencia entre ambos lenguajes es solo en los constructores. Java obliga a una llamada en cascada de constructores hijo, padre, abuelo… mientras que Python los trata como si fueran métodos normales.

Publicado en java, python | Etiquetado , , , | Deja un comentario

Bases de datos en python

Publicada el 3 agosto 2022 por Chuidiang

En el curso de Python le ha tocado al tema de base de datos. La verdad es que no tengo muy claro que orden seguir con el curso, pero le ha tocado esto 😛

Lo primero que me ha llamado la atención es que Python viene, con la instalación estándar, con la base de datos SQLite embebida. Esto me ha venido estupendo porque en el curso. Me ahorro indicar que hay que instalarse una base de datos u otra para poder seguir los ejemplos. Como Python viene con SQLite, pues simplemente usar esa en los ejemplos y cualquiera puede seguirlos sin necesidad de instalarse nada adicional.

El siguiente punto que me ha llamado la atención es el tema de cómo se implementan los módulos de base de datos. En java existen una serie de clases e interfaces predefinidos, lo que se llama la JDBC (Java Database Connectivity). En Python intentan lo mismo, es la Python Database Specification PEP 249. Pero se queda un poco cojo por las características del lenguaje. En Java, al ser de tipado estático, puede «obligar» a que los driver de conexión de base de datos cumplan más o menos a rajatabla la especificación JDBC. En Python, puesto que es de tipado dinámico, la especificación se queda en una especie de descripción de qué métodos y clases tienen que implementar los módulos de conexión a base de datos, pero no puede «obligar» tanto como lo hace java. Esto hace que sí, que quizás todos los módulos cumplen la especificación, más o menos, pero no tienes tantas garantías de que el código sea reutilizable si cambias de base de datos.

Otro punto que me ha llamado la atención y este sí es a favor de Python, es la facilidad de todo esto. Apenas hay un par de clases en la especificación con unos cuantos métodos de los cuales realmente con tres o cuatro podemos hacer prácticamente todo. La JDBC de Java es bastante más compleja.

Y finalmente otro punto, que no sé qué pensar, es el tema de fechas, horas y timestamps. Java tiene soporte para ello, tienen tipos propios java.sql.Date, java.sql.Time y java.sql.Timestamp, que se usan en JDBC y se convierten correctamente a los tipos Date, Time y Timestamp de las columnas de base de datos. Python, hasta donde he visto, no tiene este soporte. Para manejar fechas y horas, debemos hacer las conversiones a los String en los formatos que los soportan las bases de datos. No es costoso, pero no sé si es cómodo.

Publicado en java, python | Etiquetado , , , | Deja un comentario

Python timezone. Módulo pytz

Publicada el 30 julio 2022 por Chuidiang

Estaba entretenido mirando todo el tema de datetime en python y me puse a mirar todo el tema de husos horarios o timezone. Como todos sabemos, cada país tiene una hora de su padre y de su madre, según el huso o zona horaria en la que esté.

En el 99% de las aplicaciones de escritorio, sean en python o no, esto no suele dar mayores problemas. La aplicación solo corre en un ordenador y la hora es la del ordenador en el timezone que le toque.

Pero si es una web que se va a publicar en internet que se vaya a ver en varios paises o es una aplicación de escritorio más compleja que se pueda instalar en clientes de varios paises y que vayan contra una base de datos o servidor centralizado, pues es importante tener en cuenta todo esto para presentar a cada usuario su hora correcta en función de su huso horario.

En python he visto una cosa que en parte me ha gustado. Y es que los módulos por defecto de python, como datetime, sólo entienden de hora local y de hora UTC / GMT. No entienden de horas de otros paises de una forma fácil. Siempre tenemos la opción de decir GMT+2 o GMT-4, pero desde luego eso obliga a saber ese incremento respeto a GMT para un país concreto. Y si encima vamos con horarios de verano e invierno, más lio, porque ese incremento cambia según la fecha del año.

¿Por qué digo que me ha gustado esto que aparentemente es una pega?. Porque como he comentado, el 99% de los casos no necesitamos más. La hora local va que chuta.

¿Y si queremos saber las horas de otros paises?. Hay varios módulos, algunos ya instalados en python, como zoneinfo, que de alguna forma ayudan. Pero en una investigación superficial, no me he matado mirando, no los he visto suficientemente cómodos y completos. Pero sí me ha gustado el módulo adicional pytz, abreviatura de Python Timezone.

La instalación es sencilla, python viene con un programa de nombre pip que permite instalar módulos externos desde internet. Este simple comando debería hacer el trabajo.

pyp install pytz

Si todo va bien, se habrá instalado. Luego basta usarlo en cuaqluier función de datetime que admita como parámetro un timezone. Por ejemplo (en azul la salida de los comandos)

>>> datetime.now(pytz.timezone(‘America/New_York’))
datetime.datetime(2022, 7, 30, 2, 43, 56, 551152, tzinfo=<DstTzInfo ‘America/New_York’ EDT-1 day, 20:00:00 DST>)

>>> datetime.now(pytz.timezone(‘Europe/Madrid’))
datetime.datetime(2022, 7, 30, 8, 44, 2, 924587, tzinfo=<DstTzInfo ‘Europe/Madrid’ CEST+2:00:00 DST>)

>>> datetime.now(pytz.timezone(‘CET’))
datetime.datetime(2022, 7, 30, 8, 44, 13, 512663, tzinfo=<DstTzInfo ‘CET’ CEST+2:00:00 DST>)

>>> datetime.now(pytz.timezone(‘Zulu’))
datetime.datetime(2022, 7, 30, 6, 44, 18, 40771, tzinfo=<StaticTzInfo ‘Zulu’>)

Ahí tenemos cuatro ejemplos para obtener la hora actual en New York, en Madrid, en CET (Central European Time, que coincide con la de Madrid) y en hora Zulu (similar a GMT y UTC).

O podemos convertir fechas de un país a otro

>>> zulu = datetime(2022,7,4,5,6,7,123456,pytz.timezone(‘Zulu’))
>>> zulu
datetime.datetime(2022, 7, 4, 5, 6, 7, 123456, tzinfo=<StaticTzInfo ‘Zulu’>)

>>> madrid = zulu.astimezone(pytz.timezone(‘Europe/Madrid’))
>>> madrid
datetime.datetime(2022, 7, 4, 7, 6, 7, 123456, tzinfo=<DstTzInfo ‘Europe/Madrid’ CEST+2:00:00 DST>)

Aquí obtenemos una fecha/hora concreto con timezone Zulu y luego averiguamos qué hora era en Madrid en esa hora Zulu, usando la función datetime.astimezone()

A partir de un timestamp también es sencillo

>>> timestamp = datetime.now().timestamp()
>>> datetime.fromtimestamp(timestamp)
datetime.datetime(2022, 7, 30, 9, 5, 36, 831705)

>>> datetime.fromtimestamp(timestamp, pytz.timezone(‘America/New_York’))
datetime.datetime(2022, 7, 30, 3, 5, 36, 831705, tzinfo=<DstTzInfo ‘America/New_York’ EDT-1 day, 20:00:00 DST>)

La función datetime.fromtimestamp() presupone hora local si no le ponemos parámetro, pero si le ponemos un timezone de parámetro, nos muestra el datetime en ese país.

Para saber qué timezone hay disponibles, la llamada pytz.all_timezones nos da un listado de todas las disponibles.

Publicado en python | Etiquetado , , , , | Deja un comentario

Algunas pegas de Python

Publicada el 25 julio 2022 por Chuidiang

Estoy últimamente aprendiendo Python y lo que aprendo lo voy escribiendo en un curso de python en la chuwiki. Ya lo sabía desde hace tiempo y no me gustaba, pero en los ejemplos que he ido haciendo para el curso, me he tropezado con el problema de una forma inesperada.

¿Cual es el problema?. Básicamente que si tienes una clase Python, por ejemplo, esta

class Clase:
pass

Una simple clase, he puesto pass simplemente por no complicarme, pon ahí todo lo que quieras. Pues bien, si en código yo hago esto

Clase.pepe = ‘hola’

simplemente lo admite y crea el atributo pepe en la clase. Bien, esto puede ser estupendo, nos permite crear atributos de una forma dinámica si hace falta. Pero la pega que siempre he encontrado es que somos humanos y como humanos nos equivocamos, sobre todo al teclear. Estoy seguro que la tecla del del teclado es la más usada. ¿Qué pasa si la clase tiene un atributo nombre y nos equivocamos al teclearlo?

class Clase:
nombre = »

Clase.nonbre = ‘Pedro’

Pues fácil, tenemos un atributo nombre sin valor y un nuevo atributo creado al vuelo nonbre con el valor correcto. No hace falta mucha imaginación para darse cuenta la de problemas de depuración que nos puede dar esto si no nos damos cuenta. De hecho, seguro que no habrías visto nada raro si no te digo la estadística de la tecla del antes.

Pero bueno, estoy ya lo sabía e incluso creo que lo comenté en algún post anterior. El problema con el que me he encontrado ahora es el siguiente. Imagina que tenemos la clase con el nombre y hacemos esto

>>> pedro = Clase()
>>> pedro.nombre = ‘Pedro’
>>> print(pedro.nombre)
‘Pedro’
>>> print(Clase.nombre)
»

Pues bien, resulta que hemos creado una instancia pedro, le hemos asignado un nombre y se lo ha asignado. Pero no en el atributo nombre de la clase, sino creando un atributo nombre específico para la instancia y que oculta el atributo nombre de la clase.

Todo correcto, es el comportamiento esperado de Python. Aunque no sé si me convence. Como he comentado, somos humanos. El atributo de clase es compartido por todas las instancias y podemos quizás querer cambiarle el valor en algún momento de la ejecución de nuestro código. La forma correcta de cambiarlo para que afecte a todas las instancias sería usando el nombre de la clase, es decir Clase.nombre=’valor para todas las instancias’. Pero los humanos seguimos siendo humanos y nos equivocamos, tanto programadores novatos como expertos. Los primeros se lo piensan mucho y meten la pata. Los segundo meten la pata directamente. Entra dentro de lo posible que al querer cambiar ese nombre de la clase usemos una instancia como en el ejemplo. Nuevamente un dolor de cabeza de depuración.

Sin quitarle valor a python, que se ha ganado su puesto como lenguaje más utilizado, sobre todo por temas de inteligencia artificial, este es el motivo por el que no me gustan los lenguajes en los que no se declaran las variables previamente para desarrollos en serio. Por desarrollo en serio me refiero a desarrollos grandes en los que hay implicados varios desarrolladores, humanos todos ellos. En un lenguaje con declaración de variables, si cualquier de ellos se equivoca al escribir el nombre de una variable, o la mete en una clase/instancia que no tiene que estar, como no se ha declarado previamente, el error salta según el programador humano hace sus cosas humanas. En lenguajes donde no es necesario declarar las variables, esto no «canta» hasta la ejecución, donde te tocará echar tiempo depurando.

Publicado en python | Etiquetado , , | Deja un comentario

Paquetes Java vs Python

Publicada el 21 julio 2022 por Chuidiang

Hace muchos años aprendí Java. Recuerdo que me llamó mucho la atención y me pareció excesivamente rebuscado el tema de los paquetes (package). Había que crear una estructura de directorios similar a la estructura de paquetes que queremos. Es decir, si una clase está en package com.chuidiang.ejemplos, debemos crear un directorio «com», dentro de el un subdirectorio «chuidiang», dentro de él un subdirectorio «ejemplos» y dentro de este, finalmente, el fichero .java con la clase.

Últimamente estoy en proceso de aprender Python y ponerlo en un curso de python. Justamente ayer me entretuve con el tema de módulos y paquetes en Python. Y cual no fue mi sorpresa que he encontrado muchas similitudes con Java.

En Python también debes crear una estructura de directorios similar a cómo quieras organizar los paquetes.  A los ficheros Python que pongas ahí no hace falta ponerles nada similar a package, como en Java. Basta con que esté ubicados en el subdirectorio que corresponda.

Y en Python, al igual que en Java, para usar algo que está en un paquete (en un subdirectorio de una estructura de directorios), tienes un import. Por supuesto, hay diferencias entre Java y Python, pero el concepto es el mismo, hacer un import de lo que quieras usar.

¿Diferencias?. En Java, una vez haces el import, puedes usar las clases de ese paquete en tu código sin necesidad de ponerles el prefijo del paquete. En Python haces el import pero tienes que seguir usando el prefijo del paquete.

¿Qué es mejor?. Bueno, en principio es más cómodo lo de Java, pero en Python tienes posibilidad de hacerlo similar, con un poco más de trabajo. Tienes from <paquete> import as <nombre>. Haciéndolo así, puedes usar <nombre> sin necesidad de prefijo. E incluso puedes elegir un nombre que no sea el original y cambiarlo. En Java, si hay conflicto porque el mismo nombre está en dos paquetes distintos, en  uno de ellos tienes que añadir todo el prefijo. En Python puedes simplemente cambiarlo de nombre sobre la marcha. Requiere más esfuerzo por tu parte para mantener un sistema de nombres coherente, pero luego es más cómodo de usar.

En fin, salvo algunas diferencias de uso, me ha llamado la atención que la idea básica sea la misma: estructura de directorios y subdirectorios para meter las cosas, que a su vez componen el nombre del paquete. Y la necesidad de hacer el import, cosa lógica por otro lado, no va a estar todo visible para todos si no lo necesitan.

Publicado en java, python | Etiquetado , , , | Deja un comentario

Librerías GIS de escritorio con Java

Publicada el 16 julio 2022 por Chuidiang

En el curro casi todas nuestras aplicaciones son de escritorio, con javax.swing y casi todas llevan algún mapa donde pintamos «cosas». Habitualmente símbolos que representan barcos, aviones, helicópteros, pero también polígonos, líneas etc.

Por ello, hemos ido probando y pasando de unas librerías Java de mapas (GIS o Geographical Information Service) a otras.

logo nasaUna de las que seguimos usando, gratuita, es WorldWind. Escrita por la NASA, muy completa, pero que ya no tiene soporte y está discontinuada. En la Categoría WorldWind de la Chuwiki tengo algunos ejemplos que hice en su día.

Otra que miramos en su momento, es la de ESRI (ArcGis). El SDK de desarrollo de Java es gratuito, aunque viene con algunas limitaciones. Sólo es necesario el pago si vas a instalar tu aplicación en clientes o si tu aplicación necesita acceder a determinadas funciones que están hospedadas en los servidores de ESRI, como el trazado de rutas entre dos puntos siguiendo los caminos o el acceso a ficheros de mapas que tengan ellos. Una ventaja grande de ESRI es que no sólo tiene SDK de Java, sino que lo tiene en varios lenguajes, para web, para móvil, etc. WorldWind también lo tiene, pero algunas de esas opciones están un poco «a medias».

En plan gratuito también miré Geotools. pero era, cuando lo miré, claramente más cutre y me encontré con fallos gordos. Así que no la miré mucho más. De esto hace ya 8 años y Geotools sigue viva y con actualizaciones, es posible que haya mejorado mucho.

Y finalmente, ya de pago total, pero como paga la empresa nos «da un poco igual», tenemos Luciad LightSpeed. Es una librería cara, sin posiblidad de desarrollo gratuito salvo que contactes con ellos y te concedan una licencia de demo, pero es muy muy completa. Es la que conozco que soporta más formatos de ficheros de mapas (cartas náuticas, simbología militar completa, ficheros meteorológicos, de CAD, etc, etc). Tiene también versión para el lado del servidor en una aplicación Web, Luciad Fusion. Y la parte del navegador, en TypeScript, Luciad RIA. LightSpeed viene también con Lucy, todo un framework para que hagas tu aplicación con menús, docking de paneles, salvado/recuperación del workspace por usuarios, etc, etc.

Tengo algunos ejemplos en github, pero al ser de pago, no he escrito ningún tutorial. Me gusta que la gente que sigue mis tutoriales pueda hacer y jugar con el código, cosa que aquí no es posible.

Mi relación con Luciad es de amor/odio. Amor porque como comento, es muy completo y nos soluciona prácticamente todos los problemas que tenemos relativos a mapas, esos sí, codificando. Odio por el tema de precio sobre todo, aunque paga la empresa, me toca «convencer» a los que pagan que el precio merece la pena. A veces no es fácil.

Publicado en Herramientas | Etiquetado , , , , , , , , | Deja un comentario