Tome chango su banana

Prior to my current iPhone i had a Blackberry Curve. And the single most important feature it had was Blackberry Messenger. I messaged other blackberry users a lot, and since I paid a flat fee for data usage, I could basically send 1000 messages a day and not get charged extra. Even considering the extra cost for the data plan, the blackberry was cheaper than my previous Nokia phone, where I had to pay for each SMS I sent.

Then I bought an iPhone. Mind you, in Mexico we had to wait for Apple to create the iPhone 3g. Then we had to pay through the nose for the device, and then again a significant amount for the monthly data plan. All in all, phone service + data plan pretty much equals what I was paying monthly for my Blackberry. However, due to SMS usage to replace what I previously did with Blackberry Messenger, the iPhone was costing me about twice as much as the Blackberry each month. I had to cut back on my messaging;  spending that amount of money for a communications device and then having to cut back on your communications just doesn’t make sense. Why did this happen?

The iPhone has no Blackberry messenger equivalent. Sure, there’s fring and plenty of other messaging applications, but since Apple didn’t see fit to allow for 3rd-party background processes, none of these applications work unless they’re in the foreground, unlike BB messenger which would deliver messages at any time.

Can it be done? Sure it can! Apple’s applications (Mail, phone, SMS) do it all the time, beeping and popping a nice notification icon to let you know “you’ve got mail”.

“Not to worry”,  I thought. “At WWDC where the iPhone 3G was announced, Apple announced a push notification service where applications could send, through Apple’s servers, background notifications to any iPhone app, to be displayed in several different ways.” This would enable messenger functionality for almost any application and would mean you could send instant messages without incurring SMS charges. After all, I’m paying through the nose for an unlimited data plan, I should put it to use. Apple said the service would be available by September.

September came and went. October came and went, and so did November.

iPhone software updates came and went: 2.0 was the original iPhone 3G release. 2.0.1, 2.0.2, the 2.1 major release on September 12th, and 2.1.1. By now we were wondering where our push notifications were.

Apple announced the 2.2 firmware in October. Expectations grew high that it would include the vaunted push notification functionality. But on November 21, we were disappointed again: 2.2 includes mostly eyecandy improvements. Apple, come on! this is an expensive device, and you can’t keep delivering disappointments. Performance and stability improvements are welcome, but WHERE THE HELL are: 1) the PUSH NOTIFICATION SERVICE YOU PROMISED YOU’D DELIVER TWO MONTHS AGO and 2) A FREAKING CUT/PASTE FUNCTION LIKE EVERY $20 PHONE ON EARTH?

This is an official call for Apple to stop wasting time and delivering the functionality I was promised; Now don’t get me wrong, I like the iPhone, but the lack of this service is costing me money, since all those messages I have to send through SMS are not cheap. The thought of going back to the blackberry has crossed my mind; so Apple, you either deliver this sooner rather than later, or I’ll snatch a Blackberry Storm the first chance I get. Because yes, the iPhone is THAT expensive; It’d be cheaper for me to purchase a Storm at retail price, than keep subsidizing, through SMS,  the iPhone’s inability to come into the 21st century with regards to BASIC functionality. Oh, and maybe then I’d be able to keep using my wonderful Blackberry unit converter, which I’ve been unable to port to the iPhone because, hey, I can’t afford the $100 to enter the iPhone developer program, because I spend it all on SMS!

Just released Berry Unit Converter 1.2.1, to fix a stupid bug with ounces and stones conversion. An upgrade is advisable. BerryUnitConverter is free software. Get more info and a download from here.

A note on Slashdot says that vApp, [is] a tool that will allow developers to ‘encapsulate the entire app infrastructure in a single bundle — servers and all.’ Indeed part of the push with virtualization is that you can have an application running on its own instance of the operating system, and share the hardware resources between many such app/OS “bundles”.

