Automatic per-tab session isolation with Firefox

This is a guide to make automatic isolation a part of your web browsing.Instead of pulling out my tinfoil hat and going into too much detail on the why, I'll try to keep this as a step-by-step guide with some tips.

Step 1: Firefox

If you're already using Firefox as your main browser, you're good to go.If not, then get Firefox. It's good for the web as is. Seriously.If you're using Firefox and you really don't want to mess with your current set up, you can also go to about:profiles, click on "Create a New Profile", follow the instructions and then click on "Launch profile in new browser". You can easily delete the profile later if you no longer need it.

Bonus tips to make your life better

Get uBlock Origin. It's a lightweight ad blocker and more, "for users by users". Usually just works but some sites do require you to disable it via the red shield icon in your toolbar.Enable dark theme via the hamburger menu (top right) > Customize... > Themes (bottom) > Dark. I heard dark themes are a thing right now.From the customization view you can also change the UI density and remove things from the toolbar, such as empty space and the home button, by dragging them.

Step 2: Temporary Containers

There's a good explanation on what containers are in the description of the official Multi-Account Containers add-on. You can go install it, although it will only add a single button for managing permanent containers. The core functionality is already built into Firefox even without the add-on. You can also read the knowledge base article on Containers for a more thorough explanation.Once you've got an idea of what containers are in Firefox, go get the Temporary Containers add-on, which enables automating the creation and removal of containers.Temporary containers are containers that act a bit like the regular private mode in browsers, with the exception that history is retained and you can have as many of them open simultaneously as you want.Multiple tabs can belong to the same temporary container, but when you close the last tab of a temporary container, the container will be deleted, with a configurable delay to allow for re-opening the tab.The way the Temporary Containers add-on works by default is that you can manually open a temporary container tab either with the default keybinding (Alt + C) or with the Temporary Container button, which is the alarm clock icon with a plus sign in it.If you don't open one, everything works just as normal.

Step 3: Automation

The manual way takes conscious effort though, and the point here is to automate container tabs so that your sessions and other cookies are isolated by default. Temporary Containers has an option for exactly that.Go to Add-ons from the hamburger menu, or about:addons, and select Extensions if not already selected. From there, open the Options for Temporary Containers.The first option is "Automatic Mode", which on hover will show a description of it's operation. Enable that. The rest of the options on this page are a matter of taste. Feel free to fiddle with them.Next, go to Isolation > Global > Mouse Clicks on Links... and set Middle Mouse and Ctrl/Cmd+Left Mouse to "Always". Leave Left Mouse on "Never". In practice this means that whenever you consciously open a new tab, even if it's via a link, it will be in a blank session.Note that redirect links with tracking codes (Google, Facebook, Twitter) can still follow you into the new session, but let's not go into that here.Optionally you can also enable local statistics on the last options page, if you're into that.

Step 4: Permanent containers

Using temporary containers means you're never signed in to any website by default, so you'll most likely want to add at least one permanent container.As said earlier, containers are a built-in feature of Firefox now, so you can find more information on them from the browser's documentation, but I'll show you the basics.To manage containers, I recommend you hold down the new tab button, which is the plus sign after the last tab, and select "Manage Containers".By default, Firefox will give you a few example containers, but you can remove these and add your own, or edit them to suit your use cases.You can give permanent containers an icon and a color to distinguish them from each other and from temporary container tabs.I like to have a separate container for each web service I use a lot, but the default containers may very well work for you.If you use one service, for example Google, to sign in to other services, then you may want to keep some or all of those services within a single container, depending on the trade-offs you're willing to make.You can also have specific websites always open in a permanent container. To do this, you need to have the official Multi-Account Containers add-on from step 2 installed. Navigate to the website using the permanent container of your choice and click on the button added by Multi-Account Containers, then select "Always open in <container name>".

Step 5: Habits

If you've done the previous steps, then at this point your muscle memory and the path of least resistance will always lead to a blank, isolated session. You'll have to take conscious effort to break out of this isolation.You may develop your own habits, but these are some habits I've noticed after using this set up for almost a year now.

