Ilmainen aamiaisseminaari 2.12.2009, aiheena CodeIgniter ja Drupal

Perttu Tolvanen

Exove esittelee aamiaisseminaarissaan kaksi erilaisiin tarpeisiin suunniteltua avoimeen lähdekoodiin pohjautuvaa ratkaisua web-palveluiden toteutukseen.

Tällä kertaa esittelyssä on esimerkiksi CodeIgniter –niminen PHP-sovelluskehys jonka keskeisiä kilpailijoita ovat esimerkiksi Zend ja Symfony. Nämä mainitut sovelluskehyksethän tulevat yhä useammin vastaan myös perinteisten julkaisujärjestelmien kilpailijoina, koska mahdollistavat sovellusmaisten toimintojen toteutuksen helpommin ja nopeammin kuin tiettyyn käyttötarkoitukseen suunnitellut julkaisujärjestelmät.

Vierityspalkki tiedusteli Exoven Janne Kalliolalta hieman lisätietoa CodeIgniteristä ja sen käyttötarkoituksista Exoven projekteissa. Kalliola kommentoi CodeIgniterin käyttöä seuraavasti:

“CodeIgniter on nopein Model-View-Controller -pohjainen PHP-framework, eli siinä on suorin tie sovelluskehyksen läpi omaan koodiin. Siinä on kuitenkin kaikki oleelliset sovelluskehykseltä tarvittavat toiminnot. Lisäksi se on hyvin dokumentoitu, helposti laajennettavissa ja aktiivisesti kehittyvä. Sen huonoin puoli on PHP-pohjainen template-systeemi, jonka olemme päätyneet korvaamaan Smartylla.“

Kalliola kertoi myös hieman siitä millainen oppimiskynnyksen on havaittu olevan ja millaisten toimistojen ehkä kannattaisi kiinnostua CodeIgniteristä:

“CodeIgniter on nopea oppia, päivässä tai parissa pääsee jo tekemään omaa koodia. Meillä on lisäksi ohjausta uusille henkilöille, joten he pääsevät alkuun muutamassa tunnissa. CodeIgniter on hyvä web-palvelujen teossa, esimerkiksi Jaiku on alunperin toteutettu hyvin samanlaisella järjestelmällä. Eli tällaisia palveluja tekevien yritysten kannattaa ehdottomasti katsastaa CodeIgniter. Julkaisujärjestelmää siinä ei ole, mutta se on helppo laittaa toimimaan vaikkapa WordPressin vieressä.”

Muita seminaarissa käsiteltäviä aiheita ovat esimerkiksi Drupal ja erityisesti Drupalin tarjoamat mahdollisuudet omaan sovelluskehitykseen. Lisäksi Petteri Koponen on seminaarissa kertomassa Jaikun kokemista web-palvelun toteutuksen haasteista ja onnistumisista.

