oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: tasks

Somiant amb una extenció pel Gearman

Reading time: 5 – 8 minutes

Cal dir que no sóc massa ordenat al presentar noves tecnologies ja que primer de tot vaig fer un bechmark sobre Gearman abans de fer-ne una introducció, doncs bé com que en aquest article vull parlar sobre unes possibles extensions sobre les que vull treballar amb Gearman primer de tot faré una petit introducció al projecte.

Introducció

Gearman és el que comunment anomenem un servidor de tasques, o sigui, que quan el nostre codi ha de demanar una tasca, funcionalitat, treball, o quelcom similar és molt interessant de cara a:

  • l’escalavilitat: podem tenir tants servidors i/o processos consumint tasques com ens interessi.
  • paral·lelisme: les tasques es poden consumir paral·lelament.
  • balanceix de càrrega: podem fer map/reduce sobre les tasques i enviar-les als servidors que ens interessis per distribuir la càrrega.
  • independència entre lleguatges: el codi que demana la tasca i el que consumeix la tasca poden ser totalment diferents, les llibreries que té Gearman són: PHP, Pearl, Ruby, C, Python, etc.
  • interficie HTTP: a més disposa d’una interficie client HTTP que ens permetra injectar tasques desde llenguatges no suportats des de les llibreries de Gearman.

usar un servidor d’aquest tipus, ja que a més de permetrens demanar tasques síncrones, també podem demanar-li tasques asíncrones. O sigui, que no només no sabem qui ens esta fent la feina limitant-nos a rebre’n el resultat sinó que també podem demanar que aquesta feina es faci quan es pugui.

Per si tot això no fos poc encara hi ha més avantatges:

  • Open Source
  • Programat en C
  • Petit i molt ràpid
  • Suporta diversos backends: RAM, SQLite, Memcached, Tokyo Cabinet, etc.

gearman stack

La gent que va començar a implementar Gearman, van ser els de Danga Interactive famosos per LiveJournal i SixApart.

Les meves idees

Després d’aquesta introducció, ara ja puc parlar de les coses que voldria que fes Gearman però que no fa. Primer de tot he de parlar de les avantatges que tindria si pogués tenir un backend contra Redis. El que persegueixo al connectar Redis amb Gearman és aconseguir:

  • persistència de tasques malgrat es reiniciï Gearman
  • persistència de tasques en disc malgrat es reinciï Redis, gràcies a:
    • l’escriptura asíncrona a disc
    • bgrewriteaof: evita que per l’escriptura asíncrona d’informació es perdin dades al reinciar bruscament Redis
  • publicar a un canal PubSub de Redis els canvis que es fan sobre una tasca que s’ha enviat a ‘background’

Integració amb Redis

Es tracata de fer el mateix que s’ha per integrar backend de tokyo cabinet: queue_libtokyocabinet.c el problema d’usar tokyo cabinet contra disc és la pèrdua brutal de rendiment respecte a usar-lo contra RAM, ja que les escriptures es fan de forma síncrona.

A nivell de codi les semblances més grans són amb: queue_libmemcached.c, malgrat el problema que té aquesta implementació és que cada cop que reiniciem memcached no tenim persistència de la informació que s’havia guardat en memcached, és com si les claus que s’han intrudit en l’anterior sessió s’haguessin esborrat. A més memcached no suporta persistència en les seves dades tampoc.

Així doncs, el que cal fer és agafar el millor d’amdues integracions i fer el mòdul amb Redis.

Subscripció a les actualitzacions d’una tasca via Redis

Quan s’envia una tasca en segon pla a Gearman aquest ens retorna un ‘Handler’ per poder preguntar sobre l’estat de la tasca, el problema és que si volem saber com evoluciona la tasca o que ens informi quan ha acabat no hi ha manera de saber-ho si no és fent ‘pooling’. Per altre banda, el ‘worker’ va actualitzant la tasca cada quan creu convenien perquè Gearman pugui saber quin és l’estat de la mateixa.

La meva idea és que al usar el backend de Redis, al mateix moment que s’actualitzi l’estat de la tasca també es publiqui (publish) a un canal PubSub de Redis de forma que el codi que ha enviat la tasca pugui subscriures (subscribe) a aquest canal i en temps real i amb un cost de recursos baixíssim es pugui seguir l’estat de la tasca. Això ens evitaria la necessitat de que Gearman hagués de poder cridar un mètode de callback per informar-nos de l’estat de la mateixa, ja que hi ha alguns llenguatges en que fer això no és tan senzill.

En el gràfic que enganxo a continuació podem veure un esquema que he fet sobre això:

esquema idees de Gearman amb Redis

1) el nostre codi envia una tasca en ‘background’ (segon pla) a Gearman i aquest li torna un ‘Handler’ per identificar la tasca.

