Am citit atat articolul lui Adrian Plesu despre cultura de internet cat si schimbul de replici intre Dragos Butuzea si Adrian Ciubotaru pe marginea lui si as vrea sa fac public ce gandesc despre acest schimb de opinii.
As incepe prin a expune anumite caracteristici ale internetului care-l fac diferit de mediile de comunicare precedente: costurile extrem de mici de distributie ale continutului (*) si gradul de dispersie pe care aceste costuri (**) il implica. 

Mediile de comunicare anterioare aveau costuri extrem de mari: distributia era facuta manual (***), costurile hartiei sau pergamentului erau ridicate. Aceste costuri mari au creeat entitati care administrau continutul prin triaj si au decis atat nature continutului cat si nature organizatiilor care administrau. 
Initial distributia se rezuma la a copia un manuscris de mana pentru a-l trimite unui destinatar. Costurile prohibitive ale acestei operatii dictau ca singurele entitati care putea distribui continut sa fie cele care isi puteau asuma aceste costuri direct (curti regale, etc…) sau cele specializate in distributia de continut pentru care aceste costuri sunt relativ mici (diferite institutii bisericesti care erau specializate in acest domeniu datorita faptului ca erau singurii consumatori de continut. Continutul in cazul lor se rezuma in general la o singura carte: Biblia).

Odata cu introducerea tiparului costurile de distributie au scazut, mai precis s-au mutat de la copiat pur si simplu la fabricarea de linotipuri sau de tiparuri pentru paginarea continutului. Odata cu scaderea acestor costuri capacitatea de distribui si implicit cantitatea de continut in circulatie, a crescut, dar a atins limitele superioare impuse de noile costuri. Pentru a administra aceasta cantitate de continut s-au infiintat diverse entitati (cluburi literare, diverse reviste, etc…) care distribuiau continutul dupa cum era finantati. In acest interval de timp continutul reflecta in mare parte idealurile si interesele “sponsorilor” acestor entitati si este predominant artistic. De asemenea Europa se afla in plin proces de urbanizare, ceea ce ridica numarul celor care pot consuma acest continut (in marea majoritate mici burghezi care se pot dedica consumului de carte in timpul liber). Oferta de continut generata de scaderea costurilor de distributie isi gaseste un match perfect in cererea de continut generata de procesul de urbanizare.
Este marea epoca in care cei putini ii “educa” pe cei multi, epoca care dureaza atata vreme cat costurile de distributie a continutului se mentin constante(****).

Pe masura ce distributia devine mai eficienta costurile ei scad, ceea implica ca mai mult continut (in volum si in diversitate) poate fi distribuit. In acelasi timp numarul consumatorilor creste, ne aflam intr-un moment in care atat oferta cat si cererea de continut se afla in crestere (inca o data oferta si cererea par se mearga la unison). Apar sub-genuri literare, literatura “populara”, incrucisari intre sub-genuri, specializare crescanda in interiorul aceluiasi domeniu, etc… De remarcat gradul ridicat de dispersie al producerii si consumului de continut: comunitatea incepe sa se rupa in granule din ce in ce mai mici si mai specializate, oferta si consumul de continut fiind intermediata in interiorul acestor granule independent unele de altele.

Costurile de distributie ating un platou inferior pana la introducerea internetului care propune un mediu in care costurile de distributie sunt nu chiar zero, dar destul de aproape (faptul ca nu sunt chiar zero are niste implicatii care nu vor fi discutate aici). Faptul ca aceste costuri sunt din ce in ce mai mici fac ca gradul de dispersie sa se mareasca. Granulele mentionate mai sus devin din ce in ce mai mici, dar si din ce in ce mai efemere si mai fluide, poti trece de la o granula la alta cu foarte mare usurinta. Gradul de specializare se mareste pe masura ca cantitatea de continut care trebuie consumata se mareste in volum si diversitate.

In acest nou mediu intermedierea dintre cerere si oferta nu mai este facuta de catre case de editura, diverse mecene sau autoritati in domeniu, pentru ca aceste entitati nu fac fata volumului imens de continut produs, ci de catre diverse motoare de cautare si aplicatii scrise pentru ele care devin mediatorii schimbului de continut. In afara motoarelor de cautare (care actioneaza orizonal, la un nivel deasupra granulelor) in interiorul granulelor activeaza lideri de opinie care filtreaza continutul (asemanator cercurilor literare care i-au precedat) cu care intra in contact si-l distribuie mai departe.

Am scris cele de deasupra pentru ca Adrian Ciubotaru s-a referit la diferitele etape prin care mediile de comunicare au trecut in istorie si am vrut sa clarific, mai mult pentru mine, care sunt fortele care au schimbat aceste medii de comunicare de-a lungul timpului, pentru a putea raspunde mai bine intrebarilor puse de cei 2.

