A Geek from Paraguay

S.O.P.A. is NOT CAPITALISM, It's MERCANTILSM

2012-01-22T03:44:00.000-08:00

According to the famous book "The Other Path" of the Peruvian economist Hernando de Soto, Latin America does not take off economically because, although many say the opposite, true capitalism in Latin America does not exist, what we have is Mercantilism. Mercantilism is an intricate set of laws , regulations, monopolies, bureaucracy and other obstacles that result as an entry barrier difficult to overcome for new initiatives and ventures (eg government contracts awarded exclusively to "friends" or members of those who hold political and economic power or red tape to open a business in a legal manner). As a result, the informal or underground economy flourishes outside the law.

The companies behind S.O.P.A. are handled with a business model that is no longer adequate and that's why they turn to push mercantilist measures to protect them from the new market realities. It is funny that Hollywood companies -today S.O.P.A. thrusters- were born when the first entrepreneurs in the film industry fled the Thomas Alva Edison patents in force in the eastern United States and settled in Los Angeles, California .

The startup's incubator Y Combinator exemplifies this in his blog entry "Kill Hollywood" http://ycombinator.com/rfs9.html

S.O.P.A. es NO CAPITALISTA, es MERCANTILISTA

2012-01-22T03:08:00.000-08:00

S.O.P.A. es NO CAPITALISTA, es MERCANTILISTA

Según el famoso libro "El Otro Sendero" del economista peruano Hernando de Soto, Latinoamérica no despega económicamente porque, aunque muchos digan lo contrario, en Latinoamérica el verdadero capitalismo no existe, lo que tenemos es Mercantilismo, es decir un intricado conjunto de leyes, reglamentaciones, monopolios, burocracia y otras trabas que resultan como una barrera de entrada difícil de superar a las nuevas iniciativas y emprendimientos (Por ejemplo los contratos del gobierno adjudicados en exclusiva a "amigos" o miembros de quienes detentan el poder político y económico o la excesiva burocracia para abrir un negocio en forma legal). Como resultado de eso, prospera la economía informal o subterránea, al margen de estas leyes.
Las empresas que están detrás de S.O.P.A. se manejan con un modelo de negocio que ya no resulta adecuado y por eso es que recurren a impulsar medidas mercantilistas para protegerles de las nuevas realidades del mercado. Resulta simpático que las empresas de Hollywood, hoy propulsoras de S.O.P.A., nacieron cuando los primeros emprendedores de la industria del cine huyeron de las patentes de Thomas Alva Edison vigentes en el este de los Estados Unidos de América y se establecieron en los Los Angeles, California.
La incubadora de startups Y-Combinator ejemplifica esto en su entrada de blog "Kill Hollywood" http://ycombinator.com/rfs9.html

Nokia's LUMIA means Prostitute / LUMIA significa prostituta

2011-10-28T16:30:00.000-07:00

http://news.cnet.com/8301-17852_3-20125899-71/nokias-lumia-means-um-prostitute-in-spanish/

The fact that LUMIA, name of the new Windows Phone 7 Nokia's series, means PROSTITUTE in Spanish is not a good start. Although the previous work of Stephen Elop - CEO of Nokia - has been leading the Microsoft Office division does not justify imposing only Windows Phone as Nokia's platform for new smart phones. On the other hand Samsung, Motorola and HTC , in addition to Android, also have Windows Phone, and they are doing it well. The irony is that the source code of Android among its contributors has several Nokias's developers.
Hewlett-Packard was almost screwed up during the administration Léo Apotheker (former CEO of SAP AG) who knows how to sell software more than how to sell hardware. I hope that it would not happen to Nokia, which also has a CEO who knows how to sell software.

El hecho de que LUMIA, nombre de nueva serie de Nokia con Windows Phone 7 que significa PROSTITUTA en español no es un buen inicio. Aunque el anterior trabajo del CEO de Nokia Stephen Elop haya sido en Microsoft al frente de la división de MS Office no justifica que se imponga a Nokia solo Windows Phone como plataforma para los nuevos smart phones. Por otro lado Samsung, Motorola y HTC además de Android también tienen Windows Phone, y les va bien. Lo irónico es que el código fuente de Android tiene entre sus contribuidores a varios desarrolladores de Nokia.
Hewlett-Packard casi fue echada a perder durante la gestión Léo Apotheker (ex CEO de SAP AG) que sabia más vender software que hardware. Espero que eso no le pase a Nokia, que también tiene un CEO que sabe vender software.

NoSQL en iSeries/System i == RPG

2011-01-03T05:19:00.000-08:00

Antes que nada:

No SQL != Not SQL

No SQL == Not Only SQL

Existe un dejavu, una vuelta a los orígenes para hacer las consultas y actualizaciones datos con mayor velocidad. Es como volver a los años 70s, accediendo a los datos a un nivel mas bajo de abstracción que el proporcionado por los motores de bases de datos relacionales.

