Thursday, April 28, 2005

Adam Bosworth la MySQL Users Conference 2005

Foarte interesanta expunerea lui Adam Bosworth la MySQL Users Conference 2005 (via Daniel H. Steinberg
):
Bosworth advocated an open model for data.(...)
Imagine if you can query any data that is available anywhere in the world. Bosworth said that what this requires is a single, simple, open wire format for items. The format needs to be simple for any P programmer to deliver and any JavaScript programmer to consume. He also pointed out that "complex things tend to break and simple things tend to work." Google has the simplest query language in the world. There is no structure and no syntax.


Si mai ales asta m-a facut sa gandesc altfel asupra proiectului la care lucrez:
Bosworth said you need to limit your queries to those that can be easily implemented by everybody and those that can be handled by a single machine. This requires that your queries run at the item level. This might feel odd to those used to dealing with databases, as this means you are not likely to perform joins, aggregations, or subqueries. There is plenty of SQL that cannot be supported.



Deocamdata ma rezum la a da citate, sper ca in curand sa imi aduc o mai mare contributie la "data-openess" in .ro (o combinatie intre asta si asta).

Monday, April 25, 2005

Citate si alte peripetii din lumea REST-ului

O noua furtuna a cuprins lumea REST-ului (si nu me refer la clasicile "why REST is better than WS-*").
Dare Obasanjo a dat tonul printr-un post in blogul sau in care demonstreaza ca Bloglines, Flickr si del.icio.us au incalcat principiile REST ce sunt expuse pe scurt aici (pentru cine nu are rabdare sa citeasca teza lui Roy Fielding). In principiu, Flickr si del.icio.us folosesc GET cand de fapt ar fi trebuit sa foloseasca DELETE, in timp ce Bloglines foloseste acelasi GET intr-o circumstanta care nu este "idempotent or safe".
A urmat articolul lui Jon Udell (titlul spune aproape totul: "End HTTP abuse"):

Why didn't Bloglines, Flickr, or del.icio.us enforce the POST restriction? I suspect it's because they wanted their APIs to have the broadest possible reach. And from a programmer's perspective, the simplest and easiest HTTP clients are those that use GET.


Concluzia lui este ca:

But if all toolkits made POST as accessible as GET -- or as nearly so as possible -- there would be less incentive to misuse GET.


La randul lui, articolul scris de Jon Udell a avut replici interesante.
Mai intai a fost Ryan Tomayko, On HTTP Abuse:


The large majority of smart technical people believe that HTTP is legacy technology: an old protocol, maybe a step above gopher, that has somehow hung around through the years. Something to be dealt with, not taken advantage of. We need to show how limiting this mind-set is.
(...)
My feeling is that we haven't done a good enough job of showing examples of what the correct use of HTTP, URIs, and XML looks like in the real world.
(...)
To sum up, we need a good implementation of HTTP/1.1 that provides a real framework for building standards based web applications. We then need to advocate and illustrate the correct use of HTTP/URIs/XML as a killer technology that has been hiding right under our noses by showing the benefits of using the system correctly.


Urmarea a venit de la Leigh Dodds, in Ending HTTP Abuse:

And yet, how many frameworks encourage or even allow the binding of handlers based on a combination of URL+method? In my experience the protocol independence anti-pattern kicks in at that point, and the request method is the last thing that a developer is encouraged to take into account. The end result are URLs that react identically to any request method. It might be an interesting experiment if Udell tried sending PUT, DELETE, HEAD requests to the same API calls.


si citatul care mi-a placut cel mai mult :) :

This situation is often compounded by URL designs that are more RPC than REST in nature. E.g. /getPerson, /updatePerson rather than just /person. In the latter case you have to use the right request method to differentiate requests and respond appropriately.


Probabil ca v-ati plictisit de atatea citate, dar din punctul meu de vedere ele arata ca lupta pentru a construi un Web 2.0 cat mai "curat" (un termen destul de vag, stiu, dar pana la urma si "vag" se potriveste perfect cu Web 2.0 :)) este in plina desfasurare si destul de incitanta.

