Ha costat, però finalment fa dos dies vaig rebre el portàtil i el ratolí que faltava. Ara sols falta la borsa :) Avui m'he dedicat a configurar-ho un poc i dur un poc més al límit les possibilitats del sistema.

El portàtil és un Latitude 2100 amb 2 Gb de RAM, 16 Gb de disc dur d'estat sòlid, càmera de 1,3 Mp i pantalla tàctil. La pantalla és de 10 polzades amb una resolució de 1024x576 px.

El portàtil és dens, vull dir, que el pes es deixa notar en un volum tant reduït, i el que sobta més és el tamany de la bateria. El vaig demanar de 6 cel·les i sobresurt molt. Els dissenyadors de Dell han tingut l'encert, al manco, d'aprofitar aquest fet per a fer-ho servir de soport i dinar-li al ordinador una inclinació molt bona per escriure. Potser amb la bateria estàndard, de 3 cel·les, l'estètica del portàtil serà millor, però particularment el que m'interessa és tenir molta autonomia més que tenir una portàtil cool. Per ara ja duc 4 hores fent coses, connectat a Internet, fent servir la càmera, configurant, etc i segons el sistema encara en tendria per 1 h i 25 minuts més.

El teclat permet escriure amb comoditat. Recorda al teclat del Dell de 12" i és molt còmode. El touchpad està molt pròxim al teclat i no és desactivable i fa que es tengui que anar un poc més alerta de l'habitual a l'hora d'escriure per tal de no tocar-lo i situar el cursor a un lloc on no voldries.

