Ajaxia ehdoin tahdoin

Tulipa syyllistyttyä koodaajan perisyntiin - tai ainakin minusta kyse on perisynnistä. Eli teknologiasta innostuneena väänsin väkisin toiminnallisuutta AJAX:illa. Ainoa motiivi oli päästä käyttämään AJAX:ia, ei suinkaan se, että kyseinen tekniikka olisi sopinut erityisen hyvin taikka että sitä olisi toiminnallisuuden toteuttamiseen tarvittu - valinta oli ihan puhtaasti teknologiapohjainen. En väitä, että toiminnallisuus olisi tuosta kärsinyt millään lailla. Toistaiseksi näyttää, että homma toimii kuten olin ajatellutkin. Eli jos menet mutteri.com:iin ja kokeilet yllänavigaatiossa esim "etsi" -toimintoa. Klikkaamalla valikossa kyseistä näppäintä, koko sivu ei lataannukaan, vaan navigaation alla olevaan segmenttiin ladataan AJAX:illa tuo hakulomake. Samalla tavalla toimii myös palautelomake, sekä sisäänkirjautumislomake. Huomattavaa on, että jouduin tekemään pientä lisäsäätöä, koska mielestäni kaikki sivut eivät toimi järkevästi jos nuo lomakkeet ladataan AJAX:illa ilman, että koko sivua ladataan. Esimerkiksi reksteröitymissivu ei mielestäni toimisi järkevästi mikäli sallisin ladata vain tuon sivun yläosan uudestaan ja jättäisin itse rekisteröitymislomakkeen ennalleen. Mielestäni sivun vaikutelma olisi vähintäänkin erikoinen: yläosassa olisi esimerkiksi hakulomake ja sivun varsinaisessa sisältöosassa olisikin rekisteröitymislomake. Itselleni ei ainakaan olisi täysin selvää mitä tapahtuu kun klikkaan hae tai vastaavasti rekisteröidy. Eli ratkaisu logiikkaongelmaan on se, että nuo muutamat lomakkeet toimivat AJAX pohjaisesti riippuen siitä millä sivulla käyttäjä on. Vain osa palvelun sivuista on rakenteeltaan sellaisia, että ne "tukevat" tätä AJAX toteutusta, ja osa sivuista ei tue sitä. Niiltä sivuilta jotka eivät mielestäni AJAX -lähestymistä tue, ladataan koko sisäänkirjautumissivu (tai haku tai palaute).

Opetus 13: suunnittele, toteuta ja VALIDOI

Jokaisen sivuston rakentaminen pitäisi aloittaa suunnittelusta. Suunnittele etukäteen sivuston konsepti. Konseptilla tässä tarkoitan sivuston tarkoitusta, runkoa, toiminnallisuuksia ja keskinäistä yhdessätoimimista. Mieti mitä käyttäjät haluavat sivuillasi tehdä ja mieti miten voit tehdä sen käyttäjille helpoksi ja hauskaksi.

Hyvän suunnitelman, joka toivottavasti sisältää jopa sivuston ulkoasun hahmotelman, jälkeen on toteuttaminen helpompaa. Kun kaikkien sivujen toiminnallisuus on suunniteltu etukäteen, on toiminnallisuuden rakentaminen helppoa ja nopeaa. Toteutuksessa on hyvä noudattaa standardeja. Ei siis mitään selainkohtaisia laajennoksia tms. Näin takaat, että sivusi toimivat mahdollisimman laajalle käyttäjäjoukolle.

Ja kun kaikki on toteutettu, ei järjestelmä suinkaan ole valmis. Sen jälkeen alkaa testaaminen ja validointi. Vaikka olet pyrkinyt noudattamaan erilaisia standardeja, tulee kirjoittaessa usein tehtyä virheitä. Kukaan tuskin muistaa kaikkia HTML tai CSS kielten sääntöjä. Validointiin on onneksi oleamassa mitä mainioimmat työkalut:

