De esto ya ha pasado algún tiempo, pero creí necesario escribir sobre lo mismo para que quede en la posteridad.

Todo comenzó cuando navegando en internet vi que existia un concurso del periodico ADN para concoer personalmente a los chicos de Calle 13. El concurso consistía en hacer algunas cosas relacionadas con Calle 13, entre ellas hacerce el look de Residente o Cantar la canción Muerte en Hawaii de la misma banda y subir el video a YouTube. El premio se lo ganaba la persona que más likes consiguiera en Facebook.

Dado que me puedo considerar fan de la banda y que he estado neciando con música ultimamente (hice un remix de esa canción con mis juguetes musicales, ver el video abajo) y después de conversarlo con mi novia, decidimos hacer una versión de Muerte en Hawaii de Calle 13 propia para participar en el concurso. Nuestra versión iba a tener unos arreglos propios de la múscia de la costa norte de Colombia (Vallenato y Cumbia para ser más específicos). Como queriamos hacerlo rápido, decidimos hacerlo en dos sesiones por la noche y así subirlo lo más rápido posible para iniciar a conseguir "likes".

Iniciamos grabando los acordes básicos, con suerte descubrimos que la canción estaba en el tono que estaba afinado mi acordeón (Bb-Eb-Ab), asi que no tendria que buscar otro (o comprarme un Roland FR-18 ). Grabamos también los acordens en piano (usando my Korg padKontrol). Con esa base procedimos a reemplazar una de las guitarras con el acordeón, el cual grabamos con mi FastTrack pro y el micro Samsom C03 conectado a esa tarjeta. Todo lo grabamos usando GarageBand que venia con mi Mac. Aprovechamos y grabamos también la caja y la guacharaca del mismo modo. Todo eso en algo más de 3 horas un domingo por la noche.

Aunque sonaba bien, nos faltaba otra guitarra (y el bajo) y era dificil tocarla como queriamos usando algún controlador MIDI, así que le dije a mi amigo Esteban Salazar para que se trajera su guitarra al dia siguiente y así grabaramos la segunda guitarra y los bajos. Conectamos la guitarra directamente a la FastTrack Pro y usando los amplificadores virtuales del GarageBand obtuvimos los sonidos que queriamos tanto para el bajo como para la guitarra. Esteban tuvo algunos problemas identificando algunos acordes que posiblemente con algo de tiempo los hubieramos conseguido, pero como estabamos al trote, decidimos hacer algunas ediciones en Garageband y seguir.

Las voz principal la grabé y con mucha ayuda de mi novia que es profesora de canto. Ella me corrigió algunos problemas de afinación. Los coros los hicimos todos y algunas voces auxiliares las realizó ella.

El "Video" que hicimos esa misma noche y usamos la camara de mi MBP fija, sin ninguna iluminación apropiada y con la ropa del trabajo (y algunos trapos encima). Una vez grabado, hice la edición rápida en iMovie y lo publiqué (recuerdo haberme acostado esa noche como a las 2:00 AM)..

Al final no ganamos (realmente quedamos en muy mala posición en el top :P), pero fue muy divertido hacerlo y jugar con los juguetes (hablaré de los mismos en otro post). El resultado obviamente dista de ser pro (nunca habia grabado algo en mi vida) pero quedé muy contento con el mismo. Depronto me gustaría hacer algo con un acordeón más elaborado (hacerlo más vallenato tal vez) y tener cajeros y guacharaqueros de verdad para que quedara bien grabado. (por que me tocó grabar todo eso a mi, la calidad no es la mejor).

Abajo el vid con el resultado final. (El cual es totalmente Cheezy, pero divertido). Por favor obviar los errores de sincronización del cantane y la música :D.

Bonus Track

Aca un remix de la canción Muerte en Hawaii de Calle 13 con una percusión (realizada con Garageband y mi Korg padKontrol):

Cuando yo tengo un viaje a estados unidos o algún amigo viaja para allá, mucho de nosotros aprovechamos y compramos cosas. Uno de los sitios favoritos para comprar en USA tanto mio como de mis compañeros de trabajo es Amazon. Los precios, como es de esperar, están en dolares, por tanto tenemos dos opciones para ver los precios en nuestra moneda local: 1. Hacemos el calculo aproximado (por ejemplo 1 dolar = 2000 pesos) o 2. usamos una sencilla calculadora y juiciosamente realizamos el calculo. También, si usamos algún buen navegador podremos usar alguna extensión que nos ayude con ese calculo.

Sin embargo, lo ideal sería poder ver precios de nuestra moneda local directamente en Amazon. Dado que no vi ninguna extensión que hiciese eso (y la verdad no busqué de a mucho) y que también que tenia ganas de aprender Javascript (por eso del HTML5) decidí hacerme una extensión para Google Chrome (el navegador que uso) que hiciese precisamente eso, mostrar los precios en la moneda local. (En mi caso COP).

Se llama Amazon-XCH y la la desarrollé basandome en la extensión Currency Converter para Chrome, es decir, usa como fuente de datos Yahoo Finance, por tanto usa los datos en tiempo real del mercado internacional no la TRM (tasa oficial) del día, sin embargo es un buen aproximado, además de permitirle a la extensión mostrar los precios en cualquier moneda del mundo :-). El precio aparece entre parentesis luego del precio original en dolares (depronto cambio esto en el futuro cercano).

