Un outliner per gestionar tasques

Els diferents mètodes per organitzar tasques pròpies no marquen, normalment, cap eina: és elecció personal de cadascú triar-ne una.

Així, uns usaran outliners (on-line o d’escriptori), altres potser el mateix gestor de correu via carpetes o alguna eina tipus One Note o Lotus, i els més durs usaran emacs amb org-mode).

Després de provar-ne algunes, el que més valoro és:

  • que sigui una eina senzilla
  • ràpida i lleugera (poca càrrega de memòria)
  • facilitat d’instal·lació i gestió
  • que no em tingui lligat per cap format propietari en guardar dades
  • que pugui substituir-lo ràpidament per alguna altra eina
  • que pugui explotar les dades senzillament.

Veient això, finalment m’he decidit per usar un simple fitxer de text, guardant les tasques agrupades per dies i posant una mena d’etiquetes. Tot plegat, com usar un org-mode “sui generis”.

El que faig és guardar les tasques en un document amb aquesta pinta:

13-03-2014 ***
2014-03-13  PDT [CE0371] Ercnffne thv tenpvó qr [rEhoevpn], pbzc
2014-03-13  FET [CE0312] Erivfne rf aúzrebf qr frevr
2014-03-13  FET [CE0022] CZnegn. N sre + cebi nare, dhrqb craqrag
2014-03-13  CUR [CE0357] Pbzcebine shapvbanzrag gf abh freivqbe.
---

14-03-2014 ***
2014-03-14  PDT [CE0371] Ercnff rtenpvó qr [rEhoevpn] v JPP.
2014-03-14  PDT [CE0312] Erivfne  gf, j qr yn GO0071 n yn GO0078
2014-03-14  PDT [CE0312] Raivne er vó ZNPf/IVQZ n Vina. C npvó
2014-03-14  PDT [CE0022] Ervfne fv nzo >>fvtovb/pb  f'raivra ryf< <
2014-03-14  PDT [Frh] Frzof geàzvgf f'rfobeen ha qryf qbf v f'nffvtar
2014-03-14  PDT [Frh] Erivfne credhè f gevtn gnag ra pneertne. 
2014-03-14  PDT [CE0369] Ercnffne qbphzrag q'nedgvyb raivng cre.
---

Setmana ***
2014-03-14  CUR [Setm] Cercn  nygerf [CE0312] (ahzrrf n Vina)
2014-03-14  OK  [Setm] Svanyvgmne ceb cre [CE00222], qrvkn
2014-03-14  CUR [Setm] Qrsvave pbawra cre [CE0352], cebtenzne
2014-03-14  CUR [Setm] Qrvkne gnapnqn ctenqr rEhoevpn [CE0371], nzo
2014-03-14  CUR [Setm] Rayyrfgve freivqbe qr ceegn [CE0357]
---

Com funciona?

  • Guardo les tasques agrupades per dies, i em fixo uns objectius setmanals.
  • Una vegada feta la setmana, les tasques diàries es van agrupant per mesos, i el fitxer va per anys.
  • Format: la primera columna és la data, la segona és l'estat, la tercera l'etiqueta principal i després vé la descripció, que pot incloure tags.
  • estat:
    • PDT Pendent
    • CUR En curs
    • FET Fet
    • REV Revisar
    • POS Posposat
    • OK i KO per tasques setmanals
  • [] marquen etiquetes, que es poden fer servir per remarcar projectes, aplicacions...
  • *** i --- marquen inicis/finals d'agrupacions
  • >> i << marquen l'inici/final de blocs destacats

Senzill, no costa res d'omplir i em permet fer una explotació posterior per projectes o per objectius complerts, o cercar dies o feines...

Per exemple:

  • amb
    grep -o -h "\[.*[^{Setm}]\]" Tasques.notes > resultat.txt

    es poden extreure tots els projectes de la primera columna, i tenim una idea de amb què hem estat treballant (podem fer-ho de tot un fitxer, o seleccionar el període que ens interessi, o combinar fitxers de diversos anys...)

  • Es poden fer cerques per tags (etiquetes entre []) i veure com evoluciona aquella feina
  • Es poden fer núvols de tags per veure què ocupa més el nostre temps

També és veritat que un fitxer de text pla costa de llegir si és una llista extensa, i com que les tasques creixen i creixen, el fitxer on es guarden també ho fa, així que per facilitar la visualització i gestió de les tasques, m'he definit un mode outliner per notepad++, que em permet:

  • Identificar per colors l'estat de les tasques
  • Trobar fàcilment projectes, etiquetes, feines
  • Remarcar comentaris o textos importants
  • Agrupar/desagrupar grups de línies (útil per tancar dies, setmanes, mesos, notes).

Amb una captura de pantalla s'entén millor:

captura_outliner