• The W3C Markup Validation Service, jonka avulla voit varmistaa, että kirjoittamasi HTML koodi on standardin mukaista ja virheetöntä. Virheetön koodi edesauttaa sivuston nopeutta, käyttökokemusta, hakukoneiden toimintaa, jne.
• The W3C CSS Validation Service, on ylläolevan kaltainen validointipalvelu, mutta se varmistaa, että käyttämäsi CSS noudattaa standardia eikä sisällä virheitä. Virheetön CSS on kutakuinkin yhtä tärkeää kuin virheetön HTML.
• Valitettavasti se ei riitä, että sivustosi noudattaa kaikkien käyttämiesi tekniikoiden standardia, sen lisäksi sinun kannattaa varmistaa, että sivustosi todella toimivat kuten olet ajatellut eri selaimilla. Näistä suurimmat ongelmat luultavasti tulee vastaan Microsoftin Internet Explorer versioilla 5.0 - 7.0. Tähänkin on onneksi työkaluja, jotka tulevat tarpeeseen meille, jotka tekevät töitä Linux tai Mac ympäristöissä.
  
• browsershots.org tarjoaa mahdollisuuden testata käytännössä katsoen kaikilla käyttöjärjestelmä-selain yhdistelmillä. Browsershotsin ongelma on sen hitaus, se tuottaa kuvakaappauksia valitsemillasi selaimilla, mutta omien testien mukaan se antaa vain noin 2-4 kaappausta / tunti. Se ei oikein riitä debuggaamiseen.
• ipinfo netrenderer puolestaan tarjoaa mahdollisuuden testata Microsoftin IE 6 ja IE 7 selaimilla. Näillä kahdella testaaminen onneksi varmistaa sivustosi toimimisen yli 50% käyttäjistä. 40% käyttäjistä käyttää Firefoxia, ja loput 10% satunnaisia selaimia.

Mikäli törmäät jossain vastaaviin validointipalveluihin, pistä tänne ihmeessä linkkejä. Toivottavasti näistä parista työkalusta on apua; ei muuta kuin koodaamaan ja testaaamaan!

Pientä pintaremonttia

Muutama viikko sitten sain palautteena ideoita miten mutteri.com:ia voisi parantaa. Noista ideoista taas hieman motivoituneena tein saitille muutamia pienimuotoisia uudistuksia. AJAX:iin en vieläkään ole koskenut tämän saitin puitteissa. Ja syy on surkea - vaikka olen jotain pientä AJAX:ia käyttäen tehnytkin, ei se ole ihan vielä uponnut. Javascript on mielestäni perseestä, lähinnä siksi, että en sitä itse juurikaan osaa. Mutta vaikka AJAX antaa vielä odottaa, tuli tehtyä kuitenkin muutamia pikkutemppuja, jotka tuovat mutteri.comin ehkä vähän lähemmäs tämän päivän layoutteja. Olen tainnut jossain kommentoida itsekin, että saitti on tyyliltään ja toiminnallisuudeltaan lähempänä vuotta 1999 kuin vuotta 2007.

Tein pari perusjuttua nyt kuntoon:

1. tagipilvi etusivulle: tavoitteena tuoda suositut kategoriat helposti ja nopeasti saataville.
   
2. suuret pikanäppäimet niille toiminnoille, joiden toivon olevan käyttäjille tärkeitä ja paljon käytettyjä. Pikanäppäimenä on tuo "kutsu ystävä":kin jonka olen haukkunut täysin turhaksi ominaisuudeksi. Eikä sen suosio tunnu kasvavan, vaikka nappi on nyt paraatipaikalla.
3. Joutavat tekstit (esittelyt ja muut) vein etusivun loppuun. Hakukone ne sieltä löytää... ja käyttäjäkin jos jaksaa rullailla sivua alaspäin.
   

Tavoitteena näillä tempuilla oli tosiaan lisätä tilan tuntua saitilla - lisää valkoista = lisää ilmavuutta. Toinen tavoite oli tuoda keskeinen tieto keskeiselle paikalle, mistä käyttäjän silmä sitä todennäköisimmin hakee.

Muitakin muutoksia / lisäyksiä on mielessä, mutta vapaa-aika tuntuu olevan kortilla. Varsinaisia toiminnallisuuksiahan nyt ei systeemiin lisätty, jos tagipilveä ei voida pitää toiminnallisuutena.

Tattista Artulle vinkeistä. Lisävihjeitä otetaan kiitollisena vastaan.

Websafe colors

Mielenkiintoinen "tutkimuksenala" on tuo oikeiden värien valinta web sivuille. Väreillä on tunnetusti voimakas vaikutus ihmiseen. Punainen varoittaa, sininen on kylmää, oranssi lämmintä ja niin edelleen. Osa väreistä sointuu luonnollisesti toistensa seuraan ja toiset aiheuttavat suuria ristiriitoja. Ja tietenkin on väriyhdistelmiä joiden käyttö tekee järjestelmästä käyttökelvottoman - tästä esimerkkinä vaikka sininen teksti mustalla taustalla.

