Getting shut out of my Windows / Opening up to a new World

Toată povestea asta începe cu ziua când, după ce am dat super examenul la IE, micvs și cu mine am decis să ne schimbăm sistemele de operare. El, din Ubuntu în Vista 64, eu din WinXP în Ubuntu 64. Bine, ideea era așa, un test, să vedem cum merge, dar dacă tot m-am regăsit în Ubuntu, am zis ce-ar fi să redimensionez eu partiția mea NTFS de Windows să o fac un pic mai mare, că și așa n-am nevoie de 40 de Giga pe Ubuntu. Allright, zis și făcut. 5 ore de redimensionat partiția de NTFS, restart, surpriza! Pentru că probabil s-or rescris descriptorii partiției în MBR după redimensionare, Windows acuma se credea instalat pe C:\, deși el era instalat pe F:\. Normal, no more boot, no more Windows.

Am încercat să-l lămuresc eu, am citit mult și bine despre cum se poate și ce se poate face, să repari chestia asta. Vă spun imediat ce am reușit, dar ce contează e că în timp ce foloseam Ubuntu ca să mă documentez și mai instalam câte o chestie, două în el, și am reușit să găsesc metode să trec peste problemele care îl făceau enervant pentru mine și, acum, după 3 zile (vă zic, nu-i așa simplu să găsești documentație pentru problema ce-am avut-o eu :P) sunt destul de hotărât să trec, într-un final, pe Ubuntu ca sistem de operare principal. Mai mult despre aventurile mele în ultimele 3 zile mai încolo. Postul ăsta este de fapt despre cât de prost îi Windows la chestii simple, și despre ce să faceți dacă pățiți ca mine :)zu

Situația pre-dezastru

Aveam un Ubuntu 7.04 (updatat între timp la 8.10), deci un ext3 și un swap. swapu era evident, standard, într-o partiție extinsă. Când am instalat XP-ul, am redimensionat partiția primară a linuxului și i-am făcut loc între linux și swap. Windows a văzut partița ca discul F: și așa a rămas (C, ext3u, D, swapu, și E, cdrom-ul – cred).

Problema

Am micșorat partiția ext3, în setup-ul pentru Ubuntu amd64, și am lăsat spațiu între ea și partiția ntfs a windows-ului, apoi, din proaspătul instalat Ubuntu, am rulat GParted (am încercat inițial cu Partition Magic din Windows, dar fiind partiția activa o refuzat să ruleze), și am redimensionat partiția ntfs la stânga (ceea ce implică și o deplasare). De menționat că îți trebe musai ntfsprogs ca să faci trăznăi pe ntfs din GParted.

Când am repornit windows-ul, partiția mea F: era acum C: și, Windows-ul nu mai știa să pornească (ajungea chiar înainte de login!). Am citit toate forumurile posibile, și am aflat o gramadă de sfaturi utile la tot felu de oameni în probleme asemănătoare cu a mea, dar nici unul util pentru mine. Totuși, niște chestii interesante.

  • Windows nu folosește la boot litere de partiții. La boot are un fișier special, boot.ini, unde partițiile sunt definite pretty much ca in linux, adica o adresare de tipul hard/partitie. Drive letter assignment este ținut în regiștrii (se înregistrează id-ul partiției la litera asociată). Dacă id-ul partiției se modifică sau ceva se schimbă și îi dă cu virgulă, Windows decide să facă o reasignare instant pornind de la C: (ceea ce am pățit și eu)
  • Practic, se pot edita regiștrii Windows, dacă reușești să te loghezi (se pare că sunt cazuri în care ajungi să te și loghezi), sau, poți să-i modifici chiar din Linux, dar tre să știi ce faci (și atenție copii, că regiștrii îs tot ce contează în windows, dacă cineva vine cu un livecd vă poate faulta. Sugestia mea, întotdeauna să aveți parolă pe boot :)
  • GParted se mișcă în direcția în care problema asta nu o să mai existe
  • Există un utilitar pe RecoveryConsole-ul de la WindowsXP, BOOTCFG cu care se poate modifica fișierul boot.ini, și regenera în cazul în care se strică sau devine corupt
  • Vista știe să repare cu DVDul de instalare default problema asta (nice)
  • WindowsXP are posibilitatea de a se reinstala (face un soi de Recovery, zice el) dacă bagi exact cdu ăla în unitate (adica acelasi produs, nu neaparat același CD fizic – contează dacă-i SP2, dacă-i varianta pentru MSDNAA, dacă ii Pro sau Home …) în care practic își șterge toate fișierele lui și le pune la loc și rescrie regiștrii. Eu am văzut în chestia asta scăparea mea (și cred ca era) doar că, dintr-un motiv bizar, când am ajuns să bag Keyul de la MSDNAA, Windows Setup nu îmi vedea tastatura, de loc. Am încercat de două ori, și am renunțat.