Dado que es la primer aproximación el código no es de lo mejor, adicionalmente hay algunos inconvenientes en los que trabajaré si el tiempo me lo permite:

• Cuando el precio hay que verlo en el carrito ("see price in cart") para que se muestre el precio hay que darle click al link, cerrar el frame y darle click otra vez.
• Los precio desaparece cuando un producto tiene varias opciones de configuración (como el Kindle 3G).

Pueden descargar la extensión desde la Google Chrome WebStore.

El código fuente (licenciado como MIT) pueden verlo en Github.

Creo que debería hacer un post similar a este en inglés pero es algo tarde y tengo sueño.

Buena noche.

Since I graduate from college (actually a little bit before that) I always felt like I was in between worlds. I had a lot of friends from the university that had very defined profiles and skill sets. Generally, they were either Developers (some of them very good coders) or they were oriented towards networking and systems administration (many of them literally hated programming).¹

Nowadays, I still feel like a hybrid between the Sysadmin and Software Developer. Even though now I am "Software Architect" in a software development department, I really do a lot of stuff that is related to the operations part. As my team generally defines the best practices and the technology to use company-wise, It is crucial for us to be well versed in sysadmin tasks.

As I mentioned above, my team has to define/develop many of the technologies that the other development teams use, that includes SCM procedures tools, integration technologies, application servers, shared libraries, development environments, common functionality libraries and so on. As you see, many of these activities require a lot of interaction with operations people. So, we generally end up working, or at least talking, with the operations crew much more frequently that the common Software Developer. Sometimes, we even have to perform "operation's" activities on our development environment first, and then send a "How-to" manual to the operation people to perform.

As is common in many enterprises, Operations is clearly separated from Development and from QA. Moreover, QA is also split in two different teams: the "Technical QA" which "belongs" to Operations and the "Functional QA" which belongs to Software Development department ². So, my company is no different from a common enterprise, both areas have different agendas and they both claim to be "aligned" with the "strategic objectives" of the business. However, when it comes to get a new application to production (which includes getting the hardware, testing, preparing the environments, and other related task) or simply releasing a new version of an already existing application into production, all the process (even in our development department) are either manual, duplicated or extremely tedious. And generally a combination of all of them.

Currently, we are in the process of improving our Software Development Methodology. I am in charge of the SCM process definition, but only for the dev team. But this is no easy task, given the broad scope of the process and that we are basically in diapers when referring to CM. Some could think that this is a great opportunity for us to automate and improve these process, including Release Management and Build Engineering (namely, continuous integration, unit testing and other industry best practices). However, although we certainly would do better if we apply this to our processes, at the end, we would hit operations' "wall" nevertheless.

In the beginning I believed operations was a bottle-neck because they were just not agile as they should, or not as good as they should. But there was another factor I did not take into account. Operations inherently wants to prevent change, given that they are the responsible for the stability of the system and they are also rewarded for that. If you make changes (e.g deploys, new applications, etc) possibilities of making the whole system unstable increases. But if you do stop changes (or make the process of releasing new changes extremely cumbersome) the change will be accumulative and big changes are far more dangerous than small ones.³

• Information silos. We have different systems to handle requirements from users, task planning, bug database, test results and deployment requirement. That is not necessarily bad, but none of those systems are connected, so each of them have a work-flow and database. Therefore, there is no way to trace back a change with a release to production or to bug (issue).
• Cumbersome Processes: The process of getting a new application on-line is cumbersome, filled with a lot formats that ask impossible question to answer.
• Manual Build & Release Process: Once the application is "on-line" and we want to release a new version of the software all is done "manually", from the compilation, testing to the configuration of environments. Some of those task are requested using ticketing system, asking for the same information over and over (We have even two different process for asking the same stuff and performing the same task). In other words a Build and Release process should be created.
• Manual Environment Management The environment administration is done also manually, and a lot of problems occurs when a change is requested. Finding the origin of the change is difficult if not impossible. Environment configuration should be baselined and handled using appropriate tools. (Like or Chef or Puppet, just to name some Open Source alternatives). That is, the environments should be first class citizens and automated process for managing the changes should be put in place.
• Dependency Management is not managed at all by operations, I had to create a Subversion repository with some manual procedures in order to stabilize the system. (See my older post). We have minimized the problem of "It works on my machine". However, there is still problems with configuration files that are not managed at all.
• Split QA Teams: The QA department is split in two, technical and "functional", each managed differently and with different tooling and objectives. Many of the test are manual, making them difficult to re-schedule. There is no Code Coverage or Automated Unit Testing, only System testing. This not only makes the QA process slow but also may prevent a proper identification of application issues. I believe also the communication between teams (QA, Ops and Dev) can be improved.

We have more or less a broad view of the problems, and It is evident that if Operations and and Development worked together this could a lot of them could be tackled. Recently, a new "approach" called DevOps have taken strength in the last few years. Wikipedia (and the Original article) defines DevOps as

[…] a set of processes, methods and systems for communication, collaboration and integration between departments for development (applications/software engineering), technology operations and quality assurance (QA).