I think this way of seeing things is dangerous! Let’s analyze history for a bit. First, application programs ran standalone on a computer. As more and more programs began to appear, it became clear and obvious that they all required several common services: memory management, input/output, disk access, printing, graphics routines, and so on. Thus operating systems were born, where the OS would handle these common tasks and free application programmers from having to do that. An added benefit is that the OS could arbitrate access to these resources and enable multitasking of several applications, since all the apps talk to the OS through APIs and need not concern themselves with low-levelness.

Then beasts such as Windows appeared. Both the OS and the applications that use it are so brain-dead, that most vendors who sell server-grade Windows applications basically require that each app has its own dedicated server on a standalone Windows installation.

This of course is ridiculous and byzantine. This is where VMware came in and realized that a typical organization could have say, 10 servers each running at 5% usage, each with a mission critical application that absolutely must be on its own on this server. And they said “well how about we run 10 instances of Windows, isolated from each other through virtualization, and then we can have a single box at 50% usage running all 10 apps the way they want to”.

This is indeed the bread-and-butter of VMWare. But beware! are you noticing a trend here? by “demoting” each OS/app set to an “app bundle” status, VMWare is indeed taking a step backwards. Okay, so they want VMWare ESX to take the place of the traditional OS, and have each application/OS running on its own. This looks suspiciously familiar to the “app has to do everything by itself” model we escaped from a couple of decades ago!

Sure, as an application programmer I was freed from having to program my own routines for a lot of tasks (for systems such as Mac OS or a decent Linux graphical environment, the libraries free me from a LOT of mundane chores). However, the second killer advantage of an OS providing services is efficiency; this means one piece of software providing access to all applications; I run one OS for all my apps and save on memory, disk space and CPU cycles.

By moving the actual OS (VMWare) down, it provides only very basic services to the “apps” on top (the OS). So indeed, every app carries a gigantic “library” of functions since, in effect, this library is now an entire operating system. The overhead for having several copies of the OS running is gigantic; each Windows installation takes up a couple of gigabytes, while consuming a few hundred megabytes of RAM and a fair share of CPU cycles. On startup, you have 10 copies of Windows, all performing the exact same bootup sequence and reading the same files (albeit from different disk locations, so no caching performance boost).

Worst of all, without proprietary hacks, you also lose the important benefit of interprocess communications. After all, and this is one of VMWare’s purported benefits, each app is isolated from the others, by virtue of running under its own OS instance.

So who is the culprit here? Sure, poorly programmed Windows applications which can’t work without littering your entire hard drive with DLLs and barf if another unknown process is running at the same time, have most of the blame. But this trend is spreading to other operating systems (Zimbra, I’m looking at you). A huge step backwards looms over us, once developers begin to think “hey, I can actually take control of the entire operating system and have it bent to my app’s will and requirement; after all, if the user has a problem with that, he can always virtualize my app and OS”.

What is needed is to go back to well-behaved applications, ones that are designed from the ground up to play well with others, and that by this very design trait, do not interfere with others.

I realize that this might be difficult; after all, with all the dependencies between system components, it might be understandable that my app’s database configuration requirements might break another’s. But then again, the solution is NOT to run two apps with TWO separate databases on TWO different operating systems. Either I find a way to NOT require my app to mess things up, or I provide with a non-system-wrecking component that gives me the service I want. Sure, it’d be a pain in the ass to run two instances of SQL Server, each on a different directory and on a different port, but it beats running two entire copies of Windows. Or wait, wasn’t Windows stable enough for this already?

Still, I think it’s a matter of politeness and cooperation between developers, to not require me to wreck my OS or virtualize in order to run an application. The reasons for virtualization must be different: consolidation of workloads, isolation for security or experimentation purposes, ease of deployment/restoration in case of disaster. Because, hey, do you all remember when everybody was saying “one of the advantages of Windows is that developers don’t have to develop printing, graphics, file access, GUIs and sound separately for each app and for each piece of hardware out there! the OS gives us that service” ? .

