Menys és més

I mai millor dit!

Avui he actualitzat el nucli i després de reiniciar per arrencar amb el nucli nou em trobo que la pantalla es mostra a 800×600 en comptes de 1280×800.

Començo a remenar opcions i veig que sí que puc tornar als 1280×800 amb l’xrandr ((M’ha anat molt bé una meva entrada al bloc)), però després de reiniciar sempre tornava als 800×600.

Després d’examinar el /var/log/Xorg.0.log semblava que era algun tema de configuració… “Doncs res” m’he dit, a tocar el /etc/X11/xorg.conf a veure què hi passa.

El primer que se m’ha acudit es esborrar el fitxer (fent una còpia abans!) i reiniciar, i voilà! Ja funciona a1280x800 i a més a més, quan connecto la pantalla externa de casa ja me la detecta bé i a més a més a la resolució que toca i tot ((M’havia fet un script per la pantalla de casa i de la feina :D))!

Com facilitar l’arribada de nous col·laboradors

La majoria de projectes de programari lliure no tenen una o diverses empreses a darrere que els permeti desenvolupar el programari tant ràpid com vulguin i afegir totes les funcions que voldrien.

És més, per molt que en tinguin fins i tot llavors els interessa desenvolupar una comunitat de desenvolupadors, dissenyadors, traductors, grafistes, administradors, etc etc per tal que el projecte per si sol tingui molta més força, independentment dels recursos que la empresa hi pugui destinar.

Ara bé, com ho fas per aconseguir atreure nous col·laboradors?

Cadascú et dirà una resposta diferent, però el que estan fent al LibreOffice, és, almenys per mi, una de les millors maneres que hi ha: documentar tasques de diferents nivells de dificultat que permetin solucionar la primera pregunta que es fa tot col·laborador: què puc fer?

Com més facilitats es posen a que nous col·laboradors puguin contribuir al codi d’un programa, més fàcil serà que al cap d’un temps de tots els col·laboradors que han fet tasques, alguns d’ells passin a ser col·laboradors habituals i fins i tot, perquè no, col·laboradors claus del projecte.

Llibre sobre git: Pro Git

Ahir mirant com fer el rebase del que vaig parlar em vaig trobar amb una web fantàstica: Pro Git.

Resulta que és la web del llibre homònim, on a més a més del llibre sencer també hi van publicant actualitzacions, consells i demés.

Sens dubte una pàgina de referència per a qualsevol que treballi a diari amb aquest fantàstic control de versions distribuït!

Com a mostra en el capítol 7 secció 2 ens ensenyen com combinar dos programes imprescindibles per mi: el git i el Meld.

git rebase: la història sencera

Introducció

Si treballeu amb git ja haureu sentit a parlar de l’ordre rebase. Per intentar-ho resumir (( Hi ha moltíssima lectura )):

Suposem que has començat una branca de desenvolupament paral·lela a la branca principal, has fet uns quants commits i al mateix temps la branca principal també evoluciona amb uns quants commits.

En aquell moment les dues branques han divergit (tenen commits diferents) de manera que no pots enviar els canvis d’un  a l’altre de manera automàtica que sinó es perdrien els canvis que ja hi ha fets en l’altre branca.

Si vols integrar els canvis d’una branca a l’altre tens dues sol·lucions:

  • merge: combinar en un sol commit tots els canvis d’una branca per integrar-los en l’altra.
    • problema: s’ajunta en un sol commit tots els canvis de la branca, de manera que si els canvis són molt invasius és perjudicial a la llarga ja que no tens l’historial real dels commits que van portar a aquest super-commit.
  • rebase: actualitzar tots els commits de la teva branca perquè utilitzin la nova base de l’altra branca de manera que llavors sí que es puguin aplicar els canvis de forma directe
    • problema: es reescriu la història dels commits, ja que si els canvis que comporten la nova base a partir de la qual aplicar els commits toca els mateixos fitxers que els que un ha canviat en la seva branca es modifiquen els commits automàticament.

Una mica enrevessat oi? Mireu la documentació oficial del git sobre el rebase amb tots els dibuixets.

L’important, el codi

Ara bé, m’he trobat moltíssima documentació explicant el què, però no el com, així que aquí va una guia ràpida de les ordres per tal de fer un rebase:

git checkout BRANCH # anem a la branca que volem passar a master
git rebase MASTER # fem el rebase (si trobem conflictes els anem sol·lucionant)
git push -f # envies els canvis al servidor (el -f és degut a que forces el push)
git checkout MASTER # tornem a la branca master
git pull origin BRANCH # ara ja podem agafar els canvis de la branca BRANCH sense cap problema
git push # enviem al servidor la branca master amb tots els canvis de la branc BRANCH aplicats

I amb això ja teniu tot el necessari per poder treballar amb branques i fer-ne després rebase d’aquestes.

Tingueu en compte el fet aquest de la reescriptura de la història. De per si no és dolent, el principal problema és que si la branca en la que estàs treballant també l’utilitza algú altre, aquest altre tindrà problemes quan torni a fer una actualització del codi.

Si pel contrari treballeu amb aquesta branca únicament vosaltres no tindreu absolutament cap problema i, sens dubte, serà la millor manera de preservar tot els commits i per tant molt més senzill de navegar per l’historial.

sistema de plantilles TAL

