Wolfwood's Crowd blog

Kritika il’ hvala hrvatskog (IT) košmara

,

Zmijastično

pythonweb

Devsource donosi odličan članak za upoznavanje s IronPython-om:
A First Look at IronPython: Where Python meets .NET. Voidspace Techie Blog se vrlo često bavi IP-om pa je donio i četiri nastavka u seriji IronPython & Windows Forms (1, 2, 3, 4).

Ja i dalje preferiram Boo. PythonInfo Wiki donosi sažet opis razlika između njega i pravog Pythona:

The main difference is that boo is statically typed with type inference. Syntax-wise it is like Python, but feature-wise it is also similar to C#. It implements many features that have been suggested for Python3.0, including a "with" statement and optional explicit static typing declarations ("x as int"). Extra features include anonymous methods/closures, custom macros and attributes (similar to PythonDecorators), and soon, optional case-insensitivity.

Pogledati i Gotchas for Python Users.

Ultimate template engine

Od svih tih silnih template engine-a koji su na raspolaganju developerima web aplikacija nekako mi se najviše dopada TAL, a kako je on ovisan o Zope-u onda sam potražio neovisno rješenje: SimpleTAL.

Prošli tjedan naletjeh na webstring. Jako me je zainteresirao jer to je ono što je najbliže mojem poimanju kako jedan TE treba izgledati. Samo što nije prikladan za shared hosting jer ima neke ovisnosti koje nisu zadovoljene kod većine providera. Ali kako sam na putu prema svojem serveru (dedicated ili VPS) onda me to ne brine.

Ali najzanimljivije u cijeloj toj priči je činjenica da webstring ima dosta razvijeno rodoslovno stablo. PyMeld je postavio inicijalni obrazac kojeg je naslijedio i webstring. Ali tu je još i meld3 te Meld2 koji međusobno nisu kompatibilni. Prijedlog nove generacije obrazaca iznosi Paul Winkler u članku PyMeld2: A Proposal for Next Generation Templates for Python Web Apps (ciljevi koje on navodi su vrlo slični mojim zahtjevima).

PyMeld koristi regular expressione za obradu obrazaca što je za mene veliki minus. meld3 i webstring su tu napravili korak naprijed pa koriste vrlo dobre ElementTree i lxml biblioteke (meld3 prvu, a webstring obje, ali isključivo). lxml slijedi ElementTree API pa je implementacija TE-a nad različitim bibliotekama vrlo pojednostavljena. Autor lxml biblioteke napisao je odličan osvrt na razlike i sličnosti između te dvije biblioteke.

Komentari

21. srpnja 2006. 12:30

daj prevedi cms na hrvatski :)

inace ova tema me jako zanima jer vec valjda godina prckam po TL. mislim da dobar TL nije uopce tesko napisati kad znas sto zelis dobiti. naravno kao i svi, napisao sam svoj, sa kojim sam poprilicno zadovoljan, ali siguno ide revizija za 6mj do goninu, kak to vec ide

probleme koje u prici vidim su - cesto je TL vezan uz framework u kojem radis. kako su vjerovatno svi publick TL nastali kao extenzije nekog mozda zatvorenog FW, nastaju problemi. ekipi koja je to izbacila vjerovatno je to najbolji TL, drugima je uvijek nekako seprtljav (bar meni) - ima li logike u TL ili je on full vani. ako drzis cijelu logiku vani, onda se TL 70% sastoji od dobrog repeatera i popratnih inline funkcijica tuUpperCase, trim i sl. - naletio sam na neki ruby templating, koji parsa xml preko dom-a a ne saxa. jezik je predivan a brzina pre-jeziva. jel to bilo tako tesko nastekati na sax. - ... uvijek nekaj

moje misljenje je da ako imas svoj FW, nema ti druge nego nacukat i TlL. ako dijelis moje misljenje, mozemo ovdje nastaviti komunikaciju pa da si pomognemo. sad idem citati linkove koje si postavio.