Web 2.0 toi mukanaan uuden ilmeen internet sivustoille. Yksi tärkeä ulkoinen elementti on ollut sivustojen muotokieli. Tyypillinen web 2.0 sivusto sisältää pyöreitä muotoja, heijastusefektejä, paljon tyhjää tilaa ja pastellisävyjä. Väreihin liittyy myös niiden toistamiseen liittyvä problematiikka: osa väreistä toistuu aina samanlaisina, riippumatta näytöstä, selaimesta, jne. Suuri osa väriestä toistuu hieman erilaisina käytettävästä selainympäristöstä riippuen. Näitä turvallisia värejä kutsutaankin nimellä websafe colors. Perehdypä ihmeessä aiheeseen - samoin kuin noihin web 2.0 väreihin.

Utelias saattaa kysyä miksi mutteri.com:in väritys on mitä on. Siihen on erinomaisen yksinkertainen selitys: allekirjoittanut itse on värisokea, joten pyrin pitäytymään mahdollisimman tutuissa väreissä, tai värien puutteessa. Valkoinen, harmaa ja musta tuntuvat minulle turvallisilta, vaikka valitettavasti antavat usein käyttäjälle tylsän vaikutelman itse palvelusta. Tavoitteeni on uusia jossain vaiheessa mutteri.com:in väri-ilmettä ja tuolloin tulen varmaankin käyttämään jotain valmista väriskaalaa minkä webistä löydän.

Ei liikennevalo koodattuja toiminnallisuuksia, eikä punaisella korostettua tekstiä - Kiitos!

Värisokeana muuten voin antaa pari vinkkiä kaikille suunnittelijoille: perinteiset liikennevalo indikaattorit ovat "hanurista" - värisokea ei välttämättä tiedä onko nappi punainen, vihreä vai keltainen. Myös punaisen värin käyttäminen tärkeiden kohtien korostamiseen tekstissä on HUONO valinta. Punainen väri ei valitettavasti hyppää värisokean silmään mustan joukosta yhtään samalla tavalla kuin "normaalin" ihminen sen kokee.

Sivun ulkoasun suunnittelu

Sivun ulkoasun suunnittelu on luonnollisesti yksi sivuston luomisen mielenkiintoisimmista vaiheista. Asettelu on teknisesti yksinkertaista (wysiwyg, html, jne) koska html kuvauskielenä helpohkosti opittavissa. Ulkoasu on yksinkertaisuudestaan huolimatta yksi tärkeimmistä tekijöistä millä sinä voit erottua muista sivustoista. Uskaltaisin melkein väittää, että sivuston ulkoasu on heti toiseksi tärkein seikka millä voit vakuuttaa käyttäjäsi palvelusi tuomasta lisäarvosta. Kaikkein tärkein on laadukas ja originaali sisältö. Jacob Nielsen [yksi web käytettävyyden pioneereista] on usein sanonutkin "Content rules" eli sisältö hallitsee.

Kun opettelet HTMLn saloja, tutustut CSS:ään, huomaat pian, että sivuston ulkoasun suunnittelussa vain taivas on rajana. HTML sallii sinun taittaa sivusi villeimpien haaveidesi ja visioidesi mukaisesti. Tätä nykyä on mahdollista sijoittaa sivulle melkein mitä tahansa mediaa (kuvia, musiikkia, videoita, sovelluksia [kutenMarcromedian flash]). Mutta varoituksen sana:

Se että jotain voi tehdä, ei tarkoita että sitä pitää tehdä, tai että sitä edes kannattaa tehdä.

Sivustoa suunnitellessa kannattaa tutustua käytettävyyteen ja tiettyihin internetin lainalaisuuksiin. Käytettävyydestä löytyy varmasti paljon materiaalia googlaamalla, mutta jos mitään muuta et jaksa / halua lukea, niin käy katsomassa Jacob Nielsenin ajatuksia useit.com:issa.

Jacob on käytettävyyden pioneeri ja hänen kirjoituksensa jopa 90 -luvun alusta ovat yllättäen yhä pääosin ajankohtaisia ja valideja.