• If you know you want to be signed in on your next navigation, hold down the new tab button and select a container in which you're already signed in to the service you want.
• If you realize you navigated to a page that you wanted to navigate to as a signed in user instead of an anonymous user, you can right click the tab and select "Reopen in Container".
• If you want to open a link in a specific container, right click it and select "Open Link in New Container Tab".
• You can also do those with the left mouse button, if you already have one tab open that belongs to the container you want:To reopen the current page, start dragging from the left of the address bar where there's a circled "i" and hover over your target container tab until it becomes active, then drop in between tabs next to it.To open a link, start dragging the link and drop it the same way. Dropping between tabs will always cause the new tab to open in the same container as the currently active tab.
• If you want to open a new tab in your current container, you can right click the tab and select "Duplicate Tab". You can also do this by holding Ctrl (Alt on OSX) and dragging the tab.
• If all else fails, you can open a new tab in the container you want, and copy the web address you want to navigate to into that tab.
• Get into the mindset that opening a link in the same tab will open the link in the same session, while opening the link in a new tab will open it in a new clean session. Same goes for typing a new address on the address bar.

---

For web developers, it's often required to test a website as multiple different users as well as not logged in. This is now as easy as opening a couple of tabs and logging in with respective test users.

---

One thing you'll also quickly notice, especially if you live in the EU, is that the web sucks for first-time visitors, which you now are every time you open a new tab.The best solution is to make the web not suck. You would do a favor for everyone.If you can't do that, then as the next best option I'd suggest you take a look at the Behind The Overlay Revival add-on. It will hide nearly any overlay with a hotkey.If you visit a site often and get tired of hitting the hotkey, then assuming you followed my tips in the first step, you can also right click on what you want to hide and select "Block element". This is a feature of uBlock Origin and will hide the element more permanently. For documentation see the uBlock Wiki.As a disclaimer I'll have to say that I have no idea if hiding in-page popups is a good idea in a legal context, but I'll leave that research and decision to you.If none of these methods work, then I suggest you never visit that website again. Actually you may consider that as the first solution to try.

---

If you find this set up not suitable for you after all, then I hope you at least learned something about containers along the way.In that case I recommend you trace back your steps one at a time, and first reset the advanced isolation settings. If that's not enough, then turn off automatic mode on Temporary Containers and try using them manually.But if, instead, you start feeling like this should be the way browsers work by default, then you're doing it right!Keep it up. 

GitLab ja infrakustannukset

Yrityksemme on ollut olemassa jo yli 8 vuotta, tänä aikana kaikki ohjelmistokehityksen ja projektinhallinnan työkalut ovat kehittyneet huimasti. Varsinkin alussa vertailimme ja etsimme parhaita (sopivimpia) työkaluja juuri meidän toimintatapaamme pitäen mielessä kasvun myötä tulevat muuttuvat vaatimukset. Kaiken pitäisi kuitenkin sujua mahdollisimman ketterästi ja toisaalta työkalujen on koko ajan pitänyt mahdollistaa läpinäkyvyys asiakkaalle asti.

Olemme - kuten moni muukin ohjelmistotalo - rakentaneet tärkeimpiä järjestelmiä itse ja investoineet näihin tuhansia ja taas tuhansia tunteja työaikaa. Päädyimme rakentamaan tärkeimmän osan työkalupakistamme itse koska toisistaan irrallisia työkaluja löytyi, mutta selkeää kokonaisuutta niistä oli vaikea rakentaa, eikä yksikään niistä sopinut, tai riittänyt, sellaisenaan.

Tärkein työkaluistamme on Seepra -niminen toiminnanohjaustyökalu, jossa hallitaan projekteja, asiakkaita sekä kirjataan tunnit - aina työtehtäväkohtaisesti ja siten, että ylimääräistä aikaa ei kulu eri järjestelmien käyttöön.

Toiseksi tärkein työkalu meidän toimintamme kannalta on nykyään ehdottomasti GitLab, joka yhdistää ihanasti versiohallinnan, tehtävähallinnan sekä projektinhallinnan ja CI:n (Continuous integration). Käytimme pitkään sisäisesti Mercurialia versionhallintaan ja rakensimme sen ympärille omat työkalut. Meillä oli periaattessa kaikki Gitlabin tuomat ominaisuudet rakennettuna Mercurialin ympärille. Mutta ylläpitokustannukset vain kasvoivat vuosi vuodelta. Siirtymään Mercurialista Git:iin suurin syy olikin se, että Git:n päälle rakennettu työkaluvalikoima on moninkertaisesti kattavampi ja niiden ympärillä on aktiivinen kehittäjäyhteisö.