21. srpnja 2006. 19:23

Misliš na WP? Počeo sam pa sam stao, nemam dovoljno vremena da završim sve pa neću ni na pola. :-)

Ako si pogledao linkove onda si vidio kakav TL je po mojoj mjeri. Zašto sax, meni više leži dom, s njime se cijela stvar može uskladiti s js-om i dom-om na strani klijenta.

21. srpnja 2006. 20:26

znao sam da ces to reci za dom, jer je sladak kao ideja. svoj prvi ozbiljniji TL napravio da radi preko doma. problem je da je dom pre-pre-spor. napravi malo testova i sve ce ti biti jasno. recimo da se koristi call-back template jezik. zasto sam se rjesio dom-a i slozio da radi preko sax-a - zato sto je rener time skoro linearno rasao sto je dokument bio veci. recimo da imas stranicu sa 20 blogova, svaki moze imati do prvih 30 komentara. nek svaki komentar takoder block element koji u call-backu nekaj radi. recimo da koristis neki OR FW za bazu i da sve objekte i liste dovlacis iz kesa. dakle sve imamo u memoriji. garantiram da stranicu neces moci zbildati u manje od 1000ms. sa sax parserom to padne na oko 20ms. dom-u jednostavno treba previse da napravi selectNodes ili getElementById. poglec malo testove na webu. o java dom parserima ili saxonu da i ne pricam. - zato sto u biti nema potrebe za dom-om, tj. ne donosi nista tako znacajno. metode parentNode, nextChild i ostalo se jednostavno sloze u saxu ako ti treba. okidanje eventata kad naleti na element mozes cak i sa RegExp-om. - zna ici na zivce i jako nervira kada ti sav output metoda u TL mora biti valid dom objekt. nemres koristiti CDATA jer onda dom parser nece nis moc pobrat. a gradenje dom objekata iz xml struntura traje pun k. (untar metode) i onda ga jos moras prikljucit na parent strukturu, jezivo, sporo, seprtnjavo, horror. kad si u saxu samo vratis string i sve radi za 5. naravno takoder moras paziti da je valid dom, ali je jako brzo i puno elegantnije. - zato sto ti svaki imput mora biti valid xml a to je pain i cesto nemoguce. recimo sa saxom koji ne mora primati valid xml (moj favorit) nego samo okine event kad naleti na nesto sto mu se svida, mozes generirati rtf i ostala cuda. tak i asp.net radi ako se ne varam. - zaboravih escape-anje specijalnih karaktera koje se nemre bas uvijek izbjeci.

vjeruj, ne razmisljaj o dom-u U TL ako ti je zivot mio. za prikaz RSSa je to super, kao i za parsanje HTML DOM-a u JS, ali mislim da mu tu i upotrebljivost staje. da rezimiram, mislim da je DOM dobar na klijentu, a na serveru bi trebao biti zabranjen.

21. srpnja 2006. 22:08

Kakav si dom parser koristio i u čemu si programirao? Ima ih različitih, neki su spori neki su brzi. Meni sax po koncepciji ne odgovara tako da mogu žrtvovati nešto od brzine, a u planu imam i cache pa se dokument ne bi parsao svaki put od početka. Testovi koje sam do sada radio nisu me obeshrabrili u nakani da koristim dom. A opet...tvoje argumente ne mogu samo tako odbaciti, malo sam prosurfao u namjeri da pročitam novije osvrte na dom i sax (zapravo na aktualne parsere) i naletio na . Jasno je da svaki cigo svojeg konja hvali, ali hvale ga i druge, poznate i ugledne stranice pa ima tu nešto...

23. srpnja 2006. 00:08

