Commits parcials amb git

No us ha passat alguna vegada que mentre esteu escrivint alguna funció nova us adoneu que en una altra funció li falla alguna cosa? Llavors què feu? Un git stash abans de fer cap canvi a l’altre mètode i un cop el teniu arreglat un git stash pop?

Ja no cal!

Sabia que es podia fer però mai m’havia aturat a mirar com es feia:

git add -p

Amb aquesta ordre (i si voleu el fitxer o fitxers) afegireu a l’índex les parts del fitxer que vulgueu. D’aquesta manera si teniu dues parts modificades del codi en un mateix fitxer (la funció que estàveu fent i les quatre línies per arreglar un altre funció) no us cal fer cap cosa estranya per afegir només una part del fitxer, res de fitxers temporals, ni branques, ni deixar coses al porta-retalls, etc etc, senzillament fer una addició de pedaços (d’aquí ve el -p) .

Senzill i MOLT útil. Més de dues, tres i quatre vegades m’hagués estalviat una bona estona d’anar creant fitxers, deixant coses sense desar, etc etc si hagués sabut aquesta opció del git add :)

Sincronització de branques a git

És box-populi que treballar amb branques amb git és una delícia ja que ho facilita moltíssim: és molt ràpid i les eines que et posa a disposició per treballar-hi fan que sigui molt recomanable fer-ho per a qualsevol canvi que es vulgui fer en el codi d’una aplicació.

Ara bé, quan ja has fet els canvis que volies fer-hi com els sincronitzes cap a la branca master ((Així és com es diu la branca principal a git.)) ?

Tens dues opcions, la que utilitzava jo fins ara:

git checkout master
git diff –stat master..BRANCA_DEV
git merge master..BRANCA_DEV
git push

Amb això el que obtenim és que agafem tots els canvis que hi ha a BRANCA_DEV respecte de master i els mescla. A més a més per deixar-ne constància en fa un commit final amb la típica frase ((Com tot en el git es pot canviar)) “Merge branch ‘BRANCA_DEV’ into master“.

Ara bé, hi ha una manera més bonica i més elegant de fer-ho, rebase:

git checkout master
git rebase BRANCA_DEV
git pull
git push

Amb això el que estem fent és agafar els canvis de la branca BRANCA_DEV i els col·loca, en bloc, abans dels canvis que tinguem fets a la branca master. Això vol dir que si partim d’un commit X i fem tres canvis a la branca BRANCA_DEV i dos canvis a la branca master, quan executem les ordres de sobre el farà el git és reiniciar els commits fins al commit X, aplicar consecutivament els 3 commits de BRANCA_DEV i finalment un cop fet això aplicarà els nostres dos canvis a la pròpia branca master.

D’aquesta manera, sigui quin sigui el mètode utilitzat per sincronitzar les branques ja tindreu una manera molt fàcil de treballar amb diverses branques alhora, etc etc

Fonaments d’Android

Aquests dies estic començant a mirar-me tot el tema d’Android i per sort meva tenen un document, que per a mi, és molt important: Application Fundamentals.

Allà no t’explica cap truc per fer que la teva aplicació sigui perfecta, ni tan sols t’explica com l’has d’estructurar, però en canvi et vomita totes les paraulotes de la terminologia que es fa servir a Android. Per exemple: no fas crides a classes per crear una nova pantalla, sinó que fas un Intent. Totes les necessitats de hardware i software externs al teu projecte han d’estar escrits en un fitxer xml…

Evidentment llegint això no serveix per crear aplicacions, però sense llegir-ho ho passaràs força malament :)

Alguns consells sobre què més llegir o quines pàgines consultar per quan hi hagin dubtes sobre Android?

Instal·lar l’SDK (i tot el necessari) per desenvolupar per Android

Avui m’he posat a instal·lar tot el necessari per començar a desenvolupar sobre Android ((Consells, enllaços i tot el que us sembli que em pugui ajudar és benvingut!)) i com que s’ha d’instal·lar unes quantes coses, és aquí una llista ràpida sobre què i en quin moment:

  • Instal·leu el Java JDK6
  • Instal·leu l’Eclipse 3.5
  • Baixeu i instal·leu l’SDK de l’Android
  • Instal·lar el connector ADT per l’Eclipse i configureu-lo

Amb això i seguint les notes d’inici ràpid del lloc de desenvolupadors d’Android ja podreu començar a crear projectes i programar :)

afegir mètodes a classes ja existents (objective-c)

Introducció

Amb l’Objective-C tens classes, categories i protocols.

Les classes implementen un seguit de protocols (un llistat de mètodes, una interfície vaja) i per facilitar la lectura i manteniment del codi, aquestes classes es poden separar en diversos fitxers (cada un d’ells una categoria) que haurien d’implementar un subconjunt de les funcions que es vol que faci la classe.

Així per exemple la classe String compleix amb el protocol Copy, per tant es poden copiar strings i una de les categories de funcions és la de spellChecking.

Problema

