taavi

Sellel teemal milline programm on ilus on kirjutatud hunnik raamatuid. Pea igas firmas, mis programeerimisega tegeleb on olemas mingid reeglite kogud.

Väga lihtsalt on kõik need kokkuvõetud sellel karikatuuril WTF/minute metrics.

Huvitav, milline võiks olla enda kirjutatud asjade WTF/min paari aasta pärast kasvõi iseendal vaadata..

Täna oli kontoris väike arutelu teemal, kas ning kuidas õnnestuks ära kasutada üha populaarsemaks muutuvaid sotsiaalse võrgustiku vidinaid internetis.

Järjest kerkisid üles igasugu edevad märksõnad nagu twitter, facebook, keskus jne.. Edasi tuli loomilikult igasugu sügav tehnoloogiline jutt, kuidas neid ära kasutada ja sisuda. Jutu sisse tekkisid märksõnad nagu openid, REST.

Edasi hakkasid juba endal mõtted keerlema, milliseid vahendeid nendega tegelemiseks on kättesaadaval. Loomulikul uurisin kiiksuga inimesena (erlangi fännina s.t.), mis komponendid on olemas või lihtsalt teostatavad. Ringi surfates ja googlisse märksõnu toksides jäi silma, et ka needsamad suurte märksõnadega saidid kasutavad erlangi seal kus otstarbekas.

Tulemused umbes sellised:

• twitter, facebook – http://debasishg.blogspot.com/2008/08/erlang-as-middleware.html
• del.icio.us – http://blog.socklabs.com/2008/07/delicious_is_gone_long_live_de
• twitteri kloon twoorl – http://yarivsblog.com/articles/2008/05/28/announcing-twoorl-an-open-source-erlyweb-based-twitter-clone/
• AMQP – RabbitMQ
• erlyweb – http://erlyweb.org/
• scalaris – skaleeruv, veakindel, struktueeritud, transaktsioonidega p2p storage mootor
• CouchDB – http://incubator.apache.org/couchdb/

Ühesõnaga hunnik huvitavaid töövahendeid üsna valmis kujul olemas. Järsku peaks midagi neist ehitama? Materjali nagu ju oleks? Ja pagan, kui Yariv kirjutas twitteri klooni 2-3 päevaga..

IDC uuringust 139 organisatsiooni tarkvaraga seotud protsessidest tuleb välja, et vigade otsimise keerukus on järjest kasvav ja järjest kulukam. Ühe põhjusena tuuakse välja popi ja noortepärase SOA arhitektuuri kasutamine.

Software debugging costs rise; SOA blamed

http://blogs.zdnet.com/service-oriented/?p=1148
http://www.scmagazineuk.com/Cost-of-fixing-software-defects-runs-into-millions/article/112597/
http://www.infoworld.com/news/feeds/08/07/23/Faulty-complex-in-house-software-costs-companies–says-IDC.html

SOA gets a share of the blame for the escalating costs. The report
cites “increased software complexity from multicore, Web 2.0 and SOA”
that not only make bugs more prevalent, but also more complicated to
fix. As IDC put it: “The increased complexity of software development
environments and the cost of fixing defects in the field (rather than
early in the software cycle) combine in exorbitant ways to drain
income and to hamstring businesses as a result of critical software downtime.”

Eks ta nii pea olemagi – mida keerulisem on mingi süsteemi ülesehitus ning mida rohkematest komponentidest ta koosneb – seda keerulisem on sellest vigu leida. Võtame kasvõi Sveitsi noa – tükk aega läheb aega enne kui kümmnete kokkukomplekteeritud vidinate hulgast leiab noa üles aru saamaks, et tera on nüri ning essugi ei lõika. Tavalise pussnoa korral on hulka lihtsam debugida, et tera on nüri;)

Sama tähelepanek ka igapäevasest tööelust – rakendusi aetakse ühe keerulisemaks pannes sinna kõiki kolmetähelisi lühendeid SOA, XML, igasugu serviceid aga iga üksiku töövoo probleemi tagaajamine selles rägastikus muutub aina keerulisemaks. Isegi kui konkreetne ülesanne ise on ääretult lihtne, siis tegelikke tegevusi kümmnete kihtite vahel lihtsalt ei leia üles.

Tänaseks on eelmises postituses kirutud probleemid juba ajalugu. Rakendus on olnud umbes kolme nädala jagu toodangus ja ptui.. ptui siiani igati edukalt töötanud.