Andrei Plesu deplange amatorismul care decurge din usurinta cu care cineva are acces la informatie, dar acest amatorism nu se datoreaza accessului usor la informatie cat mai ales faptului ca cei care consuma produsele acestui amatorism probabil ca nu sunt in stare sa consume mai mult. Daca majoritatea romanilor se multumesc cu dictarea pe sticla a unor pasaje din Wikipedia ce rost are sa le oferi mai mult? S-ar putea sa nu fie in stare sa consume altceva si aceasta dictare din Wikipedia e chiar optimala, s-ar putea sa genereze interes pentru anumite subiecte. Parerea mea este ca Adrian Plesu face greseala de a se concentra exclusiv asupra ofertei de continut de la TV (saraca din punctul sau de vedere) dar scapa din vedere cererea de continut de pe acelasi canal (care e la fel de saraca). 

Adrian Ciubotaru se intreaba care este miza spirituala a internetului si cum va arata cultura viitorului. Internetul in sine poate fi gandit ca un depozit imens de carti indexat mai mult sau mai putin eficient care intermediaza interactii intre producatori si consumatori de continut. Intr-un asemenea depozit de carti (in care Plato, Voltaire, Shakespeare, etc… sunt pusi pe acelasi raft cu manualul de utilizare al ultimului aspirator GE) nu exista notiunea de spiritualitate pentru ca internetul este o constructie electronica. Notiunea de spiritualitate se poate aplica eventual oamenilor si interactiunilor dintre ei, dar este foarte greu de formulat o idee, un concept, ceva care sa se aplice la toti participantii pentru ca numarul imens de participanti si de relatii intre ei implica o foarte mare varietate care nu poate fi cuprinsa atat de usor. SIngurul mod in care Internetul poate fi tratat este statistic.

Singurul lucru care apropie internetul de spiritualitate pe care-l vad este faptul ca a devenit foarte usor de a creea nise destructive, care pot accelera anumite tendinte destructive si amplificarea fenomenelor de izolare pe care le traiesc anumiti indivizi care prefera noile moduri de comunicare (prin scris) vechilor moduri de comunicare (verbal). 

Faptul ca noile medii de comunicare creeaza relatii cu cost de oportunitate scazut (practic orice relatie de pe internet poate fi terminata si inlocuita cu o noua relatie relativ rapid) antreneaza relatii superficiale (practic nu faci o investitie importanta cand incepi o relatie pe internet).

As zice ca miza spirituala a internetului este cum sa te re-atasezi de persoane in contextul in care formele de comunicare si relatiile generate de ele devin din ce in ce mai impersonale.

In ceea ce priveste cultura viitorului parerea mea este ca ea va fi fragmentata, specializata si extrem de accesibila din punct de vedere fizic (poti sa intri in contact cu oricine oriunde), dar greu de inteles din exterior (din cauza specializarii), o multime de nise care interactioneaza unele cu altele prin diferite mecanisme. 

P.S. Acest post a fost scris in mai multe reprize, n-am reusit sa gasesc o pauza suficient de lunga pentru a-l scrie in liniste ci in reprize de cateva minute, sper ca nu am facut prea multe greseli de ortografie. Imi dau seama ca nu este scris incredibil de bine si este mai mult o lista de idei, dar n-am avut timp sa lucrez prea mult la el.
Am incercat sa aplic anumite concepte economice diferitelor medii de comunicare. 
Nu am facut nici un fel de cercetari in ceea ce priveste diferitele medii de comunicare. 

* Continut este folosit in intelesul cuvantului “content” din engleza.
** Pentru a vizualiza efectele pe care costurilor de distributie le au asupra continutului care este distribuit inchipuiti-va o palnie prin care continutul este pasat catre consumatori si a carei deschidere este invers proportionala cu costurile de distributie: cu cat costurile scad cu atat palnia se deschide mai mult si cantitatea de continut in circulatie (atat in volum cat si in diversitate) creste.
*** Initial a distribui un document se rezuma la a angaja un copist care sa copieze acel document de mana. Odata cu introducerea tiparului distributia unui document se rezuma la creerea unui linotip sau al unui tipar care urma sa fie folosit la creerea unui numar mai mare de copii. Costul per copie scade odata cu introducerea tiparului, dar nu este zero, nici macar aproape, daca iei in consideratie faptul ca inca se apela la munca manual si faptul ca nivelul de calificare cerut pentru aceasta functie era mare in comparatie cu celelalte ocupatii.
**** De remarcat ca echilibrul economic intre oferta de continut (constransa de costurile de distributie relativ mari) si cerere (in crestere datorita urbanizarii) din aceea vreme este considerata de multi romani ca fiind un echilibru economic optimal in care o fiinta umana se poate dezvolta armonios, modelata de entitatile care finantau distributia continutului. Mediul actual de comunicare, definit de costuri extrem de mici, este vazut cu multa ingrijorare de catre o buna parte dintre romani.

As I was saying in my previous post a lot of technological issues (such as the debate of REST vs. WS-*) are actually organizational issues and that at the bottom of them you will find that the process of communication has been broken down into tasks (namely the task of  the payload-to-processor mapping) and those tasks have been allocated (they have been externalized or internalized) according to the transaction costs of each particular environment.