Ylläpidämme Gitlabista omaa instanssia, koska se on keskeisessä roolissa kaikissa meidän prosesseissa henkilöhallinnosta projektinhallintaan. Gitlabin ylläpito itse ei sinänsä ole valtava kustannus. Jopa päinvastoin. Gitlabin käyttöönoton jälkeen meidän sisäisen työkaluvalikoiman ylläpitokustannukset putosivat murto-osaan entisestä kun pystyimme luopumaan suuresta määrästä itse rakennetuista ja ylläpidetyistä työkaluista. Olemme harkinneet maksullisten lisenssien hankkimista, mutta vielä se ei ole tullut aiheelliseksi. Kasvun myötä tosin se päivä lähenee jatkuvasti.

Ylläpidämme vastaavanlaista ympäristöä myös muutamalle asiakkaallemme ja useilla asiakkailla on pääsy meidän GitLabiin heidän projekteihin. GitLab onkin teknologiastartupille mahtava työkalu sillä se sisältää kaiken tarvittavan yhdessä paketissa. Siitä on helppo lähteä laajentumaan kun vaatimukset kasvavat. Gitlabin ylläpitoon ei välttämättä kannata itse lähteä - varsinkin koska mm. meiltä löytyy intressi pitää omat ympäristömme ajantasalla - samalla pystymme tekemään sen myös asiakkaillemme - järkevällä hinnalla.Kustannustehokkuus ja takaisinmaksuaika Gitlabin käyttöönotolle on ollut selvä: Gitlab on vähentänyt meiltä kehittämisen työkalujen kustannuksia niin selkeästi että emme enää halua takaisin entiseen aikaan ja kymmeniin eri työkaluihin ja niiden ylläpitoon. Olemme jo aloittaneet purkutyöt, ja pala kerrallaan siirrymme tukeutumaan Gitlabiin.

Koodari ja samurai-koodi – kohti koodia parantavaa koodarikoodia

Maailmaa Suomesta käsin tarkastelevan nykykoodarin vinkkelistä satojen vuosien takainen Japani ja sen silloiset soturiyläluokan edustajat saattavat äkkiseltään tuntua kaukaisilta. Tämä on aivan luonnollista, ja aluksi tässä kirjoituksessakin mainitaan joitakin eroja samuraiden ja nykyohjelmistoihmisten välillä.Tämän jälkeen kuitenkin päästään ehkä siihen mielenkiintoisempaan osuuteen – yhtäläisyyksiin. Niitä löytyy melko runsaasti, ja ne luovat pohjaa pohdinnalle siitä, voisiko (länsimainenkin) ohjelmistoteollisuus hyötyä esimerkiksi bushidōn keskeisten ihanteiden soveltamisesta.

Samurai vs. koodiapina: ilmeisiä eroja

Faktana voitaneen pitää, että entisaikojen samuraiden toimintaympäristö ja elämäntapa eittämättä erosivat melkoisesti nykykoodarin oloista. Tässä joitakin esimerkkejä:

• Ohjelmistoliiketoiminnassa – niin kuin liiketoiminnassa yleisemminkin – raha on melko keskeinen vaikutin, ja samurait tunnetusti halveksivat rahaa eivätkä käsitelleet sitä mielellään. Nykyään ohjelmistotyötä pidetään yleisesti melko hyvin palkattuna, ja osalle koodareista tämä voi toimia motivaattorina hakeutua alalle.
• Samuraiden elämään epäilemättä kuului stressi siinä kuin koodiorjankin elämään, mutta se syntyi suurelta osin varsin erilaisten vaikuttimien johdosta.
• Yleensä samurailuokka – kasteista selvästi arvostetuin – mielletään säädyksi, johon ei hevin astuttu ilman asianmukaista syntymäoikeutta (vaikka kaikkina aikoina tämä ei tiukasti pätenytkään). Jonkinlaiseksi koodariksi taas voi nykyään ryhtyä liki kuka tahansa suhteellisen pieninkin ponnistuksin. Osittain tämä saattaa vaikuttaa alentavasti myös ohjelmistoammattilaisten arvostukseen muun yhteiskunnan silmissä, vaikka maailmaa hallitsevia ohjelmistoyrityksiä katsotaankin toisinaan ihaillen.