Me recuerda a una prueba que hice años atrás, donde utilizando el generador de código CA CoolPlex -hoy dia CA Advantage Plex- para la misma lógica para acceder a datos en un servidor iSeries (AS/400), obtuve un rendimiento de alrededor de 5 veces mas que las versiones Java/SQL y C++/SQL, generando en RPG/400. Mas adelante, trabajando con el generador Artech Genexus obtuve rendimientos similares, en cuanto a comparar rendimientos de código generado en Java/SQL y RPG/400.

Un poco decepcionado, porque fui y sigo siendo admirador del modelo de bases de datos relacionales, comente el tema con un colega, que por entonces era docente en la universidad en una catedra de bases de datos. Y el me respondió que era de esperarse porque hay que tener presente que los motores de bases de datos relacionales son interpretes de sentencias SQL, y que para cada consulta, se toman un tiempo para analizar los mejores planes de ejecución de las mismas, decidiendo que indices usar en base a reglas y estadísticas, y si la consulta es frecuente y preparada, se usa la versión pre-compilada de dicha consulta. Todo esto toma un tiempo, teniendo en cuenta ademas que debe escribirse en el log de transacciones, con el correspondiente costo que esto implica en entrada/salida. Mediante el uso de un log de transacciones, ademas de la auditoria y otras cosas, pueden hacerse los Rollbacks/Commits de transacciones y mantenerse la integridad referencial.

Debido a esto, un codigo RPG/400 nativo, que no use transacciones ni SQL embebido, es de esperarse que sea mas rapido, pero a cambio se pierden muchas funcionalidades de las bases de datos relacionales.

Me acorde de esto al leer un articulo en DZone que me derivo a - http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html - sobre un desarrollo de apis que acceden a bajo nivel al almacenamiento en el motor de base de datos relacional MySQL.

Este modelo permite coexistir en MySQL el acceso a datos a bajo nivel y por SQL, al igual que SQL y el lenguaje de programación RPG para la base de datos DB2 en la plataforma iSeries/System i (AS/400).

"Eppur si muove” : Una experiencia de recibir asesoramiento en Inteligencia de Negocios

2010-12-16T18:41:00.000-08:00

Llama la atención que suele pensarse que todo lo que viene del extranjero es la maravilla. La realidad es que no siempre es así, y lo mas irónico es que quienes asesoran de afuera a veces quieren tratar de tontos a los asesorados locales.
La experiencia que tuve es la siguiente:
En la empresa en la que trabajo recibimos la consultoría de una firma extranjera para llevar adelante un proyecto de Inteligencia de Negocios: Almacén de Datos (Datawarehousing), Reportes, Tableros de Indicadores, Cuadro de Mando Integral (Balanced Scorecard), y Planeamiento.
La sorpresa que recibí fue que los consultores sugirieron cosas para el modelado del Almacén de Datos (Datawarehouse) contrarias a lo que recomiendan los académicos, en especial Ralph Kimball:
La mayor discusión fue en la recomendación para definición de claves para Dimensiones de los esquema estrella de los “datamarts”:

Uso de Claves Primarias del sistema OLTP de producción-
Uso de Claves Primarias de tipo cadena de texto
Uso de Claves Primarias de Tipo Fecha, para la dimensión tiempo - este punto debo admitir que puede ser válido.

Cuando mostré mis propuestas de diseños de dimensiones para esquemas estrella, siguiendo las recomendaciones Kimball, se me pidió cambiar todo porque usaba:

Claves primarias autonuméricas (Surrogate Keys), en lugar de claves primarias de producción o concatenado de las mismas, aunque sean de tipo texto. (http://www.dba-oracle.com/oracle_news/2005_10_4_kimball_surrogate_keys.htm)
Columnas de versionado para vigencia de dimensiones: fecha-hora de inicio, fecha-hora de fin, y número de versión, para las dimensiones que cambian lentamente (http://en.wikipedia.org/wiki/Slowly_changing_dimension#Type_2)
Una dimensión Tiempo que tenia valores numéricos como clave en lugar de tipo Fecha (Date). En este caso debo admitir que no use una clave autonumérica como se recomienda, sino sino una clave con formato “aaaammdd”, que tampoco esta mal. (http://es.wikipedia.org/wiki/Tabla_de_dimensi%C3%B3n#La_dimensi.C3.B3n_.22tiempo.22)
El sufijo “_key” para el nombre de los campos clave de las dimensiones, como esta en los textos de Kimball. En este caso me pidieron que use “id” como parte del prefijo del nombre de dicha clave para seguir una nomenclatura propuesta por la consultora. En fin, cuando la forma importa mas que el fondo....

Sintiéndome como Galileo cuando la tradición dice que pronunció la frase “Eppur si muove” (y sin embargo se mueve) luego de que la Inquisición le hizo jurar que "la tierra esta quieta y el sol gira alrededor de la misma"; cambié el diseño al gusto de los consultores.
Lo hice para que no me culpen de trabar el proyecto, que no digan de mí que estoy para “poner palos en la rueda”.
Mi actitud con los consultores es aprender de ellos todo lo que pueda sobre el uso de las herramientas de inteligencia de negocios que representan, pero con esta experiencia aprendí que aunque hay que escucharlos, no hay que aceptar todo lo que recomiendan.
Entiendo que hacer lo que recomiendan los consultores también funciona, pero en mi humilde opinión funciona de manera como se dice en Guaraní “vai vai” o en el hablar paraguayo “ya da ya”; es decir una actitud en contra de hacer un trabajo con calidad, ya que también funciona la manera aceptable.

Aprender otro lenguaje de programación

2009-05-24T09:51:00.000-07:00

Aprender otro lenguaje de programación es similar a aprender otro lenguaje hablado.

Si sólo manejaran Castellano, ¿no les parecería interesante aprender otro idioma?
Por ejemplo: Guaraní{y/o [Portugués|Inglés|Francés|Alemán|Japonés|Chino|otro lenguaje de tu preferencia]}

En mi humilde opinión, esto se puede aplicar a aprender otros lenguajes de programación. Además de ser interesante, aprender un lenguaje ayuda a comprender mejor otro que ya se conoce.

Me gano el pan programando en Java, me gusta programación orientada a objetos, aplicar Patterns (GOF y otros), la arquitectura MVC, el mapeo Objeto-Relacional(JDO/Hibernate/JPA), hacer pruebas con JUnit, etc.

En una pasantía en una casa de software en San Francisco-CA, hace mas de 2 años, me sumergí en una experiencia de 6 semanas de desarrollo web ágil usando la metodología eXtremme Programing y el framework Ruby On Rails, digamos que "crucé el rubycon", parafraseando a Julio César, usando otro lenguaje orientado a objetos: Ruby.

Para alguien que viene de Java, donde el código es elegante, pero se escribe mucho, no sólo en código, sino también en archivos de configuración XML, Ruby y su framework Rails me mostraron un mundo donde también se aplican Patterns y la arquitectura MVC, se tiene el mapeo Objeto-Relacional con la implementación del Pattern Active Record (de Martin Fowler - http://martinfowler.com/eaaCatalog/ ), pruebas de unidad, etc.; es decir encontré un entorno que se puede también tener la elegancia y ventajas de Java en menos lineas de código y con una configuración implícita, si se sigue una convención.

Aprender Ruby despertó mi interés en seguir aprendiendo otros lenguajes como Python o Groovy, y por supuesto profundizar JavaScript, o ser tentado por el lado obscuro de la fuerza y aprender C# ;).

Como la mayor parte del código que escribo son procesos concurrentes del lado servidor, al observar la ejecución de los mismos he notado que en los servidores de doble procesador y doble/cuádruple núcleo, sólo se usa el primer núcleo del primer procesador. Los servidores multiprocesador y multinúcleo llegaron para quedarse, pero escribir código para ellos con los lenguajes de programación que conocemos (C, C++, Java, C#, etc.) no es trivial, pero al parecer la respuesta a este hecho puede estar en el resurgimiento del paradigma de la programación funcional.

En esta área tenemos varios lenguajes, que proporcionan una abstracción mas alta, para el manejo de procesos distribuidos y concurrentes en estos servidores multiprocesadores con multinúcleos, citando sólo algunos: Lisp, Clojure, Haskell, Scheme, Ocaml/F#, Erlang, Scala, etc.

Entre estos me parece interesante Erlang, por mi experiencia en el área de telecomunicaciones, ya que es un lenguaje diseñado en Ericsson (nombrado en honor a un matemático danés que trabajó en la teoría de colas). El paso de mensajes mediante colas entre procesos concurrentes es muy eficiente y escalable, sin necesidad de usar bloqueos. También, además de muchas telcos, Erlang está siendo usado en Google, Amazon, Yahoo, Facebook y es el lenguaje en que está escrita la base de datos de documentos Apache CouchDB. El inconveniente que voy a tener con Erlang es aprender la sintaxis, ademas del nuevo paradigma de programación, que es bastante diferente a Java.

En cuanto a Lisp, pionero en IA, el lenguaje embebido en AutoCad y Emacs, también es fuertemente recomendado por Eric Steven Raymond, como requisito para ser un hacker ;) http://www.catb.org/~esr/faqs/hacker-howto.html .

Haskell y Scheme están presentes en el curriculum de ensañanza de las mejores universidades, y F# - con F de funcional y basado en OCaml- es la propuesta de Microsoft para la plataforma .Net.

Pero lo que me convenció de que el siguiente lenguaje que debería aprender es Scala, además de ser el lenguaje en que está escrito Twitter junto con Ruby on Rails, y que el aprendizaje por mi base de Java me sería mas fácil, es la siguiente entrada de Blog:
If you have to learn just one programming language http://blog.srinivasan.biz/2009/04/29/if-you-have-to-learn-just-one-programming-language/

Luego de Scala quiero aprender Erlang :)