I would follow this by saying that a lot of time will be saved if the interactions between various parties will be broken down into tasks and that the tasks will be allocated according to the nature of the organization(s) within which these interactions will be carried out. This applies not only message passing but to any other environment in which various entities engage in collaboration. 
For example, you may find out that DSLs will not work in particular setting not because DSLs are bad, but because the organization within which these DSLs are implemented and used simply doesn’t warrant their success.

One of the best presentations that I have seen lately is Mark Little talking about REST and WS at QCon London 2008, or rather about the differences between the uniform interfaces and the specific interface. Mark Little gets right at the bottom of the differences between REST and WS, and these differences are not all differences between architectural styles, but rather differences in organizations.

One of the best interpretations of the differences in REST vs WS that I have seen is the one that Mark makes in this presentation and that I will try to reproduce below is the division of tasks of mapping a message sent to an entity (could be a service, could be an URL) and the component/processor within that entity that will process it: when you send a message to a specific interface you will be specifying the method and the component that will process that message, so the message-to-processor mapping is done by the client. Whereas when you send a message to a specific interface you need to attach some meta-data to that message which will be used by the entity implementing the specific interface for mapping that message to its appropriate processor, therefore the message-to-processor mapping is done by the entity.

The message-to-processor mapping is externalized in the case of specific interfaces while the uniform interface internalizes it. These different mappings come with different transaction costs: in the case of the external mapping the costs are synchronizing the client with changes in the specific interface while in the case of the internal mapping the costs are adapting the uniform interface’s mapper to changes in the meta-data (a new type of messages should be mapped to a new processor).
Now, if we apply economics to the task of message-to-processor mapping we would start to get some interesting results. According to Coase’s theorem you can externalize an activity if the transaction costs for that carrying that activity are low enough and if the transaction costs are high then that activity is better internalized. It would follow that when the transaction costs of this mapping are low you can externalize it via a specific interface, otherwise you would be better off to internalize it via an uniform interface. 
The transaction costs of the specific interface are the synchronization of distributed clients and this could be resolved either thru versioning, or by not modifying the specific interface or by standards. If you can keep these costs down it follows that you can delegate the message-to-processor mapping efficiently to the client else you are better off with a uniform interface. Keeping these costs down also implies that the number of methods that get exposed is kept down in order to avoid the number of changes (more methods, more opportunities for changing them). Generally speaking interaction via specific interfaces is best limited to a few coarse-grained components, between a few participants and with components which do not change very often.
The above synchronization costs run counter to scale in number of clients: as the number of clients starts to grow you are starting to have problems synchronizing all of them and eventually the transaction costs of using the specific interface will become so high, it will not make sense to use it. One corollary of this is that the uniform interface is far better at the scale of the internet and this is probably the main reason why it is used at this scale.
The above will provide a pretty good guide to an architect trying to figure out whether to use a specific interface or an uniform one because their use is not driven by technology, but rather by the organization(s) within which they are employed.

Another interesting point in his presentation was the effort for creating a REST-ful standard for carrying out distributed transactions and the need for agreement between multiple parties. As I was saying in a previous post about REST and WS the differences between these 2 camps are more of organizational nature than anything else. Mark touched upon the fact that even if the need for carrying out distributed transactions via REST exists there is still no standard for doing so, that the REST community seems pretty much happy with implementing low-level infrastructure and not with higher-level, and higher-value, components. I find this a pity and I have the impression that this need will be fulfilled only it raises to a level at which major corporations will find profitable for getting involved. The REST community appears simply way too fragmented to be able to carry out this effort on its own…

Anyway, go ahead and watch the presentation, it is the most thoughtful presentation on distributed computing that I have seen in a while.

ESBs is an essential enterprise computing capability which allows for mediating connections between various parties. Typical EBS usage consists of message producers sending messages to an ESB which transforms them and then forwards them to message consumers.

It is at the transformation stage that the thorniest issues arise with ESBs. As outlined in this presentation from Thoughworks there is a tendency to push business logic inside the ESB resulting in a very tight coupling between applications and the ESB (part of the business logic will be stored in applications, part of it in the ESB and the business logic in the ESB will need to be kept in sync with the business logic in the applications). Not a nice scenario and unfortunately the solution provided in the presentation (apparently you only need to use Guerilla SOA) doesn’t say much. The business logic which gets shoved into the ESB in the above example are the relationships between the various parties which are sending each other messages and the mess that comes out of it as these relationships change over time.

One example of ESB usage is a customer-facing web application which takes purchase orders from customers and sends messages to an inventory and shipping system, to the accounts receivables system and to the customer loyalty system. There are a few ways that this messages can be sent: 1) the web-application sends only one message to the ESB which then creates 3 more messages, one for the inventory system, one for the accounting system and one for the customer loyalty system (in which case the relationships between the web-app and the 3 systems are managed within the ESB); 2) the web-application creates 3 messages which are all sent independently to the 3 systems (in which case the relationship between the web-application and these 3 systems is managed by the web-app typically thru dedicated senders which are transforming the message according to the other party’s specs) or 3) the web-app publishes the message on the ESB which forwards it as-is to the receiving systems which are receiving the message as it has been created by the web-app and transform it according to their rules (in which case the receiving systems are managing the relationships with the web-application typically thru dedicated receiving points which are transforming the incoming messages).
So far I have only seen 2 or 3 used and it was used successfully. I have not seen 1 being used successfully, but rather I have seen ESBs simply delegated to the role of a dumb-pipe while the processing is done on the end-points. I think that the main reason for which the ESB cannot grow beyond the role of a dumb-pipe is that the transformations typically involve data, imagine that in the above scenario the IDs of the products on the web-application are different from the ones in the inventory system (a very common case BTW). In order to service this transformation you would need an up-to-date mapping between all relationships that it is managing. Sooner or later that ESB will turn into a giant vacuum cleaner that will need to suck every byte of data available in order to service the relationships stored in it.
Lesson #1: Managing relationships typically involves managing data.