da dobro govoris, sve je to jasno. problem je sto sam emocionalno vezan uz ovu temu, moglo bi se reci da mi je to hobi u puslu u kojem se bavim. sve sto sam napisao osjetio sam na svojoj kozi, i to su iskustva iz prve ruke. recimo meni je asp .net jako zanimljiv, i mislim da je njegov templating jako dobar. on recimo izbilda cijelu dom strukturu u memoriji na osnovu pod inkludova, modula i cega god, i onda po tome mozes pikat kak te volja. to je jako dobro (ima ostalih stvari u .netu koje me jako zivciraju, ali necemo sad o tome). probao sam sam napisati dom templating, i uspio sam, a onda sam od toga odustao. koristio sam windows deault xml. zakljucke mozes vidjeti u gornjem postu.

idem procitati link, poz kao najveci problem vidim upravo FW koji zelis koristiti i koji ti nacin rada najvise pase. recimo ja sam vec 6 godina na domain modelu, a asp .net se jos uvijek nemre rjesiti page modela.

ruby tu recimo da blista,ali kod njega - mi smeta kaj se stavri nisu prerezale kod data providera i template renderinga nego su to sve zbukslai zajedno u kontroleru. onda nemrese imati ciste rpc procedure koje interno konzumiras, nego je to sve kupus. - ima previse konvencija - mapiraju path kao /class/method sto mi je idiotski, makar se samnom nece sloziti 90% ljudi. po meni bi se to trebalo mapirati na template, pa ako on oce zvat server preko call-backa, nek ga zove preko. ima puno redudancije u kodu , i opet imas klase koje se brinu o tome da dohvacaju i filtriraju podatke, te se brinu i o prezentaciji, a to su dva svijeta (brinu se zato sto u klasi pise s kojim templateom se treba parsat output, a tome tu nije mjesto) - ...

23. srpnja 2006. 00:20

hah, eto VTD requires that XML document be maintained intact in memory.

i kak bus to postigao? prvi put kad appendas dom objekt na poziciju x, banana. opet moras sve preparsavat. ??? to mi ne izgleda bas zgodno za web.

evo proucio. da to je super fast za strukture koje nisu podlozne promjenma. kazes da bi kesirao template. mozda :) ali treba uzeti u obzir da ti se final rendering sastoji od x elementa koji su ovisni o y atributa (broeser, security level, qs parametri, viewstate, ...) na kraju dojdes do toga da imas tonu kesa s kojom neznas kaj bi, pa se kao i svi oslucis na element cache. onda male komadice drzis u memoriji i imas jedan thread koji se sporo vrti i brine se o stanju cacha, ili se mozda varam.

bas me zanima kaj ces odluciti. daj probaj napisati koji je nacin rada na koji si navikao do sada.

23. srpnja 2006. 15:32

asp.net templating je dobro osmišljen, neke stvari sam si i ja tako zamišljao i prije nego što sam ga vidio, ali je sama implementacija promašila prirodu web aplikacija (npr. event model je od početka trebao biti ajaxoliki, master page su dodali tek u 2.0, VS 2003 producira nestandardni kod, viewstate bloat).

Domain model? Možeš li ga ukratko opisati/objasniti, tj. kako ga koristiš?

Nisam se detaljno bavio ROR-om, ali upoznao sam se s nekoliko PHP MVC okruženja i čini mi se da su prikladniji za jednostavnije aplikacije, dok je za složenije web stranice njihov model neprikladan.

vtd-xml nisam probao, ali čini mi se da bi mogao biti dobar kompromis između doma i saxa.

cache? To je složena priča. Ne može se samo tako uzeti neki cache i primjeniti na sve situacije. Kod weba postoji potreba da se za pojedine dijelove stranice koriste različite strategije, ovisno o učestalosti osvježivanja podataka.

Ja sam koristio cache u svojem starom TL-u tako da bih pospremio rezultat obrade obrasca (parsiranja templejta) budući da je obrada zahtijevala određeno vrijeme, a obrazac se mijenjao samo kad bi se mijenjao izgled stranica.

25. srpnja 2006. 18:31

