Krátké oRESTování

O RESTu se všude vedou dalekosáhlé debaty. Například zde se Vlasta Vávrů snaží přijít oné věci na kloub.
Nejsem sice kdovíjaký REST-guru, ale svoje si k tomu řeknu:
* REST je o zdrojích (resourcech). Každý zdroj má svou jednoznačnou identifikaci - URI. Po dobu jeho životnosti pod tímto URI vždy a za každých okolností najdete tento zdroj (jestli je to URLčko nebo URN do repozitáře je buřt). Každý zdroj JE STAVOVÝ. Minimální sada stavů je jsem - budu - byl jsem. Představíme-li si jako zdroj seznam členů CZLUGu, je jasné, že se bude v čase měnit. Ale pokaždé dostanete logicky totéž, aktuální seznam členů. No, aktuální, RESTózní architektura umožňuje plnohodnotné interceptory, kde například může stát cache, která vrátí seznam klidně včerejší. I o tom REST je. Data nemusí být vždy aktuální.
* důležitou vlastností RESTózních aplikací je omezená množina operací, které lze s daným zdrojem provádět. Proto je HTTP RESTózní, má čtyři hlavní operace GET, POST, PUT a DELETE.
* komunikace MUSÍ BÝT BEZESTAVOVÁ, tedy komunikace nesmí zahrnovat stav klienta. To ale neznamená, že sezení jako takové je v RESTu nesmysl. Pouze jeho řešení pomocí sušenek je nepřípustné. Mám-li sezení zakomponováno do URL, jsme v pohodě. Samo sezení se stává zdrojem. Dostávám se tak do situace, kdy logická operace přidej produkt s URI:XY do košíku patřící sezení s URI:SSS (třeba HTTP POST SSS produkt=XY) bude mít za následek vždy to totéž a o to právě v RESTu jde. Dalším problémem pro bezestavovost komunikace jsou <INPUT TYPE="HIDDEN">. Tyto jsou v HTML zavedeny právě pro udržení stavovosti komunikace, čili typická antiRESTóznost.
Doufám,že si někdy najdu čas a všechno, co o RESTu vím, sem napráskám.

Fotomapy alá seznam.cz

Na Ilblogu jsem zaznamenal spuštění nové služby - foto.mapy.cz. Nemá smysl komentovat funkcionalitu, to se musí vidět. paráda.
Už si žhavím foťák...

Tak to ještě se mnou není tak hrozné

O víkendu za mnou přišel bratranec s prosbou, jestli bych mu nepomohl s řešením domácího úkolu z geometrie pro jeho dceru, studentku druhého ročníku ekonomky. Danou úlohu neměli v učebnici, neprobírali ji a jejich kantor prohlásil, že to mají udělat selskou úvahou. No zkrátka nedali to.
Zadání je vcelku triviální. Zkonstruujte trojúhelník, pro který platí: |AB|=4cm, v(c)=3cm, úhel ACB=60 stupňů.
Uznávám, že je to trivka. Ale sám jsem byl přeqapen, že jsem to vypotil bez dlouhého přemýšlení a bez nutnosti použít literaturu, i přes propast 16let od maturity, kdy jsem naposled rýsoval.
Ti z vás, kterým se nechce nad řešením přemýšlet, najdou postup řešení v komentářích.

Nepoužívejte CORBU, smrdí, aneb rychlost řešení chyb v Sun JDK

Tušil jsem, že rychlost řešení nebude přílš vysoká vzhledem k množství chyb, ale co je moc, to je někdy opravdu příliš.
V Barcu máme docházkový systém, který je řešený appletem komunikující se systémem přes CORBU. V JDK 1.4.2 fungoval naprosto spolehlivě. Při přechodu na 1.5 mu přestala chodit CORBA. Lidé z ComInfa dodali workaround - soubor java.policy obsahující:

// CORBA error workaround
grant codeBase "http://192.168.11.9/watt/jar/*" {
        permission java.lang.RuntimePermission "modifyThread";
        permission java.lang.RuntimePermission "modifyThreadGroup";
};

Přišlo mi to strašně divné, protože nutnost povolovat práci s Thready považuji za prasárnu. Tak jsem začal pátrat, co za svinstvo tam můžou vlastně dělat. Odpově byla přeqapující - jsou v tom nevinně!

Chybu má totiž na svědomí com.sun.corba.se.impl.transport.SelectorImpl, který na začátku metody run() udělá naprosto samozřejmou věc - nastaví si jméno. Potíž je v tom, že v Appletu je takováto operace by default zakázána! Aby ji bylo možno provést, je třeba si spustit v Privileged módu. Stačí tedy ono volání zabalit do doPrivileged() a máme vystaráno. Jednoduché, fix na deset minut, který navíc může být potencionálně na více místech, takže za hoďku za dvě může být pořešeno celé JDK.
Jenomže to bychom museli být někde jinde. Buga číslo 6203567 byla reportována v 03-DEC-2004 a podle všeho ještě pořád není fixnutá! A to je u reportu jednoduchý kód na její reprodukci včetně patche. Navíc bylo od Sunu před třemi lety získáno prohlášení, že to bude v tehdy příští verzi opraveno. Nevím, ale fixnutí by zabralo méně času než vydání onoho prohlášení :-)
Schválně si na vašem JREčku vyzkoušejte, jestli vám projde! Já dostal:

tapik@bilbo:~> java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
tapik@bilbo:~> appletviewer CorbaTest.html
Exception in thread "Thread-2" java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        at java.security.AccessController.checkPermission(AccessController.java:546)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at sun.applet.AppletSecurity.checkAccess(AppletSecurity.java:214)
        at java.lang.Thread.checkAccess(Thread.java:1263)
        at java.lang.Thread.setName(Thread.java:1050)
        at com.sun.corba.se.impl.transport.SelectorImpl.run(SelectorImpl.java:239)

Ať žije frameworkování

Jakožto člověk, který začínal s trošku obsáhlejším programováním na Didaktiku Gama a v assembleru se mi zvedá žaludek nad dnešním přeframeworkovaném programování. To by nebylo nic divného a ani bych vás tím neotravoval, proti gustu žádný dišputát. Nebýt včerejšího dotazu na konference@java.cz .
Jeden človíček se ptal, jak číst a zapisovat data do XML, když jich má obrovskou tabulku v DB o hodně sloupcích a ještě více řádcích. Hovořil dokonce o desítkách GB dat.
Pokud jde o čtení, tam je to jasné. Je to XML a on nemůže předpokládat nějakou pevnou textovou strukturu a musí tedy využít XML parser. Co mne ale zarazilo, byl dotaz na zápis.
Osobně nepočítám s tím, že by měl všechna data v paměti a chtěl s nimi nějak zásadně při zápisu manipulovat než je prostě odněkud načíst řádek po řádku, provést nějakou substituci na onom řádku a pak jej uložit jako strukturovaný XML element. V čem vidím problém je to, že chlapce ANI NENAPADLO řešit to otevřením OutputStreamu a cpát tam data v textové podobě! Vždyť přece XML je v prvé řadě textový soubor formátovaný tak, aby byl člověkem jednoduše čitelný!

Hodina angličtiny od Elánov

Dneska jsem poslouchal $SUBJ a nevěřil jsem vlastním uším. Dvakrát jsem si vracel onu pasáž. A pak jsem se rozchechtal...
Většina písně je složená z výkladu anglických slov a frází. Tady je první sloka:
Yes je áno a no je nie,
a one je jedna a two je dve,
a hovoriť je speak a dobre je well,
a you've got what you wanted značí, máš, čo si chcel.
a know je vedieť a how je ako,
a watch the Czechs, je pozor na Slovákov,
a go je ísť a out je von,
bože Lendl ten má prachov, chcem byť ako on!

Pro ty málo vnímavé jsem onu pasáž zvýraznil :-)

Java prý prohrává boj o Web

Po delší době jsem zase brouzdal The ServerSide a musel jsem se opravdu zasmát. Přečetl jsem si "Java is losing the battle for the modern web"..., reakci Josepha Ottingera na Java is losing the battle for the modern Web. Can the JVM save the vendors? od Andiho Gutmana. Lidi, číst si některé blog2blog flameware, to je vám fakt někdy švanda. První něco ne zrovna inteligentního vymyslí pro podporu svého tvrzení, druhý to navíc špatně pochopí a polemizuje s tím. No nic.
Přesto je dobré si ona dvě zamyšlení přečíst. Andi se snaží přijít na to, proč je LAMP tak úspěšný a prosazuje se oproti Java EE řešení.
Zaujala mne myšlenka o větší RESTovosti LAMP řešení oproti klasice v Javě, která je podle něj navržena více na Enterprise aplikace a Webový Xicht je tam přidán tak nějak jako navíc. S tou historickou skutečností má dozajisté pravdu. EJB, gró J2EE, vznikaly nezávisle a odděleně od JSDK. JServ jsme používali a EJBoss byl ve stavu nepoužitelném.
Co se týká RESTovosti, tak tady je to dáno geneticky. Spustit CGIčko bylo velice rychlé, obzvláště když byl skript nakešován. Navíc CGI nemohlo být stavové a tak se všechna data předávala v INPUT HIDDEN tazích. Oproti tomu spouštět JVM pro každý request by znamenalo si vyrvat vlasy. Je celkem pochopitelné, že chtěl-li Sun dostat Javu i na serverovou stranu, musel JVM pověsit na ServerSocket. Ono to mělo zase spoustu výhod. Najednou přibyla stavovost a všichni tvůrci Webových aplikací (no, moc nás tehdy nebylo) jásali, protože si mohli data držet v HttpSession. A ano, zde se ztratil REST.
Časem ale došlo k velkému sblížení. PHP dostalo session (ó, jaká to výhoda oproti Perlu, máme podporu session přímo v systému!), J2EE patterny tvrdí něco o bezstavovosti a držení si stavu v DB, což je momentálně jediný způsob, jak si ho drží Perl či Python.
Takže o větší RESTovosti LAMPu to není. Aplikace je tak RESTová, jak se napíše.
Další zajímavý poznatek je o multiprocess versus multithread. Dozajista pád skriptu nemusí nutně znamenat pád celého systému. Ale řekněme si to jinak - od dob mod_php či mod_perl je schopen vzít s sebou skript celý apache. Deadlocky nechrozí jenom zdánlivě - maximální počet spojení na MySQL se při tuhnutí skriptu velice brzo vyčerpá, to mi věřte.
Já si myslím, že hlavní rozdíl je v nasazení. V rámci komunity se vyvíjí především na LAMP ve stylu komunita sobě, komerčnímu světu zase vládne spíše J2EE, protože platící zákazník požaduje záruku stability a pro většinu z nich není ani PHP ani MySQL dostatečnou zárukou. Proto je možno z Webu stáhnout LAMP OpenSource aplikace a vrznout je na svůj LAMP server, kdežto málokdy stáhnete OpenSource .ear .