Kehittelen siis www.mutteri.com:ia Linuxissa pyörivässä kehitysympäristössä. Laitteistoni ei ole viimeistä huutoa, joten käytän normaalisti resoluutiota 1280x1024. Mielestäni tämä on verrattain matala resoluutio, joten oletin että suurin osa käyttää ainakin tätä resoluutiota, ellei peräti 1600x1280. Olen kehittämisessä noudattanut Nielsenin oppeja mm. siinä, että sivuston taulukot on tehty skaalautiviksi (ei siis kiinteän levyisiksi, vaan leveydet on määritelty suhdelukuna selaimen leveyteen). Tällä saavutetaan normaalisti hyvä yleiskäytettävyys erilaisilla resoluutioilla. Mutta se mitä en kehittäessäni ottanut huomioon on, että googlen mainosten aseettelu vaikuttaa merkittävästi siihen miten sivustoa voi skaalata. Koska en tietenkään näytä kehitysympäristössäni googlen mainoksia (itselleni), en nähnyt tuota vaikutusta ennenkuin sain aiheesta palautetta loppukäyttäjiltä. Sain kuulla, että sivu ei mahdu kokonaisuudessaan näytölle jos käyttäjällä on resoluutio 1024x768 (tai alhaisempi). Ensimmäinen ajatukseni oli: "no kyse on marginaaliryhmästä". Mutta varmistin asian käyttötilastoista, jotka kertoivatkin karua kieltä: 50% käyttäjistä käyttää 1024x768 resoluutiot.

Älä siis oleta, että tavallisten käyttäjien laitteisto vastaa omaa laitteistoasi.

Itse asiassa, suunnittele sivustosi kaikkein heikoimmalle kokoonpanolle - siten palvelet niin vanhoilla laitteilla selaavia kuin uusimpien laitteiden käyttäjiä.

Opetus 9: Kerralla tuskin tulee valmista

Ainakin minulle tämä oli itsestäänselvyys, mutta se kuinka monta kertaa olen käynyt ja kahlannut koodin läpi on ollut taas yllätys. Mikäli päätät ohjelmoida samassa moodissa mitä minä olen tehnyt, kannattaa varautua siihen, että kirjoitat saman koodin monta kertaa.

Valmistaudu koodaamaan samat toiminnallisuudet useampaan kertaan.

Välillä on koodia siirretty pääohjelmasta funktiohin, ja sitten taas takaisin. Tämän voi mahdollisesti välttääkin, mutta väitän, että se onnistuu vain joko

• Huolellisella ja perinpohjaisella suunnittelulla


• Pitkällä kokemuksella


• tai näiden yhdistelmällä

Uudelleen koodaamisessa ei ole mitään vikaa - joka iteraatiolla koodin laatu luultavasti paranee ja luotettavuus kasvaa. Mutta tähän kuluu aikaa yllättävän paljon. Aina kun koodiin kosketaan, kannattaa se testata jollain tasolla. Jos et testaa, voi tulla odottamattomia yllätyksiä.

Kuinka ollakkaan, olin edellisellä kerralla koodia siivotessani onnistunut rikkomaan kuvan lisäys ominaisuuden.

Itselle kävi mm. siten, että ihmettelin miksei rekisteröityneet käyttäjät lisänneet kuvia. (no ihmettelen sitä välillä vieläkin, mutta se on hieman off-topic). Jonkin aikaa ihmeteltyäni, päätin varmistaa, että toiminnallisuus yhä toimii. Kuinka ollakkaan, olin edellisellä kerralla koodia "siivotessani" onnistunut rikkomaan kuvan lisäys ominaisuuden. Ei ihme, ettei kuvia tullut.

Opetus on siis se, että varaudu siihen, että samaa ohjelmakoodia pitää kirjoittaa useampaan kertaan.

Opetus 7: Panosta käytettävyyteen

Jos luomasi palvelu on haastajana markkinalla missä on jo vakiintuneita toimijoita, on sinun löydettävä kilpailu etua pienimmistäkin asioista. Sinun pitää pystyä onnistua houkuttelemaan käyttäjät pois jo olemassa olevasta järjestelmästä - ja käyttämään sinun sovellustasi. Tämä tuskin onnistuu, jos sinun järjestelmääsi ei ole kehitetty käyttäjille.

Koko Web 2.0 buumi on tuonut (mielestäni) verkkopalveluiden fokukseen käytettävyyden.

Palvelun pitää olla helppokäyttöinen. Se että sinä olet valmis käymään läpi viisisivuisen rekisteröitymisprosessin, ei tarkoita sitä, että keskiverto käyttäjä olisi siihen valmis.

