De Sezon

Posted in Regula 0, Stand-up philosophy on December 25th, 2011 by Mihnea

A venit iar vremea retrospectivelor. Faptul ca Pamintul a mai dat o tura in jurul Soarelui de la ultima recapitulare transforma fiece cetatean intr-un Captain Hindsight inarmat cu concluzii, rezolutii si linii care se cer trase. Clisma de sfirsit de an pune punct Trecutului si-l pregateste pe om pentru Viitor.

Pai daca-i vorba de catharsis, catharsis sa fie. Oricum, nu pot rupe tacerea stinjenitoare ce se lasase pe-aci cu un articol despre micile scapari ale vreunui miner sau retorica mefecista a vreunui militian. Nu. Voi arunca o privire patrunzatoare asupra evenimentelor din 2011 si voi decerna premiile si calificativele meritate de catre fiecare entitate implicata. Deci:

Muie Silviu Ardelean

Pentru ca merita.

Muie Codexpert

Aceasta muie se confera pentru inca un an de dezinformat incepatorii, raspindit semi-adevaruri despre programare si dezvoltat un mediu dulceag-caldut in care minerii mici sa poata ecloza, iar cei mari sa poata creste si mai mari si improsca internetul cu puroiul lor cranian. Se acorda si premiul special Radio Erevan pentru efortul Gardianului Ovidiu de a-si pune Intrebarile Frecvente pe care nu le intreaba nimeni.

Muie Apple

Anul asta s-a lansat XCode 4, care e si mai abject decit 3. Fanboii l-au laudat pentru ca seamana mult mai bine cu iTunes si iti zice ce face intr-un control ce aduce a LCD. Intr-adevar, de mic imi doream ca IDE-ul meu sa semene cu un casetofon de masina. In continuare nu poti naviga intre surse cu tastele, crapa de 2-3 ori pe zi, refuza ocazional sa vorbeasca cu telefonul si trebuie sa restartezi tot, se sperie daca vede provisioning profiles facute de 3 etc.

Muie Google si Samsung

In programare exista un semn universal recunoscut al esecului absolut: sa incerci sa faci ceva ce au facut Apple si sa-ti iasa mai prost. Acest semn era prezis prin carti, dar pina de curind nimeni nu reusise sa atinga nivelul necesar de prostie. Google au ridicat manusa si au adus pe lume sistemul de operare Android.

Experienta dezvoltarii pentru Android face ca programarea pe iOS sa para un masaj erotic prestat de Scarlett Johansson. Nu numai ca pe Android trebuie sa scrii Java, acest limbaj conceput de si pentru copiii cu sindromul Down rezultati din relatiile incestuoase intre pigmei retardati; actul creator se petrece in Eclipse, un fel de editor de text care stie vag ca lucrezi la un proiect compus din mai multe fisiere, dar nu e niciodata sigur care sint fisierele alea, ce sa faca ca sa le compileze si cind.

Peste Eclipse vine Android SDK care este compus dintr-un emulator inutilizabil de incet si un plugin de Eclipse care la fiecare linie de cod da cu zarul sa vada daca sa crape sau nu, si in majoritatea cazurilor pierde. Au fost zile in care Eclipse a crapat de 20-30 de ori, fara a incerca lucruri avansate gen adaugat fisiere noi in proiect sau debug. Uneori cind il repornesti dupa ce crapa refuza sa compileze proiectul, spunind ca nu mai gaseste SDK-ul, ca unknown type java.lang.Object si alte d-astea. Atunci il mai restartezi de citeva ori, ca pina la urma o ia.

Lasind la o parte micile scapari ale mediului de dezvoltare, API-ul Android e facut de niste imbecili colosali. De exemplu, proprietatile si layout-ul controalelor se definesc in niste XML-uri. Unele chestii se pot seta si din cod, dar majoritatea nu, asa ca daca vrei sa faci chestii la runtime, Google iti recomanda sa sugi pula. Nimic nu e unde te astepti sa fie, dar nu pentru ca ar fi intr-un alt loc, ci pentru ca pur si simplu nu exista. Update-urile minore, de exemplu de la 3.1 la 3.2, iti distrug aplicatia pentru ca nimic nu mai merge ca inainte. Pentru a te ajuta sa suporti versiuni multiple, aplicatia iti crapa daca pui in XML-urle pulii ceva ce nu exista in versiunea pe care rulezi; din cod ai putea detecta versiunea si lua atitudine, dar cum ziceam, de acolo n-ai acces la proprietatile care conteaza, deci sugi.

Android este open source, adica in loc sa faca ceva care sa mearga, au luat de pe net chestii scrise de altii, pe principiul ca daca sint pe net, sigur sint bune. Google, fiind un startup cu banii numarati, nu isi permite sa dezvolte un decoder video, de exemplu. E mult mai bine sa foloseasca la maxim potentialul unui alt produs al lor, care chiar merge, pentru a localiza cu precizie o pagina care contine cuvintele “video decoder” si a downloada ce cod se gaseste pe acolo. Da, mai crapa aplicatia sau tot device-ul cind se termina stream-ul, nu merg chestii de baza gen schimbat aspect ratio in timp ce cinta, iti ia 3 versiuni majore sa adaugi suport pentru stream-uri live etc.; dar ce alternative aveai? Google nu crede in reinventarea rotii, daca se gaseste deja pe net una patrata facuta de un mester faiantar.

La tot acest haos se adauga si producatorii de hardware, care customizeaza jegul in functie de bunul plac si posibilitatile siliconului propriu. Campionii sint Samsung, care par sa-si recruteze programatorii exclusiv din rindurile indienilor care liciteaza 5 dolari la orice proiect pe rentacoder. In momentul in care incerci sa faci un player video pe un device Samsung incepi sa-ti doresti bug-urile simple, cinstite, pe care le vedeai pe alte device-uri, gen butoane care uita ce imagini au cind schimbi orientarea, sau controale care isi uita pozitia cind apare tastatura on-screen.

Google e privit ca un fel de Mecca sau Mensa al tehnologiei, unde procesul de angajare permite accesul doar celor mai stralucite minti, unde lucreaza Knuth (ala care scrie carti pentru inaltat monitorul, ca sa prinda si minerii contextul), unde primesti mincare gratis la prinz si-ti cultivi creativitatea. De la astia te astepti sa inteleaga ca daca vrei un lucru, trebuie sa-l faci. Mi se strepezesc unghiile cind trebuie sa-i recunosc cite un merit lui Apple, dar aia si-au facut singuri software-ul si hardware-ul si merg. Au inteles chiar si ca daca vrei IDE, trebuie sa-ti faci, ca dejectiile open source existente sint inutile; asta nu le-a mai iesit si au ajuns tot la o dejectie, dar macar au incercat. Google au incercat sa faca din Linux, gstreamer si Eclipse bici. Firma de programatori web, ce sa le ceri?

Va dati seama cum era Chrome daca nu le facea Apple engine-ul de HTML?

