viernes, 22 de septiembre de 2017

Going wild.

Un desarrollador de software experimentado desarrolla habilidades secundarias que pueden llegar a ser tanto o mas importante que su habilidad principal de desarrollar software.

Un ejemplo de un caso real es este:

http://corgibytes.com/blog/2017/03/28/unlocking-beauty-patterns-binary-data/

Yo tengo una historia parecida que contar.

Yo necesitaba incorporar unas librerías de código nativo en C a un enorme proyecto hecho con .Net 3.5. y sin posibilidad de migrar a una versión mas reciente. Estas librerías vienen con un enlace programado en C#; por lo que en teoría es perfectamente viable usarlas.

El problema que me encontré fue que en NuGet, incluso la versión mas antigua, estaba compilado para .Net4. De hecho, no encontré, en ningún sitio,ni ninguna versión ya compilada para .Net3.5 ni el código fuente.

Así que decidir ponerme salvaje e intentar locas medidas desesperadas.

Primeramente use un inspector/decompilador de ensamblados (https://www.jetbrains.com/decompiler/) para acceder a la información interna del enlace programado en C#. Después de una hora de análisis e investigación y una vez que confirme que no existía ningún impedimento técnico para que el enlace funcionase con .Net 3.5 cogí el código fuente del enlace del decompilador y todas sus dependencias que también fuesen enlaces de C# a código no administrado y cree una solución con varios proyectos de librería con el target framework 3.5. Una vez enlazadas todas las dependencias entre proyectos lancé una compilación y TADA! Ya tenia los envoltorios C# perfectamente compilados para .Net 3.5 y completamente funcionales.

Happy coding bastardillos!

miércoles, 13 de septiembre de 2017

SCUNM - A text adventure game engine

Me he currado un pequeño proyecto en Nodejs que trata de un sencillo motor de aventuras textuales con el cual puedes crear tu propio videojuego y exponerlo online para que la gente se divierta.

No te pierdas el video de la demo usando el motor expuesto a traves de un bot de Telegram.

jueves, 6 de julio de 2017

Tuneando el control de concurrencia optimista.

Supongamos que tenemos una entidad en nuestro sistema llamada "Cliente" que se compone de los atributos [Nombre - Apellido -  EsVIP]. Si modelamos esto en un sistema de persistencia con concurrencia optimista nos quedaría así:

Nombre    - varchar(50)
Apellido   - varchar(50)
EsVIP      - bit
stamp       - rowvewsion

donde stamp es un valor que siempre cambia cuando la entidad ha sufrido algún cambio en persistencia.

Como aquí hablamos de concurrencia no me voy a meter en el tema del estancamiento de datos. Para eso les remito a la esta entrada. La gestión del estancamiento de datos no debe basarse en el campo stamp.

Los pasos que vamos a seguir serán los siguientes:
  1. Rehidratamos la entidad desde persistencia.
  2. Le aplicamos los cambios respetando las reglas e invariantes del dominio.
  3. Intentamos persistir la entidad aplicando el control de persistencia.

viernes, 24 de febrero de 2017

Paralelización con RxJava

Para los que no lo sepan: Rx es monohilo por defecto. 

Un entorno multihilo rompe un stream secuencial inmutable; puesto que deja de ser secuencial.

Aun así, todavía hay posibilidad (y potencial) de ejecutar procesos en paralelo.

jueves, 22 de diciembre de 2016

Visualizador de algoritmos

Una cucada que se han montado estos señores para ver como rulan los algoritmos paso por paso y una buena colección de algoritmos ya montados. Seguro que algo nuevo puedes aprender aunque lleves la tira de años programando.

http://algo-visualizer.jasonpark.me/

martes, 23 de agosto de 2016

Matices en la programacion asíncrona en .NET

Me han pedido de forma personal que explique ciertos matices con respecto a la programación asíncrona en .NET que pueden no estar del todo claros para algunos interesados en el tema. Voy a poner un poco de código al que iremos evolucionando y analizando sus resultados.

jueves, 11 de agosto de 2016

Programación reactiva II.

En la entrada anterior puse un ejemplo de programación reactiva. Ese ejemplo no es de muy buena calidad pero creo que ayuda mucho a obtener la mentalidad que hay que adoptar para la programación orientada a eventos.

Los problemas principales del ejemplo anterior son dos:
  1. La variable estática isRunning para filtrar el stream de eventos de scroll hace que me sangren los ojos cada vez que la veo. Es chapucero como sincronizador de hilos de ejecución y agrega una dependencia sin contexto en el método updateGrid; y el contexto importa; y mucho; si se quiere evitar tener una asquerosa bola de lodo como código fuente.
  2. No tenemos control sobre el índice de elementos a recuperar (---0---100---200---300--->) y eso no es bueno puesto que en un entorno real es necesario un máximo (aunque sólo sea para evitar un overflow) y probablemente más cosas, como decrementarlo, saltar directamente a una página no secuencial, etc.
En esta entrada toca hacer lo mismo pero un poco más pro. Al fin y al cabo necesitamos seguir ignorando eventos mientras cargamos la rejilla y necesitamos un stream con el índice de los elementos a recuperar para que se integre con los demás streams.

miércoles, 10 de agosto de 2016

Programación reactiva.

Pues estoy aquí, enredando con Reactive Extensions (Rx) en .NET y la verdad es que me gusta bastante. La inmutabilidad de los Observables y la programación funcional son conceptos encantadores para arquitecturas orientadas a eventos.

Antes de poner algo de código tonto para satisfacer mi ego me gustaría comentar ciertos detalles que voy descubriendo a medida que me pego con esto.