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.

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 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.

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.

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.

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…

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.

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.

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.

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.

I was watching this interview on infoq and I found that Gregor Hohpe pretty much voiced the same opinions, that as you scale out it is impossible to achieve state alignment at the time the operation and that you need to compensate for it by passing messages.These complexity costs are essentially the costs of managing business logic as it spawns across multiple systems, applications, departments, etc… State alignment in these cases consists primarily of having various business analysts agree on how these systems should interact (should this trade go to this depot for that security for that client) and then implementing the interaction between these systems. One thing that is not very obvious is that the cost of interaction between systems is pretty close to the cost of interaction between the departments running these systems and that as you scale out you need to be able to accomodate or change various departments you are encountering (*).

It is interesting to watch the interview from this point of view because you get to see the costly hacks that various organizations got to make in order to get their systems to talk to one another (the horrific “magic account” used in one bank makes one hair stand up). Gregor goes as far as saying that these ways to deal with these problems are pretty common, so common actually that at one point he gets defensive about the sloppiness which comes thru these examples. The fact that these problems are wide-spread is a pretty bad excuse, ideally these systems would be architected so that we do not need to add one layer of hacks on top of another in order to get something of value out of them.

At the end of this interview I ended up with the impression that we are on the first iteration of relaxing the ACID properties and that I got a pretty good glimpse into the costs associated with this relaxation. Sometime in the future patterns for relaxing these properties will appear and problems common in all these compensations will be solved. I think that these patterns will be more oriented towards business-logic and management rather than towards technology. Efficient interactions revolve around small transaction costs and minimizing transaction costs will be part of the solution of managing this growing complexity.

* Interestingly enough an SOA strategy will probably take these costs down if it manages to impose procedures so that various departments interact one with another more efficiently. However, I am pretty skeptical that we will see a lot of progress soon on this front.

Quickly I realized that I was cut-off from any source of information that I use because I access sites mostly thru their RSS feeds and my RSS feed reader was down. It was out of the question to go to those sites and read the news from their homepage (*) because those sites (BW, FT, Forbes,, Le Monde, infoq, etc…) have tons of content and I would not be able to navigate it in order to find what I like (this was what my RSS feeds were doing).
It was a pretty weird feeling to see how underlined how dependent I am on my feed reader and that my feed reader has become a single point of failure in my contact with various content providers. Take bloglines out and I am pretty much out of contact with pretty much anything I am following. And I don’t think that I can do much about it (**).
I can only hope that they come back up quickly…

* BTW, for a pretty interesting analysis oh how RSS changes browsing patterns please check out this post on Guy Kawasaki’s blog. The concept that “any page is a homepage” due to the various channels which are sending users to that page will change a few things in the content publishing business.

** Actually I could turn to my Google reader account to read the feeds from there, but this would mean that I need to update the OPML of my Google account, determine what stories are new and which ones I have read, etc… I could get past this single point of failure, but there are costs associated with it. Strangely enough, using Google reader as a replacement for Bloglines is similar to some work-arounds used for avoiding single points of failures in enterprise systems (synchronizing redundant machines).