Let’s go more into the gory details and think about how we would deal with stale data: let’s say that the datastore holding the mappings of product IDs from the webapp to the inventory systems is missing a product ID (another very common case). In the case where the relationships are maintained at the connection end-points (message producers or consumers) the operation team managing those end-points would have access to the exception (missing product ID mapping in this case) as well as to its solutions (create this mapping in your mapping store). How will the ESB deal with stale data? Well, the ESB will have to find the entity which can resolve this exception, package the exception and send it to that entity. Sooner or later the ESB gets becomes a spaghetti bowl.
Lesson #2: ESB has bad exception management capabilities. 

Pushing the transformation towards the end-points effectively couples the end-points because these endpoints must share the format (*) of the messages they exchange and, just as importantly, they need to share data. Sharing data is usually done by one party having a procedure to export its data and the other parties using this procedure for creating local replicas of that data and synch-ing them according to a calendar. In addition to that the parties replicating the data have procedure for overriding the data they receive and adding to it. As far as I have seen it works pretty well and when it doesn\t work it is more of a management issue on the side issuing the data.

To sum this up, I would keep any data enriching out of the ESB and use the ESB trasformations only for format transformations and version transformations (**). One more benefit to keeping the ESB down to routing and format transformations would be that its role is well-contained and it doesn’t turn into a wild-card (does this particular problem gets handled by the ESB, how, why, when, etc…) making your IT assets more manageable. This results in a neater division of concerns in your overall enterprise architecture.

* It is advised that the format of these messages is not using APIs but rather text-based protocols such as XML, pipe-delimited, etc… API couplings is one of the most horrendous things that I have seen, synch-ing libraries on multiple endpoints at the same time is an incredibly time-consuming activity.

** Version-based transformation are transformations of the same message between 2 different versions of it: let’s say that one message producer decides to publish a new version of the messages that it has been produced so far, the ESB should be made aware of this and deliver the new version to the consumers that are registered to receive it as well as create a new message with the old version out of the original message and send this new message (formatted according to the old version) to the clients which are still registered to receive the old version. Part of this versioning effort is the transformation from the current version to an older version and this transformation would be best done by the message producer which will load a transformer into the ESB for this transformation. The ESB will then be re-configured to apply this transformation to the original message with the new version and the resulting message to be routed on its old route. This way the versioning effort will be pushed inside the ESB and messages will be delivered transparently to the intended receipients and recipients will not have to be upgraded when their counterparties upgrade their message format effectively de-coupling their release cycles.

Urmaresc de o buna bucata de vreme criza financiara care bantuie pietele financiare de mai bine de un an de zile, iar in ultima vreme o urmaresc chiar foarte atent citind vreo duzina de analize zilnic. Nu vreau sa-mi arog vreo autoritate in materie, citesc mai mult pentru ca sunt foarte interesat de finante si pentru ca este de departe cel mai important eveniment din ultima vreme.

Tot citind asa m-am intrebat ce se scrie oare in Romania, mai mult pentru a vedea daca mai am mare lucru in comun cu cei de acolo. Eram curios in primul si in primul rand sa vad cum se pune problema in Romania in privinta unui lucru care pentru mine conteaza destul de mult. Eram de asemenea curios sa vad cam ce fel informatii i se paseaza unui roman de rand pentru ca el sa-si faca o idee despre acest fenomen. Am inceput cu unul din ziarele pentru care aveam un oarecare respect: Cotidianul.

Cotidianul mi se pare (de la 7 fuse orare distanta) un ziar al carui audienta este constituita din clasa de mijloc a Romaniei, audienta cu care reusesc sa ma identific cel mai mult: oameni cu anumite studii, care se bucura de un anumit succes si care au opinii liberale in sensul europeean al cuvantului. Primul articol despre sub-prime pe care l-am vazut a fost acest editorial scris de nimeni altul decat de Mircea Dinescu. Mda, marele poet s-a trezit peste noapte economist si a inceput sa-si dea cu parerea despre interventia statului in economie. Dupa inca un editorial al lui Dinescu mi-a fost clar ca mai bine ar fi ramas la o betie cu Marx, macar asa cititorii ar fi fost mai castigati.
Bun, pe Dinescu l-am bifat, hai sa vedem ce mai e in Cotidianul despre criza financiara. Pai, ce sa fie, articole pe un subiect economic scrise de tot felul de tipi care n-au mare lucru in comun cu finantele si economie: Teodor Baconski (aparent de profesie teolog) ne explica diferentele dintre pietele de capital din Statele Unite si cele din Europa, Alin Fumurescu (politolog  se pare) ne explica de ce politica este superioara economiei si cum ar fi fost evitat acest fenomen daca politicienii ar fi fost bagati pe fir, etc…