Niin haluttaessa toimenkuvien yksityiskohtia voisi tietysti kaivella ja tonkia eroavaisuuksien metsästämiseksi melko raa'asti, ja  luonnollisesti jo ajan kulumisesta sekä (etenkin länsimaista koodaria japanilaiseen bushiin vertailtaessa) kulttuurillisista eroista johtuen kaikenlaisia eroja voisi osoitella lisää varsin helposti. Jätettäköön tämä kuitenkin kotitehtäväksi asiasta kiinnostuneille ja pyyhällettäköön eteenpäin.

Yhtäläisyyksiä

Erojen lisäksi tosiaan yhteisiäkin piirteitä löytyy varsin runsaasti. Joitakin tällaisia – ensimmäiseksi mieleen juolahtaneita – avataan lyhyesti seuraavissa kappaleissa, jotka eivät millään muotoa muodosta aiheesta mitenkään kattavaa esitystä, mutta luovat silti pohjaa jatkotarkastelulle.(Tekstin luonteesta johtuen asioita yleistetään ja oiotaan jossain määrin sekä käytetään sanoja melko vapaasti. Blogikirjoituksen tarkoitus tässä tapauksessa on ennemminkin välittää ajatuksia tiettyyn viitekehykseen sitoen kuin kirjoittaa täsmällisesti ja hyvin määritellyillä termeillä tai toimia historiallisena kuvauksena.)

Ammatillinen monipuolisuus

Eri aikakausina samurai-säädyn edustajilta edellytettiin jossain määrin erilaisia asioita, mutta hallittavien taitojen kirjo oli joka tapauksessa suuri. Jo pelkästään toimenkuvan taistelullinen aspekti edellytti jonkinasteista monipuolisuutta. Hallittava asevalikoima oli laaja, ja sōgō bujutsu -koulukunnat (monet varhaiset ryūhat olivat tällaisia) opettivat kamppailua ”kokonaisvaltaisesti”. Taistelutaitojen lisäksi herrasmiessotureilta luonnollisesti edellytettiin esimerkiksi etiketin tuntemista ja taiteiden harrastamista. Edo-kaudella erilaiset byrokraattiset velvollisuudet luonnollisesti toivat omat lisämausteensa vaadittuun osaamiseen.Tyypilliselle liikeyritykselle on tärkeää pitää toiminnan kustannukset siedettävinä, mutta saada silti toimitettua asiakkaille riittävän laadukkaita tuotteita järkevässä aikataulussa pysyen. Lisäksi nykyään softatalolta kuin softatalolta odotetaan varsin laaja-alaista osaamista. Ohjelmistoammattilaisiltakin siis edellytetään monipuolisia taitoja. Matemaattisen logiikan tai yksittäisten ohjelmointikielten tai työkalujen hallinta ei tavanomaisissa olosuhteissa vielä riitä kovinkaan pitkälle, vaan menestyksekkäässä toiminnassa tarvitaan melkoisen ohjelmistotyökaluarsenaalin hallinnan lisäksi myös sosiaalisia taitoja, markkinointikykyä, lakiteknistä osaamista, ympäristön ja trendien seurantaa sekä jatkuvaa mukautumis- ja muuntautumiskykyä.

Harjoitus tekee mestarin?

Kyetäkseen täyttämään velvollisuutensa samurait harjoittelivat ankarasti lapsesta asti asemansa edellyttämiä taitoja. Sen lisäksi, että mestarillisia taitoja arvostettiin, säännöllinen harjoittelu ja taitojen jatkuva hiominen saattoivat myös selkeästi ja konkreettisesti pidentää elinikää.Koodarin on luonnollisesti opeteltava tietyt perustaidot alalle päästäkseen, mutta se ei yleensä riitä, vaan hänenkin on ohjelmistoalan muuttuessa ja kehittyessä huimaa vauhtia jatkuvasti kehitettävä itseään ja opeteltava uusia taitoja pysyäkseen menossa mukana. Toisaalta myös mestarit, jotka ovat hioneet taitonsa yksittäisen aseen – vaikkapa tietyn (enemmän tai vähemmän antiikkisen) ohjelmointikielen – osalta ”täydellisiksi”, saattavat olosuhteiden salliessa löytää paikkansa ja saavuttaa arvostetun aseman.