Muie Microsoft

Acum vreo 9 ani, Microsoft au zis ca C++ nu-i mai satisface intelectual si ca daca totusi vrei din C++ UI mai smecher sau feature-uri gindite pentru aplicatii web (dar nu aplicatii web propriu-zise), trebuie sa folosesti noul si stralucitorul Managed C++. Viitorul fusese trasat.

Vreo 2 ani mai tirziu, putinii oameni care au folosit mizeria au aflat ca e cazul sa se reorienteze, caci Stapinirea a infierat Managed C++ ca “deprecated”. La  schimb a fost oferit C++/CLI, care e net superior. Asta chiar e viitorul, credeti-ne de data asta!

Anul asta, Microsoft a anulat viitorul si a declarat inceputul Renasterii C++. C++/CLI nu mai e bun, aplicatiile se vor scrie de acum incolo nativ, in C++. Nu mai poti sa deschizi o pagina de MSDN fara sa ti se spuna asta. Totusi, cind te uiti prin exemplele de cod, numai C++ nu vezi. De fapt este C++/CX, o noua muie data de Microsoft limbajului. Dar sa vedeti, de data asta nu e ca data trecuta. Nu, nu, nu, asta chiar e viitorul, juram pe rosu. Ce, am mai zis asta? De ce sa privim in trecut, cind avem atita viitor de construit? Voi investiti in scris cod C++/CX si faceti-va aplicatiile sa depinda de el, ca noi sigur nu ne razgindim CEL PUTIN un an de acum incolo. CEL PUTIN!

Pentru a completa jignirea, evanghelistii o tot baga p-aia cu “at the interface” sau “at the border”. Aparent, C++/CX trebuie folosit doar cind vrei sa vorbesti cu OS-ul, si poate fi izolat acolo. Intre 99% si 99.9999% din aplicatie (in functie de evanghelistul cu care vorbesti) poate fi scrisa in C++ normal, si doar foarte, foarte rar vei recurge la un virf de /CX, drept condiment. In realitate, se vor scurge tipuri gen String din C++/CX in restul aplicatiei, sau vei muri de plictiseala facind conversii peste tot. De asemenea, e posibil sa constati ca logica de UI reprezinta, totusi, un pic mai mult de 1% din codul aplicatiei. Aceste lucruri nu-i preocupa pe evanghelisti, pentru ca ei nu scriu cod si probabil nici n-au scris vreodata.

Muie Digital Video

Compresia video nu-i un subiect accesibil minerilor. Conceptual e o chestie simpla, dar in practica sint miliarde de detalii, scenarii, profile si alte mui, astfel incit dureaza ani intregi sa scrii un codec modern. Asta este, evident, o mare timpenie.

Minerii sint perseverenti. Daca nu-i lasi sa scrie codecuri, se vor apuca sa faca containere. In fiecare zi se gaseste cite un bou sa remarce ca toate containerele sint de cacat (ceea ce e adevarat) si sa-si faca propriul container, convins ca va rezolva toate problemele (ceea ce e jenant). Unii din astia capata avint si sustinere, si astfel apar chestii ca MKV.

Rezultatul este ca n-ai nici o sansa sa faci un program de cintat sau procesat video. Inainte de a putea sa decodezi primul frame, trebuie sa ajungi la el, desfacind containere care mai de care mai ridicole, produse de programe imbecile scrise de oameni cu interpretari foarte liberale ale standardelor si specificatiilor. Daca totusi reusesti sa ajungi la frame-uri, problema se repeta, doar ca sint si mai multe variabile si e infinit mai mult loc pentru interpretari, bug-uri si alte inovatii. Sigur, poti incerca sa folosesti o biblioteca, cum ziceam mai sus ca au facut Google, dar nu faci decit sa schimbi un cosmar cu altul.

Uneori, printre aceste cacaturi digitale se mai strecoara cite o relicva analogica, gen frame rate-ul de 29.(970029) din NTSC sau codurile de Widescreen Signaling. Nu v-as dori vreodata sa ajungeti sa cititi specificatii scrise de oameni crescuti printre osciloscoape si condensatori.

Muie C++

Anul asta a fost definitivat in sfirsit noul standard C++, prilej de mare bucurie pentru unele paturi sociale care nu se descurcau prea bine nici cu vechea forma a limbajului, dar care vor putea propune acum inlocuirea enum-urilor si cu lambda-uri, nu doar cu vectori si structuri. Cu tot efortul, limbajul tot nu are un ABI si tipurile din STL tot nu pot fi folosite intr-un lib sau intr-o interfata. E induiosator cum se lauda Bjarne ca C++ este un limbaj excelent pentru construit biblioteci, dar eu cred ca e putin penibil ca nu poti distribui bibliotecile alea in forma binara. Uneori am impresia ca lumea e formata doar din freetarzi si ca e un grav faux pas sa afirmi ca vrei sa cistigi bani programind.

Din cauza ca nu exista ABI, exista COM. Din cauza ca COM este oribil si greoi, se nasc jeguri ca C++/CX.

Muie 2011

Tendintele continua: e din ce in ce mai greu sa programezi ceva, pentru ca OS-urile, bibliotecile, IDE-urile si limbajele ti se opun mai indirjit ca niciodata. De aceea, 2011 merita multa muie.

 

Tags: , , , , , , , , , , , , , , , , , ,

Coming out

Posted in Slagare internationale, Stand-up philosophy on August 25th, 2011 by Mihnea

In sfirsit Apple au decis sa faca pasul cel mare si sa iasa din closet. Noul lor CEO e gheu pe fata, nu pe ascuns ca Steve. Asteptam cu interes versiunea aniversara XCode 5 unde vei scrie cod printr-o interfata cum aveau strumfii xenozoofili cu inorogii in Avatar, doar ca in loc sa-ti impletesti pleata cu coada calului, iti vei da cu iLube si-ti vei baga in cur un iDildo. Roz.

La cit mai multe puli in cur!

 

Tags: , , , , , , , , , , , , , ,

Teorema stergerii cu rest

Posted in Codare cu premeditare, Slagare internationale on April 13th, 2011 by Mihnea

Am stabilit deja ca lista inlantuita e un subiect delicat. Este timpul sa aratam ca nu doar Ovidiu “MVP” Cucu are probleme cu dinsa, ci si aia carora el le pupa bombeurile au mici dificultati in intelegerea acestei structuri de date fenomenal de complicate. Sa urmarim pentru inceput un scurt material motivational in care se incearca stergerea unei configuratii dintr-un proiect in Visual Studio 2008 (nu stiu de ce se misca in reluare, muie youtube sau muie ffdshow):

Asta e, nu s-a sters. Lucrurile devin insa cu 57% mai interesante daca incercam sa stergem mai multe configuratii deodata:

Acum s-a reusit stergerea, dar ar fi fost un pic mai bine daca ar fi sters ce i-am zis sa stearga, nu ce doream sa pastram (de asemenea gasesc interesant cum in dropdown a ramas selectat “Debug2011”, desi cind il deschizi nu e acolo). Care sa fie explicatia?