Ilmoittaudu 2.12.2009 järjestettävään aamiaisseminaariin web-palveluiden toteutuksesta Exoven sivustolla.

  1. Kennu says:

    Viimeksi kun katselin, niin CodeIgniter tuntui olevan vanhanaikaista ja vähän epämääräistä PHP-ohjelmointitapaa suosiva frameworkki. Ilmeisesti siitä irtaantunut Kohana on modernimpi, PHP5:n oliomallia kunnolla hyödyntävä versio samasta ideasta. Minä katsastaisin Kohanan (ja syyt sen irtautumiseen yksittäisen kaupallisen toimijan kehittämästä CodeIgniterista) ennen lopullisen frameworkin valitsemista.

    Tosin nyttemmin Pythoniin ja Djangoon siirtyneenä tuntuu joka päivä vain iloiselta, ettei tarvitse enää juurikaan tehdä PHP:llä mitään. Kaikki onnistuu niin paljon helpommin ja vähemmällä vaivalla :-)

  2. Janne Kalliola says:

    Kohana (www.kohanaphp.com) on varsin mielenkiintoinen framework ja katsastimme senkin, tosin CodeIgniterin valinnan jälkeen. Silloin emme löytäneet erityistä syytä vaihtaa ja systeemi oli vielä osittain teon alla. Tilanne saattaa olla muuttunut.

    Omasta mielestäni Kohanan erityisenä vahvuutena on CodeIgniteria paremmin toteutettu jako systeemiin, kirjastoihin / moduuleihin ja varsinaisen sovelluksen luokkiin. Kohanaan pystyy siirtymään CodeIgniterista melko helposti — ainakin vielä — ja taisipa siellä olla ohjeet, kuinka CodeIgniter-pohjainen koodi muutetaan toimimaan Kohanalla. Tämä muuttuu tietysti hankalammaksi jokaisen uuden version yhteydessä, systeemien eriytyessä kauemmaksi toisistaan.

  3. Kakku says:

    Yksi pienten sovellusten tekoon sopiva vekotin on cakephp, jolla ei ehkä Suomessa ole vielä suurta suosiota, mutta toimii sekä omissa / virman projekteissa. Integrointimahdollisuudet wp:hen / muihin sovelluksiin ovat helppoja. Perus cms:ksi siitä ei ehkä ole, mutta työkalut sisällön päivittämiseen on helppo ”leipoa” (bake) kasaan.

    Kirjoittajalla ei ole CodeIgniterista kokemusta, mutta oma ratkaisu on aina paras riippumatta mihin ratkaisuun päätyy ja sehän pitää kertoa kaikille (mm. asiakkaat). Näkemykseni on että koodipojat valitsee ratkaisun ja perustelee sen myynnille ja johdolle. Sitten keksitään alustan termit: helppo integroitavuus, monikanavajulkaisu (ysäri kirosana), muokattavuus, asiakaslähtöisyys, hyvät laajennettavuusvaihtoehdot, hyvä tietoturva, …. keksi itse lisää.

    Mielestäni siis ”parasta” frameworkkia / alustaa ei ole olemassakaan – on vain sopiva tähän caseen tai sitten susi tähän caseen. Hyvin harvoin samaan alustaa siirtyminen tuo integrointietuja (kun on tehty yhdelle niin sen voi monistaa helposti). Ainoa etu on se että kaikki caset on tehty samalla tavalla ja kaikista löytyy samat palikat samasta paikasta – näin siis ohjelmointipellen näkökulmasta. Jos jotain monistetaan niin AINA siihen liittyy muutoksia / lisätöitä. Ja lisätöiden määrä on aina vakio sanon minä.

  4. Kennu says:

    Nopeus on kyllä erittäin validi kriteeri frameworkin valinnassa. Allekirjoittaneella on kokemusta Zend Frameworkista, joka on speksien perusteella oikein hieno ja siisti, mutta käytännössä osoittautunut melkoiseksi bloatiksi, joka kuluttaa hirveästi CPU:ta massiivisen luokkahierarkiansa instantioimiseen ja pyörittelyyn.

    Toinen tärkeä (ehkä tärkeämpi) kriteeri on käytetty ActiveRecord/ORM-malli. Oikea MVC-kehitys lähtee aina tietokanta-modelien määrittelystä. Zendillä tämäkin oli aika susi, ainakin verrattuna Django/RoR-maailmaan.

  5. Janne Kalliola says:

    Tuohon Kennun toisen kommentin toiseen kohtaan täytyy todeta, että joskus on hyvin virkistävää suunnitella sovellus toisinpäin — eli aloittaa rautalangoista ja näkymistä (views). Nämä kootaan nopeasti yhteen muutamalla controllerilla, jotta saadaan sovellus toimimaan selaimessa. Lopuksi kirjoitetaan tarvittavat modelit tietokantasuunnitelman pohjalta ja lisätään varsinainen toiminnallisuus controllereihin.

    Tässäkin tavassa (alustava) kantaskeema on hyvä olla olemassa jo aikaisessa vaiheessa, koska muuten rautalankoihin ja näkymiin päätyy hyvin vaikeasti toteutettavia ellei mahdottomia ratkaisuja.

    Suosittelen kokeilemaan tätäkin suunnittelutapaa, koska se tuottaa mielestäni käyttäjäkokemukseltaan ja -ystävällisyydeltään parempia sivustoja.