Not a bad idea, the data would reside in this clustered cache and it would be made available to the application. One other thing that was considered was turning the whole architecture on its head and turn from the work-flow application into an EDA application. This is how it was supposed to come: the clustered cache came along with the capability of adding events to data as data was handled (inserts, updates, deletes, etc…). This would mean that while you previously had to have an MDB that was listening for a stock-quote request you could now code a stock quote object which you would throw in this clustered cache and which could listen for events. The clustered cache would have both flushed the stock quote objects to a database and would have call events on it. The stock quote object would in turn update other objects (let`s say positions for that stock) and while these positions would get updated they would fire more events in turn. A part of the business logic would be stored in these events and in the message passing that occurs between them, in a sort of event-driven-architecture.

The more I think about this, the more I get the impression that these events are nothing more than triggers in a database (the clustered cache taking on the role of the database). And coding your business logic in triggers is not a good thing if you listen to people with experience in database programming. Relationships between various entities and the interactions between them should probably be modeled at a higher level than at object level, when you are coding business logic in triggers you are essentially limited to that object’s scope.

Now, the idea of putting the business logic into these triggers comes from a pretty hard problem: the fact that for most artchitectures out there the data store is physically away from the code that is implementing the business logic, the database which holds the data and which needs to be consulted by the business-logic tier for data. Bridging this physical distance and the performance problems that come with it was solved in various ways: pushing the business logic into the database in the form of stored procedure, addind various caching mechanisms so that data is pushed towards the middle-tier, etc… In the example above part of the reasons for pushing the business logic into these events was you would effectively push the business logic into the new data-tier (the clustered cache in this case which would trigger these events). I would say that this is a pretty interesting approach with some benefits, but attention should be paid to minimizing the number of events (triggers) which get implemented.
A decade of PL-SQL development would recommend this…

I was pretty happy with Firefox 2 and I started using Firefox 3 only after a friend recommended it. I had some doubts, mainly when I was seeing the horrific address bar that Firefox 3 decided fit to implement. I have installed it, and after 3 days I wanted back to Firefox 2. My only beef (but a big one) with Firefox 3 is the address bar and the way it searches thru your browsing history and displays possible addresses you are trying to type. It is a great exercise in obfuscation, the new address bar manages to both hide away what you are typing (the font of the address bar is smaller than the font of the browsing history search results) and obfuscate the results of the browsing history search (bold-ing the hits of the word you type in the address bar causes further confusion as you are reading the results of the browsing history).

To make things even more confusing FF3 changed the way it searches the browsing history. Previously it was matching the address that you are typing against former URLs, now it tries to match the address that you are typing against URL, page titles, URL snippets, etc… in a pathetic attempt at mining your browsing history. In FF2 I used to be able to find my address with a few key-strokes, now my eye keeps scanning this list that FF3 dumps on the unsuspecting user:

I thought pretty seriously to go back to Firefox 2, but Firefox 2 will be discontinued in December. So I am stuck with this browser, let’s call it this way for lack of a better name. Frankly, I am waiting to run IE7 on my computer, it cannot be dumber than FF3.

Firefox 3 is to Firefox 2 what Vista is to XP. Period.

Later Edit Maybe I got too carried away, but what they have done to the address bar and to the address completion algorithm it is horrific. I really liked the way FF2 was displaying the addresses, it was clean, uncluttered and to the point. None like FF3’s address bar…

One reason that I see for this problem is the current misalignment between early education providers (such as high schools) and labor market. High school’s main goal is creating “better” human beings, its mandate is more social than economic. However with the tilting of the labor market towards jobs which require education it appears that education providers should also find a way to respond to economic concerns about the students entering an educational establishment.

I would say that we need shift the way we think about education towards economic concerns and insert some incentives into the educational process that reflect these economic concerns.

I don’t have time to finish this post, I will probably re-visit it later.

One very interesting thing that I come across pretty often is the fact that in large scale computing data tends to get de-normalized, basically it grows so large that you cannot fit the entities and the relationships between entities in the same database (this infoQ article is pretty good).
Let me give an example: suppose that you have table of users and a table or messages between users having these columns:
users: userID int, firstName String, lastName String, email String
user_messages: fromUserID int, toUserID int, messageTest String.
In the initial design a message from user A to user B would have only one record in user_messages and each user will be able to get the messages it has sent and the messages it has received from this table.
Now let’s say that the number of users sky-rockets to the point where you need to partition your database horizontally into a series of identical replicas. The problem that you will face now is where to store the data that is shared between these replicas, namely the table user_messages. You cannot store it either in the replica hosting user A’s data, neither in the replica hosting user B’s data and neither in its own instance because it will grow too large and because you will need to carry out a join over 2 physically remote databases. The solution is to drop user_messages for received_user_messages (from_user_name, from_user_email, message_text) and sent_user_messages (to_user_name, to_user_email, message_text) which will store the messages that a user has sent and the ones that it had received. Each database replica will have its own instance of these 2 tables each mapped to the user table. As you can see we are not storing the userID in the message tables, but rather the user information which was previously retrieved via joins.
Sending a message from user A to user B in this environment typically involves updating 2 tables in 2 separate database instances which usually is treated as a distributed transaction. However, you cannot carry out this distributed transaction because it is very costly so sometimes you resort to updating one table and sending a message to update the second table asynchronously (the overhead for delivering a JMS message is way less than the overhead for locking rows in the second database). In the case of updating the second table asynchronously you are still enforcing the relationships between the user table and the user message tables, but at a later point in time.
De-normalized data comes with synchronization costs: when you are updating the user information on the users table you will need to propagate the changes to received_user_messages and sent_user_messages so that the data stored in these tables will be up-to-date. This could be done via asynchronous processing as well, sending a message about data being changed on an ESB and having the concerned parties listening for and processing it. Synchronization costs should be watched very carefully because they could spawn a very high number of messages. Ideally we would synchronize data which is updated rarely (such as user information) in order to keep the number of synchronization messages down. Carrying out synchronization procedures in batches could be a way to deal with a large number of synchronization messages with the side effect that it may increase the latency with which the synchronization takes place.

Large scale computing typically seems to resolve around asynchronous processing (because in transactions message passing is cheaper than database access) and de-normalized data across with the overhead implied by it. The relationships previously enforced by normalizing data are usually enforced by passing JMS messages which carry out the data changes asynchronously. This design is driven primarily by the large volume of data which cannot be serviced by only one database and by the costs of carrying out a distributed transaction spanning 2 databases.
This is one design that I see emerging for large scale computing: de-normalized data along with asynchronous processes which are enforcing the relationships between entities via message passing.

It remains to be seen if this type of grid architecture will prevail in the future. Working against it is the emergence of multi-core processors which would allow for scaling up cheaply as envisaged by Brian Goetz in this article. If chips with hundreds of multi-cores and with large amounts of memory become reality scaling out could end-up costing more than scaling up and all the above could become history pretty fast. Scaling out will continue to make sense in some environments with humongous amounts of data (think Amazon, Google, eBay, etc…) but for the current fastest growing segment in grid applications, typically applications processing moderately large amounts of data, it may make sense to scale up once chips with a large number of multi-cores become a reality.

To watch…

P.S. These shifts in data processing (moving to a grid-type of architecture in order to accommodate the increase in data and then back to a single-box architecture because of the appearance of chip with a large number of cores) makes a pretty good case for abstraction in order to lower the costs of transition from one architecture to another. Ideally the architecture and the environment in which an application runs should not affect the business logic of that application. One way to insulate your application’s business logic from these infrastructure issues is by abstraction.

Pacat de el si de societatea romaneasca care ii impartaseste soarta…

A pretty nice picture of the future, but I don’t think anymore it will happen at a large scale because I think that data is the primary way that a company uses for binding an user to its services, an issue that I have briefly touched upon in this post. If the datastores get opened then the cost of user migration from one service to another goes down and with it the risk of seeing your users migrate to your competitors. The data a user creates while using a service, and not service’s functionality, is what makes a user continue to use that service because migrating to a similar service implies losing what the data that it has created.

One other road-block to exporting data and using it outside of the place where it originated is the way it will interact with the outside systems and the possible problem of standards: how will data from one service be packaged so that it can be consumed easily by other services? Exporting the data in some RSS format and mashing it up in a Yahoo Pipes fashion could provide a way around the thorny issue of standards.
Security is another issue that comes to mind when dealing with exporting data.

For some companies binding users to their services by locking their data down doesn’t apply and Netflix is a pretty good example: Netflix can open up their users data because their service is about renting hard-to-find movies and not about hoarding user’s data in one form or another (email services, RSS readers, on-line newspapers, etc… are all about storing users data and applying some sort of functionality to it).

So we will have to wait and see how this un-folds. Frankly I do not think that data will get freed any time soon, in a world in which user loyalty exists only in history books companies will try anything it takes to bind users to their services and this includes data hoarding.
Data will probably get shared (later edit: but it will not be free in the sense that we can cherry-pick who is using it and who is not) between the different services within a large corporation not across corporations or between various companies thru partnerships, but data will not be freed without constraints. Controlling the way a service’s data is made available to other services will bind a user to that service even more because giving up on a service will mean giving up on the data stored within that service as well as giving up on the integration between that service and its partner services (within or without the original service’s corporation).

Later edit: This is one example of how our data will be shared among various entities. The new portal as envisaged by Catherine Holahan is simply a way of storing user information and disseminating it into its partner sites. Interesting to watch…

I have looked a bit at this product, but for now I do not have the time to try it out, so I read up a bit on it and read some blog posts. The award for the most imbecile post written about S2AP goes pretty easily to Marc Fleury who manages to get it wrong from the title: SpringSource`s Application Server. To him S2AP is an application server which is coming too late to the market, the market being currently dominated by, you must have guessed it, JBoss. Pretty hilarious as well as also his musings about VCs. The point is that S2AP is not an application server because it doesn`t provide the services that an application server typically provides, it is just a platform for putting together an application.

Another interesting post comes from Peter Kriens about S2AP extending the OSGi container: probably Spring Source is leveraging the market share it enjoys in order to add some headers that it finds necessary for doing a better logical partition of an application. It is confusing to the people behid OSGi, and probably a bit unfair(**), but I guess it it part of the game.

The fact that you have more control over the way you partition an application into bundles will drive the specialization of components further. In the future you will probably buy specialized bundles which target a very speficic functionality and wire them up in the SpringSource Application Platform, Billy Newport`s hits the nail on the head in this post. You will not need to buy an application server from IBM or BEA or someone else only because you need a state of the art transaction manager and not use, while paying for, the rest of the capabilities that that application server comes with, but rather you will be able to buy only the transaction manager, plug it into your application as a bundle, expose its services and then integrate it into your application’s components.
This is probably where Spring has the potential to do the most damage to the traditional app servers vendors in the future because it will force them to un-bundle their app servers into offerings that will be sold on the market as single bundles (a transaction manager, a JMS engine, etc…) rather than integrated solutions. It remains to be seen how this will un-fold, but the potential for damage is there. The road towards un-bundling of application servers into specialized components is a very disruptive process (*) to both app server vendors and their customers and as a result it will take a while to become mainstream but I think that this is where we are going: to specialized components bundled into applications.

I would conclude by saying that the future of S2AP is a bit uncertain, it is a brand-new product targetting a fairly new market, the market for composing applications out of components in OSGi (***). If there is a need for this type of application composition probably Spring will occupy a large part of the market leveraging their brand, their product portfolio and know-how.
I wish them a lot of luck in this enterprise and I will follow it closely.

* I think that this is the most disruptive product to be released by the Spring people since the IoC container. It took a while for the IoC container to start having an effect in the JEE world, but once its benefits were recognized it revolutionized JEE. Let’s see if this will happen again.

** As Glyn has pointed out the OSGi-like headers are syntactic sugar. They created a bit of a confusion, but apparently it is getting straightened out.

*** Later Edit: I don’t know why but I get the impression that setting up a marketplace for these components would help their adoption. At the very least this would open a venue for people interested in trying them out and people interested in selling them.

Except that I find right now that I am pinned to Bloglines. Let me explain.
Any feed reader lets you export your OPML file which contains your feeds grouped into categorie and this feature pretty much lets you travel from feed reader to feed reader without many headaches. No feed reader would take its users hostage by refusing to export their OPML file because every user will refuse to be taken hostage in such a way.
However, if you use Bloglines’ pin feature a lot you will find yourself hostage to Bloglines because you cannot export the items that you have pinned and leaving Bloglines would also mean leaving behind the items that you have pinned and that are probably important to you. You cannot export these pinned items typically because this is a feature which is not widely-used by other feed readers and when it is used by other feed readers it is implemented in a variety of flavors which makes its export inefficient.

So I would say that I pretty much taken hostage by a feature. A niche feature, which makes a pretty interesting case for niche products: if you manage to get your user to create data while using your niche product, chances are that your user will be hostage to the data that it created and the feature consuming this data because this data cannot be exported easily to your competitors’ services. Pretty interesting…
P.S. Initially when I started pinning items on Bloglines I realized that I will be taken hostage to this feature and I thought about bookmarking them on del.icio.us. But I decided that I am too lazy for this. So I guess I’ll have to use Bloglines for quite a while…

I am wondering if the IOC realizes what these events are doing to its brand (*) because lately the Olympic torch has become the symbol of collaboration with a brutal regime which has to be put out rather than a symbol of peace and fraternity. I am also wondering how things will play out in Beijing, because this is where the next episode of this saga will probably play. Right now the torch is safely out of the Western world where dissent is allowed (**) and it is passing thru a string of authoritarian regimes where it will not encounter any serious resistance.
I would not be too surprised if the Olympic stadium will be empty, most of the Olympic tourists preferring to stay at home. I would not be too surprised if the Chinese government would fill this stadium with people picked up at random from the street. And I would not be too surprised if we will have some similar incidents in Beijing as well. If we do have these incidents the last place that I would be in is in IOC’s shoes: they would pretty much have to wait on the sidelines and pray that the Chinese government will not quell these dissenters (which happen to be all IOC customers) with too much brutality.

Personally, I think that these events are good. They are bringing home to the IOC the dangers of doing business with dictatorships: they could devalue your brand and beat the hell of the people that believe in your values in front of the cameras. Maybe they will think twice before awarding the place where the next Olympic games will take place…

* Unlike the IOC the Chinese government doesn’t have these PR problems. It will probably continue to act the way that it does, brutally that is, after all its interests lie exclusively in providing cheap labor to the Western world and using the gains from it for consolidating its regional position. China is light years away from having any meaningful dialogue with a regular guy living in the Western world.

** The fact that the IOC banks on the success of this torch-bearing missing on collaboration with authoritarian regimes will not be lost on many. If I were in a decision-making position within the IOC I would play down the passing of the torch thru these countries because it would stress this collaboration even more. After all, IOC’s main customer is living in the Western world and you probably don’t want to alienate it by playing down its values…

Knowing how a package implements some business requirement may make a developer pick up a method from that package and use it because it fits its requirements. Unchecked this may lead to spaghetti-code, pretty much everybody calling methods from all over the place in order to get their job done quickly.
Using restrictive access attribute (such as private methods) is not really a work-around, if someone thinks they need a private method to be made public because they “know” the package they will usually make it public without any second thoughts.

The right approach to interacting in a new way with a package or system is to delegate that interaction to that package, i.e. to code this interaction in the package itself if possible. As I was arguing in a previous post knowledge about a package is one of the transaction costs of interacting with that package. Transaction costs usually delimitate who does what because resources will typically cluster together into larger entities in order to bring these transaction costs down. Transaction costs, when handled correctly, will prevent methods whose usage requires extensive knowledge (and which carry large transaction costs) to be called from all over the application. Methods that get called from all over the application are typically methods about which little knowledge is required, helper methods being a good example.

So I would advise people to either make sure that whoever is using their packages either understands them well or very little, having people in the middle that think they “know” the package may result in incorrect usage of their packages.
I would also advise people to refrain from spreading knowledge about their packages indiscriminately and rather target the recipients of this knowledge carefully.

You have to wonder what is the relationship between Walmart and the producers of fair trade coffee: does Walmart reins in the urge to apply its enormous clout in order to drive the prices down on these producers, most of whom are pretty small and un-organized? Or it does apply its clout, but reluctantly? Or it doesn’t exert any price pressures on fair trade coffee producers and uses fair trade coffee to increase its appeal among a particular demographic?

Strange, I was a bit shocked to find this on a Walmart shelf…

BTW, the price for that coffee was pretty high by Walmart standards, I could have bought 2 1-liter coffee jugs (I can’t believe that coffee can be bought this way unless you have a coffee shop or something) for the price of 250 grams of fair trade coffee.

There are generally 2 sides to the privatization of health-care debate: the side pushing for the privatization of health care services, typically pro-business, and the side wanting the government to run health care services, typically leaning towards a social democracy-type model.
The pro-business camp’s opinion is that privatizing health care services would make them more efficient and would also transfer the burden to the ones willing and able to pay for them.
The pro-social-democracy camp argues that this would cause an exodus of health-care professionals from the public services, which are barely coping with the current demand and which pay less, to the private services which would pay more and where health-care professionals would work under a smaller work load due to the filtering of “customers” by price. They argue that this would result in further degradation of the public health-care services, due to an even smaller number of professionals working for it, which in turn would raise the incentives for leaving it. The public health-care services would enter a down-ward spiral whose end-result would be that the people using the public services, the neediest in this case, would have no access to health-care services anymore. I subscribe to the first part (the public services would degrade over time), but not the second (the down-ward spiral) because there are ways to stop this exodus.
For the health-care as a public service camp the smallest chink in the public access armor would essentially rip it open to the onslaught of private health-care.

The fact is that what both camps are focusing on is the way health-care services are distributed to people and not on the imbalances between the supply and demand of such services. Anyone with a pair of eyes would see that the demand of these services greatly exceeds the supply: long waiting times in emergency rooms, people parked in the hospital corridors for days, etc… And here things start to get interesting…
Let’s suppose that you decide to privatize health-care completely and let the market decide who is paying for health-care that it consumes. A good or a service that has the supply and demand imbalances that health-care has would see its price get big pretty fast. Big prices mean also big profits, and there is no surprise here that the pro-business lobby is pushing towards privatization because they stand to gain quite a lot from it.
Now let’s suppose that you decide to keep the status-quo and allow health-care to be delivered only thru government agencies. The result would be that everyone would get the same pathetic service or no service at all, and this is exactly what we are getting right now: everybody gets to wait 5 hours in an emergency room regardless of how wealthy he or she is.

Both the pro-business group and the social-democrats are arguing over the means to distribute this very small supply of health-care services to a population that has a high demand for it. Leaving health-care to the market would ensure that only the wealthy would be have full access to it, leaving it the way it is would ensure that we are all getting the same service. It is essentially an argument over the way to distribute this scarce resource and over the winners and losers that come out of each particular distribution mechanism. Each camp is trying to prove that its distribution mechanism will also allow for the supply to grow faster, but I am pretty skeptical about it (*). So I would argue that we should look at the root of the problem and try to stimulate the supply of health care professionals and to enlarge the med schools quotas to reflect the current demand for such services.

Except that we have a bit of a problem (**) if we simply try to : we are leaving next to the US which is more than happy to let the whole health-care field to market forces. As explained above the result is that in US (which experiences pretty much the same imbalances between supply and demand) the price for health-care is very, very high along with profits and salaries among other things. If we increase the supply in Quebec we run the risk of seeing health-care professionals leave for the US in search of better salaries and reduced work-loads (***), an exodus similar to the possible exodus from public health-care agencies to private health-care companies.

So we have a problem. This pretty much is known. What solutions to this problem? Frankly, I don’t know. I think that we need to increase the number of health-care professionals running the risk of seeing some of them leave for US. In US things could be changing if the democrats get the White House (some health-care would be administered thru government agencies driving down prices and salaries) and this could dampen the incentives for leaving to US.
Hopefully we will manage to get out of the grid-lock that we find ourselves in…

* The pro-market argument for growing the supply to align itself with the demand is the following: a good which experiences high demand but a low supply sees its prices rise along with the profits. Entrepreneurs will realize that it is profitable to join this market because of the high profits and will start selling more of this very profitable good. This would in turn will raise the supply to match the demand for it and inevitably bring down the prices.
I don’t buy this argument because in health-care the supply is pretty inelastic to demand since it takes a very long time to “produce” a doctor, about 15-20 years. In order to have the supply align itself with the demand you would have to carry out extensive demographic studies from which to determine the future demand for health-care services and tweak the med schools admission rates for the future demand. The fact that supply is inelastic to demand in health-care make say that the only thing that a market-based health-care system will achieve in Quebec is to redistribute resources and not to redistribute resources plus create new ones.
There are probably some services within the health-care industry in which the supply is more elastic to demand and it would be a good idea to leave them to the market.

** It is a problem or an opportunity depending on how you look at it: high prices in US could drive the government of Quebec to sell some health-care services to US and use the money which these services would generate for funding other health-care services.

*** The fact that we have the US in vicinity renders a lot of the comparisons between Quebec and France moot: a French doctor doesn’t have the option of packing up his or her belongings in a minivan and drive 300 kms to his or her new workplace in US. This puts a downward pressure on health professionals salaries in France thus reducing the health-care costs.

P.S. I am seriously thinking about starting to write this journal in French, but I don’t have much experience in writing in French and I think the first posts would be absolutely ludicrous (I will be probably missing all the accents ;-)). I’ll see what I’ll do.