Vastuu omista ja muiden teoista keskeistä

Samurai vastasi toimistaan feodaaliherralleen ja klaanilleen. Vastuun kantaminen konkretisoitui siten, että virheillä saattoi olla hyvinkin dramaattisia seurauksia niin yksilölle itselleen kuin esimerkiksi sukulaisillekin. Sen lisäksi, että itse pyrki toimimaan asianmukaisesti, oli tärkeää, että myös kaikki, joiden käytöksestä oli vastuussa, tekivät niin.Nykyään ohjelmistotyössä seppukut eivät ole tavanomaisia, mutta kasvojen perinpohjaiseen menettämiseen on kuitenkin hyvät mahdollisuudet, jos tekee työnsä huonosti. Ohjelmistoja rakennetaan monenlaisiin tarpeisiin, ja poikkeamat virheettömästä, spesifikaation mukaisesta toiminnasta saattavat toisinaan olla vaikutuksiltaan hyvinkin kriittisiä. Vaikka koodia ei tuotettaisikaan järjestelmiin, joilla voi laukoa ydinohjuksia, on koodin korkea laatu aina valttikortti.Tuotantoprosessissa ei siis ole suotavaa oikoa, ja jokaisen kontribuoijan tulee asennoitua tuotokseensa asiaankuuluvalla vakavuudella ja olla valmis kantamaan toteutuksestaan implikoituva henkilökohtainen vastuunsa. Kliseisesti tässäkin tapauksessa ketju (järjestelmä) on yhtä vahva kuin sen heikoin lenkki, ja yksittäisten koodarien vastuuntuntoisen suhtautumisen lisäksi laadunvarmistukseen esimerkiksi katselmoinnillisilla menetelmillä, testauksella sekä tarvittaessa ohjelmien oikeiksi todistamisen keinoin tulisi panostaa riittävästi, jotta vastuun kantamisesta yhtiötasolla ei tulisi ongelmaa ja jotta asiakkaille ei aiheutuisi turhaa harmia.

Konventioiden tunteminen tärkeää

Bushien elämässä etiketin ja konventionaalisten toimintatapojen tuntemus oli varsin keskeistä. Hyvät tavat helpottivat elämää, ja etikettivirheet saattoivat hierarkkisessa feodaaliyhteiskunnassa osoittautua toisinaan kohtalokkaiksikin. Taistelukentilläkin totunnaisten menettelytapojen hallitseminen (ja toisinaan kyky poiketa niistä) antoi etua.Esimerkiksi protokollien standardoinnilla pyritään saavuttamaan mm. yhteensopivuusetuja, ja itse ohjelmistotyöhön liittyy runsaasti implisiittisiä oletuksia toimintatavoista, menetelmistä ja työkaluista. Ollakseen vakuuttava ja kyetäkseen toimimaan työssään kitkatta ohjelmistoammattilaisen tuleekin tuntea relevantit standardit, pystyä tarvittaessa noudattamaan niitä ja ”tietää, kuinka asiat tehdään” – tai vähintään kyetä ottamaan tarvittaessa selvää. Hyvät tavat helpottavat toimintaa niin työyhteisössä kuin asiakasrajapinnassakin.

Strategiset ja taktiset taidot

Usein liike-elämässä (softafirmoissakin) johtajistolla on tapana hakea oppia esimerkiksi Sunzin (Sun Tzu) kaltaisilta strategeilta, kuten joukkoja komentaneilla itämaisilla sotalordeillakin aikoinaan. Musashinkin näkemykset sisältynevät monien johtajien vakiolukemistoihin. Vaikka tavanomaisella riviohjelmistokehittäjällä ei usein olekaan valtaisia joukkoja komennettavina, hänkin toki voi hyötyä työssään strategisesta ja taktisesta pelisilmästä sompaillessaan projektinhallinnallisten haasteiden ja asiakassuhteiden hoitamisen parissa – luonnollisesti ottaen etiketin ja moraaliset näkökohdat huomioon.

Koodarin tie

