Google Chrome i proxy

Ne znam da li ste primetili, ali Google Chrome koristi podešavanja Internet Explorera za proxy server. Neko bi mogao da kaže kako je to dobar pristup jer se podešavanje proxy servera nalazi na jednom mestu, ali meni, a siguran sam i mnogima, to smeta. O čemu se zapravo radi? Radi se o tome da Internet Explorer koristim samo u korporativnoj mreži i nigde više. Da bih imao nesmetan pristup korporativnoj mreži i aplikacijama moram da koristim korporativni proxy. Sa druge strane, za ostale sajtove ne želim i ne osaćem se prijatno koristeći Internet Explorer. I tu nastaje problem. Ako mi je IE podešen za pristup preko proksija, a ja u isto vreme želim da pristupim nekom drugom sajtu preko Google Chroma to deluje nemoguće, jer koriste isto podešavanje. Ako isključim proxy za jednog, moraću i za drugog.

Naizgled nerešiva situacija, ali se može rešiti tako što se promeni prečica do Google Chrome aplikacije. Sve što je potrebno dodati na kraju je parametar –proxy-server= i nakon toga će Google Chrome prestati da preuzima proxy podešavanje od Internet Explorera.

Na kraju moram da postavim pitanje: Da li je toliko teško da se postavi opcija, koristi svoje podešavanje za proxy server. Izgleda da nekome jeste.

Na poslovnom putu

Sledeće 2 nedelje ću se nalaziti na poslovnom putu. Lokacija je Košice, Slovačka. Ako je neko u blizini i raspoložen je za društvo, neka se javi. Razmišljam da odem na jednodnevnu posetu Bratislavi ili Budimpešti. Još se nisam odlučio, ali koliko vidim put do Bratislave je veoma dug, iako ima samo 450 km. Najverovatnije ću otići samo do Budimpešte.

Ako neko ima preporuku šta bi moglo da bude interesantno u Košicama, ostavite komentar ili mi pošaljite na mail. Neki dobar pub, iako ne pijem alkohol ili zanimljive lokacije koje se ne vide na prvi pogled.

Ko želi da bude vredni mrav?