In fata acestei incropeli de opinii am decis ca vreau sa vad si alte pareri din alte ziare. Si asa am ajuns la Romania Libera si la editorialul Alina Mungiu-Pippidi (de profesie politolog). Spre deosebire de confratii de mai sus ai dansei care se multumeau sa formuleze diverse opinii despre economie doamna Pippidi ridica stacheta: este primul intelectual care are curajul sa scrie o opinie asupra planului Paulson (nota: planul Paulson este un plan destul de complex care nu se poate rezuma in cele 2 fraze pe care i le consacra Alina Mungiu-Pippidi). Singurul lucru care merita citita in acest articol este prima fraza: Daca ar fi sa sintetizez actuala criza globala financiara pe intelesul meu, as face-o cam asa. Odata ce ne previne ca dansa nu intelege mare lucru Alina Mungiu-Pippidi incepe sa bata campii. Odata cu acest editorial mi s-a taiat pofta sa mai citesc ce scris Romania Libera despre criza financiara.

Apoi am luat o mica pauza de la sub-prime pentru ca am inceput ca citesc ce scrie Evenimentul Zilei despre sub-prime. EZ nu scrie nimic, dar chiar nimic, intre meciul vietii, analiza EZ si dezastru in fotbal n-am gasit mai nimic despre actuala criza financiara. EZ a fost ultimul cotidian ne-specializat pe care m-am uitat, chiar n-aveam chef sa-mi pierd toata ziua citind ziare din Romania.

Asa ca hai sa trecem la niste ziare specializate. Am inceput cu ziarul Bursa, primul ziar financiar din Romania si pe care mi-l aminteam dinainte sa fi plecat (m-am dus pe situl lor mai mult dintr-o nostalgie pentru logo-ul lor neschimbat de mai bine de 15 ani). Am zburat de pe situl lor in mai putin de 30 de secunde, asta dupa ce am facut cunostinta cu calendarul Bursei. Am crezut initial ca o sa am de a face cu ceva asemanator cu calendarul Barrons in care redactorii fac un rezumat al principalelor evenimente din saptamana care urmeaza. Ei bine, Bursa are un calendar diferit , este vorba de un calendar de agata in perete, nu va recomand sa apasati pe el la locul de munca, veti da peste o tipa sumar imbracata intr-o pozitie provocatoare.

OK, deci asta a fost Bursa. Ia sa vedem Ziarul Financiar. ZF este intr-o liga diferita de Bursa, in primul rand pentru ca nu are calendar ci o gramada de reclame care-ti ingreuneaza cititul. ZF are chiar si o rubrica in care sunt colectate diferitele articole referitoare la criza financiara curenta. Destul de interesant materialul in acesta rubrica, din pacate ii cam lipsesc editorialele. Eu de fapt asta cautam, cautam o serie de articole in ziarele din Romania in care romanului obisnuit sa i se explice cam ce se intampla, care sunt cauzele. Cautand in rubrica de mai sus niste explicatii am dat asupra 2 articole: un articol care expune parerile profesorilor din ASE si un articol care expune parerea lui Ion Iliescu (??????).
Parerile profesorilor din ASE par sa fie un amestec exotic de vechituri, misticism si ecologism:
“Bate la usa o noua viziune mondiala care va porni de la ideea ca FMI, Banca Mondiala trebuie respiritualizate (presupun ca conceptul de re-spiritualizare a unei banci este folosit in circuit inchis in ASE, eu inca n-am gasit ceva asemanator in proza economica anglo-saxona)”

De remarcat o diferenta importanta intre economistii de la ASE si economistii din Occident: economistii de la ASE nu cunosc cauzele acestei crize dar cunosc urmarile ei, in timp ce economistii din Occident cunosc foarte bine cauzele crizei, dar habar n-au ce se va intampla:
“Crizele acestea au cauze profunde, stiinta veche, clasica nu mai poate sa explice aceste evenimente. Va fi o respiritualizare a stiintei economice, cred ca noua stiinta economica se va numi ‘ecolonomie’, stiinta economica despre sanatatea intregului viu.“ 

Un ultim citat din articolul de mai sus care ar trebui sa ne arate cu cine stam de vorba:
Din punct de vedere tehnic, nu este nicio diferenta intre pierderea a 70 sau a 700 de miliarde de unitati monetare intr-o singura zi. 

Dupa elucubratiile de mai sus suntem adusi rapid pe pamant de limba de lemn a lui Ion Iliescu:
Dincoace, este vorba de cealaltă extremă: a fetişizării pieţei şi a capacităţilor ei, adică este vorba despre un neoliberalism care spune: “statul out (a se remarca folosirea romglezei, semn ca Iliescu e in pas cu trendu-ul), iar economia se reglează de către piaţă şi regulile ei”. Aceasta este iarăşi o extremă care se dovedeşte, iată nerealistă. Adevărul este undeva, la mijloc. 