Samuraiden elämää ohjaili (enemmän tai vähemmän ja luonnollisesti aikakauden mukaan eläen) bushidō, mutta aloin miettiä, löytyisikö vastaavaa kunniakoodia ja ohjenuoraa koodareille. Tunnetusti samuraikoodi tiivistyi kasaan perushyveitä, joita on usein pyritty soveltamaan mm. liikkeenjohtoon. Päätin yrittää sovittaa näitä (vapaina käännöksinä ja merkityksiä varsin liberaalisti venyttäen) yhtäältä vielä spesifisemmin ohjelmistoyrityskontekstiin ja toisaalta laajentaa tarkastelua johdosta myös organisaation ruohonjuuritasolle.Julkisuuskuvastaan ja asiakkaidensa hyvinvoinnista kiinnostunut ohjelmistotalo tahtoo varmasti käyttäytyä sidosryhmiään (etenkin asiakkaitaan ja työntekijöitään) kohtaan oikeudenmukaisesti, ja tässä auttaa velvollisuudentunto. Toisinaan – jos ei nyt suoranaisesti kuolemaa uhmaava, niin ainakin lyhyen tähtäimen voitot vaarantava – rohkeus lähteä uusille urille ja tehdä asiat epäkonventionaalisesti saattaa olla ratkaiseva tekijä menestykseen pyrittäessä. Toisaalta myös itsekuria tarvitaan, jottei sorruta järjettömiin ylilyönteihin. Niin liikesuhteiden kukoistuksen kuin henkilöstön hyvinvoinnin kannalta kunnioitus, kohteliaisuus ja tarvittaessa myös myötätunto ja armeliaisuus ovat asiallisen toimijan ominaisuuksia, joiden kautta rakennetaan pohjaa lojaalisuudelle ja ruokitaan sitä. Edelleen rehellisyys ja kunniallisuus auttavat rakentamaan firmalle hyvää imagoa, mutta mikä vielä tärkeämpää, parantavat myös työntekijöiden oloja.Sen lisäksi, että tällaisia avainsanoja kirjataan yhtiön arvodokumentaatioon ja että yhtiötä pyritään johtamaan siten, että se näyttäisi ulkoisesti hyvältä, kaikessa käytännön toiminnassa organisaation kaikilla tasoilla tulisi toteuttaa sanojen henkeä. Yksittäinen koodarikin voi puntaroida toimintaansa melko hyvin mainittujen ominaisuuksien kautta ja näin osaltaan edistää yhtiön kulttuurin (ja lopulta myös ulkoisen imagon) muotoutumista mielekkääseen suuntaan. Osittain tulkinta voi erota yhtiön tasolla tapahtuvasta tulkinnasta – esimerkiksi rohkeutta yksittäinen työntekijä saattaa tarvita kyseenalaistaakseen firmansa huonoja tai kunniattomia käytäntöjä; ellei kissoja saada nostettua pöydille, lojaalisuus työnantajaa tai kanssatyöntekijöitä kohtaan saattaa kärsiä.Mainittuihin  bushidō-arvoihin voisi nykykoodareille – ja toki myös muille ohjelmistoyhtiön työntekijöille ml. johtoportaat – ehkäpä lisätä vielä ainakin informaation jakamisen ja läpinäkyvyyden, koska toimivan kommunikaation roolia ohjelmistotyössä on vaikea ylikorostaa. Lisäksi perinteisestä bushin mielenmaisemasta ja asennoitumisesta voisi koodarin tiehen vielä lainata ainakin tiettyä zenimäistä meditatiivista tyyneyttä ja yleisesti rauhallista tapaa suhtautua asioihin, vaikka yllätyksiä ilmeneekin koko ajan, deadlinet paukkuvat ja deploymentteja pitää suoltaa jatkuvasti. Tämä lienisi mielenterveydellisesti viisasta, vähentäisi huonojen paniikkiratkaisujen määrää  ja auttaisi koodaria panostamaan hyveisiin.Esimerkiksi Yamamoto Tsunetomon Hagakuressaan rummuttamaa näkemystä bushidōn olemuksesta kuoleman ehdottomana valitsemisena voidaan tulkita monella tavalla (ja siitä voidaan olla montaa mieltä). Tähän tarkasteluun saattaa sopia paremmin (musashimaisempi) painotus, jossa oleellista on hyväksyä kuoleman mahdollisuus päättäväisesti. Yritystasolla rohkeutta toimia voi edistää, jos yritys ”elää kuin kuollut”, mutta asia ei ole ihan yksioikoinen, ja yrityksen tulisi muistaa pysyä lojaalina esimerkiksi henkilöstölleen. Yksittäisen työntekijän osalta tilanne on ehkä selkeämpi – ainakin triviaalisti tulkiten; jos koodataan se aktiivisesti mielessä, että jokainen hetki voi olla viimeinen, saattaa huonoja väliaikaisvirityksiä tulla tehtyä vähemmän, dokumentoitua paremmin jne.Monilla reaalimaailman yhtiöillä saattaa olla perimmiltään hyvät tarkoitukset ja jalot päämäärät, mutta eräs jo mainittu seikka häiritsee usein keskeisten (enemmän tai vähemmän teoreettisiksi jäävien) arvojen heijastumista käytäntöön. Tämä seikka on suhtautuminen rahaan. Osittain johtuen toimintaympäristöstä ja yhteiskunnallisista rakenteista rahalla on ihan ymmärrettävästi ohjelmistoliiketoiminnassakin varsin keskeinen rooli. Voittoa ei kuitenkaan tulisi tahkota hinnalla millä hyvänsä, vaan tässäkin pitäisi muistaa itsekuri ja lojaalisuus kaikkia relevantteja sidosryhmiä kohtaan, jotta kunniallisuudesta ja oikeudenmukaisuudesta ei tarvitsisi luopua eikä lipsua.Yhteenvetona vielä todettakoon, että ainakin vapaasti tulkiten monet bushidōn keskeiset hyveet soveltuvat mainiosti ohjailemaan koodarinkin elämää. Toisinaan tällaisia ohjenuoria soisi käytettävän enemmän, koska ihmisten ja organisaatioiden toiminta ei aina ole parhaimmillaan luonnontilaisena.

