Minulta on viime aikoina kysytty useampaankin otteeseen ja olen asiaa itsekin pohtinyt, että millä toteutusteknologialla lähtisin toteuttamaan uutta laajempaa verkkopalvelua. Tai vastaavasti millä teknologialla lähtisin nyt toteuttamaan jo olemassa olevaa verkkopalvelua jos olisin sen kehityskaaren verran viisaampi.
Henkilökohtainen vastaukseni kallistuu varmasti johonkin niistä toteutusteknisistä ratkaisuista, joita olen kokeillut ja jotka ovat minulle tuttuja. Tähän joukkoon kuuluvat kielistä Python ja PHP ja CMS/vastaavista-järjestelmistä Django, Drupal ja Codeigniter. Lisäksi tietysti voidaan nähdä mahdollisuutena lähteä tyhjältä pöydältä ilman mitään tukijärjestelmää, joka kuitenkin nähdään nykyään melko alkukantaisena vaihtoehtona.
Ja sitten mikä ratkaisuvaihtoehto olisi paras. Tähän kuten useampaan muuhunkaan asiaan mielestäni ei tietenkään ole yksikäsitteistä vastausta vaan ratkaisu on täysin riippuvainen siitä kuka toteutusta on kehittämässä, minkälaista verkkopalvelua toteutetaan ja minkälaiset resurssit on käytettävissä. Lisäksi voidaan sanoa, että toteuttajien motivaatiolla ja sitoutumisella on merkitystä.
Etenkin Django mainostaa itseään kehitysympäristönä, jolla voidaan saada aikaan nopeita ratkaisuja. "Rapid web development" on käsite, jota pyöritellään hyvin usein puhuttaessa verkkopalveluista. Tämä käsite juontaa juurensa siitä, että verkkopalvelujen ikä on lyhentynyt huomattavasti. Erilaiset mainoskamppajat ja muut hetkelliset ilmiöt ovat johtaneet siihen, että verkkopalvelujen kehittäjiltä vaaditaan nopeaa tuotekehitystä ja valmiita ratkaisuja. Yksi tapa ratkaista tämä ongelma on erilaisten konseptien luominen mutta, koska jokainen verkkopalveluprojekti on yksilöllinen eivät konseptit useinkaan pure niihin kovinkaan tehokkaasti. Ratkaisuksi ovat siis nousseet erilaiset valmiin rungon tarjoavat palvelijat.
Django ja Drupal ovat kehikkoja, joiden ympärille on nopea rakentaa valmiin näköinen tuote. Django antaa ehkä enemmän vapauksia toteuttajalle kun taas Drupal tuottaa tyhjilläänkin jo jonkinlaisen verkkopalvelun. Tässä en ota sitten kantaa ollenkaan esimerkiksi Wordpressin ja Joomlan kaltaisiin tuotteisiin, jotka pyrkivät täysin web-käyttöliittymätasoiseen hallintaan, jossa koodarille ei jää juuri ollenkaan tarvetta. Eivätkä nämä järjestelmät myöskään tarjoa täysin rajatonta mahdollisuutta siihen minkätyyppinen verkkopalvelu niillä toteutetaan, ainakaan niin, että se olisi niillä järkevää toteuttaa.
Kehikkojen hyvä puoli on, että ne tarjoavat valmiit toteutukset verkkopalvelujen yleisimpiin toimintoihin kuten tietokannan ja käyttäjätilien hallintaan. Usein niistä löytyy myös suorat käyttöliittymätason toteutukset, joilla voidaan phpMyAdmin tyyppisesti toteuttaa yksinkertaista tietokannan hallintaa. Niiden avulla pystytään siis käynnistämään verkkopalvelun kehitysprojekti nopeasti ja saamaan aikaan asiakkaalle mielenkiintoisia tuloksia kun ei tarvitse ensin toteuttaa esimerkiksi sisäänkirjautumistoiminnallisuutta. Tätä pidetään hyvin usein perusteena sille miksi jokin kehikko otetaan käyttöön projektissa. "Let the developers focus on the real problems and issues".
Ei mitään, kehikot tuovat selkeästi etuja projekteihin. Niiden avulla pystytään ohittamaan monia sudenkuoppia ja paljon aikaa vieviä asioita, jotka jouduttaisiin ottamaan huomioon ilman niitä. Näen kuitenkin niiden käytössä myös ongelmia. On hienoa, että esimerkiksi Drupalissa voidaan esilaisia lohkoa liikuttaa tyylikkäästi JavaScriptin avulla paikasta toiseen suoraan www-selaimessa ja näin luoda lennossa asiakasta miellyttävä käyttöliittymä. Kuitenkin täytyy samaan aikaan myöntää, että käyttöliittymästä voidaan tehdä vain sellainen kuin mihin tämä kehikko pystyy. Kehittäjän valinnanvapaus rajoittuu juuri niin pitkälle kuin miten monipuolinen tämä käyttöliittymätason ominaisuus, jolla käyttöliittymää voidaan muokata on. Tietysti esimerkiksi Drupalissa käyttöliittymää voidaan muokata ohi käyttöliittymätoteutusten suoraan lähdekoodista, mutta onko tämä sitten tarkoituksen mukaista.
Kehikkojen negatiivinen puoli on myös riippuvuus niiden kehittäjistä. Esimerkiksi CakePHP oli noin pari vuotta sitten kuumaperuna kyseisellä saralla kun nyt sitä pidetään enemmänkin jälkeenjääneenä ja verkkopalveluja, jotka käyttävät sitä vanhentuneina. Tällä hetkellä Codeigniter on mahdollisesti vastaavassa asemassa, mutta ei ole sellaista lupausta olemassa, että se pitäisi asemansa tämänkaltaisena.
Statsterissa lähdekoodi on täysin kehikkovapaata. Toki erilaisia ulkopuolisia palikoita ja rajapintoja on hyödynnetty, mutta niissäkin toteutus on enintään oliotasoista. Kaikki lähdekoodi on siis suoraan muokattavissa ja kehittäjällä on täysi valta koodiin ja siihen miten muutokset koodissa vaikuttavat toteutukseen. Tämä aiheuttaa toki sen, että kaikki toteutus on tehtävä itse eikä valmiita apuelementtejä ole niiden ulkopuolelta mitä kehittäjä on itse tehnyt.
Eli summa summarum jos tästä sellaista voi vetää: Nopeissa projekteissa kehikot ovat ylipäänsä hyvä valinta. Sopivan kehikon valinta riippuu sitten siitä miten monimutkainen toteuttavan verkkopalvelun tietomalli on ja miten paljon verkkopalvelun odotetaan vaativan räätälöintiä kooditasolla. Jos räätälöintiä tarvitaan paljon tulisi kehikon olla mahdollisimman vähän valmista toteutusta omaava, jota tarvitsee lähteä muuttamaan ja päinvastoin. Intohimoisissa kotiprojekteissa, joissa aika ja resurssi on loputon on täysin omaan koodiin perustuva ratkaisukin mahdollinen, mutta mahdollisesti tässäkin tapauksessa kannattaa nykyään ottaa alle, jokin yksinkertainen PHP-framework, kuten Codeigniter, jonka avulla toteutuksen saa MVC-mallin mukaiseksi. Mielenkiinnon riittäessä myös oman MVC-mallin toteuttaminen on mahdollisesti hyvä lähtökohta.
0 comments
No comments yet.