Din pacate, in .ro disputele sterile (dupa parerea mea) in jurul unui festival de comunicare par a consuma toata energia celor ce se lupta in transeele web-developmentului, astfel incat o cautare in limba romana dupa Representational State Transfer a intors un singur rezultant relevant (ce-i drept, daca fac cautarea pentru toate site-urile .ro dau peste cateva zeci de rezultate, dar aproape toate scrise in engleza, pentru "export"). Lucrul bun este ca asa am reusit sa aflu despre acest workshop, care s-a tinut in noiembrie anul trecut (too bad I found about it only now). Totusi sper sa pot participa la editia de anul acesta (in principal daca voi avea timp, bani se gasesc intotdeauna pentru ceva ce iti place).
O sa mai scriu despre REST and stuff like this, mai ales pentru ca incerc sa fac din el "piesa de rezistenta" :) a proiectului la care lucrez acum. Acum meditez asupra dilemei "Constructing or Traversing URIs?"

Friday, April 22, 2005

Salvati Calea Grivitei (sau cel putin nu o uitati)

Cum blogul asta se cheama "Grivitei Pythonista", mi-am zis ca ar fi timpul sa scriu ceva si despre Calea Grivitei. Sau mai bine zis despre ce a mai ramas din ea, portiunea de la Gara de Nord - Polizu pana la intersectia cu Calea Victoriei, langa sediul Petrom, caci restul (Gara de Nord - Basarab pana la intesrectia cu Bulevardul 1 Mai s-ar putea numi la fel de bine Str. Drumul Taberei sau Blvd. Nicolae Grigorescu, toate arata la fel). Desi as putea fi acuzat de subiectivism cand spun ca aceasta portiune din Calea Grivitei reprezinta una din cele mai interesante strazi din Bucuresti, tinand cont de faptul ca locuiesc in apropiere, imi dau seama ca nu este asa pentru ca m-am plimbat destul de mult prin orasul asta pe jos ca sa stiu ca am dreptate. Am citit recent Chipurile orasului - Istorii de viata in Bucuresti Secolul XX de Zoltan Rostas, o carte de istorie a Bucurestiului si a locuitorilor lui ce stie sa treaca peste siropelile de genul "Calea Victoriei - Anii '30 - Cioran, Eliade, Ionesco" si de exemplu prezinta in aceleasi pagini marturia unei foste mari boierese si a unei slujnice analfabete. M-am convins ca strada aceasta si stradutele care o inconjoara au reprezentat foarte mult pentru o multime de oameni, de la Maria Mandrea, descendenta a Balcestilor, ce povesteste despre balurile de la sfarsitului secolului al XIX-lea date la resedinta Nababului (actualul muzeu G. Enescu, pe Calea Victoriei, langa intersectia cu Str. Frumoasa, din care dai in Buzesti, si ai si ajuns la Matache pe Calea Grivitei), la Anastase Nasta, poet aroman aterizat la Bucuresti in anii '20 ca student (din Macedonia via Balcic) ce se cazeaza la "Institutul Politehnic din strada Polizu. Abia dupa masa am iesit pe Calea Grivitei, pana la intretaierea cu strada Buzesti, hoteluri, cladiri mici, cu reclame zgomotoase, si cinematograful Marna si Buzesti, existene si astazi (in anii '80 - nota mea), unde am vizionat unul din primele filme din viata mea, cu Ramon Navarro, vedeta acelor timpuri; mi-a ramas in minte clar inoul sau felin intr-o mare mai albastra decat Mediterana" (e fascinant cand te gandesti ca in '27 in locul balariilor de la Cinema Feroviarul se afla un ecran alb care le facea cunostinta bucurestenilor poate pentru prima data cu vedetele de la Hollywood si in acelasi timp ii facea sa viseze la lucruri total inefabile ca albastrul Mediteranei), la maghiarul Gyula Kover, al carui tata facea calesti pentru boieri, ce statea pe actualul Blvd. N. Titulescu ("pe vremuri ii spunea Soseaua Basarab, pe urma s-a facut Bulevardul Basarab"), urmand scoala primara undeva pe langa Sala Palatului ("toata zona aceea se numea Fantana Boului") si gimnaziul la Sfintii Voievozi, nr. 50 (daca faci legatura intre aceste locatii Calea Grivitei apare ca principalul element de conexiune), la Scoala Evanghelica Nemteasca, de pe Strada Luterana (de la intersectia Grivitei - Vulcanescu - Dacia putin mai jos), care apare in cel putin o treime din interviurile din aceasta carte si care a reprezentat punctul cardinal pentru miile de copii ale mestesugarilor nemti si nu numai fara de care prima industrializare a Romaniei (din anii '20 - '30) nu ar fi fost posibila.
Stiu ca divaghez, insa tot ceea ce vreau sa spun este ca aceastra strada, Calea Grivitei, ce se leaga de destinele atator si atator generatii de bucuresteni care au construit Romania asa cum o stim noi azi (buna sau rea, nu conteaza) e deja pe trei sferturi distrusa, si nu mai e mult pana cand ea va fi invadata de zgarie nori cenusii. Acestia au invadat deja Piata Victoriei si se indreapta in jos pe strazile Buzesti si Polizu catre Calea Grivitei. Aici nu vor avea nici o problema sa se instaleze, deoarece din pricina dezinteresului institutiei municipale portiunea dintre intersectia cu Polizu si cea cu Buzesti arata la propriu ca dupa un bombardament. Si odata ajunsi aici sunt sigur ca nu se vor opri si vor incerca sa-si continue expansiunea catre intersectia cu Calea Victoriei.
Ironia este ca acum vreo patru ani cineva (dupa cate mi-aduc aminte un ONG) pornise un proiect de a salva Calea Grivitei, a fost ceva harmalaie prin presa culturala, si-a incasat frumos banii (probabil primiti de la UE) cu constiinta impacata si a plecat. Probabil ca acum e de gasit pe la concertele Stuf - Salvati Vama Veche.
Ce-i drept, e mai shic sa fii vazut gol in Vama decat la Baile Grivita.