Ultimul articol din ZF pe care l-am citit este acesta in care America este comparata cu un Bancorex (voi reveni la paralelele dintre crash-urile financiare de la noi si cele din Statele Unit). Nici aici nu sunt prezentate informatii despre cauzele actualei crize economice, potentialele canale de contagiune, etc… ci un mic tratat ieftin despre venalitatea oamenilor.

As mai fi urmarit si alte surse de informatii economice din Romania dar intre timp ma cam saturasem. Dupa un scurt sejur pe Lumea In Criza unde cel mai interesant articol este o traducere proasta din engleza am pus punct.
Dupa cum va spuneam mai sus as fi vrut sa stiu cam ce parere poate sa-si faca un roman obisnuit care citeste ziarele din Romania si am ajuns la opinia ca nu poate sa-si formeze nici o opinie, ci este inundat de stiri din care nu intelege mare lucru si care-l lasa intr-o stare avansata de panica.

Daca as fi sa rezum impresiile cu care am ramas dupa ce am facut aceasta mica revista a presei romanesti as scrie asa ceva:

• Lucrul care m-a socat cel mai tare este lipsa de discernamant cu care diferite personalitati publice (Alina Mungiu-Pippidi, Mircea Dinescu, etc…)  s-au oferit sa-si dea cu parerea despre lucruri despre care habar n-au. Eu ma simt putin tras in piept de amatorismul acestor intelectuali in care la un moment dat chiar credeam destul de mult. Opiniile pe care le-au dat cu aceasta ocazie ma fac sa ma intreb cand vorbesc despre un domeniu pe care-l cunosc bine si cand alearga dupa cai verzi pe pereti. Sincer sa fiu eu unul voi fi extrem de circumspect cand voi mai citi ceva scris de ei.
• Lipsa de personalitati in domeniul finantelor sau al economiei. Elitele Romaniei nu au un Martin Wolf, Willem Buiter, Paul Krugman si canalele aferente prin care acesti oameni sa poata intra in comunicare cu romanul obisnuit care ar dori sa stie mai multe lucruri despre acest fenomen foarte important pentru zilele noastre.
• Amatorismul presei financiare din Romania care se pare ca nu e in stare de a prezenta analize mai adanci asupra acestei crize si care se limiteaza la difuzarea de stiri non-stop catre o audienta care pare incapabila sa le inteleaga. Audienta nu e capabila sa le inteleaga si pentru ca presa financiara nu este in stare sa o educe.
• Am ramas de asemenea si cu impresia ca multi compara actuala criza cu crahurile bancare de la noi si ca in acest act introduc o doza masiva si iresponsabila de “sa moara si capra vecinului”. Dragii mei, va rog sa luati in calcul ca daca moare capra asta voi o sa zburati din functiile in care sunteti mai repede decat poti sa zici sub-prime. Dupa cum seful Reservelor Federal Americane spunea, s-ar putea ca maine sa nu mai existe o economie.
• Exista un interes destul de mare pentru ceea ce se intampla afara.

Aici inchei acest post. Presupun ca daca cineva va poposi aici va ajunge printr-un search Google si ca va cauta informatii despre actuala criza economica. Pun aici o lista de diferite articole care il pot lamuri. Singura problema este insusirea unui anumit vocabular, articolele sunt pline de termeni tehnici cu care majoritatea oamenilor s-ar putea sa aiba probleme. Daca cineva are dificultati in intelegerea termenilor il rog sa puna intrebari in comentarii si voi incerca sa-i raspund daca voi avea timp.

Deci aceasta este lista:

• Paul Krugman despre planul de salvare. Ce mi se pare cel mai important in acest articol este cum PK rezuma istoria actualei crize in 4 fraze, mai putin analiza planului.
• Problemele actuale ale firmelor de investitii rezumate de Richard Balwin. Problemele reducerii de capital prin investitii in ipoteci sub-prime si diferentele dintre problema de lichiditate (o institutie financiara are banii bagati in active solide, dar nu-i poate scoate din aceste active fara a le pune pe piata in cantitati masive, lucrul care ar face ca pretul activelor, si implicit valoarea institutiei, sa scada) si insolvabilitate (institutia financiara are banii bagati in active “toxice”). De asemenea discuta problemele de leverage si de-leverage dezordonat.
• Diferitele mecanisme prin care criza financiara din Statele Unite poate atinge Europa.
• O anatomie a crizei financiare de pe vox. Vox este un alt site pe care sunt publicate diferite analize despre aceasta criza.
• Blogul lui Willem Buiter - destul de complex, cere o intelegere destul de buna a diferitelor instrumente financiare.
• Free Exchange - un bun blog de popularizare a diferitelor concepte economice, in momentul de fata are o masa rotunda axata pe actuala criza financiara.
• The Euro-Intelligence blog. Personal, consider acest sit destul de alarmist. Totusi, daca faci abstractie de acest lucru poti gasi informatii destul de utile si link-uri catre alte sit-uri la fel de utile, mai ales despre situatia din Europa.
• Martin Wolf’s Forum.