El portàtil ve de sèrie amb Ubuntu 9.04, al manco l'espera ha significat que no he tingut que actualitzar massa el sistema, ja que el portàtil anterior duia una Ubuntu 8.x. Una i de les coses que provat és la connexió 3G de Vodafone. Una meravella, ha estat posar el modem i m'ho ha detectat, he posat el PIN i ja està, connexió establereta. La velocitat no l'he poguda comprovar, Binissalem pel que es veu encara està fora de l'autopista 3G :(

Una de les coses que més em disgusta de Gnome és el desaprofitament de l'espai que fa. Amb pantalles grans això no és un gran problema, pero quan sols hi ha 576 px s'han de treure pixels d'allà on no n'hi ha. Per això he instal·lat un nou tema Gtk que no desaprofita tant d'espai vertical anomenat Human Compact i he fet quelcom semblant amb el Firefox.

El resultat és que menús que no hi cabien a la pantall ara queden més o manca per la mitat o un poc més. Visualment és un poc menys atractiu, però és molt més pràctic a l'hora de fer feina.

Poca cosa més dir d'aquest portàtil. L'estètica es sòbria i funcional, recorda als IBMs de fa uns anys, i tot ha funcionat a la primera, la única modificació real ha estat la de la distribució del teclat que m'ha obligat a eliminar l'idioma americà per posar-hi l'espanyol.

Aquest apunt està escrit des del portàtil amb gedit i pujat amb el Firefox. Com podeu veure el tamany del teclat per permetre'm escriure en mode verbose :-P

Des de fa poquetes hores ja tenim la versió 1.1 de Django. Les novetats es poden trobar a l'anunci oficial de Django 1.1.

Per mi el més interessant són els canvis a l'ORM (les agregacions són una característica llargament esperada) i les millores a l'Admin, que es pot personalitzar sense fer tant esforç com abans.

Enhorabona als "core developers" i a tots els que feim feina amb Django. Tenim cada dia un bastiment més productiu i potent, on tot el que s'afegeix no és per mor del marketing o perquè fa "cool", sinó perquè realment serveix per a la feina.

Cada vegada que surt una nova versió d'Eclipse s'actualitza la llibreria javahl que és la que se n'encarrega de la interfície de subversion.

Això no seria cap problema si no fos que com que el client java té una versió més actualitzada que el client per línia de comandes, amb la qual cosa una vegada actualitzat un projecte fent servir Eclipse deixa de poder actualitzar-se per línia de comandes.

Això es pot sol·lucionar tornant a baixar la versió del repositori local, però tornarem a tenir el mateix problema quan tornem a actualitzar.

L'altra sol·lució és actualizar el client subversion del nostre equip. El procés és molt senzill i està força ben explicat al blog An Extraordianry Bison, tanmateix pos aquí els passos més importants:

1. Actualitzar les dependències del nostre sistema per a poder compilar subversion:

   sudo apt-get install build-essential libapr1-dev libaprutil1-dev libneon27-dev
   

2. Descarregam el codi font del subversion. La darrera versió actual és la 1.6.3, així que:

   cd /tmp
   wget http://subversion.tigris.org/downloads/subversion-1.6.3.tar.bz2
   tar xjf subversion-1.6.3.tar.bz2
   cd subversion-1.6.3
   

3. Ara ens queda el cicle de configure, make, make install típic. Com que el que volem és tenir sopurt per ssl i per JavaHL farem

   ./configure --with-ssl --enable-javahl --with-jdk=/usr/lib/jvm/java-6-sun
   make -j3
   make -j3 javahl
   

Un parell de notes: el j3 sols és convenient (que no necessari) si teniu una màquina amb més d'un processador (de doble nucli), li podeur donar el valor del nombre de nuclis més un, en cas contrari make gestionarà per si mateix el nombre de traballs simultànis que llança. En el meu cas, al manco, és més òptim "limitar-ho" així.

1. Feim la instal·lació:

   sudo make install install-javahl
   

Amb un poc de sort amb això ja tedrem actualitzat el client de svn a la darrera versió i ens tornarà a funcionar el client de línia de comandes.

Personalment ho he provat a Ubuntu 9.1 amb arquitectura PPC64 i amb arquitectura i386 i cap problema. Funciona tant l'Eclipse com el client de línia de comandes. El Netbeans es segueix queixant de que no troba la llibreria javaNL però ja caurà, ja ...

Una de les dèries que tenim com a informàtics (o que hauríem de tenir) és la d'aprofitar el millor possible els recursos que tenim a la nostra disposició.

Això es tradueix algunes vegades en discussions de que si un llenguatge és millor que un altre en l'aprofitament de la màquina, i quan toca a Python, el tema estrella és el GIL, el mecanisme intern que fa servir Python per poder ser multi-fil. GIL fa que les aplicacions que fan un us intensiu dels fils no siguin tan òptimes com podrien ser (potser sí són més segures i més bones de programar, però això és una altra història) i que puguem pensar no facin tan bon us dels múltiples processadors com es podria suposar. En aquests casos el millor potser és llegir un article molt aclaridor, en lloc de començar a pegar destralades.

Tot i això, pareix que hi ha una confusió entre el que representa l'escalabilitat d'una aplicació i el nombre de processadors d'una màquina. En principi pareix el mateix, però realment no ho és.

La vertadera escalabilitat no la dóna el fet de que l'aplicació aprofiti al 100% els 4 o 8 processadors que pugui tenir el nostre servidor, l'escalabilitat la tenim quan aquesta mateixa aplicació pot executar-se damunt 8 màquines amb els processadors que tenguin. És a dir, que davant un problema que necessiti més potència de màquina, la solució no sigui posar una màquina amb més processadors, sinó posar més màquines.

Aqui ja no parlar d'aplicacions que executin fils, parlam d'aplicacions que executen processos, de comunicacions entre processos, de particionat de la nostra aplicació de manera que pugui distribuir-se.

Una de les maneres més senzilles que he trobat d'obtenir això és mitjançant els sistemes de missatgeria i de les coes de feina. En aquest cas tenim un o varis servidors que actuen de gestors de les coes de feina i una sèrie de processos que envien tasques a la cua per a ser realitzades, processos que realitzen les tasques i processos que consumeixen els resultats. El GIL no és un problema, el problema és pensar en com s'ha de fer l'aplicació, en com distribuir les càrregues entre els servidors, en definitiva, el problema és d'enginyeria de programari pur i dur. Passam de pensar en dues dimensions a pensar en n-dimensions.

Si hi ha una cosa que té bona Python és la poca distància que hi ha entre voler fer una cosa i tenir la capacitat de fer-la. Així doncs fer programes que facin servir les cues és realment trivial: posam un servidor, el beanstalkc per exemple, les llibreries Python que facin de client i ja ho tenim llest. Separar l'aplicació real per a que vagi en capes i establir un sistema integrat de control, això ja és una altra cosa :)

Quan parlam d'aplicacions web un sistema de coes a més pot fer-se servir per a augmentar l'escalabilitat de la nostra aplicació i donar un millor temps de resposta als nostres usuaris.

Imaginem per exemple una situació típica: la nostra web (feta amb Django, per suposat) quan acaba el procés de compra envia un e-mail a l'usuari amb la factura del que acaba de comprar.

Si no ens hem complicat la vida, tendrem que dins la mateixa vista que guarda les dades de la compra hem posat una cridada a la funció que genera el pdf amb la factura i la cridada a la funció que l'envia.

Encara que la factura es generi força ràpid, generar i enviar el pdf pot ser un problema si tenim molta càrrega, consumeix cicles de CPU que estam llevant als visitants de la nostra web.

En aquest cas podem tenir una maquina o vàries destinades a la generació i enviament de les factures. La nostra aplicació web sols envia a la cua (a una altra màquina o màquines) la petició de que s'ha de fer la factura, i els processos que tenim escoltant a la cua de treballs generaran i enviaran la factura.

Com que l'enviament del treball a la cua de treballs és pràcticament instantani, l'usuari té la sensació de que la web ha respost molt ràpidament. Com que tenim màquines dedicades per a la generació de les factures aquestes també es generen força aviat i s'envien. Mentre hem deixat el servidor (o servidors web) descarregats per atendre més peticions. Hem escalat!

És un exemple típic, com veis l'escalabilitat no s'ha aconseguit posant més màquines que fessin de servidors d'aplicacions Django o posant més processadors, sinó separant les tasques en màquines especialitzades. Si parlam de parsejar XML la cosa és encara més divertida, a l'article [High-performance XML parsing in Python with lxml] (http://www.ibm.com/developerworks/xml/library/x-hiperfparse/) de la web d'IBM i gairebé a les acaballes també ens dóna la pista: l'estratègia de dividir i conquerir; una altra vegada més pensar en com feim les coses.

Aquest és un apunt damunt escalabilita, Python i Django, però perfectament podríeu substituir Python pel vostre llenguatge de capçalera i Django pel vostre bastiment web preferit, Python fa fàcil provar totes aquestes coses, però el realment important és adonar-se de que es poden fer.

Dia 15 del mes passat vaig comanar un portàtil Dell de 10" amb disc dur d'estat sòlid de 16 Gb i 2 Gb de RAM i bateria de 6 cel·les i Ubuntu com a sistema operatiu. Total 1,5 Kg de pes. La idea és que fos el portàtil de les reunions i viatges, amb prou autonomia per aguantar un dia normal de feina sense problemes.

Avui m'ha arribat, bé, casi... Ha arribat romput amb un cop d'aquests que fan fredat a la pantalla que és difícil d'explicar. La capsa ja venia copejada, però no foradada i no m'explic com el transportista (UPS) li ha pogut pegar un viatge com aquest a un article que s'ha de manipular com a fràgil.

A més d'arribar amb 15 dies de retràs que arribi d'aquesta manera és una putada. Si torba més el model ja serà antic.

Tot i això al manco ha arribat, cosa que no puc dir del ratolí ni de la borsa de transport, que s'han perdut pel camí. Serà cosa de la crisi?

El portàtil en sí i amb la mitja pantalla que es veu, està força bé. Les tecles són més usables que al portàtil de 9" encara que el mig quilet de pes també s'ha de tenir en compte. Duu Unbutu 8.10 de sèrie que ha arrancat foça ràpid. No l'he configurat perquè no m'hi veig, però promet.

És un portàtil força compacte,dens afegiria i crec que té el tamany ideal pel que cerc: que em permeti fer feina un parell d'hores sense problemes i sobre tot que em permeti dur-ho sempre a la motxilla. El que ara duc és un Dell també de 15,4" (sense copetar) i els gairebé 3,5 Kg es noten si t'has de moure molt i anar a peu. Té molta més resolució que el de 10", gairebé el doble, però com que és també un dels meus ordinadors principals de feina, no m'hi sent còmode passejant-lo. La idea del portàtil de 10" és el de tenir-hi sols la feina del moment i la resta obtenir-ho on-line.

M'hagués agradat poder escriure més coses i contar-vos si va bé o no, i si val el que he pagat per ell, però ara per ara sols us poc contar aquestes petita anècdota. Hauré d'esperar un poc més i confiar en el servei d'atenció al client de Dell, i que la reposició sigui ràpida.

La publicació de la nova versió d'Eclipse, Galileo ha servir d'excusa per a tornar (al manco temporalment) a Eclipse com a entorn de desenvolupament per Python.

És la versió Galileo d'Eclipse millor que Netbeans? Doncs depèn, al cap i a la fi del que es tracta és de que l'IDE ens faci més productius, però a partir d'aquí ja és una qüestió de preferències personals.

Anem a veure les meves...

Facilitat d'instal·lació

La facilitat d'instal·lació és important perquè fa que puguis actualitzar de versió o posar un nou programador a fer feina en poc temps. La gent que fa feina amb PL em diu que necessita molt de temps per poder tenir l'entorn de desenvolupament llest, i com tots sabem temps són doblers.

Ambdós entorns són iguals de bons d'instal·lar. Ambdós tenen una arquitectura de plugins, així que la velocitat de posada en marxa depèn fonamentalment del nostre ampla de banda.

Si ens limitam a Python dir que la versió de Netbeans per Python ja duu el pluggin integrat i necessita davallar menys coses. De la mateixa manera no és necessiten pluggins addicionals al Netbeans per fer feina amb javascript, css o html, ja ve tot de sèrie.

Guanya Netbeans però de ben poc, ja que gràcies a projectes com Yoxo podem configurar-nos la nostra pròpia distribució d'Eclipse.

Portabilitat

Faig feina gairebé al 99% damunt Linux, però amb versions i386 i PPC. De tant en tant he de provar alguna cosa damunt Windows i per això vull que el meu entorn de desenvolupament pugui funcionar igual de bé en totes aquestes plataformes.

Aquí hi ha un guanyador clar: Netbeans. Funciona igual de bé a totes les plataformes. Eclipse dóna molts problemes al PPC i de fet aquesta plataforma no està soportada als repositoris oficials.

Suport per Python

La versió Python de Nebeans ja té el pluggin integrat. Eclipse necessita el pluggin PyDev. Ambdós pluggins són molt bons: permeten la utilització del virtualenv, tenen ressaltat de sintaxi, autocompletat, ajudes, plantilles, refactorització i creació de Unit Tests. Empat!

Suport per Django

Cap d'ells proporciona un suport específic per Django, encara que Netbeans ho té com a projecte. Tanmateix, però, el més important és que l'entorn permeti executar el python manage.py runserver --noreload en mode depuració.

Aquí Netbeans falla. El depurador està molt enfora del depurador d'Eclipse i Pydev, que et permet posar punts de ruptura on vulguis i té tot el que un necessita en depuració. Amb Netbeans no hi ha més remei que fer servir import pdb; pdb.set_trace() al codi i utilitzar el depurador de línia de comandes. És un punt de millora molt important per Netbeans, i si no us sentiu còmodes amb la depuració per línea de comandes llavors l'elecció clara és Eclipse.

Suport per CSS

Eclipse necessita el puggin d'Aptana per posar-se a nivell de Netbeans i al meu parer no ho aconsegueix del tot. Ambdós tenen ressaltat de sintaxis, autocompletat i ajudes, però Netbeans a més et pot presentar un exemple de com queden les coses. Útil en algunes ocasions per veure visualment que l'estil que estam modificant queda com volem o que és el que volem modificar. Netbeans guanya per poc.

Suport per Javascript

Una altra vegada més Eclipse necessita d'Aptana per posar-se a nivell de Netbeans. Netbeans més proporciona un mode de depuració de javascript basada amb Firebug que va força bé. Pareix que Eclipse també suporta quelcom semblant però no és tan inmediat com amb Netbeans. No és una opció molt important, però donat que estam parlant d'integració de les eines més habituals a l'IDE s'ha de tenir en compte. Netbeans guanya.

Control de temps i tasques

Ambdós entorns ens permeten gestionar llistes de tasques a fer i controlar el temps dedicat a cada tasca. Associar arxius a tasques i controlar automàticament quan hi estam fent feina i quant no. Això és fonamental pels qui factures a hores o senzillament volen dur un control dels projectes.

Nosaltres feim feina amb Trac i Eclipse gràcies al pluggin Mylyn permet connectar-se a un repositori Trac i gestionar-ne les tasques. Eclipse guanya!

Aprofitament de l'espai

Personalment m'agrada tenir una distribució on tengui a la vista l'arbre d'arxius, l'editor i la consola de tasques i missatges. Quan faig feina amb les dues pantalles de 20" puc posar l'IDE a una pantalla i el navegador a l'altra, però quan faig feina amb sols una pantalla l'aprofitament de l'espai de l'IDE fa que pugui, o no, col·locar-hot tot per a tenir una visualtizació més ràpida i ergonòmica.

Eclipse consumeix molt més espai que Netbeans. Es pot tunejar un poc, però la tendència és a desaprofitar pixels en menús, pipelles i demés. L'estructura de Netbeans per mí és molt més elegant i amb un aprofitament d'espai gairebé òptim. Com a IDE per al portàtil: Netbeans.

Integració amb SCM

La integració amb el sistemes de control de versions és prou bona a ambdós entorns. En la nova versió la integració del pluggin Subversive és excel·lent a Eclipse i l'assistent gràfic en el maneig de branques de Netbeans és simplement genial.

En les operacions del dia a dia Eclipse guanya. Té una opció que et permet veure els canvis entrant i sortint (això també ho fa Netbeans) però a diferència de Netbeans la interfície d'usuari està molt més orientada a la usabilitat i és trivial llevar arxius, marcar-los com a no integrables, veure'n les diferències abans d'integrar, etc.

La usabilitat de Netbeans és força dolenta, de fet és molt més còmode anar per línia de comandes. Guanyador i amb molt avantatge: Eclipse.

Revisió de canvis

Netbeans ens permet mostrar quins canvis hem fet a l'arxiu que estam editant i manté un control local de versions. Eclipse també manté aquest control local, però la usabilitat és inferior.

A l'hora de mostrar diferències Netbeans manté el ressaltat de sintaxi, Eclipse no. Per mi el més útil és el control local i aquí Netbeans és el millor.

Plantilles

Ambdós IDEs ens permeten crear i gestionar les nostres pròpies plantilles de codi i ho fan força bé. Empat!

Execució de tests unitaris

Ambdós sistemes ho permeten, però com passa amb el control de versions, el d'Eclipse és molt més usable. Guanyador per poc: Eclipse.

Refactorització

Els dos entorns suporten la refactorització de códi. Empat!

Eines d'edició

Ambdós entorns ens permeten fer cerques a tot el projecte, fer servir expressions regulars, substitucions, ... Els dos editors són força avançats i més que suficients per a les necessitats d'edició de codi. Empat!

Afegitons

Eclipse des del principi ha fet de la possibilitat d'extendre l'entorn mitjançant pluggins una virtut. Netbeans s'hi ha incorporat més tard i això es nota. La quantitat d'afegitons per Eclipse esborrona, per Netbeans cada cop n'hi ha més i millors però encara Eclipse n'és un clar guanyador.

L'aposta per Python i Django

Eclipse no té una orientació clara cap a Python, però gràcies a PyDev i a la facilitat que té Eclipse per a integrar pluggins s'ha convertit en un entorn molt potent per a la programació.

Netbeans en canvi té un build sols per Python, ple suport i al roadmap hi ha la intenció de suportar Django: creació de projectes, plantilles, etc. L'aposta per Python a ca'n Netbeans pareix molt més clara que a Eclipse, encara que en aquests moments i com a regla general, actualment Eclipse proporciona molta més funcionalitat i integració que Netbeans.