Ma tot uit de ceva timp dupa un provider de vps-uri pe kvm sau pe xen, care sa fie in .ro si sa fie cat de cat ok. Si n-am gasit decat la niste preturi care mie imi par cam mari pentru ce ofera (min 30EUR la 512RAM, 10-20G disc) :-S
ANCOM vrea sa introduca operatori mobili virtuali, operatori ce folosesc infrastructura mobila a unui alt operator. Interesant nu ? Eu zic ca si mai interesanta este posibilitatea ca un operator sa fie furnizor de infrastructura de comunicatii mobile pentru operatori mobili virtuali. Mai aude cineva pe fundal: “Rom Rom Telecom, Rom Rom Telecom … ” ?
Sa stiti ca n-am renuntat la seria de tips pentru Perl, sunt inca articole in lucru. Pana atunci, sa va povestesc ce-am mai descoperit azi. Am nevoie sa scriu o aplicatie mica (care se va face maaare), care sa lucreze cu adrese IP. In principiu aplicatia trebuie sa ia de pe un router clasele de adrese IP exportate de routerul ala catre diversi neighbours, sa le bage intr-o baza de date si sa le zica cand se schimba ceva pe acolo. Ofc, din baza aia de date clasele de adrese IP se vor exporta prin diverse metode (webservices mostly) catre diverse aplicatii. Pare simplu nu ? O aplicatie triviala, care nu necesita cine stie ce chestii complicate. Asta in teorie, pentru ca in practica la jumatatea aplicatiei iti dai seama ca adresele alea IP nu sunt doar IPv4 ci si IPv6 :) Si asta schimba cu totul aplicatia. Pentru ca:
- daca baza de date utilizata este MySQL, surpriza: MySQL are suport pentru IPv6 doar in MySQL 6.0, care nu e pe nici o distributie.
- o adresa IPv4 impreuna cu netmask-ul asociat, pot fi stocate lejer in 2 campuri de 32 de bits fiecare. Super optimizare de stocare, indecsi rapizi, etc.
- o adresa IPv6 poti sa o stochezi momentan doar ca sir de caractere. Si netmask-ul la fel. Nu mai avem nici optimizare la stocare, nici indecsi rapizi, nici macar etc (asta tot pe MySQL)
- multe din modulele din CPAN (in special cele ce au bucati [sau sunt complet] in C) nu au suport pentru IPv6.
- regexp-urile folosite pentru IPv4 nu mai merg. Trebuie altele.
Si tot asa. Pana la urma, tot am gasit ceva bun: Net::Subnet stie sa lucreze si cu IPv4 si cu IPv6 ;)
Nu stiu altii cum sunt insa mie imi place foarte mult ca lucrurile sa fie structurate bine. Sa fie cat se poate de atomice si sa coabiteze pasnic cu alti atomi intr-un echilibru cat mai aproape de perfectiune. In acelasi timp trebuie sa ofere un anumit grad de flexibilitate absolut necesar intr- o comunitate. Dupa parerea mea structura codului trebuie sa respecte unul din principiile de baza ale GNU/Linux: un program trebuie sa permit folosirea sa ca generator de input initial, tranzit sau output final. Cumva, asa am facut intotdeauna. Am spart o problema in bucati mai mici pe care le-am facut astfel incat sa poata fi folosite nu numai in cadrul aplicatiei pentru care au fost concepute cat si in alte aplicatii (ofc, acolo unde este posibil ;) .
Teoria suna ca mai sus. Majoritatea celor ce programeaza (la orice nivel si in orice limbaj) cunosc principiile. Le cunosc adica au cunostinta ca ele exista, insa nu le aplica decat mult prea putin. Insa, atunci cand codul sursa este evaluat si sunt descoperite probleme, cel mai des sunt invocate lipsa timpului sau presiunile din partea superiorilor. Amuzant (si trist in acelasi timp) este ca evitarea principiilor sanatoase in scrierea aplicatiilor, impreuna cu resursele mai mari necesare, duce in cele din urma la costuri mai mari asociate cu mententanta si dezvoltarea ulterioara.
In urma cu cativa ani (vreo 3, daca nu ma inseala memoria), am vazut intr-o prezentare din cadrul proiectului GEANT (un proiect european foarte mare in care sunt implicate cam toate NREN-urile din Europa) un principiu foarte interesant: “principiul pisicii moarte”; care este legat de pasarea responsabilitatii la “ceilalti”. Principiul pisicii moarte spune “nu sunt eu de vina, ceilalti sunt pentru ca …”. Ei bine, acest principiu este una din problemele majore la proiectele mari, mai ales la cele comerciale. Iar in scrierea aplicatiilor este foarte usor de folosit acest principiu pentru ca problemele sunt descoperite foarte tarziu, in cazul in care sunt descoperite, iar investigatiile sunt destul de greu de realizat. Problemele generate sunt foarte multe si variaza de la bug-uri ciudate la probleme de securitate majore iar in unele cazuri duc chiar la bug-uri majore ce nu pot fi corectate si care pot afecta core-ul unei aplicatii.
Din pacate factorii autohtoni ce ar trebui sa fie promotorii principiilor sanatoase de coding evita sa se implice in mod real in promovarea si explicarea importantei acestora si se multumesc doar sa le mentioneze pe alocuri, bifand in agenda yet another … thing.
Eu folosesc statii de lucru cu Linux, MacOSX si Windows, unde Linux este in diverse combinatii si arome :) Pe toate statiile (mai putin pe cele cu MacOSX unde functioneaza impecabil), noua tema implicita de la Google (gmail si reader) se misca infiorator de lent. Interesant e ca pe toate platformele folosesc aceeasi versiune a aceuiasi browser. Oare de ce se intampla asta ?
Ma intreb de ce oare majoritatea aplicatiilor care au suport pentru corector gramatical activeaza implicit fara sa ma intrebe nimic ? Ce este cel mai trist este ca desi se lauda ca stiu aia si ailalta, de fapt nu au suport pentru romana, ceea ce le face inutile daca aplicatia este folosita in romania, nu ? Si mai trist este ca desi majoritatea oamenilor specifica in timpul instalarii, Romania, EEST aplicatiile nu prea tin seama de aceste informatii. Si cand te gandesti ca ar fi atat de simplu sa:
if ($country ! in $supported_grammar_countries) {
disable_spelling();
}
sau, varianta eleganta:
if ($country ! in $supported_grammar_countries) {
ask_user_about_spelling();
}
Dar deh, e mai simplu sa pui indieni sa scrie ceea ce un contabil gandeste decat sa te gandesti la ceea ce ar fi util pentru utilizatori.
Zilele trecute povesteam despre RIPE si whois. Si hai sa spun personajelor carora le vorbeam sa intre pe site-ul de la ripe. Din greseala, in loc de ripe.net le-am zis ripe.org . Ia ghiciti ce-i pe ripe.org :-S Mda, nici eu nu stiam. Oare cei de la RIPE stiu ?
.ro este un TLD al carui management este facut intr-un mod comunist si birocratic. Asta stiam de mult ascultand pareri de pe ici si de pe colo, insa acum, pot sa fac un rezumat al aspectelor care ma enerveaza cel mai mult, pe baza a ce am vazut eu de-a lungul timpului:
- orice om din lumea asta isi poate lua un domeniu .ro . De ce ? Un domeniu .ro ar trebui sa fie alocat cuiva cu cetatenie romana sau unei entitati comerciale cu sediu juridic in Romania.
- domeniile se dau pe “viata”. Pe viata cui ? Sunt o multime de domenii blocate, inactive sau pur si simplu nefolosite de ani de zile. Nu mai vorbesc ca este o prostie din punct de vedere economic.
- domeniile noi se creeaza manual. Chiar si atunci cand platesti online, cu cardul.
- domeniile cumparate prin parteneri ROTLD cred ca au parte de acelasi tratament. Un domeniu cumparat (si platit) intr-o zi de weekend, intra in faza de procesare abia in prima zi lucratoare. Intre timp nici macar nu este blocat. Da, asta inseamna ca altcineva poate plati acelasi domeniu, in alta parte. Ce se intampla in prima zi lucratoare … mister !
Punctele pozitive sunt asa:
- domeniile se pot plati cu cardul (chiar daca sistemul e abia implementat);
- modificarile efectuate online sunt in timp real (cele cateva secunde necesare propagarii update-urilor nu se pun).
Mai e ceva de adaugat ?
Zilele astea tocmai mi-am refacut statia de lucru si testam de zor ultimul Slick Edit (varianta pentru Mac). Cum in ultima vreme am tot cumparat aplicatiile care mi-au placut, m-am gandit ca n-ar fi rau sa-mi cumpar licenta de SlickEdit. Toate bune si frumoase, pana am ajuns la pret: o licenta pentru un singur utilizator si pentru un singur sistem de operare costa nu mai putin de 300 $ (trei sute de dolari). WTF ? 300 de dolari ?! Pentru un editor (e drept, bun) ? Neee ..
PS: sistemul de operare nu conteaza la pret: si varianta de Mac si cea de Linux sunt la acelasi pret
In 2011 au murit:
- Paul Baran – cel care a pus bazele tehnicilor de packet switching
- Willard Boyle – inventatorul CCD
- Steve Jobs – omul din spatele succesului Apple
- Dennis Ritchie – autorul limbajului C si co-autor al sistemului de operare UNIX
- John McCarthy – autor al limbajului LISP si membru marcant al comunitatii de Inteligenta Artificiala (AI)
Si 2011 inca nu e gata :-S
Post bazat pe “2011: The dark year of IT ?“