L’immensa majoria de llenguatges de programació per web (PHP, Python, JavaScript, …) tenen un sistema de plantilles de manera que permet fer una cosa semblant a l’XHTML i el CSS, per una banda preparar les dades (amb el llenguatge de programació) i per altre presentar-los (amb el sistema de plantilles).

A diferència del CSS però, els sistemes de plantilles sí que tenen part de programació, iterar, condicionals i coses per l’estil.

Si treballeu amb Plone ja haureu descobert que utilitzeu TAL, un sistema de plantilles que utilitza una sintaxi molt semblant a l’HTML de manera que el propi codi de TAL queda integrat en tot el que és l’HTML que es vol mostrar.

Avui he trobat una referència del llenguatge i per això he fet l’entrada, per recordar-me que existeix :)

Libreoffice i la Document Foundation

A hores d’ara ja deveu haver llegit/sentit la notícia: s’ha fet un fork del codi de l’OpenOffice.org.

Des de que he llegit la notícia que tenia ganes de fer alguna cosa per poder expressar els meus millors desitjos al projecte, i quina millor manera pot ser que ajudar en el projecte?

Animat per la pàgina de Easy Hacks m’he decidit a fer alguna cosa simbòlica i he enviat un pedaç que ja ha estat confirmat al repositori!

I tu? Ja has col·laborat a millorar la Libreoffice?

com tradueixo actualment

Avui((Aprofitant que és festa major a Barcelona)) m’he posat a traduir els mòduls del GNOME en els quals estic com a últim traductor.

Després de fer ja uns quants mòduls he trobat que el cicle de treball que utilitzava m’era molt còmode i de nou((Ja vaig parlar-ne fa un temps de com posar-se a traduir)) el documento a veure si algú en pot treure alguna cosa útil i aprofitar-ho i de pas a veure si algú també s’anima a publicar el seu cicle.

Disposició de treball

Com em van dir fa un temps: això de treballar amb dues pantalles enganxa,  després de provar-ho ja no podràs tornar a treballar amb una sola!

Així que amb la pantalla del portàtil i l’externa tinc:

  • Dos terminals (un per la traducció activa i l’altre per fer consultes a fitxers po d’altres mòduls o traduccions d’altres idiomes del mateix mòdul)
  • Navegador amb diverses pestanyes obertes (el Damned-Lies, el recull de Softcatalà, Termcat, la Wikipedia, l’Open-Tran i l’Optimot)
  • Nota del Tomboy amb un resum de les traduccions a fer i llistat de terminologia que vaig descobrint i establint

D’aquesta manera només haig de moure una mica al ratolí i ja tinc el focus en la finestra que vull utilitzar, en tot el matí no he fet servir l’Alt+Tab :)

Forma de treball

  • Des del terminal actualitzo el git del mòdul que traduiré (canviar de branca si fa falta i tota la pesca)
  • Actualitzo la traducció amb un script (“msgstatus ca“)
  • Faig la traducció (pas obvi :)
  • Reviso els canvis amb el Meld (entre el fitxer ca.git.po que em crea el msgstatus i el fitxer de la traducció acabada ca.po)
  • Extrec totes les cadenes del català (amb un altre script)
  • Amb el fitxer (ca.po.tmp) que em crea l’script anterior li passo el  el verificador ortogràfic (Hunspell)
  • Finalment després de traduir, revisar i passar la verificació ortogràfica pujo el fitxer al Damned-Lies

Espero que us sigui útil!

rebre notificacions del cron al teu client de correu preferit

Logo del projecte DebianA la feina ((Perdó per l’SPAM :D )) tenim un parell de servidors ((El típic escenari de producció i desenvolupament/test)) que corren amb Debian on entre moltes altres coses hi tinc alguns processos amb cron i tal.

Com que des que vaig configurar un servidor de correu al servidor de casa estic rebent la sortida de l’execució dels processos que tinc en el cron per correu electrònic i trobo que és molt útil avui he fet el mateix a la feina, i la veritat és que ha sigut la cosa més senzilla del món!

Nota: amb aquesta configuració només rebreu els correus interns del propi servidor, no tindreu un servidor de correu completament funcional ni molt menys!

Passos per fer-ho:

  1. Configurar un registre MX d’un domini que tingueu al vostre abast per poder adreçar-vos-hi per recollir el correu.
  2. Deixar tal qual està l’exim4 tal com ve per defecte a Debian (o sigui no fer res :D).
  3. Instal·lar el dovecot-imap (apt-get install dovecot-imapd) ((Si voleu també podeu instal·lar el dovecot-pop3d per accedir a través de POP)).
  4. Llestos!

Ara l’únic que heu de fer és configurar el vostre client de correu perquè vagi a recollir a través d’IMAP els correus en el vostre servidor i d’aquesta manera tindreu puntualment la sortida de les execuccions dels processos del cron al vostre client de correu :D

Punts extra

  • Per si no us n’adoneu quan instal·leu el dovecot-imapd: el propi dovecot crea un certificat auto-generat de manera que només fent els 4 passos de sobre ((Realment dos: el primer i el tercer,  i un només en el propi servidor.)) teniu xifratge de la connexió gratuïtament :D
  • Per no haver de tenir 40.000 comptes en el client de correu que utilitzeu podeu afegir la següent línia al crontab de tots els usuaris que tinguin cron:

MAILTO=jordi@localhost

D’aquesta manera tots els usuaris que en el seu crontab tinguin aquesta línia enviaran el correu a l’usuari jordi, de manera que l’únic compte que haureu de tenir en el vostre client de correu és el de l’usuari jordi.