Citeam azi Dilema veche cand am fost socat sa citesc cateva fraze in romgleza scrise de Plesu: …dar am văzut şi bătrîni pergamentoşi, aflaţi în anticamera exitului…, …al salahoriei de catedră, rezultate din imperativul: „publish or die!“. 

Incredibil!!! Plesu este ultimul om pe care as fi crezut ca va vorbi aceasta limba. Sper ca va renunta repede la ea, limba romana este prea frumoasa si Plesu o vorbeste cu mult prea mult har pentru a-si reduce editorialele la nivelul exprimarii unui piarist semi-analfabet.

Astept cu nerabdare urmatorul editorial liber de romgleza!!!!
 

P.S. This is not “fucking funny”. Nu-mi vine sa cred ca Andrei Plesu a scris randurile de mai jos:
…E inteligent, e citit, e funny. Fucking funny!…
Foarte ciudat…

Typically OOP inheritance is used for sharing various common methods and a typical example would be something like this:
You have interface Vehicle which has sub-classes Bicycle and MotorVehicle. MotorVehicle in turn has the sub-classes Car and Truck, each with its specifics. Car, Truck and Bicycle are all sub-classes of Vehicle and as such are all inheriting the same common behavior, such as some object which specifies the speed limits within which each Vehicle should operate (for example a Car should be able to handle higher speeds than a Truck or a Bicycle).
Fair enough, and this way to use OOP inheritance has its reasons for use.