Soluția mea finală: move to Ubuntu, Windows can get screwed to fast, to unexpectedly. Totuși, dacă nu aveam problema cu tastatura (care presupun că a fost cauzată de ceva problema cu drivere gata instalate) puteam să îmi bootez windows-ul. De acord, îl butam în C: nu în F:, dar apoi puteam trece la șmecheriile cu regiștrii și eram home safe. Cred că unui user de desktop i-ar fi mers.

Tema 4 IE

Am scris un pic înainte despre Tema 3 la IE, aia cu highlighter pe text (care, în tentativa de a o face mai „cool” am buşit-o). Ultima temă la IE a fost creearea unei interfeţe pentru o aplicaţie fictivă care caută în log-uri de diferite tipuri de clienţi de IM. Aplicaţia trebuia să aibă un screen de setări, configurabil (conturi / rezultate pe pagină) şi un screen pentru căutare, cu posibilitate de căutare simplă şi căutare avansată (după tip şi după dată).

Partea interesantă a fost că tema a dat mână liberă la metoda de implementare: putea să fie browserbased sau standalone sau whatever, java, javascript, c#, pygtk, ce-o fi. Eu am reuşit să mă apuc de temă după ce am încheiat ultimele modificări la site-ul pentru proiectul la IE (despre care o să scriu mai încolo), deci pe la vre-un 5AM. Prezentarea trebuia făcută la 10AM, odată cu predarea proiectului, deci nu era foarte multă vreme la dispoziţie.

Am ales să o fac în Javascript / PHP pentru că îmi era cel mai la îndemână, dar omg cât de urât am fost obligat să codez din lipsă de timp. Rezultatul final a trecut „testul” (cu toate că au existat dezbateri dacă aplicaţia chiar trebuia să facă o filtrare de date phony sau putea să afişeze orice), adică implementa în mare facilităţile cerute, chiar dacă ultimele chestii le-am făcut pe scări la EG-uri în faţa laboratorului şi chiar în timpul prezentărilor. Trebuie să spun aici ca am „furat” de la micvs ideea cu logourile aplicaţiilor de IM în interfaţă :P.

Rezultatul final e aici, dacă vreţi să aruncaţi un ochi. [notă: evident că am sfeclit ceva pe-acolo când am făcut versiunea de pus pe site, deci probabil are bug-uri].

hm

News Search Engine / Proiect CI

CI este singura materie de an 5 pe care o fac toţi studenţii, indiferent de specializare (though, în funcţie de ce specializare ai, ai un alt profesor). Presupun materia asta are numele pe care îl are ca să ofere flexibilitate şcolii în a pune acolo conţinutul pentru care are profesori la un moment dat, but this is just a wild guess. Motivul care mă face să zic asta este că materia se ocupă cu Information Retrieval, şi numele ei n-are-a face cu asta.