P.S.S. I like economics and I wrote this post mainly for applying my knowledge of economics to what I know about health-care in Quebec. I have not researched deeply how health-care is being regulated and implemented in Quebec, I just wanted to try out some concepts. Hope I got them right…

Regarding my use of testing I would say that JUnit pretty much fills my bill and I don’t see a need to move to TestNG. I was watching the presentation not so much as to know more about TestNG, but to get some exposure to the market for testing products (*). So the features which were presented and which were said to be in a high demand from the users were the ability to define test groups, to test data connectivity and to define dependencies between tests (**). Pretty fair, I would take this functionality to be a logical progression from the ability to run a bunch of tests at random as JUnit lets you do it, you are basically starting to look at the tests you run from a higher level and you start looking for ways to aggregate these tests into higher-level constructs, such as test groups, which can then be manipulated according to various needs.
So far I would say that Test NG is looking at ways to manage the complexity coming out of a high number of tests. Test NG is for test-heavy shops, where testing is considered a concern on par or close to development. Not a bad thing and I pretty sure that TestNG covers some functionality which is in high demand by Java developers.

There is, however, one need for testing that so far it is largely unsatisfied and sorely missed: the need to test workflows or series of events. Let’s say that you have an application that is a series of MDBs, each accepting messages, transforming them and then outputting them to the next MDBs. You would want to be able to test this application end-to-end.
Let’s say that you have an application that receives market trades, needs to process them and then transform them in order to send them downstream to tax systems, settlement systems, etc… You would want to put thru a trade, set-up in a certain way and then trace its execution thru these flows and determine if, in what stage and in what shape has this trade reached the Application-to-Tax-System gateway.
When I think about work-flow testing I usually think about defining a message, inputting this message into a work-flow engine and then defining interceptors to see how the original message has been manipulated at various stages. You may need to test both the work-flow itself (to see if the message has been going thru the work-flow that it needed to go thru), the end-result (to see where the message has been forwarded to and in what shape) as well as how it behaves at various stages in this workflow (if needed). I see work-flow testing primarily concerned with interception of messages (and this would probably be a great use of AOP) and with the possibility to correlate messages passing thru this work-flow with the original message.

OS testing tools so far are limited to synchronous testing. I wonder at what point will the need for work-flow testing become so pressing and the demand for it so great so that one OS shop will start doing something about implementing a testing framework for testing workflows. Then we could use Event-Driven-Testing for testing an application written in a Event-Driven-Architecture manner…

* I know that trying to form an opinion on a market such as the market for OS testing tools from a vendor presentation is a pretty risky business, what you get from vendor presentations is usually distorted because of bias and time constraints but I will assume that this presentation gave a fair image of what users want from testing tools.

** From what I know TestNG is a lot more than some annotations that give you the possibility to form test-groups and test dependencies. However, I would say that these issues are probably considered more important and more aligned with the market for OS testing tools since they were the ones which were included in this presentation.

P.S. If I were to choose one enterprise concern which is not addressed by the Spring stack I would choose work-flow. Spring h