Area51

Nešto o čemu razmišljam u skorije vreme je kako povući alate u pozadinu i omogućiti ljudima da ih koriste, a da ne moraju da imaju stalan kontakt sa njima i kada taj pristup ima smisla.

Primer jedne tehnologije koja se vodi tom logikom je Time Machine - backup softver koji dolazi uz novi Mac OS. Ne zahteva puno od vas - ako primeti slobodan hard disk ili particiju pitaće da li može da ga koristi. Recite Yes i to je to - od tog trenutka nadalje Time Machine će početi da pravi backupe i prestati da vas smara sa pitanjima.

“Nevidiljivost” ovog alata se ogleda u tome što se od vas ne očekuje ništa da bi on radio. Nastavljate da koristite računar kao i ranije, a Time Machine stoji u pozadini i radi svoje bez da vas cima ili da vi morate nešto da mu kažete. Kada vam zatreba fajl iz backupa on je na par klikova, ali do tad alat kao da ne postoji.

Softver za kolaboraciju i upravljanje projektima treba da radi na sličan način. Sama aplikacija je bitna menadžerima i ljudima koji upravljaju projektima, ali bi trebala da bude potpuno transparentna ostalim korisnicima. Oni bi trebali da mogu da je koriste bez potrebe da uče novu aplikaciju, novi interfejs, novi workflow. Idealno rešenje bi bilo kada bi sistem za upravljanje projektima i kolaboraciju bio sličan Time Machineu - vredan trudbenik koji radi u pozadini, integriše se sa ostalim aplikaciji i radi potpuno samostalno, a isplivava samo kada stvarno treba - da se izvuče neki izveštaj ili vidi kako stojimo i šta dalje.

Najveći problem koji imam pri JavaScript razvoju je konstantno mešanje konstrukcije, stilova i ponašanja u istom kodu.

Što se stilova tiče njih je relativno lako držati odvojene u zasebnom fajlu, ali opet se često dešava da se svojstva moraju menjati direktno iz JavaScripta… Ne mogu se imati klase baš za svaku moguću situaciju koja nam treba.

Kao što rekoh, stilovi nisu problem - problem je konstrukcija i ponašanje koje se kači na nju. Do sada nisam našao dovoljno fleksibilan metod koji omogućava jasnu separaciju između te dve stvari.

Kod PHP-a je lako jer on ne uključuje ponašanje već radi po run through principu (protrčiš i zaboraviš). Na primer, kada u activeCollabu korisnik zatraži projekat posetivši URL tipa:

http://projects.mycompany.com/projects/12

kontroler će od modela tražiti da učita projekat #12 i proslediti ga viewu da ga isti ispiše u pogodnom obliku. Run through - učita, ispiše, zaboravi da se ikad išta desilo.

Kod JavaScripta stvari ne idu baš tako lako jer HTML nije samo view već i konstrukcija. Evo ga primer:

$('<button type="button">Add option</button>').appendTo('body');

To bi u PHP-u bilo dosta - samo ispiši HTML i prosledi ga browseru. Ali, ovo dugme bez ikakvog ponašanja prikačenog na njega ne radi ništa. Zato moramo da dodamo ponašanje NAKON što je konstrukcija složena.

$('<button type="button">Add option</button>').click(function() {
alert('clicked!');
}).appendTo('body');

Ovo je samo jednostavan primer. Složeniji problemi mogu bili jako komplikovani sa jako mnogo nivoa konstruisanja elemenata i kačenja ponašanja na njih, intervalima i timerima, događajima… U celoj toj gužvi jako je teško jasno odvojiti slojeve što dovodi do koda od koga se ljudima često prevrne stomak kada ga prvi put vide.

PS: Primeri se oslanjaju na jQuery JavaScript biblioteku.

Sad baš videh na Web.Start sajtu da su snimci ovogodišnjih predavanja postavljeni ovde. Eto prilike da oni koji nisu bili vide o čemu se pričalo, a mi, kojima je kafana bila izuzetno draga, vidimo neka zanimljiva predavanja koja smo propustili.

Dok sam bio klinac i tokom srednje mogao sam da sedim po ceo dan i čitam. Sećam se da sam jedno leto stukao “Rat i mir” za manje od tri nedelje. Sada su stvari skroz drugačije - ne mogu da se zadržim na nekom tekstu duže od 3 pasusa, posebno na internetu. Uvek mi nešto drugo odvuče pažnju pa mi duži tekstovi stoje otvoreni u tabovima danima dok ih čituckam malo po malo.