Anyway, întâmplarea fericită a făcut ca specializările C1 şi C2 (eu sunt la C1) să îl aibă ca profesor pe first-time appeareance Paul Chiriţă, care e un meseriaş în domeniu şi care a lucrat pe la tot soiu de meseriaşi (like Yahoo) şi care acum s-a întors în Bucureşti şi lucrează la Adobe. Anyway, cursu a fost interesant, am şi reuşit să merg la câteva, dar era lunea, la 8, în Leu, ceea ce nu este prea compatibil cu mine :).

Am ales, împreună cu Gia, Micvs şi Miki să alegem calea interesantă şi să facem un proiect (alternativa era un referat). Evident, materia a început în octombrie, noi am aproximativ ales tema prin noiembrie şi am avut prima întâlnire pe 17 decembrie, cand deadline-ul era 12 ianuarie. Tema pe care ne-am ales-o a fost un news search engine, adică partea de crawl (spidering), partea de indexare, partea de gestiune a queryurilor, şi chiar şi o interfaţă de test.

Contribuţia mea la proiect nu a fost atât de mare pe cât mi-aş fi dorit, şi am ajuns la Bucureşti la aproape o săptămână dupa ce Micvs şi Gia s-or apucat deja de treabă, dar totuşi sper ca am ajutat :).

So, un pic despre proiectul nostru: ne-am propus sa re-inventăm roata ca să ne dăm seama cam cum era făcută, aşa că părţile esenţiale le-am facut de la 0. Motorul nostru de căutare de ştiri este scris în Java, şi foloseşte RMI între diferitele module (web-crawler, indexer, clienţi) şi JDBC cu baza de date în care menţinem un cache. Practic, ce ne-am pornit la drum să facem a fost o reinventare a roţii (sau, ca să citez din ceva ce-am citit pe net: ce rost are să te apuci să reinventezi roata, hai să reinventăm motorul – de căutare :P).

Crawlerul nostru este antrenat acum pe două site-uri: bbc.co.uk şi theguardian.co.uk. Am mers pe conţinut în engleză pentru că e mai uşor de găsit, mai corect format şi stufos decât ce găseam în română, dar mai ales pentru că anumite componente ale unui SE (stemming, spre exemplu) funcţionează ca în teorie când le aplici pe limba engleză. Practic, un „spider” porneşte de la site-ul principal, şi găseşte link-uri către categoriile principale ale site-ului, de unde obţine linkuri către ştiri. Se extrage textul şi titlul ştirii din pagină (cu o expresie regulată, pentru fiecare site), şi se trimite, printr-un apel RMI, server-ului de indexare. După ce termină toate linkurile, se semnalizează server-ului că s-a încheiat parcurgerea site-urilor şi crawler-ul este apelat din nou după câteva ore.

Serverul de indexare întreţine, evident :), un inverted index. Index-ul este reprezentat în memorie ca un hashtable, în care cheile sunt hashuri (int) ale cuvintelor trecute printr-un stemmer simplu de limbă engleză, şi valorile sunt liste înlănţuite de referinţe la documente şi un vector de apariţii (poziţii în document în care apare cuvântul respectiv). De fapt, se menţine câte un vector de apariţii pentru titlu, conţinut şi sumar.

În timp ce primeşte toate ştirile dintr-o „transmisie”, serverul foloseşte un pachet numit classifier4j pentru a calcula asemănările între două texte pe care le primeşte. Dacă asemănările sunt prea mari ( > 95%), ştirea este considerată duplicată şi se ignoră. Dacă ştirea seamănă în proporţie > 80% cu un text, se consideră ca este despre acelaşi eveniment sau aceeaşi serie de evenimente ca şi ştirea cu care este comparată, astfel făcându-se clustering bazat pe evenimente. Comparaţia se face folosind un motor care se foloseşte de teorema cosinusului într-un vector space de cuvinte (classifier4j mai poate folosi un comparator bazat pe teorema lui bayes, dar nu ştiam despre ce era vorba şi era mai complicat de folosit pentru ce voiam noi). La indexing-time se mai calculează şi un sumar static al textului, reprezentat din cele mai importante două propoziţii din text (calculate şi ele folosind un algoritm bazat pe teorema cosinusului aplicată pe spaţiul documentului respectiv). La fiecare indexare, cache-ul este înlocuit (în mod sincronizat) cu cache-ul nou.