Käyttötilastot ovat erinomaisen tärkeä tiedonlähde palvelun parantamiseksi. www.mutteri.com tapauksessa olin ajatellut, että käyttäjä kulkisi seuraavanlaisen polun:

1. Klikkaa "Rekisteröidy" -linkkiä


2. Käyttäjät täyttää henkilötietonsa (joista vain osa oli pakollisia).


3. Käyttäjä viedään rekisteröinnin vahvistamissivulle


4. Käyttäjä kirjautuu järjestelmään sisään


5. Käyttäjä klikkkaa "Luo ilmoitus" -linkkiä

Mielestäni tuo flow oli selkeä, intuitiivinen ja pomminvarma. Mutta kun seurasin käyttötilastoja ja käyttökaavoja (tietolähteinä Google analytics, tietokanta, palvelimen logit) huomasin, turhan usein kävikin näin:

1. Käyttäjä rekisteröityi palveluun


2. Käyttäjä loi ilmoituksen

Melkein sama mitä minä olin ajatellut, paitsi että käyttäjät eivät kirjautuneet sisään rekisteröitymisen jälkeen. Muuten ihan hyvä, mutta koska he eivät olleet kirjautuneina sisään, jäivät he paitsi niistä lisäominaisuukista miksi he ylipäätään halusivat rekisteröityä (muokata ilmoituksia, lisätä kuva, poistaa ilmoitus, etc).

Mielestäni asialle piti tehdä jotain. Siispä mietin tulisesti missä vika on... minussa, palvelussa vai käyttäjissä. Enismmäisen karsin syyllisten listalta käyttäjät - palvelussa oli jotain vikaa. Havaitsin pari asiaa, kun tutkailin palvelua (muutaman kuukauden tauon jälkeen) tuoreilla silmillä.

1. Sisäänkirjautuminen oli mahdollista jokaiselta sivulta. Sivun oikeassa yläkulmassa oli kaksi kenttää ja "sisään" nappi. Kentillä ei ollut nimikettä (label), vaan olin toteuttanut tuon nimikkeen itse kenttään siten, että käyttäjätunnus kentässä luki oletusarvoinen sähköpostiosoite ja salasanakentässä luki "salasana" joka siis näkyi tähtimerkkeinä. Minulle tuo oli erittäin looginen juttu, mutta luulen, että käyttäjät sekoittivat tuon jonkinlaiseen "tilaa uutiskirje" toiminnallisuuteen (www.mutteri.com käyttäjätunnus on käyttäjän sähköpostiosoite).


2. Sisäänkirjautumis -lomakkeella ei ollut otsikkoa. En siis missään indikoinut, että näillä kentillä kirjaudutaan palveluun sisään. En kertonut missään mitä näillä kentillä tehdään.


3. Miksi palveluun pitää kirjautua erikseen sisään rekisteröitymisen jälkeen? Käyttäjähän on jo kertonut kertaalleen kaiken mitä sisäänkirjautumiseen tarvitaan. Muutin siis logiikkaa siten, että rekisteröitymisen yhteydessä ensin tallennetaan käyttäjän tiedot käyttäjätietokantaan - ja sen jälkeen heti perään kirjataan käyttäjä sisään käyttäen rekisteröintitietoja. Jos käyttäjä nyt heti rekisteröitymisen jälkeen luo ilmoituksen, luodaan se käyttäjän nimiin, ja hän pystyy hyödyntää rekisteröityneen käyttäjän lisäpalveluita.

Tyyliseikat ratkaisevat

Kehitys siis tapahtui Linux ympräistössä. Samoin tietenkin testaus. Testasin kaikilla käytössä olevilla selaimilla vähäsen. Ja mutteri.com näytti suunnilleen samalta kaikilla selaimilla. Tässä kohtaa tein yhden virheen - oletin [vaikka tiesin toisin], että Internet Explorer toimisi suunnilleen samalla tavalla. Koska minulla ei kotona ole Windows pohjaisia tietokoneita, pääsin testaamaan IE:llä vasta töissä, ja sekin tapahtui sattumalta.

Sillä hetkellä veret seisahtuivat. Palvelu näytti verrattain kamalalta (ja täysin erilaiselta) kun käyttelin IE:tä.

Muista testata valtaselaimilla. Vaikka IE 5 ja 6 ovat susihuonoja, on niiden osuus selainmarkkinoista maailmanlaajuisesti vielä ylivoimainen. Suomessakin IE pitää hallussaan noin 50% selainmarkkinoista.