2) es guarda la tasca a Redis (set)

3) el nostre codi es subscriu al canal PubSub de la tasca

4) un worker demana la tasca

5) es publica l’estat de la tasca

6) es va actualitzant l’estat de la tasca

7) es van repetint els punts (5) i (6) fins acabar la tasca

Feedback

Com sempre s’accepten tota mena de crítiques i idees sobre la meva ‘paranoia’.

Com m’organitzo les tasques? (última incorporació MonkeyGTD)

Reading time: 6 – 10 minutes

Si alguna cosa no paro de repetir al meu blog i les meves converces, és que tinc mil coses que fer, que estic en mil temes, que no paro de fer coses, etc. doncs bé, a part de plorar per la situació que tinc faig moltes altres coses per solucionar el tema. Com per exemple, intentar no morir d’un atac de nervis i deixant-me que l’acupuntura i d’altres activitats no tècniques, com l’esport i els amics em deixin sortir d’aquest esperial que és la meva vida.

Una de les coses importants que porto temps intentant fer per millorar aquesta constant, que dubto que arribi a canviar mai en la meva vida, és llegir el llibre Getting Things Done. De fet, no espero que el llibre m’arregli els problemes. Però estic intentant millorar la meva forma auto-apresa d’organitzar-me les tasques. De fet, ja tinc diverses metodologies personals apreses una mica a base de l’experiència per tal de millorar temes d’organització personal. Però amb aquest llibre realment se’n extreuen grans tècniques que van molt bé per complementar o adaptar dintre de la meva rutina.

De fet, encara no he acabat de llegir el llibre però ja tinc força interioritzades diverses formes de millorar la forma d’atendre una nova tasca. L’última eina incorporada dins de la meva col·lecció de recursos que uso per organitzar-me és el MonkeyGTD. Es tracta d’una adaptació del TiddlyWiki especialment pensada per treballar segons la metodologia GTD.

Com que mai havia parlat d’aquests temes al blog, aprofitaré per donar una pinzella a les eines que uso per organitzar-me. Com a PIM uso l’evolution. A través d’aquest aplicatiu per linux accedeixo a les meves comptes de correu allotjades al servdiro IMAP de casa meva. A més, també disposo d’una actualitzada agenda de contactes tan personals com professionals. Finalment uso també moltíssim el calendari per tal de recordar les cites que tinc amb clients o cites personals.

Al calendari no m’agrada apuntar-hi tasques a realitzar, a menys que sigui important realitzar-les a un dia i hora concrets per algún motiu. Sinó que m’agrada tenir clar quin és el temps que tinc “lliure” entre cites obligades. Ja que donat el cas, puc decidir anar o quedar-me a l’oficina, tornar a casa per avançar feines tècniques, etc. A més em permet decidir coses en funció d’informacions que en el moment d’organitzar l’agenda no puc saber, per exemple, el meu estat d’ànim o nivell d’energia.

Una altre eina important és la Blackberry Pearl malgrat no és l’eina perfecta i hi ha moltes coses en que es queda coixa. Em permet seguir puntualment l’estat del meu correu quan estic viatjant, a casa d’un client o de camí a algún lloc. A més el client de gmail, gtalk i google maps complementen perfectament les eines que necessito en mobilitat. Pel que fa a la sincronització de l’agenda amb l’evolution ho faig a través de funambol i del servei scheduleworld via GPRS. El que no m’acaba de funcionar bé a través d’aquest servei és la sincronització del calendari de la blackberry i del google calendar. Malgrat teoricament esta suportat no funciona massa bé.

Un detall important a comentar en tot plegat, és el fet de tenir un webmail amb accés directe a l’IMAP allotjat en el servidor de casa. Això permet accedir a emails, documents adjunts i d’altres que tinc classificats en carpetes IMAP no visibles des del client de correu de la blackberry. El fet de que la blackberry actui com un dispositiu de Mass Sotarage també permet descarregar-hi fitxers que despres he de passar a clients, portàtil, etc.

Per tal de seguir les tasques de l’empresa, clients personals, projectes en desenvolupament amb equips de treball, etc. uso un programa del que ja us he parlat alguna vegada s’anomena Tasks Pro. Com ja vaig comentar algún dia és dels pocs programes que he comprat a la meva vida. És genial veure com els diferents grups de tasques que es creen des del programa es poden incorporar com a calendaris en format iCal directament a l’evolution. Això em permet seguir tasques més complexes (sovint projectes), compostes per subtasques o que mereixen un seguiment al llarg del seu desenvolupament a més ho veig reflexat tot sobre el mateix calendari de l’evolution.

