Itseäni on jatkuvasti ruvennut häiritsemään enemmän ja enemmän se, ettei JSR-168-speksi ota mitään kantaa seuraaviin asioihin:
- Miten portlettien tulisi luoda linkkejä toisille portaalisivuille?
(nykyisellään tarjotaan API ainoastaan portletin sisäisille linkeille)
- Missä muodossa ja millaisen rajapinnan kautta containerin tulisi tarjota portaalisivuston hierarkia?
(jokin JSR-170:een perustuva ratkaisu voisi olla järkevä)
- Miten portaalisivujen urlien tulisi muodostua?
(”friendly urlit”, yms)
- Miten portletteja kutsutaan portaalin ulkopuolelta ja missä muodossa HTTP-parametreja tulisi välittää sivun portleteille?
(tämä tarve on olemassa, vaikka portlet-speksin kirjoittajat yrittävätkin parhaansa mukaan olla ymmärtämättä, mitä tarkoittaa web-sovellusten kehittäminen; verkossa sovellusten tulee pystyä välittämään tietoa keskenään)
Nyt jokainen portaalituote toteuttaa nämä ominaisuudet omilla tavoillaan, eikä mitään uudelleenkäytettävyyttä eri portaalien välillä tulla koskaan saavuttamaan, paitsi ehkä jossain taskulaskin-tasoisissa “hello world”-sovelluksissa.
Matt Raible on muuten pitänyt jälleen vuosittaisen vertailunsa eri web-kehysten välillä. Erittäin suositeltavaa luettavaa etenkin niille, joiden mielestä on erihienoa, ettei JSF:ssä tarvitse välittää urleista ja HTTP-kutsuista:
ComparingJavaWebFrameworks.pdf
Toukokuu 26th, 2007
Skypen kehittäjät tekivät sen taas: Ensin pistettiin puheluiden hinnat uusiksi tarjoamalla ne ilmaiseksi netissä ja nyt on vuorossa televisio.
Joostissa katsoja voi valita haluamansa kanavan lisäksi myös haluamansa ohjelman tai vaikkapa musiikkivideon. Enää ei siis tarvitse kökkiä television äärellä tiettyyn kellonaikaan, jos haluaa nähdä jonkun ohjelman. Joostista ei myöskään peritä televisiolupamaksua.
Tällä hetkellä Joost on beta-testissä, joten suurimpia televisioyhtiöitä ei vielä ole kanavalistoilla. Sopimus on kuitenkin jo olemassa ainakin Warner Musicin, Paramount Picturesin, Viacomin ja MTV:n kanssa. Oletettavasti muutkin seuraavat.
Näin lyhyen testailun jälkeen kaipaisin Joostiin vielä tallennustoiminnallisuutta. Myöskin mahdollisen tekstityksen toteutus jäi hieman avoimeksi.
Toukokuu 5th, 2007
Eilen tuli televisiosta mielenkiintoinen keskustelu Ylen A-Talk-ohjelmassa. Siinä neliraajahalvaantunutta miestä ja tämän vaimoa ei oltu hyväksytty adoptioon ja yli viisikymppinen nainen penäsi oikeutta adoptoida pientä lasta.
En olisi aiheesta kirjoittanut, mutta kyseinen ohjelma on nostattanut melkoisen metelin erinäisillä keskustelupalstoilla. Jopa adoptiovanhemmat ovat nähneet oikeudekseen pilkata keskusteluun osallistuneita adoptiojärjestöjen edustajia täysin navan alle suunnatuilla kommenteilla. Tällainen toiminta ärsyttää minua suunnattomasti.
Minusta etenkin adoptionhakijoiden tulisi ymmärtää hyvinkin tarkkaan, etteivät Pela ja Interpedia ole mitään lastenvälitystoimistoja. Heidän työtään EI ole meidän tarpeidemme ja toiveidemme täyttäminen. Heidän työtään on lasten oikeuksien ja elinolojen parantaminen. Varsinkaan ulkomainen adoptio ei edes ole tähän tarkoitukseen paras ratkaisu ja voi olla, että loppuu nykyisessä muodossaan nopeammin kuin uskommekaan.
Adoptio ei myöskään ole mikään jokaisen suomalaisen perusoikeus. Adoptiossa on kyse siitä, että otetaan jonkun toisen lapsi omaksi; kyse ei ole mistään autopaikkojen jaosta. Adoptioneuvontaa taas voidaan verrata työpaikkahaastatteluun, jossa jokaista paikkaa kohden on moninkertainen määrä hakijoita. Työnantajan tehtävään sopivimmiksi katsovat saavat paikan. Joskus voi mennä pieleen, mutta toivottavasti mahdollisimman harvoin.
Henkilökohtaisesti ymmärrän, mikä ongelma on antaa pientä lasta perheeseen, jossa vanhemmat pistetään oletettavasti multiin 20-25 vuoden sisällä (tämä oli haastatellun naisen oma arvio) tai mikä on riski siinä, että neliraajahalvauspotilaan vaimolle kävisi jotain, mikä estäisi adoptiolapsen hoitamisen. Kuten Pelan edustaja keskustelussa mainitsikin, niin adoptiossa pyritään välttämään tilanne, jossa adoptoitu menettää vanhempansa uudelleen. Kyse on todennäköisyyksistä, eikä siitä, että ovatko ko. henkilöt soveltuvia vanhemmiksi. Ymmärtääkseni sitä ei kukaan ollut kiistämässä.
Huhtikuu 21st, 2007
Tätä muutosta toivoisin Javaan enemmän kuin mitään muuta:
http://users.encs.concordia.ca/~chalin/papers/2006-003.v3s-pub.pdf
4.5 Summary
A summary of the languages, extensions and tools covered in this section, is given in Table 3. Two key observations are that for all languages and tools not using Java 5 annotations there seems to be a trend in adopting
- non-null type system over non-null annotations, with
- non-null as the default.
Even well established languages like Eiffel are making the bold move of switching to the new default. The apparent trend in the evolution of languages supporting pointers would seem to indicate that the time is ripe to consider a switch in Java from nullable-by-default to non-null-by-default. A concrete proposal for this is given in the next section.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5030232
Huhtikuu 16th, 2007
Lueskelin artikkeleita eri JavaScript-kirjastoista ja törmäsin erittäin mielenkiintoiseen keskusteluun OpenAjax Alliancesta:
John Resig - Thoughts on OpenAjax
Uskoin Mootoolsin olevan tämän hetken kehittynein JavaScript-kehys, mutta alan nyt vahvasti kallistumaan JQueryn suuntaan. Eikä tämä ole ainoa syy. Myös Liferay siirtyi JQueryyn.
Toinen erittäin mielenkiintoinen projekti (hieman eri kaliiberia) on Microsoft Researchin Singularity. Kyseessä on mikrokernel-käyttöjärjestelmäprototyyppi, jossa käytetään hyväksi ns. hallittua koodia jo kernelitasolta lähtien.
Projektin sivutuotteena on syntynyt uusi ohjelmointikieli, joka pohjautuu aiempaan Spec#-kieleen. Kielen nimi on Sing# ja siinä on aiempaan Spec# “design by contract“-malliin lisätty Erlang-tyylinen viestinvälitys prosessien kesken. Nyt vain odotellaan kattavampaa dokumentaatiota. 
Ja lopuksi sitten otsikossa mainittuun MVC-kehykseen: En tiedä olenko ainoa, mutta mielestäni muuten niin mainiossa Springissä on toistaiseksi sekavin MVC-kehys, johon olen törmännyt. Jo pelkällä controller-hierarkian UML-mallilla tapetoisi pienen yksiön (fieldit jätetty pois):
Kehyksen perusfilosofia tuntuu olevan: “Ylikirjoita ne metodit mitä haluat”. En oikein pidä tästä lähestymistavasta. Ensinnäkin jo sen selvittäminen, että mitä metodeita missäkin prosessoinnin vaiheissa kutsutaan, on vähintäänkin sekavaa. Lisäksi kun saman ylikirjoituksen voi tehdä useammasta metodista, sekavoituu asia entisestään. Esimerkiksi formin submitin voi napata kiinni SimpleFormControllerissa ainakin kahdeksasta eri kohtaa.
Sitten on kaikenlaisia formBackingObject-, initBinder-, referenceData-, onBind- ja handleInvalidSubmit-metodeja ihan yleisimpiä luetellakseni. Ovathan ne tietyllä tapaa loogisia sitten kun luutuvat päähän, mutta esimerkiksi kaksoispostauksen estämisen selvittämiseen meni kyllä hetki (synchronizeSession true, sessionForm true ja handleInvalidSubmitissa showForm BindExceptionilla).
Jos muihin Model 2-kehyksiin verrataan, niin vaikka esimerkiksi Strutsissa on omat ongelmansa, niin ihan rehellisesti sanottuna sen käyttäminen oli erittäin paljon tuottavampaa; ainakaan ei tarvinnut arpoa, että mitä tapahtuikaan missäkin vaiheessa.
Loppukevennyksenä täytyy vielä mainostaa todella karseaa virheenkäsittelykoodia Apache Velocityssä. Montako virhettä löydätte seuraavista luokista?
org.apache.velocity.Template
org.apache.velocity.app.Velocity
Oma suosikkini:
try
{
return evaluate( context, writer,
logTag, construct.toString() );
}
catch(ParseErrorException pee)
{
throw pee;
}
catch(MethodInvocationException mie)
{
throw mie;
}
catch(ResourceNotFoundException rnfe)
{
throw rnfe;
}
catch(IOException ioe)
{
getLog().error("Velocity.invokeVelocimacro() failed", ioe);
}
/**
* pass through application level runtime exceptions
*/
catch(RuntimeException re)
{
throw re;
}
Ja tietysti kaikki init-metodit heittävät tyylikkäästi Exceptioneita. Eli suosittelen tosiaan edelleen FreeMarkeria.
Huhtikuu 12th, 2007
Uudemmat kirjoitukset
Aikaisemmat kirjoitukset