Wednesday, April 20, 2005

Mici nelamuriri legate de Bugzilla

Citeam acum cateva zile un articol mai vechi al lui Joel Painless Bug Tracking, si m-a cuprins un soi de "vinovatie" pentru faptul ca in cazul proiectelor mele "bug tracking e sublim, dar lipseste cu desavarsire" :). Si nu pot spune ca sunt mult mai bun decat Joel atunci cand vine vorba de a tine minte un bug:

At any given time, I can only remember two bugs. If you ask me to remember three, one of them will fall on the floor and get swept under the bed with the dust bunnies, who will eat it.

Stiu ca ceea ce scrie in articol se aplica in principal echipelor ce contin doi sau mai multi programatori, dar undeva spre sfarsit e un paragraf care m-a facut sa ma simt intr-adevar cu musca pe caciula ("If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are simply going to ship low quality code"), si m-a convins sa caut un sistem de bug tracking.
Desigur ca in conditiile in care proiectele la care m-am inhamat nu imi aduc vreun "gologan" in contul personal nu ma puteam gandi decat la o solutie "free", asa ca iata-ma pe site-ul Bugzilla.
Cum prietenei mele nu-i place altceva decat Windows (I'm not at all a good Linux evangelist), asta inseamna ca si eu sunt nevoit sa lucrez pe acelasi SO (desi a fost o vreme cand inca mai aveam rabdare sa fac switch-ul Linux - Windows ori de cate ori reuseam sa o scot pe prietena mea de la calculator sau invers. Datorita baietilor de la Mandrake am aflat ca exista un limbaj de programare pe nume Python :)).
Asa ca iata-ma incercand sa aflu de ce am nevoie pentru a instala Bugzilla.
La prima vedere lucrurile par in regula. Instalarea propriu zisa nu cere decat trei comenzi, dintre care una de login. Doable, I'd say.
Apache 2.x il am deja instalat, si nu ma sperie sa umblu in httpd.conf, am mai facut-o de atatea ori.
MySQL e de asemenea instalat, problema apare atunci cand imi cer sa creez "de mana" o baza de date "bugs". Piece of cake, dar ideea nu-mi place. Sa spunem ca am deja o baza de date "bugs", ce fac? O redenumesc pe cea veche? Sau ii spun altfel celei noi sperand ca exista vreun mod de a configura Bugzilla astfel incat sa stie sa se uite si dupa altceva decat "bugs"? (n-am avut timp sa ma uit dupa asta, dar sunt sigur ca se poate).
Oricum, problema apare atunci cand imi cer sa instalez Perl. Stiu ca Python nu e cel mai bun limbaj de programare existent, dar de aici pana a-mi instala Perl doar pentru a folosi un singur program e cale lunga.
Poate m-am obisnuit prea mult cu programele ce le instalezi doar apasand pe butonul mouse-ului, dar daca ar fi doar asta atunci ca mine mai sunt multi (blame it on windows :)). Insa cred ca ce ma tine (inca) departe de Bugzilla (sperand ca voi trece peste aversiunea fata de Perl) este faptul ca depinde de trei medii externe (Perl, Apache, MySQL), si poate ca in incostient asta mi se pare un punct slab. (sa spunem ca vreau sa upgradez la MySQL5 peste un an de zile, va trebuie sa astept pana Bugzilla va deveni compatibil cu aceasta versiune pentru a face trecerea? Dar daca ma conving ca Apache 2.x nu e destul de sigur si vreau sa fac downgrade la 1.3, what then?). Cred in principiul ca sansele unui program de a rezista de unul singur "out there in the wild" sunt direct proportionale cu gradul de independenta fata de alte aplicatii sau SO, si la punctul asta Bugzilla pe mine inca nu m-a convins. Sper sa nu fiu inteles gresit, din cate am citit si auzit Bugzilla isi face treaba excelent (mai ales tinand cont de faptul ca e free), dar eu inca nu am reusit sa trec de primul pas, instalarea :)
Si iata-ma apeland la vechiul Notepad...

