So my iPhone fell and got damaged. To its credit I have to say I did hit it pretty hard several times in the past, and it’d survived. However this time it didn’t, and I had to get a replacement. I had to pay for it since it was out of warranty. However the truly painful thing was spending one week without the perks of the modern smartphone.

I had to dig out my trusty 5-year-old Nokia 7210 (not the SuperNova, I mean the original funky-buttoned 7210), a stylish and compact phone which, however, is pretty featureless by modern standards. You can talk on the phone, send SMS (barely; I don’t know how I sent messages without a full QWERTY keyboard) and that’s about it. It has no camera, no network access, the screen is only 128-color and uploading stuff requires a tedious conversion process, and it only supports 4-voice MIDI polyphonic tones.

This was due in no small part to the death of my Blackberry’s lame battery; the ‘berry would have been a decent temporary replacement for the iPhone,even though it’s not compatible with my data plan. So here’s a tip: when your phone is about to be left indefinitely in a drawer, remove the battery.

Being without the iPhone, what I missed the most was:

• The QWERTY keyboard, without a doubt, is the most-missed feature. Whether virtual or real, it’s a necessity if you plan on composing a lot of text.
• The camera, believe it or not, is really useful for a lot of purposes.
• Synchronization with my computer’s address book. A lesser phone can do it but the Nokia lacked connectivity (only infrared).
• The browser, being able to access the internet anywhere, anytime has become a true necessity.
• E-mail. Yes, also not being able to receive emails periodically or, at least, on demand, is crippling and makes me feel out of touch and claustrophobic.
• Music, I guess it’s a case of “if you have it, you will use it”. Somehow carrying the iPod around in addition to the Nokia didn’t seem like a good idea.

What I didn’t miss:

• Ringtones. However weak the Nokia’s ringtone support is, it’s very loud and adequate, and my favorite ringtone ever (acceleration.mid) was available. I like it so much, I made an MP3 of it and loaded it on the iPhone.
• GPS. It’s cool to have it but I really don’t use it all that often.
• Most of my games. I don’t play on the iPhone that often. I must point out that neither the Nokia nor the iPhone had the “snakes” game from older (and newer) Nokia phones. I guess this 7210 got stuck in the past.

Also in case you hadn’t noticed, the entire point of this rant was so that I could have a new post before the 12th and thus keeping my blog updated “more than once every 6 months”.

Risk is a constant for today’s companies. Google, Microsoft, Apple, IBM (well, maybe not so much with IBM), Toyota… they all take risks developing and testing new technologies. The risk lies in the amount of money and resources they devote to creating new technology. When said technology involves keeping a team to upgrade, fix and evolve it, the risk multiplies. The risk is mitigated if the technology is successful and provides a reasonable return on investment. Indeed, the whole point of “risking” your resources is so that created technology might prove a commercial success and yield the company many times the investment.

However there are times when things don’t go quite right and a company has to “cut its losses” and scrap a project or product altogether. Google has done it, IBM has done it (PS/2), Apple has done it (the Lisa). Microsoft has done it many times, and in doing it yet again they help me make my point today.

“Users of Microsoft’s 3D simulation platform have been rocked by news that the company has laid off off or reassigned most of the of the platform’s developers“,  reads an article at thestandard.com. Microsoft has a 3D simulation platform? Well yes, as part of their venerable Flight Simulator product (has the honor of being the first piece of commercial software I bought, circa 1988), it seems they had spawned off a 3D simulation product. Microsoft’s announced enhancements to the platform meant it was going to be targeted at markets such as real estate, city planning, and law enforcement. And developers for these industries were thrilled, and had already begun work on applications using Microsoft’s ESP technology.

Maybe the reason is the current economical climate; whatever, Microsoft seems to be shedding a lot of “non-essential” teams, among them the Flight Simulator team, followed closely by the ESP team. Streamlining seems like a sensible tactic for a profit-oriented business, right?

Users don’t seem to think that way.

“As a commercial developer who is currently working on two major ESP projects I can’t begin to express the concern I have hearing this news. I look forward to hearing from Microsoft as to the future plans for ESP”

“I’m gutted that this is probably no longer going to see the light of day. It looks like there were a lot of people working really hard to build a revolutionary product. It must be totally crushing for them to see all that work go to waste.”

‘my company used it for a solution and invested time and money into getting it approved and purchased. Microsoft sure handed us a raw deal for taking a gamble on their platform.’

Anyway, my point with all this is that proprietary software is a bad idea. Microsoft is the embodiment of all we loathe in a software company; however much they talk about being business partners, the current schism is a sample, a reminder that, should your business no longer be profitable to them, Microsoft won’t hesitate to hang you out to dry. The bottom line is all that matters to them. And their use and selling of proprietary technologies means that, should the worst happen, you’re left with no recourse but to throw all your investment away and start anew with some other product, hoping that that other company won’t do the same to you.