Jednom davno, živeo je srećan i vredan Mrav, koji je svakog dana dolazio prvi na posao.
Bio je vredan. Veseo. Jednom rečju, bio je srećan dok je radio.
Pevušio je vesele pesmice, a rezultati njegovog rada su bili odlični.
Slušajući pesmu Mrava, gospodin Stršljen, direktor firme, zaključio je da se mrav previše zabavlja a premalo radi, jer nema pravo usmerenje i šefa koji bi ga kontrolisao.
Zato je zaposlio Bubamaru koja je imala veliko iskustvo sa upravljanjem.
Prva briga Bubamare bila je da organizuje evidenciju dolazaka i odlazaka mrava na posao (odnosno sa posla). U tu svrhu, uspostavila je sistem prijemnih i odlaznih dokumenata.
Sa vremenom, broj dokumenata se povećavao i zbog povećanog obima posla oko papira morali su da zaposle nekog ko bi pripremao papire i izveštaje.
Zaposlili su Pauka koji je odmah uspostavio sistem arhiviranja, a postao je odgovoran i za preuzimanje telefonskih poziva.
A mrav? Mrav je i dalje radio kao i pre.
Izveštaji koje je dostavljala Bubamara su bili izvanredni. Direktor Stršljen je bio oduševljen izveštajima koje je dobijao od Bubamare i uskoro je počeo da zahteva: uporedne studije sa grafikonima, analize trendova razvoja, itd.
Da bi se zadovoljio direktorov zahtev, bilo je nužno da se zaposli Hrčak koji bi bio direktna pomoć direktoru. Njemu su odmah kupili nov računar sa štampačem.
Srećni i vredni mrav je i dalje radio kao i pre. Jedino se požalio da bi mu bilo lakše ako bi imao računar. Nisu mu odobrili.
Ovo je bilo prvi put da se Mrav na nešto požalio i direktor Stršljen je odmah shvatio da je potrebno najhitrije reagovati. Kreirao je novo radno mesto šefa službe koji bi nadzirao srećnog i vrednog mrava.
Na novo radno mesto je zaposlio Cvrčka. On je odmah po svom dolasku zamenio celokupni nameštaj u svojoj kancelariji i na zahtev dobio ergonomski oblikovanu stolicu i nov računar sa ravnim, LCD ekranom.
Broj računara je narastao i morao je da se kupi i instalira i mrežni server.
Novi šef službe je shvatio da hitno treba pomoćnika (koji je uzgred bio njegov pomoćnik u prethodnoj firmi). I tako je zaposlio Stenicu.
U isto vreme Mrav je bio sve manje srećan i sve manje produktivan. Opet je tražio računar. Opet mu nisu odobrili.
Situacija sa Mravom zabrinula je Cvrčka i on je zaključio da mora da naruči studiju o zadovoljstvu zaposlenih u firmi. Upoznao je sa tim direktora Stršljena koji je shvatio Cvrčkovo objašnjenje i odobrio angažovanja agencije za te potrebe.
Skupa studija je urađena i Cvrčak je počeo da primenjuje predložene motivacione metode. Svuda je okačio motivacione plakate. Vodio je Bubamaru, Pauka, Hrčka i Stenicu na motivacione treninge u poznata letovališta itd…
Mrav je i dalje, ali nevoljno, radio. Čitao je motivacione poruke na plakatima i nikako nije mogao da nađe nadređene kad su mu trebali.
Jednostavno, ili nisu bili tu ili nisu imali vremena za njega.
I tako je vreme teklo.
Direktor Stršljen je i dalje dobijao redovno svoje perfektne izveštaje, ali su oni počeli da pokazuju da firma nije više tako rentabilna kao pre.
To ga je duboko zabrinulo i morao je da reaguje.
Unajmio je najelitnijeg konsultanta, gospođu Sovu. Sovin zadatak je bio da izvrši potpunu analizu organizacije i poslovanja firme i da predloži rešenja da bi firma poslovala rentabilno.
Nakon tri meseca, Gospođa Sova je direktoru predala sledeći izveštaj:
„U firmi je previše zaposlenih!“
Direktor Stršljen je oduševljeno prihvatio stručnu analizu i odmah otpustio:
MRAVA.

Prebacivanje sa starog bloga

Ranije sam pisao povremeno na http://my.opera.com/mmwlada .

Sada, sa novim hostingom i novim blogom, mislim da treba da prebacim ovde neke od zanimljivijih postova. Srećom, pa sam za objavljivanje postova koristio Windows Live Writer, koji je sve sačuvao na lokalnom disku, tako da se sve svodi na ponovno objavljivanje na novoj lokaciji

Mikro arhitektura – GoF uzori

GoF(Gang of Four) uzori su se prvi put pojavili u knjizi „Design Patterns – Elements of Reusable Object-Oriented software“ koju su napisali Erich Gamma, Richard Helm, Ralph Johnson i John Vlissides. Oni su u toj knjizi predstavili neke od najčešće korišćenih uzora i klasifikovali ih prema nameni na uzore kreiranja, strukture i ponašanja i prema domenu na uzore klasa i objekata. Postoje i drugi načini da se klasifikuju uzori. Neki uzori se često koriste zajedno. Na primer, sastavnica(composite) se često koristi uz Iterator ili Posetioca(Visitor). Neki uzori su alternative: Prototip je često alternativa apstraktnoj fabrici, kao i builder.

Uzori kreiranja

Uzori kreiranja apstrahuju proces instanciranja. Pomoću njih sistem postaje nezavisan od načina pravljenja, sastavljanja i predstavljanja objekata. Uzor za pavljenje sa domenom klase koristi nasleđivanje za menjanje klase koja se instancira, dok uzori za pravljenje sa domenom objekta delegira instanciranje nekom drugom objektu.