Friday, April 15, 2005

Code recycling

Azi mi s-a intamplat un lucru "misto", si anume am "reciclat" cod ascuns undeva prin ungherele HDD-ului, parte a unui proiect de care nu ma atinsesem de un an si jumatate si care printre altele era mandrul supravietuitor a doua "system failures".
Am "import-at" clasa respectiva, am reparat un mic bug de un singur rand, si totul a mers. Desigur ca acum, la un si jumatate de cand l-am scris, codul mi se pare "ugly" si mi-am promis ca o sa-l rescriu, dar probabil ca lenea care m-a facut sa spun "da' stai asa, eu am mai scris asa ceva" si sa incep sa-l caut ma va impiedica s-o fac.
De fapt problema este ca mereu "e altceva mai interesant de facut decat sa repari old code" :)

Thursday, April 14, 2005

"worse is better" si A&C Bucuresti

Ceva, ceva parca incepe sa se miste cand vine vorba despre situatia din scoala in care invat, chiar daca pentru moment e vorba doar despre niste comentarii (la obiect si foarte bine venite) facute de studenti pe cale de a termina.
Din punctul meu de vedere, pot spune ca fac parte din generatia celor care au facut doar "mate-fizica" in liceu si care au invatat sa deschida un calculator in primul an de facultate (nu eram singurul la vremea aceea, dar astazi cred ca nu mai exista asa ceva in anul I).
Semestrul I, anul I, Programare - 5 (de-abia, de-abia), Analiza Matematica 10 (cu laude din din partea profesorului). Semestrul II, Anul I, SDA - picat cu brio, Analiza 10. Mi-a luat trei ani pana sa am curaj sa dau din nou examen la SDA (luat cu 10 - felicitari din partea profesorului, oricat ar parea de absurd), dar intre timp am uitat raspunsul instantaneu la intrebarea "care este derivata lui 1/x^2 ?".
Din punctul meu de vedere problema nu este faptul ca "studentii nu mai invata" (invatam foarte mult in anii I si II, dar doar "invatatul" nu m-ar fi ajutat sa iau examenul la SDA, nemaivorbind de o slujba decenta, si poate chiar interesanta, in IT, cum sper ca o sa obtin dupa ce termin anul IV), ci faptul ca nimeni nu ii ajuta sa vada "the big picture" (sau "imaginea de ansamblu", cum va place).
In anul I, multi dintre studentii buni (ce aspira la burse) isi consuma 90% din energia de invatat pe Analiza, ELTH, Fizica etc. (stiu asta pentru ca am fost unul dintre ei), in anul II vine randul "Electronicelor", anul III aduce cu el TS-ul si CNA (si o restanta la DCE, daca a avut ghinion anul trecut) iar anul IV aduce IRA si IS, si uite asa vine anul V si multi descopera ca le-au mai ramas doar niste cunostinte de C si Pascal din primii ani de facultate si ceva Java acumulata din tutoriale de pe Net intre un curs de IRA si unul de TS II. Multora dintre noi (ma refer la studentii de la Automatizari, la Calculatoare poate e mai bine) notiuni ca Test Driven Development sau eXtreme Programming (notiuni de baza in multe firme IT) ni se par dupa caz fie "o chestie de marketing" fie "o emisiune de pe ESPN". La multe seminarii si cursuri se fac glume mai mult sau mai putine reusite pe seama "bazelor de date", dar nimeni nu ne indeamna sa scriem o documentatie serioasa la un program dat ca tema (oricat de frivol ar parea task-ul la prima vedere) sau sa ne puna in fata o portiune de cod scrisa de altcineva si sa fim in stare sa putem spune dupa un anumit interval de timp ce a vrut programatorul acela sa faca acolo (e un citat faimos pe net de genul "programatorii isi petrec mai mult timp citand codul altora decat scriind cod propriu", n-am timp acum sa caut cine a zis-o, cred ca Paul Graham).
Eu unul nu cred ca in scoala ar trebui sa invatam "Java" (sau orice alt limbaj ar deveni hype peste 10 ani), caci asta intr-adevar se face in particular, dar cred ca ar trebui sa se puna accentul pe principii (de genul "asa da, pentru ca...", "asa nu, pentru ca..." unde "..." pot reprezenta dupa caz un fragment de cod Lisp al unei probleme ce a fost pusa pentru prima data acum 40 de ani sau o clasa Java ce explica mai bine problema accesului simultan la resurse partajate).