Sure developers deserve a break; that’s no excuse to be lazy, and you should think of us, sysadmins of the world, who also have to care for and feed the operating system instances on which your apps run. And trust me, each OS instance, however virtual it might be, still counts as a separate server, with the same care & feeding needs as if it were a standalone box. And however cool it might sound, trust me, I’d rather not wrestle with 150 virtual servers, when 5 well-kept instances would do the same job. KTHX!

I’ve just published BerryUnitConverter’s source code. It’s GPL-licensed so grab it while it’s hot. Oh, and I also have a git repository, so feel free to contribute patches, preferrably in git format.

I just released a prefixed_attributes plugin for Rails.

Rails has a handy number_to_human_size method, but in order to use it, all
your quantities need to be in non-scaled units, and it’s cumbersome to have
your users typing 100 gigabyte amounts by hand. You’d normally have a
“bytes” column in your records and add virtual attributes to your models.
This plugin adds those attributes for you.
The plugin adds a prefixed_attribute method to all your classes. Use it to mark an
existing attribute on your class (even a non-AR one) like this:

prefixed_attribute :bytes, :type => :binary
prefixed_attribute :hertz, :type => :si

More information here.

So I’ve released version 1.0 of my Blackberry Unit Converter, aptly named BerryUnitConverter, upon the world. If you’re looking for a handy unit converter for your Java-based Blackberry smartphone, I’d love for you to give this little program a try. It can be installed over-the-air, see the instructions on the BerryUnitConverter page.

So, I bought a cheap-ass (115 pesos) bluetooth adapter, thinking I might use it to establish a PAN between my macbook and my desk computer; this is due to a) no CAT5 cable and no IP address for my laptop on the lan, b) no WLAN coverage up here. I know Bluetooth will be kind of slow but it beats having the macbook with no connection at all.

I followed the excellent HOWTO written by Zdenek Bouresh and things didn’t seem to work; the macbook wouldn’t find the Linux PC and so couldn’t pair to it.

It turns out that having ISCAN (whatever the hell that is) on your bluetooth device is imperative for it to be found. You can check if you have it by running hciconfig and you get something like this (look for ISCAN and INQUIRY on the third line; if like in this example you don’t have it, then something’s still wrong):

hci0:	Type: USB

 BD Address: 00:11:67:88:06:17 ACL MTU: 1021:8 SCO MTU: 48:10

 UP RUNNING PSCAN

 RX bytes:1377 acl:0 sco:0 events:46 errors:0

 TX bytes:672 acl:0 sco:0 commands:39 errors:0

So how to enable ISCAN?  Oddly, /etc/bluetooth/hcid.conf already contains a line that says:

iscan enable; pscan enable;

However it looks like it doesn’t work. So what I did (quick & dirty) is add this command to /etc/rc.local:

hciconfig hci0 piscan

Also, it appears as though the default startup script starts pand too quickly, and hcid hasn’t had a chance to initialize yet; as a result, your log file will show :

pand[5218]: Failed to connect to the local SDP server. Connection refused(111)

What I did was insert a 5-second sleep in /etc/init.d/bluetooth,  at the beginning of the pan_start function.

Voilá, now my macbook sees the linux computer, a passkey exchange is initiated (and managed on the linux box via kbluetooth, I highly recommend it). The Mac gives a list of “services you want to use with your device”. If you enable PAN only, it will probably say “there were no supported services found on your device”. I guess if you also enable Bluetooth DUN you’ll see this service. Regardless, when you click “continue” a cheery message says “congratulations” and states “your computer and device were configured with the following services” and “use as a personal area network” will be shown.

As you dismiss this dialog, the bluetooth icon on the status bar will sprout a new option, “join network on whatever”. Clicking this will initiate a connection attempt.

Again, the HOWTO refers to creation of a dev-up script but I found I also needed a dev-down.  so in /etc/defaults/bluetooth:

PAND_OPTIONS=” –listen –role nap -u /etc/bluetooth/pan/dev-up -o /etc/bluetooth/pan/dev-down”

/dev-down contains:

#!/bin/sh

ifdown bnep0

sleep 2
/etc/init.d/dhcp3-server stop

and it looks to be working now

everyone’s first vi session. ^C^C^X^X^X^XquitqQ!qdammit[esc]qwertyuiopasdfghjkl;:xwhat

Los manos libres Bluetooth son un rubro donde realmente vale la pena buscar una marca especializada para obtener un producto de calidad. Tras una mala experiencia con un manos libres Genius diseñado para sostenerse únicamente con un auricular dentro de la oreja (y fallando miserablemente, se cae con gran frecuencia), y tambien adolesciendo de multitud de problemas de calidad, funcionamiento y diseño, y casi un año de no visitar este nicho tecnológico, me encontré con el aclamado Plantronics 640 que ha cambiado mi opinión completamente.

Existe una diferencia básica entre las compañías que producen equipos Bluetooth como parte de una línea de productos muy extensa (Motorola, Sony Ericsson, Nokia, Genius, Samsung, e incluso los fabricantes de electrónica sin nombre de Taiwan y zonas aledañas) y aquellas que se dedican exclusivamente a equipos de auricular (Plantronics, Jabra, Tekkeon, Nextlink); se trata de compañías que están obligadas a generar un producto competitivo, so pena de salir del mercado desplazados completamente por las economías de escala.

Plantronics entrega un claro ejemplo de esta filosofía con el 640; un equipo sumamente refinado, bien pensado y funcional que evidencia el hecho de que los diseñadores en efecto piensan en auriculares todo el día.

El 640 viene con una serie de aditamentos para permitir cargarlo de varias maneras. En su “sillón” de carga utilizando un adaptador de corriente incluido; se pueden conectar adaptadores para diversos teléfonos celulares, evitando acarrear varios cargadores. Otro accesorio permite cargar el auricular por medio de una pila AAA, ideal para viajes. Lo interesante es que todas estas piezas se ensamblan para formar una especie de “pluma” que en caso de un viaje puede incluir todo lo necesario: el auricular, el sillón de carga, el cargador con pila, y el adaptador para el cargador del teléfono. Esto provee una solución muy elegante al asunto de la carga del auricular.

El auricular en sí es tubular de aproximadamente 5 cm de longitud y 9g de peso, con tres botones: dos de volumen y uno para control de llamadas. El auricular soporta las funciones clásicas de un manos libres, como son contestar y terminar la llamada, subir y bajar volumen, silencio (ambos botones de volumen a la vez), llamadas tripartitas y transferencia de llamada, remarcado de último número y marcado por voz. La mayoría de estas funciones se operan con presiones prolongadas del botón de control de llamada y son dependientes del contexto de forma que en cada situación la presión del botón realiza solamente una acción, evitando estar tecleando “clave morse” con el botón.
El ajuste se hace por medio de un audífono de gel (goma) que se detiene de manera bastante firme pero cómoda en el oido. Bajo circunstancias normales es la única sujección que se requiere. De manera inteligente el sistema incluye tres tamaños de gel que vienen incluidos en el paquete para ajustarlos al tamaño de oreja del usuario. Para extra seguridad también incluye un sostén de alambre similar al de unos anteojos; en general encontré que no es necesario pero sí proporciona seguridad adicional.

El emparejemiento con el teléfono es sumamente sencillo y una vez emparejado, el 640 se conecta automáticamente al teléfono. El tiempo de respuesta es muy rápido y se puede, por ejemplo, tener el 640 apagado; al recibir una llamada, el tiempo que toma encenderlo, esperar que enlace, y presionar el botón para contestar, es de aproximadamente 5 segundos; suficientemente rápido para contestar la llamada.
Dos factores muy importantes para el auricular son la calidad del audio y la seguridad del agarre. El primero fue comprobado utilizándolo para hablar en ambientes ruidosos con mucha gente. En este ambiente el rendimiento fue excelente, el audio con gran claridad en ambas direcciones y sin intromisión excesiva del ruido.