e fino, sad imamo o cemu pricati. sve sto si rekao o .net-u po meni stoji, i to su i najvece mane. ja osobno volim .net fw, ali mislim na je asp.net sranje. ok radi brzo i stabilno, ima masu modula, dobar community i najlakse nades takvog probramera danas kao poslodavaoc, ali i dalje je sranje u pravo zbog stvari koje si gore naveo. navise mi smeta umjesto da rade interace, oni rade implementacije. nadalje mislim da fw u kojem nemres cukat kod u text editoru takoder sranje.

ali pustimo sad to. evo ja cu ti reci kako sam stvari rjesio, kaj me boli, pa da vidimo di cemo stici. mozda se tebi neke stvari razbistre, a i meni.

pod domain modelom mislim da se na jednm mjestu deiniraju globalni parametri aplikacije, veze izmedu objekata, i struktura podataka na domeni u "rootu" evo linka http://www.phpwact.org/pattern/domain_model to je u biti ror i java struts

evo jedan jednostavan primjer templejta za popis blogova (koristim [] zbog tvog filtera)

[g:rpc ns="blog" do="blog.list" param="userid:=sys.user.id" cache="10 min"] [data poz="1"] [div class="blog_first"] [h2]$blog.name - $blog.created[/h2] [p]$blog.data.bbcode()[p] [/div] [/data] [data] [div class="blog"] [h3]$blog.name[/h3] [p]$blog.data.trim(2000).bbcode()[p] [/div] [/data] [nodata]korisnik user.name nema blogova[/nodata] [/g:rpc]

evo pa da pojasnim u detalje [g:rpc ns="blog" do="blog.list" param="grp:5;userid:=sys.user.id" cache="10 min"] rpc - je modul koji radi upit na klasu u sustavu. blog.list daje listu listi koja izgleda recimo ovako [ title, body, created ] ['zadlji post naslov', 'zadlji post tijelo poruke', '4.4.2006'] ['prijasnji post naslov', 'prijaslji post tijelo poruke', '3.3.2006']

ns - je namespace za exportane variable. tu sad nije bio potreban, ali treba kad imas nestane or petlje (sto bi u biti trebalo izbjegavati)

do - klasa.metoda

param - parametri i css obliku, sa time da ako pocinje sa = onda se uzima vrijednost varijable od onoga sto slijedi

cache - koliko dugo da kesira rezultat. on cijelog sadrzaja rpc metode se napravi kljuc sa md5. cache nije vezan uz rpc modul, njega se moze naljepiti na bilo koji drugi

data, data poz=1 i nodata - jasno samo po sebi. data je default repeat blok, poz-1 za prvi, poz=last za zadnji i tako. mozes reci poz=6 pa ce 6. element u for petlji biti drugacije formatiran

$blog.data.trim(2000).bbcode() $blog.data sadrzi vrijednost body polja za taj prolaz petlje (current row) na to ide inline funkcija trim(2000) koja prereze postove dujle od 2000 karaktera (recimo kao kod borje na popisu blogova) a na kraju bbcode() koji nakelji pravila za bbcode formatiranje.

naravno da je cijeli data blok mogao ici u poseban file. to inace tako radim kada postoje templati za neke tipicne liste (tipa user+nick+avatar). onda mogu ici sa razlicitim podacima u repeater petlje(top useri, novi useri,...), samo moram paziti da su imena polja uvijek ista kad se vuku podaci. to sam pobrao iz zope-plone-a.

sve radi preko custom sax parsera, tj. sam sam ga napisao, ima oko 100 redova u perlu. u biti ono sto napravi je da od gornjeg elementa napravi dict. koji izgleda ovako $n->{ NODENAME } = rpc; $n->{ NS } = g; $n->{ do } = blog.list; $n->{ param } = ... skuzio si vec. i onda idem sa referencom na dict u modul rpc. ovo je zgodno jer on moze promjeniti neki parametar i vratiti $n ref iz kojeg se onda nazad izgradi node. primjer [g:img src="path/do/slike.jpg" width="120" /]