Laskutusta rahoituksella vai ilman?

Isojen kelausten äärellä taas painitaan. Eilen oli hyvä keskustelu Padio Oy:n Jere Vuorion kanssa, aiheena laskurahoitus. Tähän asiaan päästiin teemasta, joka tuntuu nyt toistuvan kaikkien pk-yrittäjien kanssa käydyissä keskusteluissa. Eli kassavirtaongelmat ja kassakriisin välttely.

On ihan hemmetin väärin, että tällaiseen tilanteeseen joudutaan. Sopimukset on tehty, työt on tehty, lasku lähetetty, mutta rahoja ei kuulu. Yleensä syynä tähän ei ole se, etteikö asiakas haluaisi maksaa vaan se, että nämä viivästykset moninkertaistuvat matkalla aina sieltä viimeisimmältä taholta. Jos asiakkaan asiakas ei maksa ajoissa, niin ymmärtäähän sen, että yritykset pyrkivät optimoimaan kassaansa siten, että verot ja palkat saadaan hoidettua.

Miksi yhteiskunta on luonut tällaisen ansan ja mahdollistaa laskurahoitusliiketoiminnan? Miksei niitä laskuja voisi maksaa sopimusten mukaisesti ja järkevässä ajassa? Esim. meidän alalla 90 päivän maksuehto tarkoittaa sitä, että varsinainen työ on tehty joka 4kk ennen kuin rahat tulevat tilille. Välissä on maksettu palkat, alvit ja eläke- yms maksut siitä tehdystä työstä. Ja lyhyemmilläkin maksuehdoilla, esim. 30 päivää + 1-2 viikon myöhässämaksaminenkin on kustannustehokkaassa tekemisessä aika raskasta.

Eli minusta on vähintäänkin reilua, että rahat saadaan tilille eräpäivänä ja toisaalta jos olisi mahdollisuus saada rahat tilille vielä nopeammin, niin alkaahan se kiinnostamaan. Kustannukset näissä palveluissa ovat mielestäni vähintäänkin kohtuulliset, mutta ainoa asia mikä minua koko hommassa arveluttaa on se, miten asiakkaat tähän reagoivat?

Ilkan kanssa kun juteltiin, niin tultiin yhdessä siihen johtopäätökseen, että eihän tähän negatiivisesti voi reagoida, jos kaikki hoitavat tonttinsa, niin kuin on sovittu. Eli tulemme nyt ainakin testaamaan laskurahoitusta yhteistyökumppanimme Talenomin kanssa ja katsotaan miten homma lähtee rullaamaan.