Uzori kreiranja postaju važni kada sistemi dođu u fazu da više zavise od sastavljanja objekata nego od nasleđivanja. U takvoj situaciji, naglasak sa fiksnog kodiranja fiksnog skupa ponašanja prelazi na definisanje manjeg skupa osnovnih ponašanja koja se mogu sastavljati u veći broj složenijih. Prema tome, pravljenje objekata sa nekim određenim ponašanjem zahteva više od pukog instanciranja klase.

Kod ovih uzora postoje dve teme koje se stalno ponavljaju. Prvo, svi uzori enkapsuliraju znanje o tome koje konkretne klase sistem koristi. Drugo, oni kriju kako se prave konkretni objekti ovih klasa i kako se sastavljaju. U celom sistemu se o objektima zna jedino za njihove interfejse, na osnovu toga kako su definisani u apstraktnim klasama.

Uzori strukture

Strukturni uzori se bave načinom na koji se klase i objekti sastavljaju u veće strukture. Strukturni uzori klasa koriste nasleđivanje za sastavljanje interfejsa ili implementacija. Strukturni uzori sa domenom objekata opisuju načine za postizanje nove funkcionalnosti kombinovanjem objekata umesto sastavljanjem interfejsa ili implementacija. Dodatna fleksibilnost sastavljanja objekata potiče od mogućnosti da se sastav menja u vreme izvršavanja, što je nemoguće kod statičkog sastavljanja klasa.

Uzori ponašanja

Uzori ponašanja se bave algoritmima i raspodelom odgovornosti među objektima. Uzori ponašanja ne opisuju samo uzore objekata ili klasa, već i uzore njihove međusobne komunikacije. Ovi uzori opisuju prirodu složenog toka kontrole koji se teško prati u vreme izvršavanja. Pažnja prelazi sa samoga toka kontrole na način međusobnog povezivanja objekata.

Klasni uzori ponašanja koriste nasleđivanje za distribuiranje ponašanja među klasama. Objektni uzori ponašanja koriste sastavljanje objekata, a ne nasleđivanje. Neki od njih opisuju kako grupa objekata ortaka sarađuje na zadatku koji nijedan od njih ne može sam da obavi. Ovde je važno kako ti objekti saznaju jedan za drugoga. Oni bi mogli da čuvaju međusobne eksplicitne reference, ali bi to pojačalo njihovo vezivanje. U krajnjem slučaju bi svaki objekat znao za sve ostale.

Kod svih GoF uzora se može primetiti struktura koja se sastoji od klijenta, apstraktnog servera i konkretnih servera. To se može prikazati sledećim UML dijagramom.

Arhitekturni uzori i MVC

Pre nego što počnem o ovome, mislim da treba da razgraničimo šta su nivoi a šta slojevi.
Sloj (En. Layer)
Nivo (En. Tier)
Koja je razlika između ova dva? Iako na prvi pogled deluju kao sinonimi, razlika je ogromna. Kada se govori o slojevima, prvo se misli na logičkom nivou, dok se kod nivoa misli na fizičkom. Šta to znači u programiranju? S obzirom da ću se koncentrisati na .NET framework, koristiću termine koji su tamo standardni, ali verujem da će se i poklonici ostalih jezika snaći. Ako kažemo da imamo dve klase koje pripadaju različitim slojevima, to znači da su one u istom projektu, ali u okviru različitih namespace-ova. Dok ako kažemo da dve klase pripadaju različitim nivoima, to znači da pripadaju različitim projektima, pa čak i da su na različitim računarima nakon instalacije.