a img metoda napravi resize na width=120, postavi $n->{ height } = 300, doda alt ako ga neme i samo vrati $n. template render to pretvori u [img src="path/do/slike_male.jpg" width="120" height="300" alt="Thumbnail for path/do/slike.jpg" /]

eto ovo je recimo 20% templatinga, ali moramo sa necim poceti. kak ti se cini za sada?

25. srpnja 2006. 18:59

nadalje ajd da objasnim par domain fora koje koristim qs /blog/show/15-neznam kaj napisati pretvorim u /?path=blog/show&id=15 ili /forum/15-prijava-bugova?topic=32 u /?path=forum&id=15&topic=32 dakle ako je u pathu element koji pocinje sa brojem, izcupam broj pretvorim ga u id prametar i stripam text van nadalje sve get parametre provucem kroz filter i jednostavno izbrisem sve qs parametre koji ne prolaze regexp /^[\w-]+$/, tako da se odmah rjesim sql injection i drugih problema.

kako se parsa path parametar /blog/show gledam dali postoji root.inc u i uzimam prvi po redu - /blog/show/root.inc - /blog/root.inc - /root.inc ako nema niti jednog vratim error. na taj nacin mozes super simple raditi posebne master templejte za odredene kategorije poanta je da - /blog/show.inc nema pojma koji mu je master template - zbog toga se mozes igrati sa dizajnom, a sto bilo koji pront page controler fw moze samo sanjati. treba ti samo dobar grid maher napraviti dobre html templejte (web.burza i nivas.hr, ostali kod nas su banananjerosi) - ovo sam naveo zato sto sam u nekom prijasnjem postu rekao da mislim da je templating vezan uz fw, a ovo je ociti primjer.

imas mali "core" za fw, a vecinu stvari rjesavas preko modula i event hendlera. deiniras recimo request.start, page.render.start, page.render.end i ostalo kaj ti treba i popikas na odgovarajuce mjesta u jezgri sustava. onda ako recimo zelis raditi windows-1250 (jer eto radis na windozama kao ja) u utf-8 i nazad transormaciju, samo se zakacis na page.render.end da pretvoris windows-1250 u ut-8 i na request.start da elemente $post.data ako ga ima pretvoris iz utf-8 u windows-1250. zgodno ja da stranice u sustavu nemaju pojma kroz kaj se filtriraju. tak radi diango recimo. radosti globanog hookanja prije i poslije zapisivanja u bazu ne zelim ni spominjati :)

zisku?

25. srpnja 2006. 21:20

Ti si se raspisao, treba mi malo vremena da to provarim. Pogledao sam onaj link, pročitam da . Pomislim si kako je to ok, ali da je ono što ja planiram zapravo Object model, i zapravo sve se svodi na isto.

Kao pravom produktivnom lijenčini meni je cilj da pišem što manje koda, ali i da ne mučim svoje računalo s previše koda. Zato mi se ne dopadaju neka rješenja koja generiraju kod. Ja zamišljam to drugačije, kod se ne smije ponavljati, bez obzira da li ga piše programer ili program. Neki imaju razne data objekte i aktivni slogove koji su odraz onoga što je u bazi. Čemu to ponavljanje? Zašto bi aplikacija trebala biti svjesna stanja u bazi, zar se ne bi trebala brinuti samo o podacima koji joj se dostavljaju. Baza kao takva treba se brinuti o podacima i njihovoj cjelovitosti.

Ja razmišljam o prilagođavajućem kodu, čak sam predvidio i ime za taj engine: Morpheus (he who forms, shapes, molds). Objekt se prilagođava podacima koje dobiva i koji određuju njegovo ponašanje. Hm...radi se o web aplikacijama, treba sačuvati cjelovitost dizajna. Template bi zapravo trebao biti vrlo sličan onome kako bi konačna stranica trebala izgledati. Programer bi uzeo kod od web dizajnera i samo naznačio kojemu objektu koji dio pripada. Database majstor bi složio bazu i procedure koje bi se brinule o proslijeđivanju podataka i njihovom unosu u bazu. Eventualno bi trebalo napraviti neki maping (url-ovi, baza-objekti) i to bi bilo to. Što programer programira? Ništa. Sve ostalo radi Morpheus. Zapravo to je idealan slučaj. Programer se brine o Morpheusu koji je svaki dan sve jači...;-)