Para el agarre equipé el 640 con el aditamento de sujección y me fui a correr; durante la carrera de aproximadamente 25 minutos me caí, y en todo ese tiempo el 640 se mantuvo en su posición sin ningún problema. Para uso en condiciones menos extremas basta con la goma sin el aditamento extra; bajo este uso es posible mover la cabeza violentamente y el auricular se mantiene en posición. Dos de los usos más comunes, usarlo mientras se camina y mientras se conduce el auto, mostraron que el 640 no tiene ningún problema para mantenerse en su lugar aún usando solamente la goma.

Finalmente el Plantronics 640 es un equipo bien diseñado, con atención a los detalles en donde éstos realmente cuentan, y que deja claro el hecho de que en este caso, la especialización del fabricante ha destilado un producto sobresaliente.

Sucks or rocks? googleometer gives us a parameter.

20,900,000 pages mention ruby on rails, while 1,560,000 mention django AND python.

These are our baselines. Now for the rocks:

714 pages think Django rocks. 1,000 pages think ruby on rails rocks.

The sucks are as follows:

541 pages think ruby on rails sucks. 147 think Django sucks.

Of course since I can’t grok Python I still think Ruby rocks most.

I tried to deploy to a remote debian (etch/testing) server running dropbear instead of openssh. Rake blew up (Vlad impaled it?) with an error such as this:

Writing configuration file to /***/mongrel_cluster.conf.
rake aborted!
execution failed with status 255: ssh www.****.com mongrel_rails cluster::configure -N 2 -p 8000 -e production

-a 127.0.0.1 -c /****/current -C ****/shared/mongrel_cluster.conf

This was strange because when I checked on the server, all of the tasks were being executed correctly, and dirs and files were created.

I switched to OpenSSH and the problem went away.

It looks like, even if the command executed is successful, dropbear sometimes ignores the return code and exits with 255, which confuses rake. This doesn’t happen with OpenSSH.

It looks as if the problem is with dropbear, as I had the same issue when trying to deploy with capistrano (crapistrano?). So I guess I’m back to plain old openssh…

rich: n. Laden with useless features and incredibly difficult to use in real life.

Example:

“ZK is a Web framework designed to enable Web applications to have both rich user experiences and a simple programming model. ZK includes an AJAX-based event-driven engine to automate interactivity, a rich set of XUL and XHTML components to enrich usability”

Translation: ZK has a boatload of components which you will never use; those you do, will be incredibly hard to program even though they include basically text fields, buttons and checkboxes; and all this will result in a molasses-slow experience for your end-user.

Durante la debacle del año 2000 muchos programadores cayeron en cuenta de que era mejor utilizar 4 dígitos para almacenar el año. Muchos, por sistema, lo hacemos incluso desde antes. Sin embargo es curioso que una vez pasada la crisis, en muchos lugares se comienzan a utilizar nuevamente cantidades de 2 dígitos para representar el año. Esto es MUY TONTO! El argumento clásico es “bueno, en el año 2100 el sistema ya no va a estar en uso”. Es EXACTAMENTE lo que dijeron en los 70’s con “bueno, en el año 2000 el sistema ya no va a estar en uso”. Quizá se requerirá una crisis como la próxima del año 2032 para zarandearles el tapete a todos y que agarren la onda. A mi por lo menos me dan calambres mentales cada vez que veo un “75″ para representar una fecha. Gente, faltan apenas 69 años para el 2075 y entonces este caso concreto del que hablo va a empezar a dar problemas. Juar juar.
The eighties called… but I AIN’T GIVING THE MUSIC BACK!! HAHAHA