Kokkuvõtteks:


1900 rida erlangi koodi s.h. kolmanda osapoole komponentide emulaatorid
480 rida VXML-i


Aega umbes 2 töönädalat. Põhiline sellest aru saamaks, mis loom see vxml on. Erlangi osa läks suhteliselt valutult. Paar gen_server moodulit, supervisor, application, paar API moodulit, hunnik emulaatoreid keskkonna testimiseks. Kõige rohkem aega erlangi poolel kulus xml’i parseri kenasti streaming reziimis tööle panekuks.

Umbes võrreldava (aga mitte täpselt sama) funktsionaalsusega rakendus javas 8300 rida koodi.

Midagi pole öelda, ka siin leiab kinnitust Ulf Wigeri tees 4 kordsest produktiivsuse kasvust võrreldes muude vahenditega [http://www.erlang.se/publications/Ulf_Wiger.pdf].

Viimasel paaril päeval on tulnud kokku puutuda IVR e. Interactive Voice Response süsteemidega. Kahjuks on ka sinna jõudnud popp ning noortepärane idee, et absoluutselt kõike tuleb kirjutada .xml formeeringus.

Kõige hullem, et kui juba üks kord on hakatud xml’iga tegelema, siis ei saada enam kuidagi pidama. Kõike üritatakse sama vitsaga lüüa.

Näiteks Hewlett-Packardi OpenCall Media Platvorm. Sellele pakutakse ilusti development kit’i. Aga oh õudust – see ütleb mingi konfiguratsioooni faili peale – “unable to parse, moving to corrupt.xml”. Kõik on kena, xml’i tagid klapivad, mingit imeasja ei ole – aga ei ole konfiguratsioonifailiga rahul.

Pusid pool päeva sadade xml konfifailide vahel, aeg-ajalt paned käima ühte või teist O&M rakendust, ikka ei toimi. Ikka ei parsi. Siis lõpuks leiad kuskilt failist üles mingi rea kujul <license expires=”11/2007″/>. Ning kuklataga hakkab lööma kella – äkki, äkki on mitteparsimise põhjus vananenud litsentsis?. Pealse sadu muutmisi, paned igaks juhuks arvuti kella aasta jagu tagasi – ja ennäe – xml on kohe paremini parsitav;) Vähemalt rakenduse sai käima!

Hea! Aga kahjuks mitte kauaks. Serveerid voice browserile omast arust täiesti pädevaid .vxml dokumente, see väidab ikka, et “unable to parse: (null)”. Surfad kasutajaliideses ringi, leiad mingi valiku – recent ccxml calls. Sealt saab siis vaadata, mis on toimunud. Ette manatakse .xml formaadis CDR, mis on siis koht kus on kirjas reaalne veateade. Ja jälle nurksulgude vahel mingite tagide vahel. Koos lehekülje jagu muu läbuga.

Kiri – “unable to parse vxml”. No mida see siis veel tähendab? Dokumenti serveerides on on ilusti mime tüüp kaasas application/voicexml+xml nigu RFC-s nõutakse, no mis häda veel saab olla? Jälle tunnike-paar hiljem on selgus käes, tuleb täiega ära näidata dokumendi schema.


<vxml xmlns="http://www.w3.org/2001/vxml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/vxml http://www.w3.org/TR/voicexml20/vxml.xsd"
version="2.0">


No pagan.. Tahab valideerida? Siis kui on vaja tempokalt reaalajas kliendiga suhelda? Tõmba veebiserverist seal jooksupealt genereeritud xml, parsi seesama xml, valideeri ja samal ajal katsu sammu pidada muusikaga, mis kliendile telefonitorus kostub?

Siis veel mõned juhuslikud vead, kus <var name=”number” expr=”0″/> peab kohati olemas ülakomade vahel, kohati mitte või ümbernurga <assign name=”number” expr=”number+1″/>. Need saab juba kiiresti ära parandatud. Kuniks päevase pusimise tulemusena öeldakse mulle “tere taavi” minu enda käreda häälega. Toru esialgu veel hargile ei panda. Aga see selleks.

Oeh, miks ei võiks selle asemel olla üks hea rakenduse kohane spetsialiseeritud keel (Domain Specific Language). Kus saaks kohe kirjutada muutuja=väärtus või midagi sellist lihtsat.

Aga aitab, on noritud küllalt. Homme maadleb edasi..