(els blocs s'obren/tanquen per facilitar el desplaçament entre dies, serveixen per crear notes i es poden aniuar)

La definició del mode és a GitHub, i es pot modificar com es vulgui (el mode té associada l'extensió ".notes" i està associat a un tema fosc, si el proveu).

L’art de programar

Quan desenvolupem codi moltes vegades ens centrem en cobrir els requeriments que se’ns estan demanant, en el temps requerit. Ens basem en la potència dels ordinadors actuals, en la interconnexió pseudomàgica dels serveis o de terceres funcions que usem com caixes negres, sense saber com funcionen, apliquem patrons i fem proves, i si funciona, voilà, ja està fet i a per les següent coses.

Tenim mètriques, proves d’unitat, uat’s, diagrames i casos d’ús per preveure, veure, justificar i informar del que fem i com funciona, tenim tota una metodologia científica i tècnica al nostre abast.

Però desenvolupar codi no és només això: tots sabem reconèixer una documentació ben feta, aprenem i gaudim quan veiem un codi elegant, ben documentat, indentat i precís, i ens desesperem quan trobem instruccions incomprensibles, repetitives i sense documentació que donen voltes i més voltes, complicant innecessàriament el producte (de vegades això reflecteix un mal treball, de vegades es dissimula el no saber fer, la incomprensió d’allò que es demana o de l’eina que es fa servir amb un codi extremadament complicat, com en un mal discurs d’un polític).

Així, programar és també copsar el problema o la solució que se’ns requereix, i treballar no només per força bruta si no entenent tot l’entorn que rodejarà al nostre producte: interaccions, sessions, peticions concurrents o voluminosos treballs batch. Hi ha part d’art, d’aprenentatge en la programació, hi ha la part d’elegància que rodeja a un bon codi, la robustesa d’una api ben definida i la documentació, en línia i final, comprensible per tothom, quan s’hagi perdut l’entorn on va sorgir la necessitat d’aquell programa.

Oh, sí, és clar: al final un programa és un programa.

Però internament és una seqüència lògica d’instruccions per resoldre un problema, i aquesta solució pot ser més o menys elegant, pot no només donar solució a una finalitat, si no ensenyar en si a com fer les coses. Heus ací la diferència entre un nyap temporal que faci una funció i en la construcció d’una solució duradora i elegant: en com apliquem aquesta lògica.

Nou? O millor millor?

Finally, Sophos reported that Microsoft and FBI have taken down over 1400 botnets by disabling the software that creates them. Now, if they can just disable the people who write the software in the first place, the world will be a happier place.

Nata’s Corner a la newsletter d’ExpertsExchange de 19 de juny de 2013

Tot i coincidir amb la frase final, no m’acaba de quedar clar si quan parla de la gent que escriu software es refereix als que escriuen codi perquè el teu ordinador quedi zombie dins d’una botnet o als de les companyies (programadors o responsables, tant és) que permeten que això passi…

Com ella mateixa diu, perquè s’entesten en fer coses noves? Perquè no s’entesten en fer coses millors, que funcionin més bé? (i aquí podriem parlar també de l’encaparrament d’ubuntu amb Unity i una millor experiència d’usuari, si voleu).

Qualitat i conservació de les dades

És suficient el tractament i les tècniques de la ciència informàtica per garantir la qualitat i la perdurabilitat de les dades que emmagatzemem?

Històricament s’han desenvolupat teories i mecanismes per garantir la certesa i la exactitud de les dades recollides, la no repetició de les mateixes, s’han estudiat les estructures més òptimes d’emmagatzematge per cada cas i la millor manera de reflectir diferents tipus d’informació. Les formes normals de les bases de dades, els arbres B, les bases de dades relacionals o orientades a objectes o les més modernes distribuïdes, l’estudi de les relacions entre les dades, etc., ja fa molts anys que està inventat i aplicat, cada vegada més refinat i més optimitzat.

A mesura que els volums de dades han anat creixent, s’han anat desenvolupant paral·lelament noves tècniques i motors de cerca, nous índexs i millors automatismes per millorar els temps de resposta, s’han implementat mecanismes per garantir la no pèrdua de les dades (backups, redundàncies, sistemes distribuïts, replicacions de sistemes, miralls on-line) i el ràpid accés a les mateixes, s’ha guanyat en flexibilitat d’accés i ens hem tret de sobre (fins a cert punt) la tirania dels bits, ens permetem el luxe de poder dissenyar bases de dades sense haver-nos de preocupar (en excés) de com s’emmagatzemaran.

Es dissenyen sistemes que capten molta informació per la gestió de determinats processos i sistemes, i que automatitzen cada vegada més feines repetitives i faciliten la optimització de la resta de tasques.

Però és suficient tot això? Tot el tractament de les dades del que parlo dalt és eminentment sintàctic: les dades son correctes a nivell de format, i s’emmagatzema allò que el sistema necessita per als seus processos actuals, si… però es dissenyen encara els sistemes pensant de manera aïllada, des d’un punt de vista eminentment tècnic i utilitari de la informació, però no es pensa (més enllà d’algunes metadades de registre) en complimentar i enriquir la informació amb metadades que donin informació semàntica sobre l’entorn d’aquell conjunt, de manera que facilitin la conservació en un futur de la mateixes dades, o millor dit, no tant la conservació com la comprensió d’aquelles dades i per tant facilitin la integració amb d’altres, o la generació d’encara més informació a partir d’aquestes dades, ja siguin documents, estadístiques o resultats estadístics a partir de mineria de dades. Exemples podrien ser registres de modificacions, generacions d’històrics, signatura de la informació, no-repetició de les dades ja existents en altres llocs…

En resum, cal anar una mica més enllà de la gestió pura i dura de la informació actual: què fem quan una aplicació es migra? Què passa amb les dades velles? Tenen alguna validesa, més enllà del que es passa al següent aplicatiu o versió? Els documentalistes arxivers/gestors de documents ja fa temps que parlen d’aquestes qüestions i que les apliquen a la qualitat de les dades com a documents, i de la preservació i la meta-informació que els mateixos ens poden donar en un futur (la preservació dels documents a llarg termini en entorns digitals és un problema complex)

Cal preguntar-se aleshores si aquests mateixos conceptes no s’haurien d’aplicar també al disseny de les bases de dades de suport a les aplicacions, pensar des d’un primer moment ja en els resultats posteriors i les explotacions que es faran (de ben segur) d’aquelles dades, i per tant no guardar només les dades estrictament necessàries per l’aplicació en aquell moment ans també metadades, informació de registres, disposar-les de manera que es faciliti el creuament posterior amb d’altres dades o es facilitin estudis històrics evolutius i que es garanteixi també la preservació de les dades a llarg termini d’una manera no estrictament tècnica, sinó també semàntica: de què ens serviria tenir tabletes en cuneïforme si no sabem desxifrar-les? de què ens serveix saber llatí si no entenem la societat on es parlava? De la mateixa manera, de què ens serviria tenir conjunts de dades dels quals no sabríem com han evolucionat perquè guarden només una instantània de la informació, no l’evolució històrica, per exemple?

Aquest, a més, és un problema diferent del fet de cercar en quantitats ingents d’informació (la tan actual big data, abans mineria de dades): cercar dades, creuar-les i extreure’n nous resultats, generar nova informació, és important, és clar. Però per tal que la informació resultant d’aquestes operacions tingui qualitat, la informació original, la que nosaltres estem deixant en aquest moment, també ha de tenir-la, el que vol dir tenir en compte alguns dels punts esmentats dalt.

Això, a més, implica un canvi en la cultura de treball de les organitzacions que treballen amb la informació com a principal actiu o eina de gestió:

  • implica crear equips multidisciplinaris en la creació inicial de les bases de dades: informàtics, documentalistes, el propi gestor tradicional de la informació
  • implica que tothom es faci seus els projectes i entengui el que es demana i el que es vol treballar
  • implica una visió no tancada en les pròpies necessitats del moment si no en pensar a llarg termini: emmagatzematge, reserva, utilitat
  • implica conèixer altres sistemes d’informació que treballin amb informació relacionada per veure si els podem enriquir o ens poden aportar quelcom

En definitiva, pensar en les dades de manera no només sintàctica sino també semàntica i de conservació és el camí per garantir una bona qualitat de les mateixes ja en origen i facilitar enormement tasques posteriors de neteja i enriquiment, conservació de documents i/o conjunts autocontinguts i robustos, i per tant en la obertura al públic de dades de més qualitat, ara que s’obre el camí de l’open data i la transparència.

Accessibilitat, usabilitat

De la mateixa manera que a la web hi ha unes pautes d’accessibilitat, no es podrien definir algunes pautes d’usabilitat o, encara més, intel·ligibilitat?

De veritat, és que hi ha algunes webs on no hi ha manera de trobar res, sigui per què està amagat, o perquè primer s’ha de desxifrar el que diu. I sí, tenen la AA d’accessibilitat, com marquen algunes normatives, però s’han limitat a passar algun validar del W3C i poca cosa més. Les parts d’ús intuïtiu i senzill i informació perceptible no les han llegides. I això és nota, i molt de vegades.

Així que: o els que aproven aquestes pàgines han de signar que les han provades (amb efectes secundaris negatius per als seus sous en cas d’evidències… evidents), o que defineixin algun estàndard d’usabilitat i comprensió d’obligat compliment (així com a mínim algú hi haurà de pensar i els altres només aplicar, com màquines, aquelles directrius, però per algun lloc es comença).