M'agrada llegir, molt. M'agrada llegir novel·la, sobretot de ciència ficció, però també assaig divulgatiu i com no llibres d'informàtica, que són la meva afició i despesa més gran.

Sovint m'han dit perquè encara no tenc un lector de llibres electrònics. Podria contestar que per una cosa que s'anomena eròtica del paper, de que m'agrada la sensació d'espera que implica comanar un llibre i començar a fer-te la idea de quan arribarà, de si t'agradarà, de si complirà el que esperes.

Podria dir que no m'agrada dependre de que l'aparell es quedi sense bateries quan més interessant és el capítol. Que m'agrada llegir gairebé a qualsevol lloc, que no vull patir si me qued dormit i el llibre me cau de les mans, cosa que no m'ha passat mai, per cert, però sí que m'he quedat dormit amb les ulleres a la mà.

Podria dir que és perquè tenc por de tenir tots els llibres que m'interessen a un dispositiu electrònic i perdre'ls per que algú li pegui per canviar el DRM o vet a saber què.

Però la vertadera raó és molt més senzilla: el ROI no és bo. El lector electrònic que m'agrada, el d'Amazon gran està als voltants dels 500$. Més petit no li trauria prou partit, ja que també el vull aprofitar per llegir pdfs format A4.

Aquests 500$ representen un poc menys que la meva inversió anual amb llibres tècnics, així que per justificar la inversió els llibres m'haurien de sortir millor de preu, cert? Doncs no! Resulta que en general els llibres tècnics en format ebook són molt més cars que els llibres en paper. Així doncs no tant sols hi ha la despesa de l'eBook en sí, que potser seria amortitzable en el temps, sinó que la inversió no s'amortitzarà, sinó que empitjorarà per mor que els llibres que m'agradaria llegir tenen un preu més car en format electrònic que en el seu equivalent en paper de tota la vida.

És doncs una qüestió de prioritats, de saber en què m'estic gastant les euros que tant costen a guanyar avui en dia. En aquests moments el llibre electrònic sols em llevaria uns quants dies d'espera, però potser m'animaria a la compra compulsiva. Els preus per mi passats de voltes dels llibres tècnics fan que per mi i en aquests moments l'ebook no sigui una opció vàlida.

Potser hauré de tornar el carnet de geek, però és que tampoc no sóc d'allò que se'n diu en early adopter tecnològic. M'agraden els gatgets com al qui més, però no vull que aquests definesquin el que sóc.

Ahir estava mirant la presentació de James Bennet a la DjangoCon anomenada "UR DOIN IT WRONG" i me'n vaig adonar que feia referència a una sèrie de màximes tipus:

#11919 No.  You must believe the ERROR MESSAGE.  You MUST believe the error message.

La conferència és molt bona, us la recoman. El cas, però, és que em va picar la curiositat i vaig seguir l'enllaç fins a arribar a una entrada de comp.lang.perl.misc del març del 2002 on Mark Jason Dominus feia una relació de consells que ell tenia a un arxiu anomenat File of Good Advice.

Les màximes, encara que plenes de sentit comú, tenen una mala llet considerable, i m'han recordat al nostre metge de la tele favorit. Supòs que no desapareixeran de la xarxa, però per si un cas les torn a escriure aquí. Ha passat temps, però la majoria són perfectament aplicables! Esper que les disfruteu tant com jo ho he fet.

#11900 You cannot just paste code with no understanding of what is going on 
 and expect it to work.
#11901 You can't just make shit up and expect the computer to know what you
 mean, Retardo!
#11902 You said it didn't work, but you didn't say what it would have done if
 it *had* worked.
#11903 What are you really trying to accomplish here?
#11904 Who the fuck cares which one is faster?
#11905 Now is the time in our program where you look at the manual.
#11906 Look at the error message!  Look at the error message!
#11907 Looking for a compiler bug is the strategy of LAST resort.  LAST resort.
#11908 Premature optimization is the root of all evil.
#11909 Bad programmer!  No cookie!
#11910 I see you omitted $! from the error message.   
It won't tell you what went wrong if you don't ask it to.
#11911 You wrote the same thing twice here.  The cardinal rule of programming 
 is that you never ever write the same thing twice.
