Un articol mai vechi, insa totusi interesant: Microsoft is dead.

Foarte amuzant:

http://www.aegisub.net/2008/12/if-programming-languages-were-religions.html

Not everything is an object

Am ştiut, dar nu prea am crezut, că de fapt mai exista şi altceva în afara de Java şi .NET care cu adevărat să fie folosit şi în afara mediului academic atunci când vine vorba de un anumit tip de aplicaţii. Mă refer aici la acele în care ţi se cere repede să implementezi ceva, un proces în afacerea clientului, sau o bază de date cu nişte informaţii mai structurate dar şi cu un „mic program” în faţă, sau orice costă prea mult să fie cumpărat la cutie şi apoi adaptat, şi se decide că e mai bine să fie dezvoltat from scratch. Dacă astfel de aplicaţii fac parte din domeniul tău de activitate, tu (ca firmă) nu prea ai curajul să te axezi pe altceva în afară de Java sau .NET.

Odată pentru că ai nevoie de o tehnologie în care să poti face de toate, pentru că aplicaţiile tale nu au nimic specific. Apoi esti constrâns de timp şi bani deci nu prea pui mare preţ pe optimizări/performanţă (decât izolat în anumite zone); şi oricum în mare parte în aplicaţia ta e vorba de „data input”, GUI şi rapoarte. Iar cel mai mult contează faptul că ai nevoie de oameni. Mulţi. Sau, mă rog, mai mulţi decât găseşti. Şi nu-ţi permiţi să dai anunţuri în care ceri cunoştinţe despre tehnologii elitiste. Şi motive ar mai fi (ai nevoie de biblioteci scrise de alţii, ţi se impune o anumită tehnologie, etc.), dar nu ele mă interesează acum, ci faptul că această folosire în masă a celor două tehnologii, care în esenţa lor nu prea diferită cu ceva, îţi formează gândirea, vrei/nu vrei, după modelul pe care îl implementează. Adică OOP. Ajungi să vezi totul prin prisma acestei paradigme şi, după un timp, cumva, uiţi că OOP de fapt nu e nici singurul drum posibil, nici cel mai bun.

Am avut ocazia în ultimul an să lucrez cu un sistem care are la baza sa nişte idei mai neobişnuite. Mai exact, este profund relaţional. Se numeşte Remedy şi e un fel de application server (de fapt mi-e greu să-l bag intr-o astfel de categorie pentru că e atipic din multe puncte de vedere, dar probabil application server i se potriveşte cel mai bine). Iniţial a fost gândit ca o soluţie pentru Help Desk (acel departament din fiecare companie mai mare la care suni dacă ai o problema – oricare ar fi ea) unde procesele se incadrează intr-un tipar destul de bine definit; a fost gândit ca un workflow engine dacă vrei, însă mai târziu a fost aplicat cu succes şi în alte zone.

Vine cu două aplicaţii client: una pentru dezvoltare (aplicaţiile se dezvoltă şi există numai pe server) şi una pentru utilizare (echivalentul unui runtime – ceea ce ai nevoie să fie instalat pe calculatorul tău ca să foloseşti aplicaţia). Iar aplicaţia constă într-un set de obiecte (nu în sensul OOP!) care se ţin pe server. Nu există cod sursă, fişiere, compilare sau alte lucruri cu care suntem obişnuiţi să lucrăm.

Sistemul e aplicat cu succes în industrie (ba chiar e destul de scump şi puţini şi-l pot permite) şi, ceea ce e cel mai important, chiar functionează! Cu volum de date mare şi cu flux de procesare complex. Am avut ocazia să vad aplicaţii surprinzător de complexe puse în producţie şi funcţionând destul de bine, cu sute de utilizatori conectaţi simultan şi nu puţine date de prelucrat. La capitolul performanţă nu stătea deloc rău (cred că aici marele beneficiu al lui Remedy este că se întelege bine cu baza de date din moment ce vorbesc acelaşi limbaj; lipsa unui ORM cred că se simte considerabil în performanţă).

Fără a intra prea mult în detalii, voi încerca să explic cum vede Remedy lumea prin ochelari relaţionali. Cărămida de bază este un ecran GUI (form), cu butoane, meniuri, câmpuri text, etc. Un ecran se construiește la clic de mouse, cam ca în orice Designer de interfețe GUI. Ecranul se mapează (destul de) direct cu o tabela din baza de date și, în principiu, fiecărui câmp de pe ecran (textfield, combobox etc.) îi corespunde o coloană din tabelă. Legătura dintre ecran si tabelă e directă. La o arhitectură clasică 3-tier între ecran (client) şi tabelă (sursa de date) ai în mod normal implementarea proceselor (application server). La Remedy, insă, nu. Pe ecran se pot şi efectua şi cele 4 operaţii de bază din DML. Ecranul are 3 moduri posibile: search, submit sau modify în funcție de ce operație cu baza de date se face: select, insert sau update (există și delete, însă ca acţiune – nu are echivalent intr-un mod de ecran). În absența oricăror alte lucruri, ecranul este o interfață directă pentru tabelă, fără nicio prelucrare de date.

Pentru prelucrare de date, la ecran poți atașa un set de acțiuni cu care poți construi foarte repede un workflow. Acțiunile intră în 3 categorii:

1. Acțiuni executate pe client și declanșate de un eveniment ce ține de client (click pe un buton, selectarea unei valori în combobox)
2. Executate pe server și declanșate de un eveniment ce ține de server (o operație cu niște date – insert, update, delete)
3. Executate pe server și declanșate pe baza unor reguli de timp (de genul “rulează din 5 in 5 minute în fiecare vineri”)

Aşa îşi construieşte Remedy aplicaţiile: ca nişte colecţii de ecrane cu acţiunile ataşate. Mai există încă o serie de obiecte pe care le ai la dispoziţie, însă nu prea multe, şi cam asta e tot!

Cam prea simplu, nu? E adevarat. Sistemul e ceva mai complex de atât. Ecranele sunt de mai multe feluri (îţi permit join-uri sau surse de date externe), există o serie de posibilităţi de integrare cu sisteme externe, există web-service-uri, versioning control, suport pentru clustering, sistem de licenţiere, sistem de securitate (predefinit însă surpinzător de flexibil) şi multe altele care nu îmi vin toate în minte acum, marea majoritate fiind accesibile la clic de mouse.

Bun, să nu ne facem totuşi iluzii: are şi el limitările sale. Unele sunt chiar absurde (de genul: „maxim 255 de caractere pentru sirul X în acţiunea Y”) şi mă enervează la culme. Şi are şi module prost gândite şi instabile (unele făcute chiar în Java). Orice grădină cu buruienile ei, nu? Însă dacă e să privesc totul în ansamblu văd multe lucruri bine gândite şi implementate. Văd idei bune care au fost cu success puse într-un produs funcţional şi viabil din punct de vedere economic. Eu sunt foarte entuziasmat de el. Mi-a demonstrat că se poate!

Simple Service Discovery Protocol

În timp ce sniffer-eam traficul pe un Windows XP am observat un protocol ciudat în lista de acolo. Se numea SSDP. S-ar putea să-l găseşti interesant pentru proiectul tău de indentificare automată a serviciilor dintr-o reţea.

Mai multe detalii:
http://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
http://quimby.gnus.org/internet-drafts/draft-cai-ssdp-v1-03.txt