Pai e destul de simplu, de fapt. Proiectul are doua configuratii care se cheama Debug5, doua Debug6 si asa mai departe, cite una pentru fiecare platforma (Win32 si x64). Acest lucru se poate observa cu ochiul liber in vcproj, unde nu exista Debug5, ci Debug5|Win32 si Debug5|x64. Mai departe in arhitectura lui VS, o configuratie trebuie sa existe in toate platformele – nu poti, de exemplu, sa ai Debug5 doar in Win32. Orice programator care a folosit vreodata platforme multiple in VC stie asta. Indianul care a implementat stergerea nu stie. Cind apesi pe “Remove”, el cauta prima configuratie care se cheama “Debug5” si o rade. In felul asta se sterge doar aia de Win32, dar cind deschide din nou dropdown-ul, o gaseste p-aia de x64 si o afiseaza acolo, iar acum proiectul e intr-o stare invalida, cu o configuratie care nu exista in toate platformele. Workaround-ul este sa stergi o configuratie, sa inchizi dialogul de edit, sa-l deschizi din nou si s-o stergi inca o data. In felul asta se sterge si Debug5|x64, si proiectul e utilizabil din nou.

Daca te aventurezi sa stergi mai multe configuratii de-odata, ca in al doilea filmulet, se evidentiaza o noua latura a retardarii indiene, aceasta ruda karmica a retardarii ardelene. Boul sterge configuratiile dupa index, nu dupa nume. Daca stersul propriu-zis i-ar fi mers, asta n-ar fi fost o problema. Din pacate insa, deoarece configuratia ramine acolo cind se manifesta prima parte a incompetentei, se fut maparile intre indecsi si nume, asa ca atunci cind dai sa stergi Debug6, se sterge de fapt altceva (jumate de altceva, mai exact). Mai departe retardarea 1 se compune cu retardarea 2 intr-un fel sublim, astfel incit tu dai sa stergi 6 din cele 8 configuratii, dar de fapt se sterg doar 3, printre care si singurele doua pe care vroiai de fapt sa le pastrezi.

VC are acest bug de la 2005, de cind a fost introdus noul configuration manager, cu platforme si cacat. De atunci au iesit 2005 SP1, 2008, 2008 SP1 plus o intreaga pleiada de hotfix-uri, dar nimeni nu s-a ostenit sa invete cum functioneaza de fapt configuratiile si cum se cauta intr-o lista. Bug-ul s-a rezolvat in sfirsit in 2010, pacat ca ala e inutilizabil gratie rescrierii editorului in dotniet (plus alte “goodies”, gen gunoiul ala de MSBuild).

Sa trecem acum in tabara adversa. Aparent exista o corelatie intre retardare si softurile de instalat alte softuri. Cel mai idiot lucru scos vreodata de Microsoft este MSI (chiar luind in considerare Songsmith si reclama pentru el). Cel mai idiot lucru scos de Apple este PackageMaker, echivalentul hipsteristic al lui MSI. Iata ce face PackageMaker cind vrei sa stergi un target din installer:

Pentru asta n-am o explicatie, caci nu inteleg cum functioneaza mintea oamenilor care programeaza pentru Apple. Cert e ca atunci cind stergi ceva, reuseste sa amestece restul target-urilor si chiar sa lase un fisier orfan, atasindu-l de root-ul proiectului. As dori sa mentionez ca in mod normal n-ai cum sa atasezi fisiere direct acolo, folosind UI-ul lui.

Workaround-ul este sa editezi proiectul de mina, caci este tinut in XML. In XML-uri, mai exact. Cite 2 XML-uri pentru fiecare target, plus un XML mare, to rule them all (in speta, 71 de fisiere in proiectul din film). Si aceste XML-uri sint scrise pe o singura linie, cum mentionam in post-ul despre XCode. Si numele lor conteaza, fiind prefixate cu un numar. Si alea in care zici ca vrei sa instaleze tot ce-i intr-un director contin si numele fisierelor din directorul ala, la momentul la care ai facut proiectul. Care nu folosesc la nimic, pentru ca daca adaugi un nou fisier intre timp, se va copia, asa cum iti doresti, dar nu va fi trecut in XML. Si asa mai departe, in pula mea.

Ca sa fiu perfect obiectiv ar trebui sa expun si o muie dintr-un IDE de Linux. Gluma asta se scrie singura, va las pe voi sa va imaginati ce vreti.

Oricum, ce vroiam sa spun e ca le doresc epidermoliza buloasa alora care-s responsabili de chestiile astea. Sau munca silnica pe viata in mina cu Silviu Ardelean ca team leader.

Update: am elucidat si misterul PackageMaker. Si aici retardarea este usor de inteles: gunoiul are un index.xml in care, odata ce-l formatam sa nu mai fie tot pe o singura linie, putem vedea chestii de genul:

<choice title="8.5 plug-in" id="choice210">
	<pkgref id="com.nextlimit.realflowPluginForMaya.realflow.pkg"/>
</choice>
<choice title="2008 plug-in" id="choice211">
	<pkgref id="com.nextlimit.realflowPluginForMaya.realflow-1.pkg"/>
</choice>
<choice title="2009 plug-in" id="choice212">
	<pkgref id="com.nextlimit.realflowPluginForMaya.realflow-2.pkg"/>
</choice>

Mai jos in fisier scrie si:

<item type="file">01realflow.xml</item>
<item type="file">02realflow.xml</item>
<item type="file">03realflow.xml</item>

Observam deja un design fabulos, caci corespondenta dintre “choice-urile” alea si fisierele in care se spune ce contin se face pe baza ordinii. Nu s-a putut pune nodul ala de item sub nodul de choice, sau ceva. Mai departe, daca privim in 01realflow.xml, vedem ca e scris package name ala, ba chiar are si un UUID dupa care ar putea fi identificat:

<pkgref spec="1.12" uuid="A23E47A9-3AB3-4619-847F-2104601981F9">
	<config>
		<identifier>com.nextlimit.realflowPluginForMaya.realflow.pkg</identifier>

Atingerea de geniu este ca muistul tine package name-urile alea acolo doar de decor. De fapt el se asteapta ca in primul fisier sa fie definit intotdeauna pachetul “com.nextlimit.realflowPluginForMaya.realflow.pkg”, in al doilea sa fie ala cu -1 in coada, in al treilea ala cu -2 etc. Nu conteaza ce scrie de fapt in fisier, iar UUID-ul ala nu e folosit la nimic.

Deci ce se intimpla cind dai click dreapta remove? Pai simplu, indianul care a implementat functia de sters nu stie ca numele sint hardcodate. El sterge nodul din XML, sperind ca potriveala se va face dupa nume. Din cauza ca se face dupa ordine, totul aluneca cu o pozitie in jos, deci pachetul de 2009 ajunge in choice-ul de 2008, ala de 2010 in choice-ul de 2009 etc. Primul pachet ramine orfan, iar ultimul choice ramine gol.

