Euroopan ohjelmistoalan järjestöt ovat listanneet Euroopan top 200 it-taloja. Listan kärjessä on tietysti Microsoft, IBM ja SAP. Kuitenkin meidän puljumme Visma on aika mukavasti siellä sijalla 45 ja puhtaasti eurooppalaisista yrityksistä sijalla 11!

Parhaimpana "suomalaisena" löytyy Tieto sijalta 54. Ystävämme Basware on sijalla 130.

 

Pitäisköhän kohta muuttaa koko otsikko? Tämä vuosi menee open source maailmassa ja toistaiseksi se näyttää hyvältä. Oikeastaan ainoa huonompi juttu on ollut, että koneen resurssit ovat kovilla, kun koneessa pyörii Microsoftin kehitysvälineet ja Java kehitysvälineet + sovelluspalvelimet ja tietokannat samanaikaisesti.

Noh, siihenkin tulee apua ensi viikolla kun pistään uuteen kannettavaani vain Ubuntu Linuxin! (En siis Windowsia. Saas nähdä miten äijän käy.)

Siirryttyäni Java-maailmaan olen ollut positiivisesti yllättynyt kuinka hyviä ilmaistyökalut ovat oikeasti olleet. Teen kehitystä pääasiassa Enterprise JavaBeans 3.0:lla (EJB3), joka on osoittautunut erittäin hyväksi ja tehokkaaksi frameworkiksi business-logiikan toteuttamiseen. Kehitysmalli ja ratkaisutavat ovat selkeitä. IDE-puolella olen käyttänyt Netbeans 6.0:aa, joka on ollut helppo oppia. Se näyttäisi lisäksi olevan aika hyvin optimoitu nimenomaan EJB3-kehitykseen. Kun pakettiin laitetaan vielä ilmainen application server (GlassFish v2) ja tietokanta (MySQL), niin koossa onkin aika paljon tavaraa, joilla palvelinpään logiikan pystyy toteuttamaan. Käyttöliittymäpuoleen en ole toistaiseksi paljoa vielä keskittynyt. Itse asiassa olen tehnyt joitakin UI-asioita vielä 'vanhoilla' Microsoft-työkaluilla. (Vanhoilla siksi, että Java-työkalut ovat minulle se uudempi maailma.) Eri teknologiat kyllä näyttävät oikeasti keskustelevan hyvin sujuvasti keskenään.

 

En olisi tätä vielä jokin aika sitten uskonut itsekään, mutta perusbusinesslogiikan toteuttamisessa EJB3-alusta on osoittautunut tehokkaammaksi tavaksi kuin .NET. EJB on suunniteltu nimenomaan businesslogiikan tekemiseen toisin kuin .NET Framework, joka on paljon geneerisempi. Siis on toisaalta hyvin ymmärrettävää, että EJB on niin hyvä tässä vertailussa... Ehkä suurin yksittäinen tekijä on EJB persistence, jonka vuoksi SQL:ää ei tarvitse enää manuaalisesti kirjoittaa. Tämä nopeuttaa ohjelmistokehitystä huomattavasti.

Viime aikoina .NET puolella on ollut hiljaista ja siihen on syynsä. Viimeiset kuukaudet olen ollut tekemisissä Java-kehityksen kanssa! Näin Microsoft-puolelta tulleena on ollut kiinnostavaa nähdä mitä kaikkea erityisesti Java + open-source puolella todella löytyy. Kun Microsoft-puoli tarjoaa useimmiten yhden tavan ratkaista asia, niin Java-puolella homma on laajempi. Vaihtoehtoisia tapoja on useita (erilaisia application servereitä, sovelluskehitys frameworkeja, peristence providereita jne.). Outoa on ollut myös huomata miten hyvää tavaraa löytyy Java puolelta ja täysin ilmaiseksi.

Tai oikeastaan se julkaistiin eilen. Moni lienee jo odotellut uutta .net frameworkia ja erityisesti LINQ:ta. - Ainakin itse olen. Lisäksi Visual Studiolla pystyy nyt tekemään eri .NET Frameworkia käyttäviä komponentteja. Taremmin sanottuna .NET Framework 2.0, 3.0 tai 3.5 -komponentteja. Ei tarvinne enää olla niin useita Visual Studioita omalla koneella.

 

 