Verujem da nisam jedini. Takođe verujem da nije potrebno mnogo reči da bi se prenela poruka ili obradila neka tema. Čini mi se kao da ljudi pokušavaju da natrpaju previše stvari u svoje postove kako bi obradili sve potrebne detalje. :

1. Prvo mindset - otarasite se osećaja da nešto mora biti dugačko i opširno da bi bilo vredno nečije pažnje. Čak je čest slučaj da ljudi upravo opširnošću pokušavaju da sakriju svoju neposobnost da kažu nešto konkretno. Setite se samo “sranja” na ispitima…
2. Kraći tekstovi, 250 do 500 reči, izlomljeni u par kraćih celina. Ta dužina se meni pokazala kao dovoljna da se nešto kaže, a da ne davi i ne zahteva dubok udah pre čitanja. Sve preko 1000, 1500 reči je previše ako mene pitate.
3. Ne mora sve da bude pokriveno jednim postom. Umesto jednog masivnog posta napravite seriju postova i tako u detalje obradite temu.
4. Koristeći liste možete osetno da skratite tekstove jer omogućavaju da se nešto opiše korak po korak uz zadržavanje konteksta. Ukoliko su elementi liste duži od par reči naznačite najbitnije stvari kako bi se lista mogla brzo preletati. Ako nekog baš zanimaju detalji pročitaće sve.
5. Pročitajte svoj tekst par puta pre nego što kliknete Publish dugme. Na taj način možete da izbacite gomilu viška i osetno podignete kvalitet teksta.

Kao i uvek, ne može se generalizovati. Nekada nešto mora da bude opisano nadugačko i naširoko. Ti slučajevi su ipak pre izuzetak, nego pravilo. Ovaj tekst ima nešto manje od 350 reči. Da li je preneta dovoljna količina informacija? Da li je rečeno nešto konkretno? Ja se iskreno nadam…

Ukoliko imate proizvod koji (pro)dajete u bilo kom obliku (setup.exe, skript, servis itd) pre ili kasnije će se pojaviti neko ko će želeti da se vaše rešenje prekroji kako bi odgovaralo njegovim potrebama. Naravno, vi ćete biti prvi kojima će taj projekat biti ponuđen kao neko ko najbolje poznaje samu aplikaciju i kod. U slučajevima kada ne nudite izvorni kod to je i jedino rešenje.

Nema ništa loše ni u prihvatanju ni u odbijanju takvog posla ako vidite zaradu u tome, ali postoji par stvari kojih treba biti svestan:

1. Da li taj projekat podrazumeva i usklađivanje prekrojenog rešenja sa novim verzijama koje izdate? Meni lično, a verujem da nisam sam, nema ništa gore nego terati dve ili više različitih grana u isto vreme. Vremenom će vam dosaditi i možda se budeti lupali u glavu zašto ste dozvolili da se za “sitnu lovu” tako obavežete.
2. Ovakvi projekti su uglavnom samo kratkoročna rešenja za dolazak do novca. Na duže staze se više isplati da ulažete u razvoj proizvoda i marketing.
3. Ne bi smeli da dođete u situaciju da trošite previše vremena na customization projekte i ugrozite svoj posao jer ne radite na samom proizvodu.

Ne može se generalizovati (softverska rešenja pokrivaju raspon od besplatnih do rešenja koja koštaju milione), ali moje je mišljenje da u prvih godinu dana nipošto ne prihvatate ovakve projekte. Umesto toga slušajte šta vaši korisnici traže i fokusirajte se na razvoj samog proizvoda. Teško da postoji išta što će se bolje isplatiti na duže staze od toga.

Što se našeg proizvoda tiče, mi smo se opredelili za kompletno otvorenu platformu sa dva osnovan metoda proširivanja - API i moduli. Ako to nije dosta, tu je sav izvorni kod. Na ovaj način naši klijenti imaju mogućnost da sami prilagode aplikaciju svojim potrebama ili da unajme nekog da to uradi za njih, a da mi nismo jedina opcija. Win-Win-Win ako mene pitanje - dobro i mušterijama i nama, a i drugim programerskim firmama koje mogu da zarade prilagođavajući naše rešenje specifičnim potrebama klijenata.