Visual Studio CODE

Pongamos un nuevo editor multiplataforma dijeron, y boom Visual Studio Code. Extrañamente explota en mi maquina, y no lo puedo probar. Seguire intentando.

En otras notas, EmbedIO tiene nueva versión con algunas correcciones y mejoras como el EmbedIO CLI para tener un webserver rápido con soporte a WebAPI y WebSockets.

EmbedIO

EmbedIO es un proyecto que hicieron en mi trabajo, que a diferencia del montón de aburridas pantallas de CRUD, si es interesante. Que por cierto esta en Github.

Como sea, EmbedIO es un pequeño web server de en C# que te da acceso a una versión ligera y amable de WebAPI, sin tanto drama y Web Sockets, que dios me libre nunca he usado y espero no hacer. Tiene otros detalles interesante como Static Files y Web Sessions. Claro que no tiene Razor o algún Template Engine, pero en estos días del JSON a quien le importa.

Una de las utilidades que le he visto, y en que he utilizado EmbedIO en dos proyectos, es para generar la UI de aplicaciones de escritorio que corren en Windows y Linux. De hecho tengo que probarlo en OSX con Mono, ojala y si funcione a la primera. En estos casos con la UI simplemente hubiera muerto intentando usar Winforms o Gtk#. La última app la estoy diseñando con una UI Framework en AngularJS que espero pronto me den permiso de publicar en Github de nombre Tubular, yo no escojo los nombres.

Hay algunos puntos que puede mejorar el Web Server, por ejemplo tiene de dependencia log4net, lo que se me hace absurdo y necesito trabajar en algún tipo de dependency injector sencillo para el log. No es decente depender de una librería así en un componente.

Este es solo un pequeño recordatorio para mi de la existencia del blog, aunque si posteare una pequeña guía en la semana de como trabajar con EmbedIO y Tubular. Por cierto EmbedIO tiene un Nuget, asi que no hay forma de decirle que no.

Joyitas

while($reg = mysql_fetch_array($res))
        { switch($reg['mes'])
            { case 1:    $pagOK[1] = 'OK';  break;
              case 2:    $pagOK[2] = 'OK';  break;
              case 3:    $pagOK[3] = 'OK';  break;
              case 4:    $pagOK[4] = 'OK';  break;
              case 5:    $pagOK[5] = 'OK';  break;
              case 6:    $pagOK[6] = 'OK';  break;
              case 7:    $pagOK[7] = 'OK';  break;
              case 8:    $pagOK[8] = 'OK';  break;
              case 9:    $pagOK[9] = 'OK';  break;
              case 10:    $pagOK[10] = 'OK';  break;
              case 11:    $pagOK[11] = 'OK';  break;
              case 12:    $pagOK[12] = 'OK';  break;
            }
        }

Deploy REALTIME

Si pensaron que tener un cliente de SVN en el servidor productivo era el pedo, y que nadie hacia deployments más rápido que ustedes, estaban equivocados. Esto es el pedo:

http://wiki.dropbox.com/TipsAndTricks/TextBasedLinuxInstall

Headless Dropbox Linux Client! TAKE THAT! Tan comodo como guardar archivo local... darle F5 al browser, y OMG el cambio esta en el servidor. Al diablo con las revision, comparaciones, merge y demás ñoñadas! FileZilla puedes morir right now!

Lo implemente en un EC2 de Amazon, y es suave como crema batida sobre pan... rico!

2 Fast 2 MySQL

Amigo, usted es un depresivo coder que se ve horrorizado por complejas y hermosas consultas SQL en sistemas legados que desconocen IX, FK y demás fancy features? Tiene el terrible problema de hacer transformaciones de datos tan complicadas y cargadas que los discos de su HD saldran girando fuera de su eje? Si esta en esa situación, lo comprendo, sufro de los mismos males. Por eso hoy le recomiendo, hacer una idiotes. Si señor, montar MySQL en un RAM disk.

WTF? Pues bien la idea no es novedosa, más no es aplicada a diario. Y les puedo decir que no puedo hacer comparativa alguna, mis consultas y ejecucciones son tan rápidas que ya tengo tiempo libre para mi familia xD. Para realizar esta amable tarea, basta que consigamos un buen driver de RAM Disk, recomiendo este (Descargar), el cual es muy fácil de entender y de usar. Creamos nuestro RAM disk, de unos 500 MB. Que tanto puede ser no?

Una vez creado procedemos a parar MySQL, editar el my.ini para apuntar nuestro datadir a nuestra recien creada unidad RAM. Entonces procedemos a copiar el contenido de todo datadir original en nuestro RAM disk, prendemos MySQL y apreciad el poder de no usar el disco duro!!!

Espero que lo pongan a prueban, y vean la velocidad. Solo hay que tener cuidado de no apagar la maquina, sino recuperaste tu info. Para recuperarla basta revertir los cambios en my.ini y copiar los archivos del RAM disk al datadir original.

Viejas tecnologías...

Día a día me enfrento contra la resistencia a las actualizaciones. No lo puedo soportar, es como un Javiersillo molesto que en todo sistema que toco aparece con sus downgrade. El día de hoy tuve caos por dos detalles que me molestan y quiero compartir.