Aspectul la care micvs a insistat la construirea indexului a fost performanţa: parsări minime ( = 1) a oricărei liste, oricărui string, şi optimizări pentru tratare de queryuri, în detrimentul performanţei indexării, dacă a fost cazul.

Pentru tratarea query-urilor, server-ul primeşte de la aplicaţiile client o listă de cuvinte cheie, printr-un apel RMI. Serverul foloseşte inverted index-ul pentru a găsi documentele care conţin cuvintele respective, şi aceste liste sunt apoi intersectate. Fiecare document primeşte o notă, la query-time, bazată pe numărul de apariţii a cuvântului în textul documentului şi pe existenţa sau absenţa cuvântului căutat în titlu şi în sumarul documentului. Dacă căutarea se face după mai multe cuvinte, nota se acordă şi în funcţie de apropierea în cadrul documentului între cuvinte (adică e mai relevant un document care contine termenii de căutare mai apropiaţi – în special unul lângă celălalt).

Pentru prezentare, miki a lucrat la o interfaţă în java, aşa, de POC (proof of concept) ca să putem să arătăm cum se obţin rezultatele şi cum se grupează. Pe mine m-a ros nonstop faptu că nu am făcut ceva webbased pentru căutare, că pentru mine făcea mai mult sens să fie webbased, aşa că, după predarea proiectului, m-am jucat un pic, pentru prima dată ever cu nişte Servlet-uri. Promit că dacă o să chiar termin ceva o să le pun la mine pe site să le poată testa cine vrea :).

Oricum, a fost un proiect instructiv, şi, pe cât îmi displace mie Java, trebuie să recunosc că munca în echipă e mult mai clar definită când se programează în limbaje gen Java. Proiectul ăsta a fost şi primul proiect la care am reuşit să-i conving pe ceilalţi să folosim SVN pentru controlul codului, ceea ce pentru mine a fost o reuşită personală.

Partea mai puţin reuşită a fost prezentarea efectivă a proiectului, unde am mers direct după o noapte nedormită cu o prezentare încropită şi un proiect semi-finalizat. M-am bâlbâit nonstop la prezentare, şi când i s-o terminat la Gia bateria de la laptopu de pe care prezentam I froze. Evident, se pare că prezentările astea erau oarecum mai puţin colegiale şi mai mult „oficiale” aşa ca mi-am luat bobârnacu necesar peste nas, dar îl meritam pentru că am mers, într-adevăr nepregătit pentru o prezentare.

meeting JavaScript

Tema 3 la Interfeţe Evoluate ne-a cerut să scriem, folosind Javascript pentru scripting, un webbased thingie care sa faca highlight pe cuvinte / fraze dintr-o pagina web, încărcată dinamic (eventual folosind Ajax). Ceva foarte simplu, menit să ne familiarizeze, presupun, cu Javascript.

Eu fug de Javascript încă de la începuturile experimentărilor mele web-astice, pentru ca ce am văzut atunci arăta foarte foarte aiurea pentru mine. E drept, cred, ce se spune despre Javascript, că e un limbaj Ok de scripting, dar care e folosit în cel mai hidos mod. Acum ceva vreme era folosit pentru nenorociri de-alea de animaţii de prost gust, ceasuri ascii care fug după mouse şi alte nenorociri care nu au ce căuta într-o intefaţă bună.