Si tenim un classe que ja ens ve del sistema (la classe String per exemple) i n’hem creat sub-classes (StringA, StringB, StringC) que totes tenen un mètode en comú (markSpell), quan creem instàncies de les subclasses ho podem fer amb un punter a la classe String però quan s’executa el codi ens dóna un avís de que la classe String podria no respondre ((A Objective-C les crides a mètodes en diuen enviament de missatges)) al missatge markSpell.

Solució

Crees un protocol que contingui aquest mètode ((Sí, la sintaxi és una mica estranya, però al final t’hi acostumes)):

@protocol MarkSpell

– (void) markSpell

@end

I quan crees el punter genèric de la classe Spell li dius que la variable compleix el protocol anterior:

String <MarkSpell> *myString = [[String alloc] init];

I amb això el compilador de l’Xcode ja no es queixarà més :)

llenguatge de gràfics

Llegint la documentació del JHBuild ((Programa per a compilar el GNOME des dels dipòsits de codi font)) he vist que pots mirar les dependències que tenen cada programa des del propi terminal o generar un gràfic que ho mostri, per exemple les dependències de l’Epiphany són:

Resulta que aquest gràfic tant ben fet es fa amb un llenguatge de programació anomenat DOT. La sintaxi és ben senzilla i la facilitat de creació de gràfics és impresionant (només cal mirar els exemples de la Wikipedia).

La genialitat de la implementació que en fa el Graphviz és que no només et treu .jpg o .png sinó que a més a més et pot treure .svg de manera que amb dos minuts pot definir el gràfic amb llenguatge DOT i després et pots estar l’estona que faci falta retocant-lo amb l’Inkscape.

Em sembla que a partir d’ara quan hagi de fer gràfics obriré el terminal en comptes d’un editor d’imatges o de vectors :D

un parell de pàgines útils

Com que a la nova feina faig de programador des de fa dies que estic consultant una pàgina web que suposo que ja deu ser força coneguda:

És un web que et permet fer preguntes, etiquetar-les i respondre’n. La interfície realment és molt senzilla i és molt còmode utilitzar-la ((A diferència de molts webs anomenats 2.0 que sembla més que el seu objectiu sigui entrar a una galeria d’art més que no pas utilitzar-se))

Fa pocs dies que a més vaig descobrir que tenen una versió del web pensada per a administradors:

Igual com la primera també molt molt útil (tot i que amb menys volum pel que sembla de moment).

arreglar bugs

Quan portes setmanes darrere un error que no hi ha manera racional d’explicar-lo i després d’un intensiu des de les 7 de la tarda a pràcticament les 12 de la nit (uff són unes 5 hores!) però l’acabes resolent … uff no té preu!

Això sí, ha sigut difícil trobar-lo el c*** quan per fi l’he trobat tenir obertes 12 terminals, diferents instàncies del Meld, uns quants Gedit, a saber quantíssimes pàgines web (amb l’Epiphany òbviament :)), etc etc

Com podeu veure que he posat el logo de l’empresa on treballo és un programa que estic fent per l’empresa i que gràcies a que ja (per fi!!) he trobat aquest bug aviat (espero) podrà veure la llum el què he estat fent :)

Nota no relacionada en absolut: Intenteu no barrejar programar en C i amb Python, us oblidareu TOTS els punt i coma del final de sentències a C i haureu de recompilar com 12 vegades per tonteries per l’estil :(

Introspecció a Python

Per tenir les dades que genera una aplicació que estic fent amb Python he escrit un parell de funcions que em permeten tenir un document estructurat (en xml) de totes les dades que es generen[1].

La tècnica de introspecció es basa en aprofitar les meta-dades (per dir-ho d’alguna manera) que tens sobre els objectes que has anat construint en l’aplicació per (dinàmicament) poder-ho formatar d’alguna manera.

Amb Python tenim algunes propietats, com molt bé es descriuen en un article d’IBM [2]:

  • objecte.__dict__ : Ens retorna una llista amb els elements que formen part de l’objecte. Així per mostrar els elements faríem:
  • for element in objecte__dict__:
    print “%s val %s” % (element, objecte.__dict__[element])

  • Si volem refinar el que volem mostrar tenim tot un seguit de funcions que ens diuen quin tipus de variable estem tractant: les comparacions amb el comparador is (exemple: if x is dict ….) per als tipus bàsics, callable per saber si és tracta d’un mètode, i per a objectes i classes isinstance(objecte, classe-o-llista-de-classes) i issubclass(classe, info-de-classe).

Només amb això podem treure molt suc a la informació que tenim ara mateix a les estructures de dades que estem muntant i si es fa el més genèric possible, no caldrà tocar ni una coma quan afegim més dades o hi encadenem alguna altra estructura.

[1] En certa manera hi ha truc perquè el sistema són classes que tenen diccionaris de classes a dintre fins a 5 nivells de manera que la introspecció és recursiva per naturalesa.

[2] És una mica vell, del 2002, però pels meus objectius n’he tingut ben prou :)