#11912 Evidently it's important to you to get the wrong answer as quickly as
 possible.
#11913 Gee, I don't know.  I wonder what the manual says about that?
#11914 Well, no duh.  That's because you ignored the error message, dimwit.
#11915 Only Sherlock Holmes can debug the program by pure deduction from the
 output. You are not Sherlock Holmes.  Run the fucking debugger already.
#11916 Always ignore the second error message unless the meaning is obvious.
#11917 Read.  Learn.  Evolve.
#11918 Well, then get one that *does* do auto-indent.  You can't do good work
 with bad tools.
#11919 No.  You must believe the ERROR MESSAGE.  
 You MUST believe the error message.
#11920 The error message is the Truth.  The error message is God.  
#11921 It could be anything.  
 Too bad you didn't bother to diagnose the error, huh?
#11922 You don't suppress error messages, you dumbass, you PAY ATTENTION 
 and try to understand them.
#11923 Never catch a signal except as a last resort.
#11924 Well, if you don't know what it does, 
 why did you put it in your program?
#11925 Gosh, that wasn't very bright, was it?
#11926 That's like taking a crap on someone's doorstep and then ringing 
 the doorbell to ask for toilet paper.
#11927 A good approach to that problem would be to hire a computer programmer.
#11928 First get a book on programming.  Then read it.  Then write the program.
#11929 First ask yourself `How would I do this without a computer?'  Then have
 the computer do it the same way.
#11930 Would you like to see my rate card?
#11931 I think you are asking the wrong question here.
#11932 Holy cow.
#11933 Because it's a syntax error.
#11934 Because this is Perl, not C.
#11935 Because this is Perl, not Lisp.
#11936 Because that's the way it is.
#11937 Because.
#11938 If you have `some weird error', the problem is probably with your
 frobnitzer.
#11939 Because the computer cannot read your mind.  Guess what?  I cannot read
 your mind *either*.
#11940 You said `It doesn't work'.  The next violation will be punished by
 death.
#11941 Of course it doesn't work!  That's because you don't know what you are
 doing!
#11942 Sure, but you have to have some understanding also.
#11943 Ah yes, and you are the first person to have noticed this bug since
1987.  Sure.
#11944 Yes, that's what it's supposed to do when you say that.
#11945 Well, what did you expect?
#11946 Perhaps you have forgotten that this is an engineering discipline, not 
 some sort of black magic.
#11947 You know, this sort of thing is amenable to experimental observation.
#11948 Perhaps your veeblefitzer is clogged.
#11949 What happens when you try?
#11950 Now you are just being superstitious.  
#11951 Your question has exceeded the system limit for pronouns in a single 
 sentence.  Please dereference and try again.