Solutia e sa stergi de mina XML-urile corespunzatoare target-urilor de care vrei sa scapi, dupa care sa iei la rind toate XML-urile ramase si sa cirpesti package name-urile alea, ca sa fie consecutive. Apropo, nu eu am dat numele alea care-s toate la fel, sint generate de el pe baza numelor fisierelor din target-uri, iar daca le schimbi se fute.

Uimitor. Fabulos. Nici la scoala ajutatoare nu vezi asemenea “design”. Ala care a facut cacatul asta n-a inteles nimic din programare.

Cum ziceam, epidermoliza buloasa.

Tags: , , , , , , , , , , , , , ,

Despre simularea si disimularea creierului

Posted in 112, Premiul n00bel on April 8th, 2011 by Mihnea

Motto-ul site-ului scientia.ro este “Stiinta pe intelesul tuturor”. Pe bune, chiar al tuturor? Si al astora? Si al lui Silviu Ardelean? Din ce s-o fi tragind convingerea fondatorilor ca oricine poate intelege “stiinta” – sa fie noblete, naivitate sau comunism? Sa fie oare posibil sa prezinti “stiinta” asta (orice ar fi ea) intr-un asemenea mod incit s-o poata pricepe si cea mai intunecata minte de miner?

Din fericire putem gasi raspunsul negativ la aceasta ultima intrebare pe forumul cu care este inzestrat scientia.ro, unde care cei ce se simt in target – “tuturorii”, daca-mi permiteti – ne arata ce-au inteles si dau glas intrebarilor ce le framinta starea de veghe. Sa-i dam cuvintul lui Sorin_dan84:

Salut. Am vazut de curand o stire despre computere uriase care pot simula clima de pe pamant, si alte chiestii(chiar formarea unei galaxii)…ce spuneti in cati ani credeti ca se poate simul toata viata de pe pamant?     Si de aici ideea unor regizori de filme sf., gen Matrix.

