Planeta Srbija

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 kasnu 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:

var add_option_button = $('<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.

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:

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

Odavno znam da je u nekim OO jezicima moguće pozvati privatnu metodu (ili pristupiti privatnom atributu, sasvim je svejedno), ali nikad nisam naleteo na tu vrstu problema, pa se nisam preterano ni udubljivao. Međutim malopre sam naleteo na diskusiju na ESu gde je postavljano pitanje na koje bi odgovor mogao da bude baš ovo.

Princip koji se koristi da bi se ovo postiglo je refleksija. Wikipedia za refleksiju kaže da je to proces u kome program prati i menja svoju strukturu i ponašanje. Deo sa menjanjem ponašanja je upravo ono što nama treba.

Ukoliko sami pišete ceo projekat bez korišćenja bilo kakvog frameworka verovatno Vam ovako nešto nikad neće ni trebati, ali mala je šansa da ćete uvek svaki projekat raditi od nule. Jednostavno previše vremena oduzima, a ne treba izmišljati toplu vodu i raditi nešto što je neko već uradio. A kad već koristite tuđe delove koda može se desiti da bi Vam baš zgodno bilo da možete da  pozovete neku metodu ili da koristite neko polje za koje je autor smatrao da Vam nikad neće trebati. Te metode nisu privatne bez razloga, tako da se trudite da izbegnete da radite ovo (zvučim kao oni sa TV-a : “Ovo su radili uvežbani profesionalci i ne pokušavajte ovo kod kuće” ).

U svakom slučaju, potražio sam kako da uradim ovo u dva jezika koja trenutno naviše koristim. U pitanju su Python i Java.

U Python-u je metoda privatna ukoliko joj ime počinje sa dve podcrte, a ne završava sa dve podcrte. Pošto je u Pythonu sve objekat (i moduli, i klase, i metode…) sve se može uraditi u jednoj liniji (u ovom kodu poslednja linija):

#!/usr/bin/env python class T: def __test(self): print "Privatna metoda __test iz klase T" def test(self): print "Javna metoda test iz klase T" self.__test() if __name__ == "__main__": t = T() t.test() try: t.__test() except AttributeError: print "\t***Pokusaj pozivanja privatne metode klase T***" t.__class__._T__test(t)

Što se tiče Jave, stvari su malo komplikovanije (zar može jednostavnije od Python-a ):

public class A { private void echo() { System.out.println("Iz klase A"); } } import java.lang.reflect.Method; public class B { public static void main(String args[])  { try { A a = new A(); Class c = a.getClass(); Method m = c.getDeclaredMethod("echo", new Class[0]); m.setAccessible(true); m.invoke(a); } catch (Exception e) { e.printStackTrace(); } } }

Pokušao sam da nađem kod i za C++, međutim kad nakon par minuta googlanja nisam pronašao odustao sam (ipak je pola 7 ujutru ), ali zbog same strukture jezika pretpostavljam da ovako nešto nije moguće uraditi u par linija koda. Sam C++ ne podržava refleksiju, ali koliko znam postoje neki mehanizmi, kao na primer korišćenje podataka za debug-ovanje koje kompajler ugrađuje u izvršne fajlove, korišćenjem dynamic_cast operatora ili čak menjanje samog kompajlera, međutim ni jedno rešenje mi ne deluje kao nešto što mi je potrebno u ovom trenutku… Sledeći put…

Najnoviji download rekorder - Firefox 3 je na raspolaganju i to je bajata vest. U nastavku posta opisaću hak kojim možete poterati i dvojku i trojku (na Windowsima). Ako ne vidite razlog da to imate na raspolaganju u ovom tranzicionom vremenu, podsetite se da još uvek nisu sve ekstenzije (add ons) iz dvojke prilagođene za trojku, ukoliko razvijate neki web zgodno je proveriti “look and feel” u obe verzije… itd.

Hak se zasniva na manje poznatim Firefox profilima (više korisnika na jednoj instalaciji). Najpre se u dvojci otvori novi profil, potom se instalira trojka (ali ne preko dvojke) i onda se trojka pokreće iz tog novootvorenog profila, čime se verzije “ne kolju”… evo postupka.

1. Otvaranje novog profila u dvojci

U Start/Run otkucajte:

firefox.exe -ProfileManager

otvoriće se dijalog u kojem ćete se lako snaći… klik na “Create profile…”… nazovite profil recimo firefox3.

Nešto detaljnije uputstvo imate ovde.

2. Instalacija Firefoxa 3

Preuzmite instalaciju, i pokrenite je… sve ide standarno (Custom instalacija) osim, što treba paziti da se ne “pregazi” dvojka. Dakle kada se ne dijalogu ponudi putanja poput ove:

C:\Program Files\Mozilla Firefox

promenite je u (dodajte tu trojku na kraj putanje):

C:\Program Files\Mozilla Firefox3

Nemojte instalirati ikone, da ne unosite zabunu, a trojkin Start Menu folder neka se zove Mozilla Firefox3

3. Start Firefoxa 3

Iz Start/Run pokrenite

"C:\Program Files\Mozilla Firefox3\firefox.exe" -P firefox3 -no-remote

…odnosno vi stavite tu putanju do vašeg foldera gde je instaliran FF3. Ono firefox3 iza -P je ime profila koje ste dali u koraku 1.

Naravno, jednostavnije je napraviti batch datoteku sa ovom komandom i trojku pokretati tako.

Verovatno ste čuli za Joint Strike Fighter(JSF). Cilj projekta je da se napravi borbeni avion koji bi objedinio potrebe sva tri roda vojske. Bilo je nekoliko emisija o razvoju ovog aviona na kablovskim kanalima. Ono što verovatno niste znali, je da je softver koji pogoni ovaj avion pisan u C++u. Za one hardcore C++ programere, ovde se nalazi dokument standarda kodiranja, koji koristi razvojni tim. Embeded sistemi, ugrađeni u ovakav avion, zahtevaju real-time izvršavanje(zamislite posledice u suprotnom), te su na primer, izuzeci(exception) i upotreba operatora new standardom zabranjeni.

Međutim, ovo priča nije toliko dokaz o upotrebljivosti i mogućnosti široke primeni C++a, koliko je dokaz da je vojska digla ruke od jezika Ada. Čime je, praktično, ozvaničena smrt Ade. Na širem planu, ovo nas podseća na nešto još važnije. Da koliko se god trudili prethodnih decenija da kvalitativno unapredimo postupak razvoja, uvek bi dolazili u ćorsokak. Rezultati su bili samo kvantitativna poboljšanja, merena jednocifrenim faktorom. Formalna specifikacija. Verifikacija i validacija. Transformacioni razvoj. CASE alati i generisanje koda. Sva čuda softverskog inženjerstva su bila tu,  ali rezultati nikada nisu zavredili veću pažnju. Sve te tehnike gotovo da nikada nisu videle širu primenu. Opet smo se vratili na početak. Na C++, kakav god on bio. Bolje, izgleda, nemamo.

No da što kraće pokušam da zaključim celu priču. Mnogi će izgleda morati da pročitaju taj „No silver bullet“. Razvoj softvera je ipak inherentno složen proces. Rešenje problema nećemo ugledati skorije. Iskren da budem, mislim da rešenje nećemo nikada ni naći. Možda zato što ovaj problem i nema rešenje.

Evo kratkog videa (od pre par nedelja) u kojem se mogu sagledati kratkoročni trendovi u oblasti web klijentskih tehnologija. Ovog puta, direktno od Džona Resiga, oca jQuery biblioteke.

Zar je zajednica domaćih programera iz ovih tehnologija toliko mala, škrta ili zauzeta da se ne možemo organizovati da se sa sličnim video prilozima sistematično informišemo?

Kratki hint, ukoliko želite postaviti boju GTK widgeta direktno iz koda (a ne preko resurs fajla), ovo je način da se to uradi:

GdkColor boja; gdk_color_parse("#F3F3F3", &boja); gtk_widget_modify_bg (my_widget, GTK_STATE_NORMAL, &boja);

Funkcija gdk_color_parse kao prvi parametar prihvata opis boje, i kao što vidite, moguće je boju postaviti i u HTML formatu.

Ukoliko želite da postavite boju GtkLabel widgeta, na primer, najbolje je da ga stavite u GtkEventBox, pa onda njemu menjate boju.

Nakon mog prethodnog članka o povećanoj potražnji web programera, naleteo sam na analizu tog stanja od strane jendog web preduzetnika sa Kipra. Jasno se vidi da je (iz čiste, meni poznate muke) duboko razmišljao o svemu… a evo i po njemu osnovnih razloga zašto postoji nestašica PHP programera (namerno nisam preveo):

PHP is an ugly language PHP is newbie safe PHP avoidance PHP is rich with secondary reasons PHP is getting mature

Impuls koji je izrodio ovaj post bio je komentar na taj članak… kaže čovek… (PrettyCoder) … da ga sve to podseća na razgovor sa neudatom ženom u poznim tridesetim:

ONA: Gde su nestali svi ti pravi/dobri muškarci?

ON: Svi smo već zauzeti… a ono šta tebi preostaje je:

nađi najboljeg među lošima/slobodnima… ili… ukradi pravog/dobrog oženjenog

Na kraju krajeva skoro svi poznajemo žene sa takvom socijalnom pozicijom.

Na kraju krajeva skoro svi poznajemo preduzetnike sa takvom poslovnom pozicijom.

Evo priznajem, nisam imun na omiljeni domaći sport “smatranje i ukazivanje” o (svim) domaćim pojavama i problemima. “Ukazivanje” za danas su teško podnošljivi, te pojačavajući trendovi na domaćem IT tržištu koji se valja već mesecima (možda i godinama) unazad. Ne verujem da ću većini reći nešto novo, ali niko o tome ne priča… Ukratko… svakim danom povećava se tražnja i smanjuje ponuda za IT uslugama na domaćem tržištu. Tržište, u skoro pa kompletnom integritetu, već funkcioniše - te su neminovne posledice toga - povećanja cena. Mali preduzetnici u oblasti razvoja softvera, poput mene, to već vide, zaziru i preorijentišu se - što manja firma to brže promene. Ukrupnjavamo se, prodajemo strancima, orijentišemo proizvode na globalno tržište… čak smo počeli da tražimo stranu radnu snagu (!?)…

Tražite li web programere? Naravno, pa to danas svi rade!

Evo nekoliko uzroka:

Škole i fakulteti ne proizvode dovoljno upotrebljivih kadrova, već na fakultetima uglavnom “profesorske” firme regrutuju “kajmak” generacije. IT stručnjaci se sve više specijalizuju, nema više univerzalaca i klinaca “koji sve znaju”. Jednom rečju - opasna nestašica ljudskih resursa. Barem u Novom Sadu otvoreno je u poslednjih godinu-dve, nekoliko desetina (sa ili bez kancelarija) stranih firmi, koje su potpuno orijentisane na strano tržište (uključujući i “profesorske” firme). One su prosto “posrkale” ono malo ljudskih resursa. Znam to po broju ljudi koji mi se jave na oglas za posao. Investicije su lepa stvar, ali recimo IT park u Inđiji (sa u Srbiji trenutno neizvodljivih 2500 ljudi) može “sahraniti” male domaće IT firme - ostaće prosto bez ljudi. Pritom sigurno neće raditi za domaće tržište. Domaći kupci IT usluga, pritisnuti sve krupnijom konkurencijom, pokušavaju da izvedu optimizaciju svog poslovanja primenom IT-ija, i stvaraju povećanu tražnju. Prečesto, firme (pod 3) žele napraviti neki reverzni inženjering već postojećeg (po pravilu stranog) IT sistema, stvarajući nepodnošljivu apsktrakciju ovakvih sistema. Time povećana tražnja dobija i ovaj iracionalni množilac.

Sve ovo navedeno stvara dosad neviđenu tenziju i “groblje nerava”, jer se sa obe strane (i kod kupaca i kod prodavaca) stvara i “groblje firmi” i to onih koje nisu imale resursa (ljudskih ili materijalnih) da optimizuju svoje poslovanje. Siguran sam da smo za tu optimizaciju spremniji mi prodavci i već gore navedenim potezima “bežimo” iz prolaznog ali bolnog “haosa”. Ne žalim se, to smo tražili - liberalizacija, tranzicija, brze globalne komunikacije… Danak će platiti uglavnom firme domaći kupci IT usluga i njihovi kupci (privremeno)… sve to tako dok se cena IT usluga na domaćem i na svetskom tržištu ne izjednači - gubitnici će biti ona MSP koja tu cenu u međuvremenu ne ukalkulišu i ne plate.

Nekada je najveća dilema studenata bila: „Da li treba da naučim C?“. Oni manje iskusni dolazili bi kod svojih iskusnijih kolega sa ovim pitanjem. Čini mi se, nažalost, ovo pitanje danas više niko i ne postavlja. Nekada je C bio stvar prestiža, a danas na onoga ko zna C gledaju kao na budalu, koja je protraćila par godina svog života. I da budem potpuno jasan. Kada kažem C, mislim tada na kombinaciju C/C++. I imam potpuno jasan odgovor. Pravi programer mora da zna C! Tačka. Oko ovoga nema rasprave. Ne zato što ga ja znam, već iz jedinog dobrog razloga koga mogu da se setim. C nema nikakvu zamenu.

Za one koji ne veruju meni, zanimljivo je šta kaže jedan poznati bloger. O onima koji ne znaju C:

They don't really know what a pointer is. They're not even using a real compiler!  That thing they're using doesn't even generate native code you know.  It's "byte code", so it's not real. Those people have never had to manage their own memory. In fact, they've never really had to do anything at all.  I mean really.  They're building on a class library that's got more features in it than Photoshop.

Ne znam koliko su ovi argumenti objektivni. Niti znam koliko je ovo značajno za vas. Ali sa sledećim zapažanjem mogu samo u potpunosti da se složim:

All of the truly extraordinary developer s I know are people who really understand the kind of low-level details that C forces you to know. Every programmer without C experience has a clear path of personal development:  Learn C.  Get some real experience using C to write a serious piece of software.  Even if you never use it again, you'll be a better programmer when you're done.

I možda ono najbitnije na kraju: Furthermore, I'll admit that knowing C is not a magic solution to poor skills.  A lousy developer who happens to know C is simply better equipped to hurt himself or somebody nearby. Ili na prostom srpskom: „Od lošeg programera, C će napraviti još goreg“. Jednostavno za neke nema nikakve pomoći. Osim možda da promene profesiju…

U zadnjih par dana sam poslao 2 maila vezana za posao firmama kroz kontakt forme na njihovim sajtovima. U oba slučaja sam dobio potvrdu od njihovog sistema da je poruka primljena i prosleđena gde treba.

Juhu! Ovo je stvarno bitan korak. Ako forma na vašem sajtu ne šalje ovakva “Šta se upravo desilo i šta dalje?” obaveštenja trebalo bi da ih dodate. Značajno unapređuju korisnički doživljaj jer korisniku jasno govori da je sve u redu i kako će se razgovor nastaviti.

Međutim, ono što u oba slučaja nisam dobio je tekst MOJE poruke. Nije najvažnija stvar na svetu, ali kada je priča vezana za posao voleo bih da imam celu diskusiju u logovima. Ovo je možda samo moj trip, ali mislim da ne bi bilo loše da na dnu poruke sa obaveštenjem o prispeću stoji i:

You wrote:

– Tekst moje poruke –

Bio bi to fin detalj.

Naslov možda ne prija uhu, ali svi znaju o čemu se radi. Gotova svi imaju svest koliko je ovo bitna tema. Međutim, bez obzira na važnost ovog pitanja, problem bezbednosti je najčešće zanemaren. Retko gde ćete imati priliku da učite o sigurnosti računarskih sistema. Svi akademski kursevi posvećeni su algoritmima, programskim jezicima(čitaj Java) ili teorijskom računarstvu. Ovu temu, obično i sami programeri poznati po samoukosti, ostavljaju za kasnije, što obično bude nikada. U tom pogledu, imao sam sreće da u prošlom semestru izučavam ovu materiju, i hteo to ili ne upoznam se sa nečim što čini pismenost jednog programera.

Problem bezbednosti je izražen posebno danas, u uslovima poplave Web aplikacija, od kojih je dabar deo ranjiv još „iz aviona“. U kombinaciji sa gomilom aljkavih programera, rezultati su potencijalno katastrofalani. Verovatno da jedino lenjost sprečava zlonamernike da učine više štete.

Da li je sistem siguran?

Prvo pitanje koje pada na pamet. Kao i obično, pitanje bez dobro dogovora.

Ovo nije problem koji bi mogao da bude rešen nekim matematičkim aparatom. Ne postoji instrument koji može da kaže da li je neki sistem siguran ili ne. Kao što ne može da se kaže da li neki program ima ili nema grešaka. Nejasno je da li strogo formalno, uopšte i možemo da definišemo šta je siguran sistem. Najbolje je na ovaj problem gledati kao na jedan inženjerski problem, i uvesti nešto manje strog kriterijum, sa pitanjem da li je sistem dovoljno siguran. Jedino dovoljno dobro rešenje je osloniti se na dobru praksu i skup već oprobanih metoda.

Sa ekonomskog aspekta može da se govori i o prihvatljivom nivou rizika. Kako nisam ljubitelj, a nadam se ni drugi, ekonomskog pogleda na stvari, ostavimo tu temu za neki drugi put…

Napadi i pretnje

Prosto rečeno, napad je bilo koja akcija koja ugrožava sigurnost informacija. U [1] se kaže:

U osnovi, napadi su akcije koje su usmerene na ugrožavanje sigurnosti informacija, računarskih sistema i mreža. Postoje različite vrste napada, ali one se generalno mogu klasifikovati u 4 različite kategorije.

Tako autori navode sledeće kategorije napada:

Presecanje ili prekidanje Presretanje Izmena Fabrikovanje

Da bi se napad uopšte dogodio, sistem mora da ima određenu ranjivost(vulnerability), koja može da se iskoristi(eksploatiše) sa ciljem kompromitovanja sistema. Ranjivost može da nastane na više načina. Kao posledica greške u dizajnu, kao posledica greške ili previda u poslovnim pravilima ili kao posledica programerske greške(ko je rekao prekoračenje bafera). Na taj način, svaki potencijalni protivnik sa namerom i kapacitetom da iskoristi određenu ranjivost i situacija koja može da dovede do napada, predstavljaju pretnju po sistem.

Na osnovu pretnje, mogućnosti da se pretnja realizuje i materijalnog gubitka koji bi na taj način nastao, može da se izračuna i rizik. Zatim, na osnovu rizika može da se kreira i strategija ili plan rešavanja ili ublažavanja pretnje. No, ekonomski aspekti nas ne interesuju u ovoj priči…

Kriptografija

U osnovi svake sigurnosne tehnike ili servisa obično leži kriptografija. Bruce Schneier je na pitanje šta je to kriptografija dao sledeći jednostavan odgovor:

Ako uzmem pismo, zaključam ga u sef, sakrijem taj sef negde u Njujorku, a zatim vam kažem da pročitate pismo, onda to nije kriptografija. Sa druge strane, ako uzmem pismo i zaključam ga u sef, a zatim vam dam taj sef, njegovu projektnu dokumentaciju i stotinu identičnih sefova sa njihovim šiframa, a vi i dalje ne možete da otvorite sef i pročitate pismo, to je kriptografija.

Osnovni zadatak kriptografije je proučavanje kriptografskih algoritama, ili svima poznato, algoritama šifrovanja. Današnje šifre svoju moć zasnivaju na nečemu što se zove ključ(nije uvek tako, Cezarova šifra). Nasuprot kriptografiji, kriptoanaliza ima zadatak da na osnovu šifrovanog teksta odredi početni tekst ili ključ koji je korišćen. Kriptologija obuhvata zajedno kriptografiju i kriptoanalizu.

Postoje dve osnovne vrste šifara sa ključem. Simetrične i asimetrične šifre. Simetrične šifre, poznate i kao šifre sa tajnim ključem, koriste jedan te isti ključ i za šifrovanje i za dešifrovanje podataka. Simetrične šifre mogu da rade bit po bit(bajt po bajt) sa ulaznim podacima, kada se nazivaju šifre toka, ili sa blokovima podatka, kada se kaže da su to blokovske šifre. Asimetrične šifre, koje se još zovu i šifre sa javnim ključem, koriste dva različita ključa. Javni i privatni ključ. Poruka se šifruje javnim ključem, a zatim je dešifrovanje moguće jedino privatnim ključem.

U zavisnosti od toga na koji način šifra obrađuje ulazne podatke, razlikuju se supstitucione i transpozicione šifre. Supstituciona šifra svaki element(slovo) ulaza, zamenjuje nekim drugim(ne uvek istim) elementom. Kod transpozicionih šifara, elementi ulaza ostaju isti, ali im se menja raspored.

Jednosmerne heš funkcije

Jednosmerne funkcije nisu same algoritmi šifrovanja, ali su sastavni deo gotovo svih šifara. To su funkcije koje je relativno lako izračunati, ali jako teško naći inverznu funkciju. Lako je razbiti prozor, ali gotovo je nemoguće od komadića sastaviti prvobitni oblik. Da li „prave“ jednosmerne funkcije u matematičkom smislu postoje, ne zna se niti postoji dokaza za to. Primenjena kriptografija koristi jedan poseban oblik jednosmernih funkcija. Jednosmerne heš funkcije. Heš funkcija za ulaznu, originalnu poruku, daje vrednost fiksne dužine, nazvanu heš. Na taj način, dobija se digitalni „otisak prsta“ originalne poruke. Kako ove funkcije ulaznu poruku preslikavaju u vrednost fiksne dužine moguće je da postoje dve različite poruke koje imaju jednaku heš vrednost. Očigledno je da ove funkcije nisu bijekcije, te da nisu ni prave jednosmerne funkcije. Međutim njihov rezultat je dovoljno dobar za primenu u kriptografiji. Naime, ako je heš dužine 160 bita, tada je verovatnoća da dve poruke imaju jednaku heš vrednost jednaka 1:2^160.

SSL

Da bi se uspostavio siguran komunikacioni kanal između dva računara, potreban je nekakav sigurnosni protokol. Jedan takav protokol, koji dodaje sigurnost u TCP/IP model, je dobro poznati SSL – Secure Socket Layer. Konkretno SSL nudi:

Privatnost. Sve poruke između dva računara šifrovane su simetričnom šifrom. Proveru identiteta. Identitet obe strane može da se proveri(klijent i server). Pouzdanost. Protokol proverava integritet poruka.

Funkcionalno SSL se sastoji iz dva protokola: SSL Handshake-a i SSL Record-a. Handshake uspostavlja sigurnu sesiju između dve strane. Identifikuje računare, bira konkretan protokol za šifrovanje i razmenjuje ključ sesije kojim će nadalje biti šifrovane sve poruke. SSL Record obavlja samo šifrovanje komunikacije. Posebna snaga ovog protokola ogleda se u tome što se sam ključ sesije, koji razmenjuju dve strane, šifruje javnim ključem. Sa druge strane relativna brzina proizilazi iz činjenice da se za komunikaciju koristi simetrična šifra.

Najpoznatija primena SSL-a je HTTPS protokol. Uistinu HTTPS nije novi protokol, već je to stari obični HTTP, koji kao komunikacioni kanal koristi SSL.

Zaključak

Kako su neke teme ostale nedorečene u jednom od prethodnih tekstova, da pokušam da sada budem potpuno jasan. Ako želite da učite o ovakvim stvarima, upišite FIT. Ako želite efikasno, brzo, i studiranje koje vam daje praktično i upotrebljivo znanju, upišite FIT. Ako hoćete da učite o pravom programiranju, i da vas uči ekipa sjanih profesora i asistenata, upišite FIT. Uzgred, imao sam priliku da mi jedan od dole potpisanih autora knjige bude profesor…

[1] Sigurnost računarskih sistema i mreža, Mikro Knjiga 2007, Dragan Pleskonjić, Nemanja Maček, Borislav Đorđević, Marko Carić

[2] Primenjena kriptografija, prevod drugog izdanja, Mikro Knjiga 2007, Bruce Schneier

Deo onog jednog, jedva izdvojenog dana, za predavanje na Paliću, proveo sam sa veselom DTP ekipom. I tako… odemo na ručak i otvori se (naravno) totalno geekovska diskusija o tome kako je najbolje kompresovati JavaScript kôd.

Pomenemo onaj genijalni hak gde se više JavaScript datoteka dovlači u browser jednim HTTP zahtevom. Pomenemo gzip i nekoliko compresora koji rade na principu uklanjanja white spacea, skraćivanju imena funkcija i varijabli… ali na kraju ostanemo bez nekog jasnog iskustva šta je najbolje… Možda zato što je deo ekipe već počeo da kompresuje vino.

I kako to biva, totalno ne namerno naletim danas na on-line alat koji u benchmarkingu daje rezultate za nekoliko kompresora i to sa ili bez gzip kompresije. Možete probati i sopstveni kôd pa videti šta je bolje na vašem konkretnom primeru, i to sa varijantama uključenih opcija kompresovanja. Divan on-line alat. Vama najbolji rezultat kompresije možete preuzeti - za poneti.

Eto zašto volim ovakve seminare.

Nešto je u ljudskoj prirodi (barem mojoj), te ne mogu prećutno svoje ranije procene koje se pokazuju tačnim… i… da, ubeđujem vas da verujete onome šta ovde pišem

Povod ovom “mom egzibicionizmu” je članak koji govori da “jači” korisnici postaju nezadovoljni AJAX rešenjima. Sada je o tome počeo govoriti u svojim (za nas) skupim studijama i čuveni Forrester Research od 20. marta.

Njihovi argumenti snažno podsećaju na ono što sam pisao ovde (pre više od pola godine), predavao pomalo ovde (pre oko godinu i po na IT seminaru u Nišu) ili nedavno komentarisao kod Ilije na blogu.

“Oštrim” se da još argumentovanije o tome pričam i na E-trgovini 2008.

Što bi Miloje rekao Marku… “sad se malo valjaj po terenu”…

A monetizacija? Pa eto… uzdamo se kao i nekoliko naših klijenata u naše čedo DataMeal, kojeg kao potvrda svega u pomenutim pravcima razvijamo evo već tri godine (uz pauze).

Ima li negde investitora?

Ima sad već nekoliko godina kako sam naleteo na ovaj štos za brzo pravljenje takozvanog “connection stringa”. U poslednjih mesec dana dva puta sam ga “prodao” programerima, i pre toga ko zna koliko… pa bi bio red da ostane trag i na blogu kada se svi tako već oduševljavaju sa hintom…

String za konekciju na bazu ima relativno kompleksnu i vrlo “pipavu” sintaksu, i neohodan je kod konekcija na bilo koju popularniju bazu iz većine razvojnih alata odnosno iz većine desktop programskih jezika. Nisu svi razvojni alati opremljeni “čarobnjakom” koji ovaj string kreira, a sa druge strane malo je poznato da je jedan ovakav čarobnjak dostupan u svakom novijem Windowsu (barem od 2000 na ovamo).

Dovoljno je da:

Otvorite Windows Explorer Odaberite File > New > Text Document i promenite ime tako da ima UDL ekstenziju npr. mojakonekcija.udl (veličina će inicijalno biti nula bajtova) Dvokliknite na tu datoteku i otvoriće se Data Link Properties dijalog, preko kojeg podesite parametre konekcije: drajver, korisnika…i sa “Test Connection” proverite da li se pomoću zadatih parametara konekcija ostvaruje. Zatvorite dijalog klikom na OK Videćete da datoteka (koju ste kreirali u koraku 2) nije više prazna nego da je dobila nekakav sadržaj. U nekom plain-text editoru/vieweru videćete da se u njoj nalazi potreban i proveren connection string.

Pošto često posećujem http://www.blic.co.yu/strip.php (svaki dan) ne bih li pročitao novi strip, odlučio sam da malo automatizujem proces. Napisao sam kratku bash skriptu koja skida strip, zalepi ga na wallpaper i osveži ga.

Skripta je urađena za mene, tako da oni koji ne koristi fluxbox moraju da je izmene da bi im se pozadine osvežavala. Ako nemate instaliran fluxbox verovatno će biti prijavljena greška da program fbsetbg ne postoji.

Pored toga, da bi skripta ispravno funkcionisala, potrebno je da imate instaliran ImageMagick (po mogućnosti iz repozitorijuma).

Udaljenost od leve i gornje ivice možete menjati u skripti kroz odgovarajuće promenljive u zavisnosti od Vaše rezolucije. Takođe je potrebno da navedete putanju do originalne slike na koju hoćete da nalepite strip.

Skript se ne pokreće periodično, pa ako to želite sami ga dodajte u cron. Ja ga nisam dodao jer ga uglavnom koristim na lap-top-u, pa nema mnogo smisla.

Ovako to izgleda kod mene za današnji strip:

I na kraju, samu skriptu možete pronaći ovde.

Pošto često posećujem http://www.blic.co.yu/strip.php (svaki dan) ne bih li pročitao novi strip, odlučio sam da malo automatizujem proces. Napisao sam kratku bash skriptu koja skida strip, zalepi ga na wallpaper i osveži ga.

Skripta je urađena za mene, tako da oni koji ne koristi fluxbox moraju da je izmene da bi im se pozadine osvežavala. Ako nemate instaliran fluxbox verovatno će biti prijavljena greška da program fbsetbg ne postoji.

Pored toga, da bi skripta ispravno funkcionisala, potrebno je da imate instaliran ImageMagick (po mogućnosti iz repozitorijuma).

Udaljenost od leve i gornje ivice možete menjati u skripti kroz odgovarajuće promenljive u zavisnosti od Vaše rezolucije. Takođe je potrebno da navedete putanju do originalne slike na koju hoćete da nalepite strip.

Skript se ne pokreće periodično, pa ako to želite sami ga dodajte u cron. Ja ga nisam dodao jer ga uglavnom koristim na lap-top-u, pa nema mnogo smisla.

Ovako to izgleda kod mene za današnji strip:

I na kraju, samu skriptu možete pronaći ovde.

Nije mi jasno kada će, oni koji do sada to nisu, da shvate da u feed ne mogu da idu relativne putanje. Ako ste primetili da u nekim agregatorima nema slika u Vašim tekstovima, već se pojavljuju precrtani kvadratići, odgovor leži ovde:

Explanation

Some RSS elements are allowed to contain HTML, including links and images. However, if these links use relative URLs to point to resources, users of some news aggregators will not be able to click on them. And your images use the relative URLs, the images may not appear (since the news aggregator will be looking for the images locally on the user's hard drive, rather than on your web site).

Znači ne može:

<img src="mojaslika.jpg" />

već samo:

<img src="http://www.ja.blog.com/mojaslika.jpg" />

Prosto rečeno, Heroku je Rails razvojno okruženje u pretraživaču(jel sad bolje?). Nešto preciznije, Heroku je kompletna, web zasnovana, code/deploy/run platforma za Rails aplikacije. Ili, sve na jednom mestu. To znači da nove Rails aplikacije kreirate kroz web interfejs. Tako napravljene aplikacije možete da menjate kroz IDE u samom brauzeru. Kako sam skeptičan po pitanju složenijih web aplikacija, ovaj IDE je prevazišao moja očekivanja. Svakako nedostaju neke napredne opcije kao code completion, ali je editor i pored toga potpuno upotrebljiv. Dovoljan je jedan pritisak na dugme pa da pokrenete ovako napravljenu aplikaciju, koja je odmah dostupna na webu.

Svi drugi aspekti razvoja Rails aplikacije su identični. Kao da pišete kod na svojoj lokanoj mašini. Tako imate i pun pristup Rails konzoli, Rake zadacima i logovima aplikacije.

Zanimljivo je i šta se krije ispod haube. Autori Heroku-a kažu da cela platforma leži na Amazon EC2 osnovi. Tvrde da zahvaljujući tome, imate pristup neograničenim resursima i skalabilnosti. Ja sam se malo igrao, i sve ovo izgleda sjajno. Pitanje je samo kako bi se sistem ponašao u realnim uslovima i pod realnim opterećenjem. No za to treba sačekati da Heroku izađe iz beta faze, i da zaživi kao deo neke prave aplikacije.

Zaista sam oduševljen idejom. Ono što je Rails za Ruby, to je Heroku za Rails. U ostalom, probajte sami.

Profiler je ubedljivo najbolji alat ukoliko tražite uska grla u vašim PHP aplikacijama. Da bi isti radio unutar Zend Studija treba vam Zend Debugger serverska ekstenzija. Ako koristite PHP i Apache koji dolaze uz Leopard primetićete da stvari baš i ne funkcionišu kako treba. Problem je u tome što Zend Debugger ne radi sa Apachem koji radi u 64-bitnim režimu kako je isti konfigurisan na Leopardu. Rešenje - ubijte Apache iz Sharing Preferences panela i poterajte ga u 32-bitnom režimu:

sudo arch -i386 /usr/sbin/httpd

Više detalja možete naći u ovoj diskusiji. Postujem sebi kao podsetnik pošto sumanjam da će ovo ikome zatrebati

Naravno, mislim na sposobnost ljudi da naizmenično obavljaju više poslova, prelazeći sa jednog zadatka na drugi i opet nazad, sve u kratkom vremenskom intervalu. Ko je čitao makar uvodno štivo iz arhitekture računara ili operativnih sistema, zna koliko je context switch skupa operacija. Izgleda da je stvar sa našim mozgom jednaka.

Ovaj problem posebno je izražen u današnjem okruženju informacionog overload-a, u kome smo osuđeni na računare, mobilne telefone, kamere i koje kakve uređaje, koji nam život čine lakšim. Bar bi tako trebalo da bude. Međutim, mesto da nam svi ovi gedžeti poboljšaju kvalitet života, postali smo robovi tehničkih dostignuća. Na način na koji niko nije moga ni da predvidi, veštačka inteligencija zavladala je svetom. Ostvarivši tako sve one slutnje SF horora o „dominaciji mašina“. Kao i virus, sa pre bi moglo da se kaže manjkom, nego viškom inteligencije, fenomen nazvan gedžet razjeda savremenog čoveka.

Mobilni telefon koji bez ikakvog pravila, i uvek u trenutku kada radite nešto važno, zvoni. PDA koji svakih pet minuta odvlači pažnju na sebe. RSS feed koji, više ni ne znam preko kog uređaja čitate. Da ne pominjem, kakvo je stanje kada se stigne do desktop-a. Ukoliko se od svih ovih smetnji uopšte i dokopate tastature. Tu teror tek počinje. Prvo i obavezno, otvorena mail aplikacija, koja Vas tera da svakih 30 sekundi, klikćete na Send/Receive, iako je mail klijent podešen da u pravilnim vremenskim intervalima sam to radi. 30 stranica koje kakvih help-ova. 7 instanci IE-a(upišite ovde Opera, Firefox, Safari, šta god) svaka sa po najmanje 15 otvorenih tabova. 3 otvorena Word dokumenta, koja nikako da otkucate. I na kraju, ako se nađe vremena da uradite checkout i otvorite IDE.

Meni ne treba nikakvo naučno istraživanje i potvrda lekara, da bih znao da ovo nije zdravo. Da bih znao, da ovakav način rada maksimalno iscrpljuje i dovodimozak do krajnjih granica izdržljivosti. Kakva je fiziološka i psihološka osnova ovakve reakcije čovekovog tela, na kraju nije ni bitno.

Da li rešenje postoji? Najveći problem je utvrditi problem. Tj. postati svestan činjenice da je bolest prisutna. Kada budete uspešni sa dijagnozom, rešenje je blizu. Malo discipline može lako da reši sve muke.

1.      Ne klikćite neprestano i bez ikakve potrebe iz jednog u drugi prozor.

2.      Svu pažnju usmerite na ono što trenutno radite.

3.      Ne prekidajte to što ste počeli, dok zadatak ne dovedete do kraja.

4.      Konsultujte drugi prozor, samo kada to zaista morate.

Možda Vam sve ovo zvuči banalno, ali pokušajte da poštujete sva ova pravila i ubrzo bi trebalo da vidite napredak u svojoj produktivnosti(kako mi samo ovo zvuči socijalistički). Za početak, ja sam uspeo ovaj tekst, da otkucam u jednom dahu.

PS: Kao što vidite ne gledam TV duel

PPS: Tekst ide u kategoriju programiranje, u nedostatku boljeg izbora…

Nakon povampirenja povećane primene JavaScripta od pre 3-4 godine, popularisalo se u primeni nekoliko klijentskih biblioteka (to i vrapci znaju): Ajile, Dojo toolkit, Echo, ExtJS, JQuery, MochiKit, MooTools, Prototype, Rialto, Rico, script.aculo.us, Yahoo! UI Library … ima ih još… Interesanto je dalje, da je postojanje ove palete stvorilo drugu - paletu JavaScript programera. Nove specijalnosti - nova kasta, novi fetiš, novo pleme…

Biranje “prave” uvek je kompromis, a o programerskim fetišima sam se naterao da ne razmišljam. E sad, nije o tome reč, a ako o tome neko želi iole racinalno mišljenje evo mu polaznih linkova:

Mootools protiv jQuery protiv Prototype Prototype protiv jQuery Mootools protiv jQuery protiv Prototype protiv ext protiv Dojo

Može se reći da iza svake od navedenih biblioteka stoji barem nekoliko čovek/godina kodiranja i testiranja i najbolje prakse. Zbog toga nema snažnijeg razloga da ovakve biblioteke sami razvijamo. Kada se uz korišćenje jedne od njih iskodira neki deo web apikacije, biblioteku dalje održava open-source zajednica a naš deo kôda bi (teoretski) trebao da radi i na sledećim stabilnijim i performantnijim verzijama. Mod(ula)(e)rno, nema šta… ali ne i bez glavobolje.

Hakić na koji želim ukazati zapravo je trend u arhitekturi. Dešava se da krenete da web aplikaciju razvijate sa jednom bibliotekom, a kasnije pronađete savršenu komponentu za vašu web aplikaciju ali pisanu na drugoj biblioteci. Problem je što bi sad trebalo u browser “dovući” obe ne baš male biblioteke, ugroziti mu stabilnost. Ponekad se JavaScript biblioteke (programerskim žargonom rečeno) “kolju”, odnosno smetaju jedna drugoj da rade ispravno. Tipično i jednostavno je recimo različito tretiranje window.onload eventa… Apsurd je veći jer obe biblioteke imaju iste ili slične metode/funkcije - redudantan kôd. Drugi problem biblioteka je da se često iz njih koristi tek nekoliko procenata kôda. Kasnije ću se pozvati na sve ove problem, pa ih sada nazivam - “bibliotekarski problemi” (neću sad braniti zašto baš takvo ime).

Hak u arhitekturi je zapravo dodatna mogućnost neke JavaScript komponente da rade na više biblioteka. To na primeru ExtJS izgleda otprilike ovako (izvor slike):

Ovo je arhitektura tog haka na u primeru sa ExtJS, ali se treba šire posmatrati. Dakle neka komponenta (gornji široki plavi bar) može da radi na na baznoj biblioteci (u datom primeru je to: ext-base.js), ali se preko tzv. adaptera može koristiti i na drugim bibliotekama (zeleni, crveni i narandžasti pravougaonik). Adapter je po pravilu malo parče kôda - tzv. apstrakcija (proksiranje) prema drugoj biblioteci. Na taj način rešavaju se “bibliotekarski problemi”.

Ovaj “pattern” (ili hak) u arhitekturi ovih meseci postaje trend. Za kraj evo jedne popularne komponente, sa rešenim “bibliotekarskim problemom”. Javite se ako pronađete još JS komponenti u ovoj arhitekturi.

WordPress je u verziji 2.3 uveo podršku za tagove. Ali najverovatnije niste osvežili vašu WordPress temu tako da, i ako koristite tagove, oni se ne vide i vaši posetioci ne mogu da iskoriste ovu blagodet web 2.0 web-a. Mnogi ne vole tagove i ne vide ništa preterano korisno u njima, a ježe se na pomen tag oblačića (tag cloud). Ali ja sam ipak na strani tagova, oni će pomoći da vaši posetioci lakše pronađu vaše stare i zaboravljene postove (tekstove), koji su označeni sa istim tagom kao tekst koji upravo čitaju. Drugi argument u korist tagova je da vam neće škoditi, a čim ne škode to znači da koriste, pa da …

Sve što treba da uradite jeste da u single.php fajl, koji je deo vaše WordPress teme umetnete sledeći kod:

Ovo je funkcija koju ćemo koristiti

Code (php) <?php the_tags(‘before’, ’separator’, ‘after’);?>

Tako da vaš kod može izgledati ovako:

Code (php) <?php the_tags(‘Tagovi : ‘,‘ • ‘,‘ ‘);?>

Tagovi će na izlazu izgledati ovako Tagovi : WordPress • Djuki • Tutorijal

Ili na sledeći način:

Code (php) <?php the_tags(‘Tagovi : ‘,‘ | ‘); ?>

Izlaz će izgledati ovako: Tagovi : WordPress | Djuki | Tutorijal

Tagove možete da postavite upravo ispod sadržaja vašeg posta, pa će deo koda u single.php fajlu izgledati ovako

Code (php)   <h1><?php the_title(); ?></h1> <?php the_content(‘<p class="serif">Read the rest of this entry &raquo;</p>’);?> <p><?php the_tags(‘WordPress tagovi: ‘,‘ | ‘); ?></p>  

A za one koji žele da svoju temu ulepšaju sa tag oblačićem, samo treba da na pogodno mesto dodaju sledeći kod. Ovo može biti u vašem sidebaru (sidebar.php), ili možda u footeru (footer.php), ili gde god vi to želite.

Code (php) <?php wp_tag_cloud(’smallest=8&largest=36&number=150′);?>

Ovde je “smallest” veličina fonta za najmanji tag, koji se najmanje pojavljuje na vašem blogu, “largest” je font za najveći tag tj. tag koji se najviše pojavljuje na vašem blogu. “Number” je broj koji označava koliko tagova želite da prikažete u tag oblaćiču. Što je broj veći i oblačić će da raste. Počnite da koristite tagove i sledeće godine moćićete da vidite, šta je najzastupljenije na vašem blogu, i što je najvažnije videćete šta ste zapostavili tokom godine, a o čemu je vredelo pisati. Pa neka sada kažu da su oblačići beskorisni i da samo zauzimaju mesto.

Znate onaj: Postoji 10 vrsta programera. Oni koji koriste Rails, i oni koji još nisu čuli za Rails.

Vic je možda izlizan, ali je u ovom slučaju surovo istinit. Teško da se neko sreo sa Rails-om, a da nije bio oduševljen njime.

Ruby on Rails

Pa šta je zaista Rails. Tehnički govoreći Rails nije programski jezik. Ruby je jezik, dok je Rails framework izrađen i napisan u Ruby-u. Otuda i ono „Ruby on Rails“. Međutim, mirne savesti bih mogao da kažem daje  Rails jezik. Stoga, ne bih voleo da mi neko zameri, ako to i učinim.ppOno što Rails razlikuje od bilo čega drugog, je što je nastao u realnim uslovima, i iz stvarne potrebe. Naime, Rails je izdvojen iz prave aplikacije(Base Camp) koja zaista i postoji i koja svakoga dana opsluži hiljade korisnika. Otuda verovatno nema prirodnijeg alata za razvoj Web aplikacije. Sve što je ušlo u Rails, nekada i negde je korišćeno u realnim uslovima.

Intrerpreter, ne kompajler

Rekao sam da je jezik u predmetu ove priče Ruby. Ruby je interpreter. Drugim rečima, oprostite se od performansi. Ruby je i funkcionalni jezik. Funkcionalni zato što ima funkcije prvog reda. Sve što možete sa bilo kojom drugom promenljivom, možete i sa funkcijom. Telo funkcije možete da dodelite nekoj promenljivoj, možete kasnije tako napravljenu funkciju da pozovete ili pak da je prosledite drugoj funkciji. Ruby je i dinamički jezik. Delove programskog koda možete da menjate u toku izvršavanja. Čik probajte to u C-u. Zahvaljujući svim ovim osobinama Rubyja, Rails je izuzetno elegantan i prirodan jezik.

MVC Framework

Na vrh svega ovoga što nudi Ruby, Rails dodaje još dosta toga. Tako Rails formira čitav WEB framework. I to ne bilo kakav, već MVC framework.  Po uzoru na MVC obrazac, Rails jasno prepoznaje i razlikuje koncepte kao što su kontroler, akcija, model, prikaz itd. Sve to ima za rezultat, jasno odvojena pravila poslovne logike, akcija i rezultata koji se prikazuju. Međutim to što je Rails MVC framework ne znači ništa. I Tapestry je MVC framework, pa su aplikacije pisane pomoću njega nešto najružnije i najsloženije što sam ikada video. Prava moć leži u dva koncepta koja se razvojni tim Railsa striktno pridržava. To su: DRY i convention over configuration.

Prvi princip, ili Don’t Repeat Yourself, obezbeđuje minimalno ponavljanje koda. Aplikacija je tako strukturirana da primorava programera da piše čist kod i eliminiše ponavljanje. Drugi princip, konfiguraciju, kako samog frameworka, tako i aplikacije, svodi na nužni minimum. To znači da je konfiguracija predefinisana i da podleže strogo određenim pravilima. U praksi, retko ćete imati potrebu da bilo šta u Railsu podešavate. Ako se pridržavate svih principa koje Rails određuje, dobićete gotove, funkcionalne, aplikacije uz minimum truda i koda.

Rekao sam da Rails prepoznaje koncept kao što je model. Međutim Rails čini i mnogo više od toga. Rails je čitav Object-Relational Mapper. Ovo programera oslobađa potrebe da radi direktno sa bazom podataka, u bilo kom smislu. Svi objekti u domenu aplikacije definišu se u samom jeziku, dok teret lepljenja na bazu, pada na Rails.

Klasika ili trend

Rails svakako nije zaobišao ni agile trend. Sve što je potrebno za unit testing je prisutno. Šta više poželjno je da testom pokrijete svaki aspekt aplikacije. Tu je agile, ali tu je i AJAX. Pisanje, kako vole da kažu, WEB 2.0 aplikacija je potpuno prirodno u Rails okruženju.

Ovo je samo delić priče o Rails-u. Nadam se da će ovo biti samo prvi tekst u Rails serijalu…

Na početku da priznam je ovaj post posledica ovog Varaginog članka, i potonjih komentara.

Na E-trgovini 2007. sam imao predavanje o potrebi da firma pre dorade ili izrade on-line prisustva naruči studiju o korporativnom on-line prisustvu. Namerno kažem on-line prisustvo jer je to značajno širi pojam od termina koji lakše razumeju mase - web sajt. Evo prezentacije sa tog predavanja:

Neće svaka firma prepoznati ovu svoju potrebu. Mi koji se bavimo ovim poslom treba da prepoznamo takve firme. Način na koji empirijski mogu prepoznati ovakvu firmu sam sročio u nešto što ću neskromno nazvati “Stevino pravilo” - evo kako ono glasi:

Da bi firma/organizacija imala kvalitetno internet prisustvo mora imati barem dve od ove tri stavke:

Budžet za on-line prisustvo Bitan uticaj konkurencije u on-line sferi Barem svest ili viziju o povratku te investicije (ROI)

Ako se vratim na slučaj Medoprodukta koji je naveo Varagić, mislim da se da lako primetiti da nijedna od tri stavke nije ispunjena. Sa druge strane nema dovoljno agresivne domaće firme da Medoproduktu jasno predstavi barem ono pod 3.

Pitanje koje sam imao na kraju tog predavanja je bilo nešto poput: “Kako kad firme ne žele studiju on-line pisustva?”, odogovorio sam da takve firme naprosto nemaju unapred potrebne osobine (iz Stevinog pravila) i da one najverovatnije takve nikad neće imati kvalitetno on-line prisustvo.

Na kraju ohrabrenje je da firmi sa potrebnim osobinama ima prilično i da se ovakve studije itekako rade i kod nas.