Acum vedem însă tot mai puţine utilizări negative (cel puţin din punct de vedere vizual) a Javascript, şi tot mai multe exemple pozitive. Nu ştiu exact istoria, şi sunt sigur că o călătorie scurtă pe wikipedia vă poată lămuri mai bine ca mine, dar eu cred că Javascript a început să devină widely accepted ca un limbaj de scripting serios odată cu trecerea la Web2.0, care, printre alte calităţi, se defineşte prin interfeţe web mult mai responsive. Dezvoltarea Javascript-ului ca limbaj a permis Web2.0 să existe, şi, la fel, nevoia de creştere a calităţii interfeţelor a dus la dezvoltarea limbajului. Cele mai populare trăznăi ce le folosim azi, Gmail, Y!Mail, Noul WordPress, dar şi vechiul, aproape tot ce e Google-ish, toate folosesc la greu Javascript.

De ce avem aşa super nevoie de Javascript? Well, înainte de web2.0 şi de toată nebunia cu superinterfeţele web, problema comunicării cât mai responsive cu clientul se putea rezolva în două moduri. Prima strategie era cea locală (client-side scripting): aveai un script care încărca totul în pagina curentă, în javascript, şi atunci puteai interacţiona cu utilizatorul (să validezi date, să îi dai nişte opţiuni diferite în funcţie de alegerile pe car ele face …) într-o manieră limitată la informaţiile care existau la încărcarea paginii. Şi cum să trimiţi toate posibilităţile înseamnă cantitate mare de date şi cantitate mare de date e un big no-no pentru interfeţe web, interacţiunea era limitată.

A doua strategie (server-side scripting) implica de cele mai multe ori reîncărcarea paginii şi procesarea opţiunilor cu server-ul. Necazul era că şi pe legăturile rapide (gen intraneturi) se observa reîncărcarea paginii, iar pe legăturile lente (sau no, normale) asta devenea o problemă serioasă.

Toate problemele astea au primit o soluţie unică, elegantă şi foarte foarte folosită azi de toate aplicaţiile web ce le folosim frecvent: AJAX. Asynchronous Javascript And XML. Deşi tehnologiile care fac AJAX posibil există de prin 95, W3C a propus un draft pentru chestia asta doar în 2006. Ideea e relativ simplă, AJAX se bazează pe un obiect Javascript  (da, JavaScript e şi OO :P) care face o cerere HTTP către un server şi înregistrează un handler (o funcţie) care se apelează în momentul când cererea întoarce ceva sau dă un timeout. Răspunsul cererii se presupune a fi un XML, deşi din ce am încercat eu se poate folosi şi HTML ca răspuns, dar nu sunt sigur de alte tipuri de date.

Avantajul cel mare e că toată bucătăria se întâmplă în culise, utilizatorul are o experienţă fluentă, care seamănă cu experienţele cu interfeţe ne-web. Există şi limitări. Deşi, teoretic, se pot cere fişiere oricât de mari, având în vedere că totul se întâmplă peste un mediu care are performanţe variabile indiferent de locaţie, se preferă ca răspunsurile să fie minime. O limitare de securitate care am observat-o (nu ştiu exact când a fost introdusă) este că cererile XMLttpRequest (obiectul de care vă ziceam) nu pot fi făcute decât către serverul de la care a fost încărcată pagina care execută scriptul.

Desigur, problema asta se poate rezolva urgent cu un urlfopen pe partea se server, şi asta e mirific la AJAX, posibilitatea de a trece peste limitările iniţiale impuse de modelul Web prin pasarea lor către partea celalată (client <-> server).

Anyway, pentru cine este interesat, tema mea 3 la IE este aici. Si, ca sa o testati, puteti incerca sa folositi pagina asta şi asta :)

Am devenit mult mai interesat după tema asta să investighez mai îndeaproape JavaScript şi, mai ales AJAX pentru yPHP (pentru început, un modul de formuri dinamice şi de verificare a formurilor pentru început :P). Vorbind de tehnologii, am înţeles că jQuery (ăla de aici, nu ăla care ţine de baze de date şi Java) e util. Are cineva vreo experienţă cu trăznaia asta? I will give it a try, and post here on the results :)