Rather than risking this, why not go free software? Things would be very different if Microsoft opened up ESP; it’s not like they’re going to profit from that anymore. That way companies with a reasonably talented developer pool might take the project forward, as has happened with many open-sourced, formerly-commercial products (Blender comes to mind). That’s a company that protects your investment. Microsoft just ripped them off, plain and simple.

For all those companies developing products using ESP, it’s likely their business is not primarily software development. Thus they chose to go with a commercial, specialized software vendor. And look what happened to them! Even if they don’t have the in-house expertise to develop something like ESP, a pooling of resources or funding a non-profit tasked with developing and freely releasing an ESP substitute would make sense. A law enforcement organization sees no competition from a real estate, architecture or urban planning company, so what’s it to them if they use the same, freely-developed product on which to base their custom offerings? (look at Unreal Engine and what ID Software does with their Quake FPS engines; also, ID software has open-sourced their old releases, which rings true with what I’m ranting about here). Again, as long as it’s not their core business, there’s no problem with them cooperating in the creation of a component for their main project.

Misery loves company and at least, through heated discussion in MSDN, those users who were wronged by Microsoft have come in contact with each other and might, if they have the vision to venture into the world of free software, have an opportunity to make sure this never happens again to them or others wanting similar technologies.

OK, so I happily hack away on my  Rails application on a Debian box with Ruby 1.8.7 and Rails 2.1.0, and then deploy to a Fedora 8 server with Ruby 1.8.6 and Rails 2.2.2. All of a sudden a particular release causes Passenger to spit an error page on application startup. The key error was:

undefined method `empty?’ for nil:NilClass

Now I’m combing all over my code to find where I’m using “empty?” but I’m sure it’s somewhere that gets run on application startup, otherwise it wouldn’t show up when Passenger tries to start the application. But I find nothing and I’m about to shoot myself.

Following the trace I end up hacking Ruby’s erb.rb file, as there appear to be some bugs in this; indeed, this one from 1.8.6 is different from what I have in 1.8.7, so the app runs fine here. I try to fix instances where empty? might get called on a nil object, but after fixing 3 of these the app stops responding altogether. Hmm, so something, somewhere, depends on erb.rb’s buggy behavior. Best to leave it alone.

HOWEVER, on the deployment server, running with script/server works fine; it’s only when using Passenger that things blow up.

Finally I find this thread that points me in the right direction:

One of the users dropped some
JPEG files into the /app/views/static directory, and that seems to be
jamming up the works with 2.2.2.

Indeed, as part of my last set of revisions, I’d left several samples of static content I was converting into dynamically generated pages; sure enough, they included JPGs and whatnot. Just to be safe, I decided to move the entire directory into public to avoid any problems.

Now the app runs just peachy and I only wasted 2 hours chasing down this bug. Thanks to the guys at Nabble!

Eventually it all boils down to this Rails bug reported at Lighthouse. So hopefully it’ll be fixed soon. In the meanwhile, keep binary files out of your views subtree.

I’m attaching the entire Passenger error page, in case it’s useful to anyone. Mainly so that Google can find it faster for other people with this problem.

A new version of BerryUnitConverter is up. This one adds data units as well as Blackberry Storm compatibility. Let me know of any problems. Get it at the usual place.

Few internet companies or services or phenomena, if you will, seem to attract as many visceral reactions as Twitter. First there was the whole buzz about Twitter and Ruby on Rails,  which always excites passions. Then the “Rails doesn’t scale” debacle. Next the “built wrong” accusations. Twitter even got some sprinklings from Zed Shaw’s spectacular departure from the Ruby scene. Then Twitter screws over their users and stops SMS service basically everywhere but the USA.

Recently Twitter indirectly angered another user community when they hired Rael Dornfest, creator of personal productivity apps I Want Sandy and Stikkit. The problem is that Mr. Dornfest decided to kill both services, altough he will take the “intellectual property” behind them to Twitter. Of course he is within his right to terminate a service that was free and under no promises, but all the users who had come to rely in these apps certainly don’t agree.

Sandy’s user community seems to be, by far, the most affected: messages at Rael’s “going offline” announcement range from the indifferent few to the truly upset, inflamed and disappointed at the whole Web 2.0 thing, specially Twitter. “Karma’s a bitch”, says one comment, and it’s true that Rael’s decision to leave users hanging out to dry will bring him and a whole bag of negative karma to Twitter. As another poster said, “I’d be weary of using any Twitter product with your name on it”.

Will Sandy and Stikkit return as twitter add-ons? possibly, but the real lesson to remember here is this: Twitter itself is also free, so it might go away at any time the creators decide it’s in their best personal interest to kill it and move on. So are most Web 2.0 apps. So if you must use them and learn to depend on them, you’d better make sure you choose the ones that, at least, let you get your data out when they die.

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.