Si daca ar fi creat un simulator al Terei, plecand de la tehnologia actuala(punand in acest simulator cam toate cunostintele stintifice actuale si apoi “furand” noi descoperiri stintifice de la simulator?…..sa zicem ca in simulator 1 an=cu o secunda la noi.
Ar fi un computer cat o metropola…un oras calculator?, daca nu pun in aplicare nanotehnologia.

In caz ca n-ati inteles pentru ca inca asteptati sa se inchida paranteza aia, propunerea lui Sorin este ca cercetatorii sa simuleze niste mini-cercetatori si doar sa se uite ce mini-cerceteaza aia. Eu imi permit sa-i propun o chestie si mai simpla, pe care am vazut-o intr-un film: pentru a obtine ORICE, te apuci si faci un robot care produce acel ORICE, dar de asemenea poate calatori inapoi in timp. Nici nu termini bine de gindit cu gindul la aceasta idee, ca robotul va si aparea linga tine cu obiectul dorit, ca doar te-ai gindit sa-l faci, deci l-ai facut, deci el s-a intors in timp la tine. Nici nu mai e nevoie sa-l faci.

Simtind ca a dat peste o idee de valoare, Sorin continua:

Astept pareri de la specialisti in domeniu….sau poate am dat o idee de proiect, care ar putea fi impartasit(japonezilor sau americanilor – ca la noi e criza ) pt. accelerarea stiitei ……Multumesc.

Cine se baga la implementarea proiectului? Oportunitatile ca asta nu cresc in copaci, o singura data in viata ai sansa sa-ti dea cineva o asemenea idee (daca o ai si p-aia). Ar fi pacat sa dati cu piciorul. Nu faceti ca florin_, care s-a impotmolit in calculele unor alti “specialisti”:

Acum vre-o multi ani in urma citisem undeva ca specialistii in domeniu au venit cu cea mai acurata prezicere a cite PC-uri de pe vremea aia (cam Pentium III la 0.5-1GHz) ar fi necesare sa faca toate operatiunile pe care le face creierul uman (toate functiile si cele constiente si cele inconstiente).

Ei bine cantitatea de PC-uri necesare ar fi  asa de mare ca nu ar fi  incaput in intreg universul vizibil de azi.

Ei bine, eu as propune pur si simplu sa simulam un univers mai mare, in care sa incapa toate PC-urile necesare pentru a simula universul nostru mai mic. Nu stiu daca propunerea mea e fezabila, caci nu ma pricep la calcul polinomial cu n arbitrar:

Explicatia lor tinea de faptul ca sinapsele si retelele neuronale pot executa calcul polinomial cu n arbitrar de mare in timp linear (cu alte cuvinte retelele neuronale ar putea rezolva probleme ce necesita xn operatii intr-un timp proportional nu cu xn ci cu x1 (linear)).

Noroc ca a venit Dendros sa le deschida si mai mult orizonturile:

E doar o parere. Dar daca e adevarata afirmatia lui florin_, suntem departe de a atinge intregul potential al creierului sau poate nu-l vom atinge niciodata pe deplin, fiindca ar putea fi nelimitat, doar sa avem timp suficient.

Luati aminte, daca ai suficient timp, poti sa numeri pina la infinit si poti atinge limita potentialului nelimitat. Totusi trebuie sa recunoasteti ca omul are dreptate, participantii la discutie nu au prea multe sanse de a atinge vreodata pe deplin potentialul unui creier.

Subiectul neuronilor si al retelelor pe care acestia le formeaza apare frecvent in discutiile de pe scientia.ro. Este si normal, caci oamenii care fac diferenta nu se multumesc cu status quo-ul, ci incearca tot timpul sa obtina ceea ce n-au. tavy ne explica cum sta treaba cu translatoarele automate, aceste unelte ale diavolului ce-l sperie pe Silviu Ardelean:

Traducerile nu sunt chestiuni exacte, de multe ori sunt subiective și de multe ori nu se pot face sau dau aberații mari dacă sunt scoase din context. Din acest motiv, la traduceri se pretează mai bine rețelele neuronale în dezavantajul calculului algoritmic.

Stiu ca acum sinteti pe cale sa va inlocuiti toate calculele algoritmice cu retele neuronale, dar mai zaboviti oleaca. Inainte de a te arunca cu capul inainte in truda, e bine sa te intrebi daca meseria pe care incerci s-o practici chiar exista, asa cum face XploreDesign in thread-ul Meseria de programator – mit sau realitate:

Una dintre cele mai căutate profesii  este cea de programator. Sunt foarte multe motivele care te-ar putea determina să optezi pentru o asemenea opțiune, dar cel mai important, după părerea mea, este faptul că această profesie îți oferă o deschidere internațională

Ce coincidenta, si ing. Boata Cristian zice la fel.

Simpla cunoaștere a unui limbaj de programare, sau a unei tehnologii, nu iți poate asigura statutul de programator, mult dorit. E nevoie de mult mai mult. E nevoie de experiență, e nevoie de cunoașterea mai multor limbaje de programare sau de scripting, e nevoie de cunoașterea celor mai noi tehnologii precum și de un portofoliu consistent de lucrari care să te diferențieze de ceilalți concurenți și, un lucru foarte important, e nevoie de ”atitudine” ”pro-to-do”.

Atitudine? Protodo? Portofoliu de lucrari? Inseamna ca Silviu si-a asigurat “statutul de programator virgula mult dorit”. Unde mai pui ca are si inteligenta emotionala…

Afirmatiile provocatoare ale lui Xplorica au alimentat nesiguranta alle_csandr_ei, care n-a mai rezistat si a pus intrebarea ce statea pe buzele tuturor:

As avea si eu o intrebare cat de bine este sa fii programator? ???in comparatie cu alte meserii ma refer

Nici un post despre imbecilitate nu poate fi complet fara un citat din viorel2005, singurul om in viata a carui retardare iese in evidenta chiar si pe codexpert. Sa vedem ce are el de zis despre… pula mea, n-am inteles. Poate gasiti voi vreo legatura intre propozitiile din comunicarea sa, sau macar intre cuvintele din interiorul propozitiilor:

In prima versiune a cartii lui Charles Petzold de programare in Windows, era o propozitie despre niste “eroi necunoscuti” care au pus bazele sistemului Windows(chiar daca a fost inspirat de la Apple, totusi el este un succes comercial). Acum hardware-ul dicteaza totul si apoi software-ul. De aceea nu exista tablete Windows. Si atunci se ajunge intr-o directie managed. Legea lui Moore va limita puterea lui C++.

Cine sloboz e Moore asta, ca eu nu l-am votat?

LE: inca una repede, ca am dat de ea dupa ce am postat. Din putul gindirii numit wikipedia in romana aflam ce-i ala un “systems programmer”:

Programatorul de sistem este persoana care se ocupă de instalarea / generarea și întreținerea sistemului de operare furnizat de producătorul unui calculator pentru a-l adapta la cerințele utilizatorului. Sistemul de operare este frecvent distribuit pe un suport de date într-o formă standard, conținând un maxim de funcțiuni. Din această formă standard programatorul de sistem poate instala sau genera un sistem de operare concret, potrivit configurației hardware individuale și nevoilor utilizatorului.

Zic ca merita un loc caldut in panoplia esecurilor wikipedofile, linga articolul despre CoBra. Tu cind ti-ai generat ultima oara Windows-ul?

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Stare avansata de Tutorialism.

Posted in Codare cu premeditare, Premiul n00bel on March 30th, 2011 by jos8cal

El este Marian Pop si este intr-o relatie stabila cu un Mac OS X de peste 6 ani. Cind intr-o relatie anii devin unitatea de masura a tolerantei, este evident ca secretia de feromoni a crescut proportional cu durata relatiei.

Unii dintre voi or sa spuna ca o relatie sta in picioare datorita fundamentului de cunostinte comune cu care ne-am impaunat reciproc de la primele intilniri. Ei bine, nu! Relatia daca ar fi sa o reprezentam 2D ar fi o linie pe orizontala, nu pe verticala, deoarece “fundamentul de cunostinte comune” se transforma in Obicei, iar acesta stim cu totii ca e neplacut iar neplacerea se reprezinta pe orizontala. Este o enumerare. De ce credeti ca puscariasii isi numara zilele tragind linii verticale, ca mai apoi sa le taie cu una orizontala? Pentru a exemplifica moartea sperantei si nasterea Obiceiului.

Bun. Acum ca avem clar stabilite bazele vietii in doi, sa trecem sa mulam aceasta schema metafizica pe viata familiei Marian Pop OS X.

Marian se considera un geek datorita pasiunii lui pentru computere dusa la limite extreme. Dupa cum vom vedea mai jos, computerul nu pare insa sa-si aduca aminte de unde-l stie pe Marian.

El s-a decis sa programeze in C/C++, PHP si MySQL, deci este evident ca are nevoie de un Mac, ca PC-ul e pentru jocuri. S-a oprit la primul bordel Apple si a platit pentru un Mac OS X, toate serviciile incluse. G4. MILF. XCode.

Dupa cum am vazut, daca vrei doar sex de la un Mac, vei avea parte de un gay porn numit XCode. Cind esti in schimb intr-o relatie cu Mac-ul, secretia mare de feromoni emisa de dinsul va face ca experienta cu XCode sa-ti para o sansa unica in viata.

Odata ajuns applosexual, Marian a inceput sa-si filmeze orgiile cu XXXCode si sa le puna online sub forma unui Decalog speram noi.

Primul Film. Introducere in C++.

Aici se poate observa cum folosirea cuvintelor “variabile” si “using namespace std” l-ar face pe orice incepator sa se urce pe pereti de placere, neintelegind nimic dar incercind sa simta apasarea tastelor care nu se apasa pe tastatura de Mac.

Al doilea film. Structuri conditionale in C

Vizibil stresat din cauza unui algoritm, Marian isi face totusi timp sa readuca in atentia publicului recurenta tema a variabilelor. Aflam astfel ca variabilele sint niste cutii in care stocam date. Acum mai ramine sa aflam ce sint alea date. Climaxul acestui film incepe la minutul 6, cind Pauza devine subiect principal pentru 35 de secunde. Mai aflam ca

for (int a=0; a>0; a++)

il incrementeaza pe a cu a.

Daca Gaddafi si-ar fi luat gindul pentru o secunda de la lumea modei si ar fi deschis XCode, ar fi propus (te pup Silviu) ca si Marian urmatoare alternativa la scris numere pe ecran:

int a;
cin >> a;
for (int i=a; i > 2; i++){
	cout << i;
	break;
}

sau

while (a == 2){
	cout << a;
	break;
}

Al treilea film. Functii in C++.

Sau cum sa nu faci cout << 40;

int fun(int n){
	n = n + 20;
	return n;
}

int main(){
	int n=20;
	int i;
	for (i=n; i>0; i++){
		cout << fun(i);
		break;
	}
	return 0;
}

Al patrulea film.

Aici aflam ca pointerii sint ca niste muschi si trebuie sa facem zilnic exercitii pentru a-i mentine in forma. Si aici Pauza primeste un rol in scena in care Marian cauta punctul si virgula pe tastatura lui Apple.
Mai aflam ca putem scrie cod oriunde vedem loc liber in pagina, asa ca pe ciorna, si mai tirziu il copiem unde trebuie. Cind te trece creativitatea trebuie sa ai un loc liber sa o depui in cel mai scurt timp.

Disclamer: Nu a fost ranita nici o masina in timpul efectuarii cercetarilor pentru acest material. In schimb se pare ca alti oameni au fost raniti in timpul orgiilor familiei Pop OS XXX.

PS. In caz ca doriti autografe, codexpert.ro il are invitat permanent in platou.

PS2. Si da, ca si pe Silviu Ardelean sistemul de invatamint romanesc l-a avut la cirma si pe Marian Pop.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

XCode

Posted in Slagare internationale on February 17th, 2011 by Mihnea

Steve Jobs are cancer la pancreas deoarece o multime de programatori au vrut sa-si bage pulile in ficatul lui si unii din ei au nimerit pe linga. Probabil Steve nu e direct de vina pentru faptul ca XCode este un puroi revoltator, dar oftica e mult mai spornica atunci cind o poti canaliza in directia unei persoane si Steve e usor de nimerit in pozitia fruntasa in care s-a postat. Cancerul nu este total nejustificat insa, caci rolul de Führer al Nationalsozialistische Hipsterisch Arbeiterpartei ii confera lui Steve dreptul de a-i spinzura cu coarde de pian pe cei care au adus pe lume abominatia; faptul ca el nu-si exercita acest drept este o insulta la adresa intregii omeniri de la Charles Babbage incoace.

Pentru a intelege cum a putut lua nastere XCode, acest abject esec al spiritului uman, trebuie sa examinam intii contextul in care a fost construit el. Vom vedea ca soarta lui a fost pecetluita inca inainte de a se scrie prima linie de cod, dar ca maimutele care au lucrat la el nu s-au multumit sa mosteneasca imbecilitatile platformei pe care cladeau, ci au dus stafeta prostiei pe noi culmi.

Contextul lui XCode este OS X. In Finder (echivalentul hipsteristic al lui Windows Explorer, pentru neinitiati), tasta pentru a deschide un fisier selectat nu este Enter, ci Cmd+O. Enter face rename. Articolul asta s-ar putea incheia aici. Evident n-o sa se incheie, dar macar discutiile din magazinele Apple intre clientii potentiali si vinzatori ar trebui sa se sfirseasca in acest mod.

– Cum fac rename la un fisier?
– Apesi Enter.
– Muie.

Este clar de ce cred Apple ca au facut asta cu Cmd+O: pentru consistenta. In alte programe, “Open” este Cmd+O, deci sa fie si in Finder. Motivul real pentru care au facut asta este la fel de clar: pentru ca sint retardati. Pentru rename cu enter nici macar nu exista un motiv inchipuit, exista doar retardarea.

Fanboii vor spune ca asta cu tastele e doar o preconceptie a cuiva care vine dintr-un alt mediu. Pentru ei am exemplul redimensionarii. In OS X, ferestrele se pot redimensiona doar din coltul din dreapta-jos. Daca ai un geam in dreapta ecranului si vrei sa-l faci mai lat, intii trebuie sa-l tragi mai la stinga, dupa care sa-l maresti. In general n-o sa stii cit de mare vrei sa-l faci, deci n-o sa-l tragi suficient de mult in stinga si n-o sa ai loc sa-l faci cit de mare vrei, asa ca o sa-l mai tragi un pic, si o sa-l mai maresti un pic. Aparent, un test cu un focus grup a relevat faptul ca utilizatorii sufera un atac de panica daca ii lasi sa redimensioneze geamurile din orice colt. Eu cred ca de fapt testul a relevat surprinzatoarea implicatie ca daca faci focus grupuri cu retardati, ajungi la concluzii retardate.

In Biblia UI-ului Apple, unde regasim porunca asta cu strictetea redimensionarii, putem citi si citeva reguli de bun simt. Una din ele e sa nu-ti faci alfabetul tau din pictograme, pentru ca in general oamenii stiu deja un alfabet. Pictogramele trebuie folosite pentru grupat vizual chestiile similare, nu pentru a inlocui textul. Exceptie fac pictogramele pe care le pricepe orice om, gen sagetile, dar si alea trebuie folosite cu mare grija. In aroganta lor, Apple isi dau derogare de la regula asta si pentru mazgalelile de pe tastele lor speciale, caci daca nu vrei sa inveti ca semnul de puscarie e tasta de linga spatiu, nu meriti Lumina lui Steve. Scrie in pula mea “Alt+Cmd+Enter”, nu “juma’ de zvastica puscarie inapoi”, ca nu vreau sa invat ideograme hipsteristice doar ca sa pot sa joc Finder din taste. De asemenea, tastaturile Apple au ergonomia unei mine antipersonal, deci daca vrei sa-ti mai poti misca miinile dupa o zi de interactionat cu un Mac trebuie sa-ti iei o tastatura de oameni, care n-o sa aiba simbolurile cultului Apple pe tastele speciale si n-o sa poti sa te uiti sub degete sa vezi pe ce cacat de buton vrea sa apesi. Pentru avansati avem si o intrebare bonus: cum se numesc cele trei taste din poza urmatoare? Indiciu 1: nici macar pe tastaturile Apple nu sint. Indiciu 2: da, sint 3, muia aia din stinga care abia se vede asa apare in dialogurile de configurare.

Problemele astea sint minore, dar le-am mentionat pentru a putea zugravi o mentalitate. Apple cred ca orice iese din mina lor este perfectiunea intruchipata si o binecuvintare pentru intreaga suflare a planetei, asa ca vor tine cu dintii de orice idee, chiar daca se dovedeste a fi o imbecilitate. Mai mult, daca intrebi cum poti face o chestie care nu se poate face, nu-ti vor spune “nu se poate, sintem retardati”, ci vor incerca sa-ti explice ca de fapt nu vrei sa faci chestia aia. Nu vei putea redimensiona niciodata geamurile ca oamenii, din orice colt, pentru ca Apple stiu mai bine decit tine ca nu vrei sa faci asta, asa cum au stiut timp de 20 de ani ca mouse-ul trebuie sa aiba un singur buton. Heil Apple.

De la mentalitatea asta ajungem la problema editarii textului, care il afecteaza direct pe XCode. Prin 1986, IBM s-au prins ca oamenii folosesc tastatura pentru a scrie text si ca ar fi frumos daca ar pune pe ea niste butoane pentru chestii uzuale cum ar fi mers la inceputul rindului, la sfirsitul lui, o pagina in sus sau una in jos. Apple nu au fost de acord. Cine cacat vrea un buton de home? De la balconul Geamiei Perfectiunii si Adevarului Suprem, muezinii Apple le-au tot repetat credinciosilor: mouse-ul are un buton si n-aveti nevoie de home, end sau function keys. Pina la urma fatwa-ul impotriva butoanelor a fost ridicat si o vreme tastaturile Apple au avut butoane de home si end, dar tocmai a fost reinstituit, si ultimele instrumente de torturat degete marca Steve iar au pierdut butoanele astea eretice. Oricum, nici cind le aveau nu mergeau, pentru ca in dorinta lor de a fi altfel, Apple le-au pus sa te duca la inceputul si sfirsitul documentului, dar fara sa mute cursorul, ca asta sigur e o chestie care-ti trebuie foarte des (mult mai des decit sa duci cursorul la inceputul liniei). De asemenea, page up si page down muta doar view-ul, nu si cursorul, alta chestie teribil de utila (mai ales cind ai scroll wheel la mouse, o inventie recenta in lumea Apple, ce-i drept).

In concluzie, viteza cu care poti edita text in XCode l-ar face pe Gutenberg sa se sufoce de ris. Risul lui Gutenberg poate duce la cancer la pancreas pentru Steve prin mecanismul descris in introducere, avind in vedere ca programatorii tind sa-si petreaca majoritatea timpului scriind text. Sigur, te poti duce la inceputul rindului apasind Ctrl+A, ca pe vremea lui VT100, sau Cmd+Stinga, dar Apple n-au auzit nici macar de smart home, un feature care e in toate editoarele de text din ultimii 20 de ani. Ctrl+A si Cmd+Stinga te duc intotdeauna la prima coloana, nu schimba intre primul caracter din rind si prima coloana, ca la oameni. Au si Alt+Page Up / Alt+Page Down, care muta si cursorul (normal, doua taste pentru functia uzuala si una singura pentru aia inutila). Daca te simti aventuros poti chiar sa-ti redefinesti tastele ca-n jocuri si sa pui home sa faca home, doar ca sa-ti amplifici frustrarea in momentul in care trebuie sa faci ceva la calculatorul altcuiva. Cu putina vointa poti sa-ti cresti productivitatea pina undeva la nivelul lui notepad din Windows, moment in care intervin feature-urile avansate, alea care ne arata ca XCode stie ca nu-i un editor de text chior, ci un editor de cod.

XCode are code completion. Tasta cu care il activezi este Escape. Asta e si mai tare decit rename cu Enter. Escape, in pula mea. Bine, ca in practica nu conteaza, deoarece parserul de C++ e cam la nivelul pe care l-ai obtine daca i-ai cere celui mai prost student din grupa sa-ti faca un parser de C++ dupa ce a mers mahmur la prima ora a unui curs in care se mentioneaza tangential programele “flex” si “bison”. Code completion-ul intelege functii, metode si uneori nume de variabile, dar cam atit. Daca ii arati un template intra in fibrilatie. Totusi, in rarele ocazii cind incepi sa scrii numele unei functii si i se pare ca stie ce vrei sa scrii, iti sugereaza functia, cu tot cu parametrii sai:

Daca dai enter sa accepti sugestia, selecteaza definitia primului parametru, astfel incit s-o poti suprascrie cu ce vrei sa pasezi acolo. Urmatoarele defintii nu se mai selecteaza automat, deci trebuie sa le stergi de mina. Daca nu le stergi, ramin acolo in program si poti chiar sa salvezi textul in halul ala:

Daca te uiti in fisier dupa ce-l salvezi, observi urmatoarea aberatie:

int main()
{
    test(5, <#float y#>)
    return 0;
}

Ineficienta in editarea textului ar fi o problema daca ai putea sa ajungi la fisiere ca sa le editezi, ceea ce in general nu e cazul. Un nou focus grup compus din retardati i-a ajutat pe Apple sa decida ca schimbatul intre ferestre din taste este o alta mare sursa de confuzie pentru utilizatori. In OS X, tasta cu care schimbi intre geamurile aceleiasi aplicatii ia ferestrele la rind in ordinea in care au fost create, nu schimba ordinea in functie de ultima accesare, cum face Ctrl+Tab in Windows. Daca ai 10 fisiere deschise dar umbli in momentul de fata in doua, nu poti cicla intre ele cu o tasta. Daca apesi Cmd+`, vei trece de fiecare data prin toate cele 10 surse, plus celelate geamuri ale lui XCode care or mai fi deschise. Daca nu-ti convine asta, exista un mod in care toate sursele se deschid in acelasi geam, dar atunci nu poti sa ciclezi intre ele in nici un fel din taste. In cel mai bun caz iti pui o tasta care deschide dropdown-ul cu lista de fisiere active, dupa care il alegi cu sagetile p-ala pe care il vrei. Daca intrebi un fanboi Apple ce-i cu retardarea asta, iti va spune ori ca nu-i bine sa ai atitea fisiere deschise in acelasi timp, ori ca exista o tasta pentru schimbat intre doua fisiere .h si .cpp cu acelasi nume si e gresit sa vrei sa ciclezi intre doua fisiere care nu respecta regula asta. In orice caz, Apple stiu mai bine decit tine ce vrei sa programezi si cum.

Presupunind ca nu te deranjeaza sa tot duci mina de pe tastatura pe mouse ca sa schimbi intre ferestre de parca ai avea OCD si ti s-ar parea ca mouse-ul nu-i niciodata unde trebuie, tot vei avea o problema: ce geam sa alegi? XCode e un program saritor, care stie ca e bine sa-ti deschida acelasi fisier in cit mai multe geamuri de-odata. Recordul meu e de 5 geamuri diferite cu acelasi fisier, si l-am obtinut in felul urmator:

  1. Click pe fisier in lista din geamul principal al proiectului, se deschide in geamul ala.
  2. Dublu click pe fisier, vine si un geam separat cu el.
  3. Fa-l sa contina o eroare de compilare, da-i build. Da click pe iconu’ cu eroarea, vine un geam cu build status care va contine si el fisierul.
  4. Da find in files dupa ceva din fisierul ala. Click pe rezultat. Ai ghicit.
  5. Pune un breakpoint in fisier, deschide debugger-ul (care e un geam separat, dintr-un motiv ce-mi scapa) si fa-l sa se opreasca in breakpoint. Da, acum il ai si-n debugger.

Sint convins ca se poate depasi recordul, dar mi-e lene acum sa mai caut cacaturi prin meniuri. Mai interesant este sa ne aplecam un pic asupra debugger-ului, daca tot l-am mentionat. Fiind o companie care incearca din rasputeri sa fie altfel decit tot restul lumii doar de dragul de a fi altfel, era de asteptat ca Apple sa copieze ce fac altii fix in locurile in care nu trebuie. In speta, XCode trateaza problema debuggingului in acelasi mod retardat in care o abordeaza toate pocnitorile de IDE-uri facute pe genunchi in baie de adolescenti cuprinsi de febra Linux si open source: vorbeste cu GDB printr-un pipe. Prin viu grai. Ceva de genul write(gdb_pipe[0], “Draga gdb, poti te rog sa pui un breakpoint?”). Ca si in pocnitorile open source, schimbul de amabilitati se incheie abrupt cind gdb nu intelege sonetul expediat prin pipe, de exemplu atunci cind incerci sa faci step in printf().

Desi cu gdb se pot face multe lucruri, XCode e pe undeva pe la nivelul lui Borland C++ 1.0 ca feature-uri expuse. Tastele de step into/over nu merg in disassembly daca dai sa vezi combinat source cu disassembly. Nu exista set next statement (exista o consola unde poti vorbi direct cu gdb, insa, daca te simti poet). Exista un fel de edit & continue, dar merge doar pe programe didactice si oricum e destul de limitat fara set next statement. Daca ai un breakpoint si inserezi linii deasupra lui, uneori nu se muta mai jos, astfel incit sa ramina la codul la care era, ci ramine la linia lui, adica ti se va opri la alt cod. Daca ai un program mai complicat decit hello world, uneori se plictiseste de facut debug la el dupa citeva rulari, si nu se mai opreste in nici un breakpoint pina nu restartezi sistemul. Lista poate continua, dar cred ca s-a inteles cit de impecabil e debugger-ul. Probabil ca daca-i arati problemele unui fanboi, iti va spune sa scrii cod fara buguri, ca sa n-ai nevoie de debugger.

Totusi, ca sa ai la ce sa faci debug, trebuie sa poti intii sa-ti compilezi proiectul. Apple au vazut la Visual Studio manevra cu platforme, configuratii, Debug, Release, cacat, dar n-au inteles nimic. La ei nu poti avea doua target-uri cu configuratii diferite in acelasi proiect. Cretinatatea acestui fapt mi se pare colosala, caci nu-mi dau seama cit de retardat trebuie sa fii ca sa concepi sistemul in acest mod, mai ales cind exista alte IDE-uri care s-au lovit de aceeasi problema si au rezolvat-o deja. Raspunsul la intrebarea retorica este ca Apple au concluzionat ca configuratiile sint ca widget-ul de redimensionat geamuri: prea multe optiuni, prea mare confuzia in focus grup. Iar au stiut mai bine ca tine.

Sa presupunem ca facem doua plug-in-uri pentru doua aplicatii 3rd party. Fiecare plug-in suporta o serie de versiuni ale aplicatiei sale, si pentru fiecare versiune vom avea doua configuratii, Debug si Release. Primul plugin va avea Debug2008, Release2008, Debug2009, Release2009 etc. iar al doilea va avea Debug8.0, Release 8.0, Debug 9.0, Release 9.0 etc. Acum surpriza: facem si un lib cu care linkeaza ambele. Deoarece dezvoltarea lib-ului se intimpla concomitent cu dezvoltarea plug-in-urilor, vrem sa includem proiectul lib-ului in ambele solutii, ca asa ne-am obisnuit din Visual Studio, unde ai voie sa-ti setezi proiectele cum vrei tu, nu cum vrea Steve. Mai mult, lib-ul nu depinde de aplicatia-host, deci va avea doar doua configuratii: Debug si Release.

In primul rind, XCode nu are conceptul de proiect impartit intre doua solutii. Poti ori sa faci un proiect separat cu lib-ul si sa stai cu ambele proiecte deschise si sa dai build de mina in ambele cind schimbi ceva, ori sa faci proiectul lib-ului de doua ori, o data in fiecare proiect de plugin, cu toate fisierele si setarile si muile. Daca alegi metoda asta, vei remarca ca trebuie sa-i faci lib-ului aceleasi configuratii pe care le are plug-in-ul, pentru ca XCode nu vrea sa vada disensiuni intre target-urile aceluiasi proiect. Daca nici asta nu te convinge, o sa te rezolve faptul ca uneori oricum nu linkeaza cum trebuie, ca desi pui dependinte si cacaturi pe-acolo, nu se prinde tot timpul ca trebuie sa linkeze din nou plug-in-ul pentru ca s-a schimbat lib-ul.

Sistemul de muire a programatorilor din XCode are multiple nivele de fallback. Daca nu reuseste sa va futa cu cacaturile astea legate de configuratii si target-uri, tot va gasi un mod in care sa se asigure ca nu-l puteti folosi in nimic mai mare de hello world. De exemplu, daca va trece prin cap sa aveti un lib care se cheama altfel intre configuratii diferite (cacat_debug.lib si cacat_release.lib, sa zicem) si sa-l puneti ca dependinta la alt target din proiect, simpaticul XCode ii va trece numele curent in setarile de link ale target-ului care depinde de el. Cind schimbati configuratia activa, se schimba si numele ala, la linia corespunzatoare in fisierul cu proiectul. Daca dai commit asa si dupa aia da update un nefericit care are alta configuratie activa decit aveai tu, o sa iasa un conflict. Ca bonus, cind il rulezi in command line ca sa faci un batch build, nu-i in stare sa calculeze numele lib-ului asa cum o face cind e in GUI mode, asa ca o sa incerce sa-ti linkeze target-ul cu ce a ramas scris acolo ultima data cind ai inchis GUI-ul. Si in final, daca nici in cazuri d-astea nu va prinde, uneori se decide sa mute random chestii prin fisierul de proiect desi tu nu schimbi nimic cu mina ta, ca sa o puna totusi de un conflict cind dai urmatorul update.

XCode vine si cu o serie de unelte ajutatoare de o calitate la fel de suprema ca el. Preferatul meu este muismul ala de facut installere. Apple au decretat ca nu vor sa vada installere pentru aplicatii, ceea ce e un lucru bun (la ei aplicatiile vin ca niste arhive din care tragi fisierele afara si gata). Totusi, in unele cazuri chiar trebuie sa faci un installer, si atunci ai la dispozitie PackageMaker, cel mai bugos program pe care l-am vazut vreodata. Pe linga faptul ca periodic iti fute proiectul pentru ca asa i s-a sculat, si ca setarea proiectului in sine este un demers sisific, cel mai tare feature al acestui program mi se pare ca isi tine proiectul in format XML, dar XML-ul e tot pe o singura linie. Daca deschizi un proiect de installer, ii dai build si dai sa-l inchizi, iti va spune ca s-a schimbat. Daca faci timpenia sa-i zici sa salveze, in multe cazuri iti va distruge proiectul. Daca incerci sa dai un diff sa vezi ce-a facut, nu vei avea prea mare spor, fiind totul pe o linie. Noroc ca-i XML, acest format care poate fi citit si de oameni, si de masini, si de Silviu Ardelean.

Observ ca s-a facut tirziu si ca m-am intins un pic. As mai avea chestii de zis, dar ma voi screme inspre retorica finala. Inteleg ca pe Steve il doare la pancreas despre XCode si suferinta pe care o provoaca el programatorilor fortati sa faca aplicatii pe OS X. Nu inteleg totusi cum se face ca muistii care lucreaza la gunoiul asta nu au fost inca linsati de colegii lor, care trebuie sa-l foloseasca. Daca eu as fi programator pe plantatia de meri si as sti ca in cladire cu mine traiesc si defeca cod infectii care au abatut asupra mea cel mai rau intentionat IDE din istorie, s-ar lasa cu singe. Aia de la Apple ori au un IDE secret pe care-l folosesc in-house, ori isi cirpesc propriile solutii cu vim, emacs sau alte editoare preistorice (ceea ce nu e neaparat mai bine), ori spalarea pe creier aplicata personal de Steve fiecarui nou angajat chiar are randament 100%.

Tags: , , , , , , , , , , ,