26. srpnja 2006. 01:10

Zašto bi aplikacija trebala biti svjesna stanja u bazi, zar se ne bi trebala brinuti samo o podacima koji joj se dostavljaju. Baza kao takva treba se brinuti o podacima i njihovoj cjelovitosti. - pa recimo banalan primjer. imas polje email pored usera. baza to ne moze provjerirti (ili moze jako komplicirano). sada da ne radis svaki put provjeru jeli to pravi email, stavis to u model objekt. onda samo nafilas user objekt sa podacima, a objekt vrati ok ili error u slucaju greske. pametan model objekt ce vratiti error, email u krivom formatu, ili email moram imati @. fora je da ti u kontroleru samo ljepis i tuneliras podatke, a info o uspjesnosti operacije samo proslijedis na klijent. kotroler cak ne treba znati jeli operacija uspjela ili nije, on samo tunelira. imas recimo takoder fore da jedan od dva moguca polja mora biti ispunje. kak bus to bazu natjero daa radi bez redudancije?

Database majstor bi složio bazu i procedure koje bi se brinule o proslijeðivanju podataka i njihovom unosu u bazu. - svasta, pobogu pa kaj si neznas bazu slozit? to su price, tak se mozda radi kad imas velike timove i velike projekte, pa se podjele odgovornosti. za web portale i aplikacije to je nepotrebni "overhead". ja cesto dam da mi se napisu neki sqlserver botovi i tak, ali to je jako rijetko. nadalje, mislim da ruby iz koda direktno generira bazu, tj. bazu ne moras nikada ni vidjeti (da moguce je to :). a sta bi tu database maher radio, pitam se. sluzi samo da napise dobar or maper i to je to.

vjerujem jedino u suradnju designeri - programeri - strucnjaci iz podrucja koje se obraduje. ostalo je sve uglavnom visak. a kad mi db admini pocnu trkeljat sranja o blobovima i kak je to super, digne mi se kosa na glavi.

ah ha, ajd malo prouci ovo gore pa se javi. inace meni je najbolji php mvc fw "code igniter". burazi su to lijepo zakopali i vidi se da imaju iskustva. cak im se moj frend javio i sada sa njima to dalje razvija. pogle si to malo, fino su to slozili. kaj se pitona tice dijango ak se mene pita.

ideja sa Morpheus-om je zgodna, i stvarno bi tako i bilo da se svako malo nekaj novo ne dogodi. nazalos treba stvari raditi tako da su prilagodljive.

26. srpnja 2006. 05:30

Spominjanjem DB-a želio sam naznačiti važnost da se baza složi na pravi način. Kod malih web aplikacija (koje su male po napisanom kodu, a ne po važnosti) sve uloge može odraditi jedan čovjek, ali danas ćeš teško naći osobu koja zna sve te uloge odraditi na profesionalan način.

Ti alati koji iz koda generiranje bazu su lijepi i krasni, ali s njima ćeš uvijek imati ograničenja, stvari koje oni ne mogu odraditi, a o optimizaciji baze nema ni govora. Baza se treba posebno složiti bez ikakvih čarobnjaka koji su prilagodljivi različitim bazama pa da ti ne moraš misliti već samo pisati kod. Kod nekog od tih alata (ne znam sad koji) vidio sam da uvijek kreira tekstualna polja koja su sva iste dužine u bazi. Pametnome dosta.

CI je zgodan, meni se dopao najviše od tih PHP okruženja, ali naišao sam na par stvari na koje sam se spotaknuo pa sam odustao od njega.

Ima svugdje naših ljudi, koliko sam vidio neki od njih rade i na Zend frameworku (Cache modul).

14. listopada 2006. 23:52

ništa ne kontam