#11952 In my experience that is a bad strategy, because the people who ask 
such questions are the ones who paste the answer into their program without 
understanding it and then complain that it `does not work'.
#11953 Of course, this is a heuristic, which is a fancy way of saying that it 
 doesn't work.
#11954 If your function is written correctly, it will handle an empty array 
 the same way as a nonempty array.
#11955 When in doubt, use brute force.
#11956 Well, it might be more intuitive that way, but it would also be useless.
#11957 Show the code.
#11958 The bug is in you, not in Perl.
#11959 Cargo-cult.
#11960 So you threw in some random punctuation for no particular reason, and 
 then you didn't get the result you expected.  Hmmmm.
#11961 How should I know what is wrong when I haven't even seen the code?  
 I am not clairvoyant.
#11962 How should I know how to do what you want when you didn't say what you
 wanted to do?
#11963 It's easy to get the *wrong* answer in O(1) time.
#11964 I guess this just goes to show that you can lead a horse to water, but 
 you can't make him drink it.
#11999 You are a stupid asshole.  Shut the fuck up.

Avui iniciam el primer curs de ASCII art en Python. Per començar un repte: el pare de n'ETE en ASCII art, generat en Python. Seria així:

1

print(chr(79))

I ja ho tenim, Don ETE!

Eps! Algú ha vist les meves pastilles?

Al blog de Marcelo Ramos he trobat un apunt amb aquesta imatge

que pareix que prové de makeuseof.com. Una troballa prou divertida de Marcelo. :)

El de l'arbre de Nadal m'ha fet especial gràcia, ja que a l'oficina hi ha una divertida anècdota amb un rack de comunicacions i un arbre de Nadal com a protagonista.

Endevinau que s'havia desendollat per encendre els llums de l'arbre? ... Sí, això mateix!

"When the productive have to ask permission from the unproductive in order to produce, then you may know your culture is doomed."

Llegit a un apunt de James Carr que a la seva vegad ho havia llegit del lblog de Reg.

Pels que els costa un poc més llegir l'anglès que el català:

Quan els productius han de demanar permís als improductius per tal de produïr, llavors saps que la teva cultura està condemnada.

On diu cultura, posau-hi empresa o la vostra organització altament jerarquitzada, sí, aquella que posen sempre d'exemple quan es parla del principi de Peter.

Vols desmoralitzar un equip? No saps com fer-ho? T'explicam com, és molt fàcil

1. Fes una pujada de sous ridícula i insultant. Justifica-la dient que els pressuposts no es poden canviar. Millor si ho fas el mateix dia que dius que l'empresa ha tingut uns beneficis extraordinaris, molt per damunt del pressupostat.
2. Fes una borsa única per la pujada ridícula del punt anterior que se repartirà en proporció inversa al sou que s'està cobrant actualment. No tenguis en consideració que potser hi ha gent junior que ha de fer un canvi salarial d'escala. Si és així, el canvi salarial també sortirà de la borsa.
3. Condiciona la pujada salarial no a la competència sinó al que ja s'està cobrant, de manera que la gent sàpiga que el sou no depèn de la competència professional, sinó del que cobren la resta de companys. A més té el factor motivador de fer que es vegi a la gent junior com a amenaces, ja que normalment comencen cobrant menys.
4. Deixa ben clar que la única manera d'aconseguir no perdre poder adquisitiu cada any és marxar o canviar de categoria laboral. Això té l'avantatge de potenciar el principi de Peter i fer que la gent arribi el més aviat possible al seu màxim nivell d'incompetència, però a més té altres conseqüències no menys interessants:
   1. Donat que en una escala jeràrquica el nombre de llocs més especialitzats es va reduint, la única manera d'aconseguir mantenir o millorar el poder adquisitiu és que el cap immediatament superior renuncii o el facin fora. Per tant, els subordinats han de tractar per tot els mitjans de putejar els seus caps.
   2. Per tal d'evitar que els subordinats el facin fora, el millor que pot fer el cap és rodejar-se de subordinats sense iniciativa, llepaculs i incompetents, de manera que el cap sempre destaqui. Les noves contractacions de personal i promocions professionals fes que vagin en aquesta línia.
   3. La gent que no vulgui entrar en el joc acabarà marxant, i per tant sols quedarà a l'empresa un perfil homogeni de gent que entén de què va la cosa.
5. Diguès que s'acomiadarà molta gent en breu. La gent que tengui més possibilitats de col·locar-se a altres llocs anirà fugint i l'empresa es quedarà amb tots aquells que tenen més problemes per trobar feina. D'aquesta manera el més probable és que et quedis en una posició ideal per a assolir el punt 4 i les seves conseqüències.
6. Contracta quant més consultors externs millor a preus ridículament alts per a que facin la feina de la gent que se n'ha anat per mor de l'augment de sou. Demostraràs que ningú és imprescindible i a més faràs befa dels que quedin.
7. Posa al teu equip fites impossibles. Després contracta a empreses externes pel projecte dient-les que facin el que puguin.
8. Negocia contractes de manteniment absurdament inflats amb els teus proveïdors. Després tanca el negoci d'aquell departament amb l'excusa de que no hi ha beneficis.
9. Exigeix resultats però no donis les eines per a aconseguir-los i deixa ben clar que mai es tindran.
10. Explica a tothom que ets el salvador de l'empresa i que els altres tenen molta sort de tenir-te. Fes-los sentir que viuen permanentment en una història de Dilbert.

Desmotivar gent que fa una feina vocacional no és fàcil, esperam que aquests senzills consells us siguin d'utilitat.

Els anglosaxons són molt bons inventant nous termes per a fer referència a situacions típiques i expressar en poques paraules un concepte. En el món de la programació i projectes un dels que més m'agrada és de "pizza team", que descriu un equip de projecte d'un tamany adequat com per poder demanar una pizza quan hi ha hores extres a fer i no quedar amb gana.

No per això hem de deixar, però, que en tenguin l'exclusiva dels neologismes, així que aquí va la meva contribució: el programa trinxera.

El programa trinxera descriu aquell programa darrera del qual s'amaga un equip o una organització per tal d'impedir l'avanç de l'enemic. Qui és l'enemic és del tot irrellevant, potser una part de l'organització, un client, o els simples avanços tecnològics.

El programa trinxera es caracteritza per estar totalment acoblat, per la dificultat de saber per a un observador extern què fa el codi o perquè el programa fa el que fa. El programa és tan complexa que es requereix moltes vegades més feina saber el que fa que refer el codi de nou.

Per a que un programa trinxera sigui de qualitat a més ha de tenir moltes ramificacions, ha de ser un programa que faci de tot, que tant servesqui per gestionar l'empresa com per a enviar SMS. Cada necessitat que plantegi el client s'ha d'acabar lligant d'alguna manera amb el programa, d'una manera íntima i indissoluble, de tal manera que sigui impossible saber on comença un modul i on acaba un altre.

El programa trinxera es un gran devorador de recursos. Per la seva pròpia definició ha de ser totalment monolític i per a cada mòdul que se l'incorpora requerir més i més màquina. Com a bona trinxera ha de ser tortuós i amb molts llocs on amagar-se, de tal manera que si algun dia l'enemic es capaç d'entrar a la trinxera, se'l pugui estar esperant al proper racó per donar-li una sorpresa en forma de milers de línies de codi embullat i ineficient.

Per acabar de ser perfecte, el programa trinxera ha d'estar fet amb algun llenguatge obsolet, a ser possible mal de depurar i testejar, del qual sols els atrinxerats en saben algunes coses, no moltes, sols les justes per anar fent modificacions, però no les suficients com per a poder arribar mai a desfer el que s'ha creat.

Si no fos pels edificis hauria dit que era la foto de l'entrada del metro de Palma d'Asima.

click to enlarge

Seguint la línia d'assajos com "How to write unmaintainable code" o el refuctoring, ens arriba un assaig que revolucionarà la vostra manera d'entendre la programació: l'abject-oriented programming.

En el seu assaig Greg Jorgensen introdueix novetosos conceptes que sovint ens hem trobat en el codi, com les fragile base class, aquella classe o mòdul, que fa molt de temps que està a l'aplicació i que qualsevol canvi que s'hi faci romprà tota l'aplicació.

Interessantíssima també la seva recomanació pel control de versions, encara que he de dir que hi ha molt "previous art", l'he vista aplicada nombroses vegades en tota mena de documents word i fulles de càlcul.

En definitiva, un entreteniment estiuenc per passar l'estona.

http://typicalprogrammer.com/programming/abject-oriented/

• Si la prioritat d'un ticket és molt alta el nombre de forats pot impedir la seva legibilitat. Una vegada més reiteram la importància de fer servir xinxetes certificades.
• El suroserver s'ha d'instal·lar a un lloc sense vent. S'ha demostrat que les condicions de vent o pluja intensa afecten negativament al suroserver fent desapareixer aleatòriament els tickets o fent-ne malbé els continguts.