However, one other reason for using inheritance that I see is for creating substitutes in order to partition code bases. In this case you are using sub-classes not because you need some shared behavior to be encapsulated in a super-class, but because you have distributed teams working on the same codebase and you need to minimize collisions between them in the codebase (a collision would be 2 or more persons working on the same file and is usually resolved by a merge in CVS). Solving conflicts thru CVS merge is a pretty error-prone process and doesn`t scale out well, so at one point it is necessary to partition development so that different teams can work on the same project without elbowing each other.
Sub-classing in this case would solve this problem by letting a developer substitute its team’s type for another team’s type.

One example is using helper classes which service a POJO and which are used by more than one team:
Let’s say that we have a TaxProcessor class that uses a TaxCalculator for calculating the taxes to be applied to a trade. Let’s say that you have 2 teams, one working on taxing bond trades and one working on taxing equity trades and that they are all using the same TaxCalculator class on the TaxProcessor. TaxCalculator has the method taxTrade which delegates to taxBondTrade and taxEquityTrade. As time goes on a lot of fixes are put into taxTrade in order to deal with various corner-cases to the point where 1) TaxCalculator becomes hard to maintain and 2) more than one developer is working on the same method at the same time. A solution would be to sub-class TaxCalculator into BondTaxCalculator and EquityTaxCalculator, have each implement the method taxTrade according to its specifics and then have TaxProcessor use the appropriate class according to the trade type.

As you can see from above good software models imply good separation of concerns. Good separation of concerns translates in good separation between development teams working in parallel on the same project. Good separation between development teams results in low transaction costs or interaction costs between teams and into a more efficient way to delegate work and in a development environment which scales better.

I was reading this post on BW’s Blogspotting and I think that link-less is not going to work because the content producers will be pushed out of the equation like it is explained below:
But what Raghavan is describing sounds very much like an effort to push relevant Web pages down, or even out of the equation. “We’re not giving you pages, we’re giving you information synthesized from other pages,” he says.
In this scheme, Web pages cease to be destinations. They simply fork over information, gratis.  

Yeah, like I would ever want to fork-over my content to Yahoo so that they can put an ad next to it. There is a sense of ownership to the content that you are creating (not necessarily monetizable) that would enrage many content producers if Yahoo would neglect it.

If search engines master this transition, how will the Search Engine Optimization crowd tweak their Web pages?

If search engines get around to this SEO will transform itself into a business that would protect your content from being pulled out of your site and plastered on Yahoo’s link-less search.

Chrome, the browser developed by Google is about to be released. I get a pretty weird feeling from this, because Google was known to support Firefox, because it comes on such a short-notice and because I don’t see any benefits to Google, at least not immediately.

Firefox is a pretty decent browser, or more likely, a pretty decent browsing platform onto which you can install various plugins which will make you browsing experience better. Not too bad, even though I have a lot of problems with their address bar.

I think that what sets Google’s brower apart from the Firefox and IE, the browsers currently with the biggest market share, is the vast mass of data that Google has upon browser users and the way they will leverage this data to gain market share and the number of web-applications that it has in its portfolio. This browser will probably be integrated with Google’s other offerings such as GMail, Google Apps, etc… I think this sets them so far apart that the browser to come out of Google may not look like a browser anymore, but rather as an integration tool between your email (GMail), your RSS reader (Google Reader), your office documents (Google Documents), instant messaging (Google talk), etc… Who knows, maybe it will integrate even with Google Android ;-).

As I have said before, Google has put together a large amount of data that helps it describe the typical user that browses the web, and I think that this data will be leveraged in order to get ahead of Firefox because it Google may develop better ergonomics with of this data. Google will probably battle against Firefox for market share and this battle will be a battle between application designers (Firefox) and statistics on usage (Google). It will be interesting to see how it unfolds.

Later edit: I have been using Chrome for an hour or so and it feels more like a desktop than a browser. It manages to hide away, yet make available when needed, a lot of browser-specific functionalities. It feels like Firefox when run in full-screen mode, it gives you more space and manages to stay in the back-ground. A web-application should take advantage of all this space. The web is the new desktop…

My assumptions about Chrome’s design were largely wrong, from what I see Chrome is pretty much concerned with getting the browser out of the browsing experience by using a minimalist design rather than with implementing some funky ergonomics.
I think that its biggest hit is the extra space given to its user and I get the impression that  this extra space will make more of a difference for people WORKING thru the browser rather than simply consuming some passivly thru it, because this extra space makes you more productive. I don’t even see Chrome, yet with a few keystrokes I get any browser-specific functionality I need. I get the feeling that web-applications will need to be re-designed to work in Chrome and take advantage of Chrome’s extra space, for example Wordpress works atrociously in Chrome. 

Oh yeah, and the address bar is way better than Firefox’s. A few more tests and Firefox is history.

Later Edit: Firefox is history as far as I am concerned, I will be using Chrome.

Last thoughts on Chrome: Chrome is taking the browser out of web- browsing, it is almost invisible, when I am browsing I don’t see it at all, it has no edges and no menus, you only get the page that you are working on and its menus (this is why I said that web-applications may need to be re-designed in order to take advantage of the extra space that Chrome gives you, I am a bit confused when I am using Wordpress because where I now see Wordpress’s menus I was used to see Firefox’s menus). When I am toggling between pages I feel like I am toggling between 2 different applications.

You are probably familiar with Martin Fowler’s Technical Debt, a metaphor around the idea that doing things the quick-and-dirty way creates bad code, bad code which can be viewed as a debt which needs to be paid later in installments (the principal is the re-factoring of the bad code and the installments are the extra effort that this bad code forces on development). The concept was originally set-up by Ward Cunninghan.

Technical Debt is pretty much different from ordinary, everyday debt primarily because there is no creditor and no maturity date. Also, unlike regular debt, it is very hard to quantify. Technical Debt seems a bastardized version of regular debt in the sense that some development costs are identified as the principal (the re-factoring of the bad code) and some as the interest (the hacks used for dealing with this bad code) and it is built by taking some concepts out of the ordinary debt concept as the author sees appropriate in order to underline some development costs.
At the same time Tech Debt is defined exclusively from the point of view of the borrower who has to worry about paying the principal and the interest leaving out other actors (even though once you take the creditor out of the picture you have to wonder why you have to pay this debt at all ;-)). But, like Martin Fowler said at the beginning of his article, this is a metaphor, which leaves a lot of room for stretching various concepts. Fair enough.

However, Technical Debt seems to have been taken up and spawned quite a few siblings as you can see in this infoq article: liquid assets, moral hazard, fertile assets (???) etc…, which are either unfortunate enough to bear little or no resemblance to the original economic concepts they try to refer to or unfortunate enough to not refer to anything (fertile assets stands out as a prime example).
Let’s pick for example “Liquid Asset” which is defined this way: Perhaps the term “technical debt” focuses us on the wrong things; maybe focusing on the converse, on the investment side of things might be more effective.
First of all, a real-world definition: a liquid asset is an asset for which transaction costs are lower and for which there exists a market in which this asset can be sold and bought for a reasonable fee. Try to look into the above definition (or in this link which is provided next to it in the infoq example) and if you can spot the asset that is referred to, as well as the market in which this asset is sold and bought and the fees for these transactions please let me know.
Second, switching terms in order to motivate people displays how shallow these concepts are to begin with: if Technical Debt would be a concept that relates to somethings tangible in the real world, if it would manage to encapsulate a real problem or some real costs then Tech Debt should should not be swept under the rug for fear of under-mining the developers’ morale, but rather dealt with up-front because in doing so you would solve a real problem. The fact that Tech Debt is used the way this way points to the fact that it is so vaguely defined that few people can extract some somthing valuable out of it and that it can be stretched in any direction you want to.

What I see when I am reading the infoq article mentioned above are the first steps in the attempt to “marry” 2 fields which are pretty different one from another: economics and writing code and the excesses which appear when interest start to pick up in some vague concept (excesses similar to the introduction of the SOA concept). There is a desire to bring IT development under control and one way to look at it is to define costs and benefits associated with various actions and then apply economics to these costs and benefits in order to write code more efficiently. I don’t know where this will lead because we are at the beginning of exploring this.

As far as I am concerned I have developed an interest in economics a while ago and I read on it as much as I can. I also tried to “marry” the domains of writing code with and of economics, I even have an Econo-computing category, but I find it pretty hard. So far the only economic concept I found that can be applied pretty well to software development are transaction costs because they actually encapsulate pretty well some very real costs which arise when various entities are interacting one with another.

I will be following this Econo-computing field with a lot of interest and, who knows, maybe the concepts in this field will actually start to relate to something tangigle in the real world and will improve developer productivity.