Windows Communication Foundation (WCF) tarjoaa mahdollisuuden hyödyntää sessiopohjaisia yhteyksiä. Erityisesti kun käytetään transaktioita (transactionFlow), suositellaan käytettäväksi myös ReliableSession-määritystä. Tällöin sessioita luonnollisesti käytetään. 

 

Asiakaspuolella hyödynnetään usein ChannelFactory:ä, jolla tarvittavan proxy-luokan voi helposti luoda. Tässä on kuitenkin yksi huono puoli: se ei tarjoa Close() -metodia, jolla session voisi sulkea kun pyyntö on suoritettu. Tässä tapauksessa sessio vapautetaan vasta kun Timeout tapahtuu. (Oletusarvo taitaa olla 10 minuuttia.) Tällä tietysti voi olla huomattavia vaikutuksia resurssien käyttöön ja sessioiden varaamiseen. Session timeoutin voi toki myös määritellä esim. konfiguraatiotiedostossa binding-elementin receiveTimeout-attribuutilla.

 

Em. tapa on huono, koska se ei vapauta käyttämättömiä resursseja heti kun mahdollista. Oikeampi tapa toimia olisi sulkea sessio heti kun sitä ei enää tarvita. Mainio tapa toteuttaa tämä on hyödyntää geneeristä ClientBase-luokkaa. (http://msdn2.microsoft.com/en-us/library/ms576141.aspx) Käytännössä sitä käytetään niin, että luodaan uusi luokka, joka kytketään palvelun tarjoamaan rajapintaan:

 

esim.

 

Tämän jälkeen ko. proxy-luokka toteuttaa rajapinnan metodit suunnilleen seuraavasti:

 

 

Kun tällaista proxy-luokkaa käytetään asiakassovelluksessa, niin nyt tarjolla on Close() -metodi, jolla session voi sulkea. Helpoin tapa on kuitenkin käyttää proxy-luokkaa Using-lohkon sisällä, jolloin Close() -metodia ei tarvitse erikseen kutsua.

 

esim.

 

 

Team Foundation Server on monessa mielessä hyvä peli. "Pelkästään" versiohallinnan uudet ominaisuudet ovat jo käyttämisen arvoisia. Sen avulla on mahdollista määritellä vaatimuksia (check-in policy) versiohallintaan palautettaville tiedostoille. Voidaan esimerkiksi vaatia, että kaikki muutokset on kommentoitu ja että muutos liittyy johonkin TFS workitemiin. Lisäksi koodia voi analysoida millä keinoin tahansa, koska näitä sääntöjä voidaan ohjelmoida myös itse. Tällöin voidaan esimerkiksi tehdä erilaisia koodin tarkastuksia kunkin yrityksen käytäntöjen ja koodaussääntöjen perusteella.

 

TFS:ssä voidaan myös määritellä palvelimella tehtäviä komponenttien käännöksiä. Tällöin kun ohjelmoija palauttaa koodin versiohallintaan, voi hän tehdä käännöksen ajamalla käännöksen palvelimella (team build). Hieno juttu on myös se, että käännösten yhteydessä voidaan ajaa yksikkötestit. Tai olisi, jos se vain onnistuisi. Ongelmana nimittäin on, että tällöin täytyy kertoa ajettavat yksikkötestit testauslistana (test list). Ongelmalliseksi tämän tekee se, että esim. minulla käytössä olevalla Visual Studio 2005 Team Edition for Software Developers -versiolla ei tuollaisia testilistoja saa määriteltyä. Tätä varten pitäisi olla ymmärtääkseni versio "Team Edition for Testers". Aika typerästi paketoitu tuo Developers-versio, koska sillä saa luotua yksikkötestejä, mutta ei testilistoja!

 

Tuohon löytyy kuitenkin kiertotie. Kaikki yksikkötesit pystyy nimittäin ajamaan Visual Studio 2005 -komentokehotteessa mstest-komentorivityökalulla. Tällöin voi testien ajamisen määritellä vaikka bat-tiedostoon. Tämän jälkeen yksikkötestien ajamiseen riittää aina tuon bat'in ajaminen. Jos haluaa vielä kikkailla, niin tuon bat'in ajamisen voi laittaa esim. web servicen ja/tai web -sovelluksen taakse, jolloin sen ajaminen remotena onnistuu myös. Niin ja toki sen voi ajaa myös suoraan sen team buildin yhteydessä, mutta tällöin on huomioitava, että mstest'in käyttö on tuskastuttavan hidasta ja tällöin käännösten tekeminenkin hidastuu. Jokainen mstest-ajo kopioi kaikki tarvittavat dll:t yksilölliseen hakemistoon TestResults-hakemiston alle. Tämä lienee yksi syy siihen, että homma on niiiiiiin hidasta.

(Entä, miten saat käyttöösi Visual Studio 2005 Command Promptin? No bat-komennossa vaikka alla olevalla tavalla. Siinä on myös mstest-kutsu, joka ajaa yhden yksikkötestin.

 

 

Huom! Noita test caseja voi olla useita peräkkäin tuossa samassa mstest-kutsussa. Niiden järjestystä ei kuitenkaan voine määritellä mitenkään. Tällöin pitänee tehdä vain useampia mstest-kutsuja.
)

MSMQ:n oma API ei sisällä keinoja, joilla voisi ohjelmallisesti luoda MSMQ triggereitä ja liittää niihin sääntöjä (rule). Tätä varten on ollut Triggers Admin Utility (trigadm.exe), joka on command line -työkalu ja sillä on pystynyt nuo asiat tekemään. Vistaan ko. mokkulaa ei ole saatavilla. Milläköhän Vista-puolella voisi tehdä MSMQ triggerit?

 

Olen kysellyt asiaa myös MSDN:n newsgroupissa, mutta toistaiseksi ei vastausta. Täytyy seurailla seuraavia sivuja ja odottaa, josko joku löytäisi vastauksen:

 

 

Kävin perjantaina tekemässä toisen osan MCSD:n päivitystestistäni ja testi meni reilusti läpi! Tarvittava pistemäärä testin läpäisemiseksi oli 700 ja aikaa sitä varten oli 240 minuuttia. Käytin aikaa puolet varatusta ajasta ja sain 833 pistettä.  Testi oli tosi vaikea, mutta lopulta se meni läpi yllättävän hyvin. Nyt taskussa on siis tutkinto nimeltä MCPD: Enterprise Applications Developer.

 

Kokonaisuudessaan tutkinto on aika laaja sisältäen yhteensä n. 20 kirjaa MOC-materiaaleina ja harjoituksina. Ko. kirjallisuus ei kuitenkaan sisällä kaikkea testissä tarvittavaa tietoa, vaan niiden lisäksi on täytynyt päntätä suuri määrä dokumentaatiota ja artikkeleita Internetistä. Paljonkohan Suomessa on tämän tutkinnon suorittaneita?

 

 

Yhdistelmällä, jossa on Windows Vista ja Excel 2007, on ongelmia saada yhteyttä esimerkiksi paikallisiin SQL Server 2005 Analysis Services-kuutioihin. Itse sain seuraavaa herjaa toistuvasti: “The Data Connection Wizard cannot obtain a list of database from the specified data source”.  Lääke tähän olikin yllättävän helppo - Excel piti taas käynnistää Administratorin oikeuksilla. Kesti kuitenkin sen verran tämän löytämisessä, että parree laittaa ratkaisu näkyviin. Samaan oli törmännyt myös joku muukin jannu:

Kävin viime viikolla päivittämässä MCSD tutkintoani Visual Studio 2005 -tasolle. Päivittäminen vaatii kahden eri testin suorittamista, joista ensimmäisenä suoritin hajautettuun sovelluskehitykseen pääasiassa liittyvän testin "UPGRADE: MCSD Microsoft .NET Skills to MCPD Enterprise Application Developer by Using the Microsoft .NET Framework: Part 2". Testi on tosi kettumainen eikä MOC-materiaalista löydy vastauksia kaikkiin kysymyksiin. Kysymyksiä oli 58 ja aikaa niiden kelaamiseen muistaakseni 215 minuuttia. Osa kysymyksistä oli sellaisia, että en olisi löytänyt niihin vastauksia vaikka olisi ollut kaikki materiaali tarjolla sekä rajaton aika etsiä tietoa netistä... Vaan tulihan käytyä.

 

.NET Framework 3.0 sisältää yhtenäisen tavan toteuttaa hajautettuja järjestelmiä ja käytännössä kutsua toisella koneella olevaa logiikkaa. Nykyisin käytössä ovat lähinnä Web Servicet, .NET Remoting sekä DCOM. Windows Communication Foundation tarjoaa samanlaisen rajapinnan kaikkiin mainittuihin teknologioihin, jolloin jää konfiguroitavaksi, mitä teknologiaa oikeasti käytetään.

Kannattaako siis siirtyä suoraan käyttämään Windows Communication Foudation palveluita? Kuten tämäkin osoittaa, on Microsoft tuonut aina tietyin väliajoin uusia teknologioita ja mahdollisuuksia toteuttaa koneiden välistä kommunikointia. Mikäli halutaan tehdä mahdollisimman pitkäikäisiä ratkaisuja, kannattaa alla olevan teknologian käyttö aina abstrahoida ja paketoida adapterien sisään. Käytännössä tämä tarkoittaa, että lisäämällä yhden abstraktiokerroksen käytettävän teknologian päälle pyritään siihen, että jos alla oleva teknologia muuttuu, niin riittää pelkkien adapterien muuttaminen eikä itse sovelluksiin tarvitse tehdä muutoksia. Ei tarvita suuriakaan ennustuslahjoja jos veikkaa, että Windows Communication Foudation on muuttunut seuraavan viiden vuoden päästä melkoisesti ja uusia versioita siitä julkaistaan sekä uusia kommunikointiteknologioita esitellään tämänkin jälkeen. Parhaiten näihin muutoksiin pystyy varautumaan kun toteuttaa oman abstraktiokerroksen käytettävän teknologian päälle.

Uskoisin, että muillakin on ollut mielessä käyttää Crystal Reportsia ja ja ADO.NET:in DataSettejä yhdessä. Yksi mahdollinen skenaario voisi olla, että koska Crystal ei suoraan pysty lukemaan tietoja  olioista, voidaan olioista tiedot tuoda automaattisesti DataSetteihin, joita vasten raportteja voidaan tehdä. Tällöin voitaisiin tehdä raportteja businesslogiikan päälle. Sen avulla päästäisiin eroon mm. tietokannan väliaikaisista tauluista, joihin laskettaisiin valmiiksi jotain dataa raportointia varten; laskenta voitaisiin tehdä sujuvasti businesslogiikassa.

 

Tähän kuitenkin liittyy yksi Crystalin ongelma: jos raportteja tehdään DataSettien päälle, niin touhuun tulee huomattava lisähitaus. Tämä johtuu siitä, että Crystal ei osaa käyttää hyväkseen määritelty linkkejä DataSetin taulujen välillä, vaan yrittää itse tehdä tarvittavat päätelmät. Tästä Crystal on kertonutkin jo tuotetukisivullaan version 10 myötä. Sama ongelma kuitenkin näyttää jatkuvan Crystal Reports XI Release 2:n kanssa. Hitaus on sen verran suurta, että sillä on paljon merkitystä sovellusten käytettävyyteen. Esim. jos neljässä datasetissä on yhteensä 6 taulua ja raportille niistä tulisi 16 000 riviä, niin tämän raportin avaaminen Crystalin Designerissä esikatselutilaan vie noin 15 minuuttia. Sovelluksessa avaamiseen menee noin tunti. Tämä on demottu myös silloin kun datasetit on talletettu XML-tiedostoiksi ja raportti tehty niitä vasten. Eli hitauden aiheuttajaksi osoittautuu yksiselitteisesti Crystal. Crystalin tuotetuki tietää asian ja kehottaa tekemään raportteja vain yhdestä DataSetin taulusta! ÄÄh…

 

Linkki http://technicalsupport.businessobjects.com/KanisaSupportSite/search.do;jsessionid=8E23963EEC00FF49B4ECD3DA7137A9ED?cmd=displayKC&docType=kc&externalId=c2017149&sliceId=&dialogID=3820139&stateId=1%200%203818327

System.Transactions tuo uuden ja helpon keinon käsitellä transaktioita koodissa. Koodi voi esimerkiksi sisältää vain using-lohkon, jossa transaktiota käsitellään. Vaikka koodi on helppoa, niin on huomattava, että toimintaan liittyy eroja sen mukaan, mikä tietokanta taustalla on. Mikäli käsitellään SQL Server 2000 tietokantaa, niin System.Transactions nojautuu MS DTC:hen (Distributed Transaction Coordinator), joka on keino hallita hajautettuja transaktioita Windows ympäristössä. Mikäli puolestaan käsitellään vain SQL Server 2005:ttä, niin tällöin DTC:tä ei käytetä, vaan taustalla hyödynnetään lightweight transaction:ia. Kuten termikin jo kertoo, niin kyseessä on kevyt (lightweight) toimenpide. Käytännössä tämä tarkoittaa mm. sitä, että käytettäessä DTC:tä tulee sovellukseen ”ylimääräinen” sekunnin tai jopa kahden hitaus. Tätä ei kuitenkaan tule lightweight transactiossa! Eli DTC tuo ylimääristä overheadia ja hitautta sovellukseen, koska se on luonteeltaan sellainen, että se pystyy käsittelemään hajautettuja transaktioita jopa eri tietokantojen välillä. Tämä ominaisuus ei kuitenkaan ole oikeasti tarpeen, jos käsitellään vain yhtä tietokantaa. SQL Server 2000 ei tunne lightweight transaction -teknologiaa, joten sen on hyödynnettävä DTC:tä. SQL Server 2005 puolestaan hallitsee myös lightweight transactionit, joten mikäli muita tietokantoja ei liity transaktioon, niin tällöin riittää lightweight transaction. Jos transaktio on alkanut lightweight transaktionina (SQL Server 2005:een) ja saman transaktion sisällä otetaan yhteys SQL Server 2000:een, niin System.Transactions osaa automaattisesti taustalla muuttaa transaktion hyödyntämään DTC:tä mikä tällöin tietysti tarvitaan.

 

Summa summarum: DTC soveltuu oikein käytettynä tiettyihin paikkoihin. Se kuitenkin tuo ylimääräistä hitautta sovellukseen.

 

Transaktioita voi tutkia COM+:n alta ”transaction statistics”:ssa. Debugin aikana transaktioita voi tutkia kooditasolla System.Transactions.Transaction.Current- oliosta. Ylläpidon ja uudelleenkäytettävyyden kannalta voi olla hyödyllistä ottaa transaktiot pois talletettujen proseduurien tasolta ja nostaa ne komponentti (BL) tasolle. Näin transaktion laajuutta (scope) voidaan kasvattaa jatkokehityksen aikana helposti. System.Transactions tarjoaa myös keinon tehdä omia transaktionaalisia luokkia ja ne voivat integroitua mm. DTC transaktioihin. (Esimerkiksi SQL haku + tulosten kirjoittaminen tiedostoksi voidaan tehdä yhden transaktion sisällä, jos toteutetaan transaktionaalinen tiedostonkäsittelyluokka.) Kooditasolla voidaan katsoa, onko transaktio hajautettu propertystä: DistributedIndentifierGuid.Empty

Ensinäkemältä kuulostaa, että .NET Frameworkista olisi tullut uusi versio. Näin ei oikeasti ole. Termi lienee tullut markkinointipuolelta, sillä se ei oikeasti sisällä uutta versiota .NET Frameworkista! Sen vuoksi uusi termi on harhaanjohtava ja huono. Se sisältää .NET Framework 2.0:n sekä kolme teknologiaa, jotka on aikaisemmin liitetty termin WinFX alle. Nämä ovat:

Windows Presentation Foundation (WPF)

Aikaisemmin tunnettu nimellä Avalon. Se tarkoittaa täysin uutta keinoa tuottaa Windows-käyttöliittymiä. Konsepti noudattaa hyvin pitkälle ASP.NET:stä tuttuja periaatteita, jossa käyttöliittymä ja siihen liittyvä logiikka on erotettu toisistaan. Tässä ei kuitenkaan käytetä HTML:ää käyttöliittymän kuvaamiseen vaan XAML-kieltä, joka on tietysti XML-muotoista. Käytännössä tällä pyritään siihen, että käyttöliittymäsuunnittelijat ja visuaalisesti lahjakkaammat voivat XAML-kielellä toteuttaa käyttöliittymän ulkoasun, jonka jälkeen ohjelmoija voi toteuttaa tarvittavan logiikan käyttöliittymän taakse esim. Visual Basic 2005:lla tai C#:lla. WPF tarjoaa erittäin kehittyneitä tapoja toteuttaa mitä monipuolisempia ominaisuuksia käyttöliittymiin. Se pystyy yhdistämään mediaa ja kehittyneitä datan esittämismuotoja (zoomaus, piirrosominaisuudet jne.). Ikävä kyllä tällä hetkellä työkalut, joilla XAML:ia kirjoitetaan ovat suhteellisen kehittymättömiä, joten en lähtisi aivan heti käyttämään sitä. Vasta kun työkalut ovat kehittyneet kunnollisiksi, kannattaa tuo ottaa käyttöön.

Windows Communication Foudation (WCF)

Tämä tunnettiin aikaisemmin nimellä Indigo. Se yhtenäistää keinot, joilla hajautettuja järjestelmiä on Windows-alustalla tehty. Nykyisin on lähinnä ohjelmoijien vastuulla päättää käytetäänkö hajautetuissa järjestelmissä Web Servicejä, .NET Remoting’ia vai DCOM:ia. WCF tarjoaa yhtenäisen ohjelmointirajapinnan riippumatta siitä mitä teknologiaa alla oikeastaan käteytään. Konfiguraatiota muuttamalla voidaan järjestelmä muuttaa toimimaan esimerkiksi DCOM:in kautta vaikka se alunperin olisi toiminutkin .NET Remoting’in läpi. Koodia ei siis tarvitse muuttaa vaikka alla oleva teknologia muutettaisiinkin. Toki WCF tarjoaa myös paljon muuta kuin pelkän wrapperin alla oleviin teknologioihin.

Windows Workflow Foundation (WF)

Tämä teknologia tarjoaa keinon tehdä workflow-tyyppisiä toiminnallisuuksia yhtenäisin keinoin Windows-sovelluksiin.

Tänä kesänä ei ole TechEd seminaaria Euroopassa, joten olen menossa VS Live! tapahtumaan Las Vegasiin. Olisikohan Suomesta muita lähtijöitä ko. suunnalle?? Sisällön puolesta esitykset näyttävät erittäin hyviltä ja esiintyjäkaartikin on vakuuttava.

Codezonelle on tullut taltioinnit kaikista pidetyistä esityksistä. Oma esitykseni löytyy osion 4 alta otsikolla Microsoft Solution Framework CMMI.

DevDays järjestetään 27.4 Tennispalatsissa.

 

Aiheina tietoturva, Web käyttöliittymät, Windows-ohjelmoinnin uutuudet sekä sovellusprojektien hallinta. Itse olen mukana pitämässä esitystä MSF for CMMI Process Improvement -mallista, joka on integroituna Team Systemiin ja tarjoaa mallin koko tuotekehitysprosessin organisoimiseksi ja hallinnaksi.

Kuulin, että ei löydy esimerkkejä siitä, miten käytetään attribuutteja siten, että tietty koodi suoritetaan ennen jonkin metodin (tai luokan) suoritusta automaattisesti sekä metodin suorituksen jälkeen. Tässä yksinkertainen esimerkki, josta näkee perusidean.