Uzori arhitekture izražavaju fundamentalnu strukturnu organizaciju ili šemu sistema. Oni pružaju set predefinisanih podsistema, opisuju njihove odgovornosti i uključuju pravila i smernice za organizaciju odnosa između datih podsistema. Ono što je bitno kod arhitekturnih uzora, to je da oni nisu previše konkretni. Oni predstavljaju jednu ogromnu apstrakciju sistema, koja se može tumačiti i implementirati na više načina.

Postoji više uzora arhitekture. MVC je samo jedan od njih. IBM je skupio neke ahtitekturne uzore koji se odnose na e-poslovanje. Možete ih pogledati ovde: http://www-128.ibm.com/developerworks/patterns/
Ako želite da saznate više o arhitekturnim uzorima pogledajte http://wi.wu-wien.ac.at/home/uzdun/publications/ArchPatterns.pdf i http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) , a ja ću se zadržati MVC uzoru

MVC (Model – View – Controller) uzor je arhitekturni uzor koji organizuje aplikaciju u tri odvojena sloja: jedan za aplikacioni model sa prikazom podataka i biznis logikom, drugi za prezentaciju podatala korisniku i unos podataka i treći za kontroler koji prosleđuje zahteve i izvršava tok. Imajte na umu da arhitekturni uzori uzimaju olako termine kao što su sloj i nivo, jer im je svejedno da li će se MVC na primer implementirati u okviru jednog projekta ili više.

Postoji više implementacija MVC uzora, ali dva najčešća imaju oblike kao na slikama

Pune linije predstavljaju direktne asocijacije, dok su isprekidane indirektne. Isprekidane linije se mogu implementirati preko događaja, ali je najpoželjnije da se implementira preko observer uzora, o kome ću malo kasnije kada budem pisao o GoF uzorima.

Šta radi Kontroler:
Upravlja tokom programa
Odlučuje koji view da prikaže
Odlučuje koji model da menja
Upravlja izuzecima

Šta radi View:
Renderuje UI (HTML, GUI…)
Omogućava prikaz korisnicima
Prihvata i proverava da li su podaci validni

Šta radi model:
Sadrži poslovnu logiku
Ima pristup nižim servisima
Sadrži perzistentne objekte (iako je model sam po sebi tranzijentan)

Uzori u projektovanju programa – uvod

Šta je zapravo softverska arhitektura? Odgovor na to pitanje se nalazi na više nivoa. Na najvišem nivou, nalaze se arhitekturni uzori koji definišu sveukupan oblik i strukturu aplikacije. Na nižem nivou je arhitektura koja je specifična za aplikaciju koju razvijamo. Na još nižem niovu je arhitektura modula, klasa i njihovih veza. To je zapravo nivo mikro arhitekture. Dok se na još nižem nivou nalaze idiomi.

Značaj uzora u proizvodnji složenih sistema je odavno priznat u drugim disciplinama. Konkretno, Kristofer Aleksander i njegove kolege su prvi predložili da se jezik uzora upotrebi u arhitekturi zgrada i gradova. Njegove ideje i doprinosi sada su ukorenjeni u zajednici objektno orijentisanog softvera.
Sve dobro strukturirane objektno orijentisane arhitekture su pune uzora. Ako se prilikom razvoja sistema usresredi na pravilno korišćenje uzora dobija se manja, jednostavnija i razumljivija arhitektura nego ako se ignorišu.

Uzori sadrže rešenja koja su se vremenom razvijala i proširivala. To nisu rešenja koja se prave iz prve, već su prošla dosta iterativnih poboljšanja.
Postoji više definicija šta je uzor. Najjednostavnija je „uzor je provereno rešenje za problem u datom kontekstu“. Međutim, mnogi smatraju da je ovo isuviše pojednostavljeno. Čak je i Richard Gabriel rekao „Alexander je mogao da napiše definiciju uzora u jednoj rečenici, ili esej, ali je umesto toga napisao knjigu od 550 stranica, zato što je koncept težak za razumevanje“.

Ovo je samo mali uvod u ono o čemu planiram da pišem. Stoga se može smatrati kao prvi od više članaka na tu temu.