Si poate ca intr-un final fericit indemnul "invatati, invatati, invatati" (cu care sunt intoxicati studentii romani) va fi inlocuit cu "worse is better" :)

Friday, April 08, 2005

Despre afisele din holul facultatii

Cineva ar trebui sa puna un afis la intrarea in facultate :
Programarea in Matlab poate crea stari de depresie. A se evita pe cat posibil..
Pe de alta parte, majoritatea afiselor cu oferte de munca din holurile facultatii sunt pline de "Java", "C#", "Oracle". O singura data am vazut unul care cerea programatori Lisp, acum un an de zile. Despre Python nici nu mai vorbesc. Cred ca ar trebui sa las prejudecatile de-o parte si sa ma apuc sa invat Java (desi spun asta de cel putin un an de zile). Sau poate nu am sa o fac, tot incercand sa ma conving singur cu citatul asta din Paul Graham:

During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

Saturday, April 02, 2005

marshal vs. cPickle in python

obisnuiam sa "serializez" datele cu marshal, mai rapid decat pickle si cPickle (varianta scrisa in C a lui pickle).
acum cateva zile aveam placerea de scrie un program ce imi genera un dictionar de liste (de forma dictionar["Gigel"] = [lista cu mai mult de 100 de elemente], cu len(dictionar) ~ 5), ce dupa aceea era salvat ("dump"-uit) intr-un fisier binar. La un "load" succesiv, pentru len(dictionar["Gigel"]) ~ 100), nici o problema. mai adaug niste elemente lui dictionar["Gigel"] (ca si lui dictionar["Vasile"] sau dictionar["Alina"]), astfel incat len(dictionar["Gigel"]) ~ 200, "dump" din nou, nici o problema. Insa cand incerc din nou un "load", imi afiseaza eroare de serializare.
Am pierdut o seara intreaga inainte de a-mi da seama ca ar fi bine sa incerc sa fac "dump" din prima pentru un dictionar cu len(dictionar[item]) ~ 200. O fac, nici o eroare la "dump", insa imediat eroare la "load".
Redeschid manualul, citesc asta


The following types are supported: None, integers, long integers, floating point numbers, strings, Unicode objects, tuples, lists, dictionaries, and code objects, where it should be understood that tuples, lists and dictionaries are only supported as long as the values contained therein are themselves supported; and recursive lists and dictionaries should not be written (they will cause infinite loops).


si desi nu am liste sau dictionare recursive ma gandesc ca ar fi bine sa-i dau o sansa si lui cPickle. peste tot unde apare "marshal" inlocuiesc cu "cPickle", run...
nici o eroare, totul merge bine. Inca nu am stat sa caut pe google daca si altii s-au confruntat cu ceva de genul asta, dar morala este ca ar fi trebuit sa imi intre in cap "warning-urile" din manual:

The marshal module exists mainly to support reading and writing the ``pseudo-compiled'' code for Python modules of .pyc files. Therefore, the Python maintainers reserve the right to modify the marshal format in backward incompatible ways should the need arise.