Tämän hirveyden huomattuani oli aika ruvet siivoamaan tyylejä koodista. En koskaan (ennen tätä) ollut perehtynyt CSS:ään (cascading style sheets), mutta nyt oli senkin aika. Eli aloin siirtämään layoutteja pois ohjelma koodista. Tämä periaate on vanha ja tuttu (sovelluslogiikka ja User Interface pitää olla erillään), mutta se ei ollut minulle tärkeätä ennen tätä.

Design haasteita horisontissa

Kuten ideointivaiheessa tuli esille, minä en ole graafinen suunnittelija. Itse kukin haluaisi olla visuaalisesti erinomaisen taitava - moni saattaa jopa luulla olevansa. Tässä suhteessa olen ollut suhteellisen realistinen ja tunnistin sekä tunnustin omat rajoitukseni.

Yksi minulle suuria ongelmia aiheuttava alue on värimaailma. Minulla ongelma on suurempi kuin monilla muilla, sillä olen värisokea. Punaiset, vihreät, ruskeat ja oranssit menevät turhan helposti sekaisin. Koska minulla on ollut tällä saralla hieman haasteita, en ole siihen juurikaan perehtynyt edes niissä puitteissa mihin minulla olisi ollut mahdollisuuksia. Siispä en rehellisesti sanottuna osaa sanoa mitkä värit sopivat yhteen ja mitkä eivät.

Tikkurilan värilastuilla saitille toimiva väritys.

Mutta kun into on kovaa, niin hätä kyllä keinot keksii (vai mitenkäs se nyt menikään). Minä keksin Tikkurilan värilastut. Tikkurilalla on asiantuntijoita jotka kuluttavat aikaansa pohtimalla trendivärejä ja väriyhdistelmiä - miksi siis yrittää keksiä pyörää uudestaan. Hain Tikkurilan web-sivuilta värikartan ja siitä valitsin www.mutteri.com:in värimaailman.

Tuumasta toimeen

Nyt oli asiaa märehditty riittävästi. Suunnitelmat www.mutteri.com:ista olivat suunnilleen valmiit ja kaikki kritiikki oli sujuvasti unohdettu tai painettu villaisella. Päätös palvelun perustamisesta oli valmis. Sitten ei muuta kuin kehitysympäristö pystyyn Linux:iin, muutama rivi html:ää, php:ta ja tietokanta pystyyn. Eihän siinä sen kummempaa. Kaksi viikkoa (iltaisin) ja homma valmis... Tai sitten ei.

Arvioin kehittämisen vaatiman ajan todella pahasti väärin. Pyrin koodaamaan jonkinlaisessaa sovelletussa XP eli extreme programming moodissa, missä aina tehtiin yksi toiminnallisuus valmiiksi, niin sitä pientä tekemistä vain riitti ja riitti ja riitti (ja riittää yhä). Jossain kohtaa kirjoittelen lisää kehitysmetodeista(ni) ja kaikesta mitä siinä olen oppinut.

Tässä kohtaa elettiin muistaakseni kesä-heinäkuuta 2006.

Kehitysympäristö
Kehitysympäristönä käytän Linux Fedora Core versiota 6. Apachesta taitaa olla versio 2.x, phpsta 5.x ja taitaa MYSQL:kin olla viitos versiota.
Työkaluina käytän:
- tekstieditori (jep, kaikki on käsin koodattu) Quanta+ [aivan loistava editori KDE ympäristössä]
- selaimena Firefox, Moxilla, Konqueror ja Opera. Koska teen kehitystä Linux:illa, saattaa tulos IE:llä olla sillointällöin ei niin kaunista. Mutta pyrin tarkistamaan sillointällöin jollain windows koneella miltä näyttää - ja korjata kun ongelmia löyty.
- FTP sovelluksena ja tiedostonhallintaan soveltuu erinomaisesti tuo Konqueror (siinä on myös selain samassa mikä on välillä ihan kätevä ominaisuus).
- versionhallinta: ei mitään koska teen järjestelmää yksin, ja jokaisen session jälkeen käteen jää toimiva / julkaisukelpoinen järjestelmä.
- backupit: ei oikeastaan mitään - jokaisen session jälkeen koodi heitetään tuotantojärjestelmään joten siellä on backup, jos kotikone hajoaa.