El primero de estos es con mi aplicación horrible de VB6, al descubrir que con el cliente no funcionan los booleanos. Esto es nonsense al por mayor, pues resulta que el maldito RDO/DAO, no puede ajustar su vida para entender que 0 es FALSE y -1 es TRUE. Asi que en en ciertas maquinas tengo que -1 es TRUE y en las que no hacen las cosas bien dice que es FALSE!. No entiendo porque, pero bueno, así que tendre que dejar a SQL de Access ayudarme con algo como IIF.

Ahora la otra, un cliente de PHP, tenía una horrible librería de JSON para su sitio. Yo dije WTF!, porque hace mamadas como esas, no conoce acaso json_encode y json_decode? En fin programe, y fui feliz todo el update del sistema (reescribirlo en clases) funciono. Pero oh sorpresa! El cliente es old fashion, y tiene una versión antiquisima de PHP (eso explica porque usan la librería). Ya esta el proceso de intentar actualizar el server, espero que sea factible, porque de lo contrario... Bueno no necesito aclarar más.

YUI y CSS no me respetan

Para los simios tontos, que no saben que es YUI (Yahoo! User Interface) es un framework en JScript con controlitos y tonterías como XHR, JSON y demás ñoñadas de hoy en día.

En otro de mis MP (multiproyectos) tengo la extraña necesidad de usar YUI para crear los forms y grids de la aplicación (yo quería usar ExtJS, pero la maldita licencia no me lo permite). La vida no es tan fácil con YUI que con ExtJS, pero aún así no dire que es mal framework. Lo que me tiene al borde del odio a YUI es su sistema de skinning o themes.

Sucede que mis objetos visuales, trabajan, y extrañamente no requerí muchas líneas de código. Esto después de comerme los tutoriales y batallar con la selección de archivos JS uno por uno del YUI (que fastidio porque no ponen un YUI-ALL.js). El problema que el CSS no aparece, todo esta en default format, no tengo los gradientes lindos del grid, o botones. Firebug me muestra que se cargo correctamente el CSS, los elementos tienen sus class correctamente. Las class apuntan a sus background URL correctamente, pero nada!.

He buscado en internet sin éxito. Lo que me extraña que los tutoriales si tienen el malvado CSS funcionando (obvio hablo localmente). Así que bendigo a cualquier simio coder que me pueda dar una idea de porque YUI es tán malvado conmigo y no presenta correctamente el skin.

Actualización:

<body class="yui-skin-sam">

Sin comentarios!

Antes del DDL, teníamos...

En uno de los multiproyectos que estoy trabajando actualmente, tengo una hermosa aplicación VB6 de esas que se conectan a MS Access. Maldigo el día que me di cuenta que Access era tan "avanzado" que tenía relaciones de tablas y que estás son invisibles. He intentado muchas cosas para intentar descubrir como se llama una FK para poder borrarla en la aplicación, y mis intentos han sido fracasados una y otra vez.

El metadata de Access es algo misterioso (MISTICO), y más cuando tienes que usar cosas como DAO. La documentación esta más perdida que la de PHP, encontrar un indicio de DDL fue una proeza que me llevo a pelearme a entender que COUNTER es la keyword más extraña para definir un entero autoincremental (tiene sentido, pero saber que era COUNTER me costo un día).

En mi opinión, creo que si esto continua optare por sugerir cambiar el Access por un SQLite o algo más actual. Al cabo solo sería cambiar un tonto ODBC que no? Bueno, para darle un poco de valor a este post, les listare las trampas mortales que caí y espero que sirvan a alguién más en el manejo de Access:

• La creación de una tabla por DDL si es CREATE TABLE, pero ojo, los datatypes son algo diferentes a los que se acostumbran, por ejemplo un int autoinc es un COUNTER, un varchar(x) es un TEXT (notese que no es un BLOB, el pseudoBLOB es MEMO). El resto de datatypes es LONG, INTEGER, CURRENCY, DATETIME. No recuerdo algo como un float o double, así que CURRENCY ayudo, je.
• Para lograr sacar metadata rápido, recomiendo soltar el VB6 y utilizar VBA de Access. Esto porque, simplemente porque conectar por DAO es en ocasiones algo como un ritual. Asi que CurrentDB desde VBA será su amigo, creanlo (ahorraran mucho tiempo).
• La manera más sencilla de ejecutar código en DAO, es crear un modulo en VBA poner nuestro código en una function y luego con la Inmediate correr la función. Se que suena chafa, pero ahorra tiempo valioso. Un código podría ser algo así por ejemplo:

Public Function runMe()
Dim db As Database
Dim mobjTable As TableDef

Set db = CurrentDb
Set mobjTable = db.TableDefs("TABLE001")

For Each objIndex In mobjTable.Indexes
Debug.Print objIndex.Name
Next objIndex
End Function

Horrible, pero cierto. Esta es mi manera fácil de encontrar los Indices y FK de Access. Recuerden, trabajar en Access en lugar de VB6 les ahorrara mucho tiempo! Y quizás me digan anticuado, pero seamos realistas hay muchos sistemas legados alla afuera en VB6/Access, así que no esten de pussers diciendo que nunca lo harán, un buen coder se echa cualquiér trompo a la uña.