A més des del navegador web de la blackberry puc connectar al tasks per tal de veure l’estat dels projectes, crar noves tasques, etc. Així doncs també hem serveix com a eina en mobilitat. Doncs bé el MonkeyGTD és l’últma incorporació a tot plegat. De fet, encara no la tinc operativa al 100% aquesta eina. Però es tracta d’un wiki que funciona sobre un únic fitxer HTML, no per això és una eina poc potent, al contrari. Amb una interficie cuidadíssima i una usabilitat exquisida gràcies a AJAX, podem disfrutar d’una eina perfecta per seguir les tasques diaries.

M’explico, fins ara he estat usant una simple llibreta (amb una mida la meitat d’un DIN A4 amb requadres). De fet, en els últims 4 o 5 anys porto gastades una pila de llibretes d’aquest tipus. Aquesta llibreta és ideal per prendre notes en reunions i per fer esquemes del que s’explica o per anotar qualsevol cosa que tinguem pel cap. A més de servir-nos per apuntar qualsevol altre tipus d’informació que després haguem de classificar on sigui. Doncs bé, el MonkeyGTD espero que es converteixi en el complement que em falta en tot plegat.

Que espero treure’n i com el vull usar en tot aquest esquema? doncs bé, la idea és anotar-hi les llistes de ToDo que fins ara anotava a la llibreta. De fet, puc continuar fent-ho a la llibreta, però sempre ha de portar cert sincronis-me amb el que hi ha al MonkeyGTD. Per què duplico informacions? doncs perquè el fet de treballar amb suport paper em suposa algunes limitacions per exemple:

  • Decidir la next action, no tinc prioritats o les prioritats poden canviar i llavors he de re-llegir la llista de tasques per decidir quina faig a continuació.
  • Les tasques no tenen contexte, és a dir, no les puc ordenar segons l’entorn on em trobo. Per exemple, hi ha tasques que només puc fer a l’oficina i quan sóc a casa no les vull veure.
  • No puc mantenir llistes de tasques que no sé quan faré, ja que queden enrera a les fulles de la llibreta i les perdo de vista. Tasques del tipus someday maybe.
  • No puc adjuntar-hi fitxers i copiar-hi URLs sovint és pesat.
  • Accés sempre seqüència a la informació que hi introdueixo.
  • No puc tenir-hi llistes de whishlists. Coses que vull comprar-me, llistes de compres de regals, llibres que m’interessen, etc.

Obviament el sistema de la llibreta també té les seves avantatges, com per exemple, la comoditat d’escriure a mà, no se li acaba la bateria, pots dibuixar-hi esquemes sense aprendre a usar cap aplicatiu, etc. però a l’hora de mantenir les llistes de tasques diaries de les que us parlava abans es queda un pel limitada.

De fet, encara no sé si el MonkeyGTD podrà acomplir el seu objectiu, perquè hi ha certes coses que no pinten gaire clares. Treballa en local, no sé si instal·lant-lo en un servidor HTTP amb suport WebDAV el podria usar des de la blackberry, però ho dubto per la gran quantitat de JavaScript que té degut a l’AJAX. A més, no usa un fitxer extern per guardar les dades, no sé què passarà quan hagi d’actualitzar la versió. Només exporta a RSS les tasques, no a iCal. A més tampoc, pot importar tasques ni via RSS ni via iCal. Seria genial poder-lo connectar amb el Tasks Pro. Així doncs, la seva poca integració amb la resta d’elements que uso em fa una mica de por.

Ja aniré comentant com va evolucionant tot plegat, si a algú l’interessa saber més detalls de com faig alguna de les tasques que he comentat per aquí de passada que m’ho comenti. També espero poder refereciar-vos cap a molt material que he anat trobant per internet sobre mètodes GTD, aplicatius i d’altres.

Organitzant les nostres tasques

Reading time: 2 – 2 minutes

No tinc cap ganes d’escriure avui, he tingut un dia molt mogut i productiu. Estic més que content del dia. Però no tinc ganes de passar-me més temps al PC. Per què escric? doncs resulta que mirant el bloglines m’he trobat una aplicació via web per organitzar les nostres tàsques que sembla molt guapa: voo2do. Què té d’especial doncs malgrat no soportar el treball multi-usuari planteja una original i diria que efectiva forma de treballar i organitzar les nostres tasques i/o projectes personals, la filosofia esta explicada aquí: Painless Software Schedules. Així que el voo2do només intenta aplicar la teoria explicada a l’article comentat amb tècniques tan noves com l’Ajax.

dashboard-small.gif

tasklist-small.gif

Fins ara l’eina que més m’ha agradat per organitzar les meves tàsques tan a nivell personal com per treballs en grup és el tasks pro fins hi tot estic sindicat al blog del seu autor, ja que el tio viu només d’aquest software. Li trobo alguna petita mancança encara, però malgrat ser de pagament en moltes de les seves versions crec que és d’aquelles coses que val la pena pagar. Si el voleu evaluar també hi ha versions lite per provar.

saved_300.gif