Mikset kehittäisi yhteistyössä?

Videon krediitit kuuluvat Hämeenlinnan kaupungin aktiivisille käyttäjille ja kehittäjille. Olemme vuodesta 2011 alkaen rakentaneet opetussektorille (ja sittemmin myös yritys-/hallintopuolelle) sähköistä työpöytää. Ei siis mitään mitä saisit huonekalukaupasta vaan sellaista pilvityöpöytää, joka yhdistää kaikki käyttämäsi sähköiset palvelut yhden kirjautumisen taakse.

Idea on erittäin yksinkertainen: Kaikki palvelut, joihin sinulla on käyttöoikeus on valittavana omaan räätälöitävissä olevaan näkymään eli työpöytään. Sieltä voi sitten poistaa työkaluja ja niitä voi myös järjestää tarpeen mukaan - ja aina tarvittaessa palata niihin.

Jossain kohdassa käytin tästä vertausta, että tää on vähän niin kuin intranetti, sillä poikkeuksella, että löydät tarvitsemasi palvelut heti. Ajansäästö on merkittävä - ja kun oppitunnin alusta säästyy aikaa säätämiseltä niin jää enemmän aikaa oppimiselle. Se on tärkeintä.

Tämän tuotteen rakentaminen ei ole ollut helppoa - ja lopputulos muistuttaa linkkilistaa, kuten monet usein sanovat. On tarvittu useita ja taas useita uusia versioita, jotta olemme pystyneet vastaamaan käyttäjien tarpeeseen, kuunnelleet useiden satojen eri opettajien ja oppilaiden mielipiteitä ja ottaneet ne huomioon kehityksessä. Olemme lisäksi antaneet käyttäjille täyden vallan päättää, miltä järjestelmä näyttää ja miten se nimetään.

Sittemmin meille on syntynyt kilpailijoita - tai siis oikeammin meille on syntynyt verrokkeja, joita kutsutaan samalla nimellä, mutta joiden kehittämiseen on lähetty ylimalkaisesti juuri sillä "Miten vaikeeta muka tuollainen ruudukko/linkkilista voi olla tehdä". Se on ollut ilmeisen pitkä prosessi ja siitä kunnia ei missään nimessä kuulu meille. Kunnia kuuluu käyttäjille, aktiivisille opettajille ja tvt-asiantuntijoille sekä oppilaille.

Olemme tehneet valtavan pitkään yhteistyötä mm. Kauniaisten Kasavuoren koulun kanssa (täältä kaikki alkoi), Hämeenlinnan kaupungin kanssa (Airo), Kangasalan (Tori) sekä Kuntien Tieran (Edison-oppimisympäristö) kanssa. Ja viimeisimpinä lisäyksinä meillä on Parkano (Kampus) ja Tampere, jolle käyttöönotto on parhaillaan käynnissä. Koko tällä porukalla pitäisikin saada tehtyä entistä enemmän yhteistyötä ja pystyä jakamaan käytäntöjä. Käytäntöjen jakaminen sitten helpottaisi myös muita vastaavia tuotteita kehittäviä tahoja ottamaan huomioon ne hyvät puolet ja ennen kaikkia puutteet ja tarpeet, johon nykyinen toteutus ei vielä vastaa.

Yhdessä tekemiseen onkin jo hyvä alusta olemassa, katso mitä Digikilta tekee. Nykyinen toteutus on tosiaan avointa lähdekoodia ja eri versioita (kuten mm. MPASSid:n demo) on saatavilla suoraan Haltun github-tililtä. Haluamme edistää avoimuutta, läpinäkyvyyttä ja yhteistyötä, koska en usko, että olemme paras kumppani jokaiselle asiakkaalle, koska hyvät ratkaisut ja toteutukset vaativat kuitenkin parempaa tuntemusta, luottamusta ja rohkeutta.

Jos olet softafirma ja tarvitse jeesiä palvelun pystyttämiseen, niin ota yhteyttä. Ja jos olet nykyinen tai mahdollisesti tuleva palvelun käyttäjä, niin sovitaan tarkempaa esittelyä.