Futurice Blog

Five environments you cannot develop without

How do you achieve high quality, satisfied users, happy developers, and minimal downtime when developing a live digital service? Sufficient conditions for these goals are yet to be discovered, but you'll have a hard time achieving any of them without proper environments.

Then, what is the proper set of environments for server-side software development? Here's our take on the matter.

Development
This is where you write code. The product you're building can be run here, and any changes to it can be tested with minimal delay. Integrations to external services are replaced with mockups or stubs to avoid daily work being interrupted by network issues or server downtime. In particular, any databases are local. However, highly available public services may be used as such.

Continuous Integration
Continuous Integration (CI) builds your product and runs all automated tests as soon as anything changes in the codebase. Failures are reported immediately. CI also runs end-to-end integration tests.

Testing
The Testing environment used by dedicated testers doubles as a production-like playground for developers. External integrations are by default set up to staging-level versions of other services. Developers can experiment with and try out new integrations here—this environment is also known as Integration Testing.

Demonstration
This one's optional. Depending on your approval process, the demonstration environment can be used to allow for stakeholders to review changes on their own schedule before approval for production.

Staging
This one goes by many names: staging, QA, or pre-production. If a release breaks something in production, it will break identically here. Thus the staging environment is set up exactly like production (except for necessary configuration parameters), and kept like production between releases. Mysterious production issues can be debugged here. Dedicated testers can also use this environment.

Production
The real deal. Never ever modified in any way without rehearsing in staging first. Regular clean-up is scheduled for accumulating data, such as logs and temporary files.

We've found that this set helps developers to come up with the best technical solutions and resolve issues quickly, and users will only ever notice a new release by the product's increased awesomeness.

Do you think we're missing something essential? Is there something you would leave out?

Posted by Olli Ahonen 

BHAG: About People and Goals

When you are just a couple of people starting up a company, your goals are often straightforward and well understood. But as your company grows and becomes too big to have everything work without effort, it is time to think about what brings everyone together as a group of people and what the purpose of the company is. Here I am not talking about the legal entity 'company', whose goal it is to generate profit, but about the people. Why do they get out of bed – just to get a paycheck each month? For the sake of your long term success, I hope the answer to that is not "yes". 

For those who are unsure about the validity of this claim, here are some links to check out:

http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

http://www.amazon.com/Start-Why-Leaders-Inspire-Everyone/dp/1591842808

http://hbr.org/1996/09/building-your-companys-vision/ar/1

So also began Futurice's discovery to the "why". I specifically use the word discovery because your long term identity and goals should flow from who you are. It should not be an invented why.

One of the elements in this discovery is our BHAG (big, hairy audacious goal; see wiki: http://en.wikipedia.org/wiki/Big_Hairy_Audacious_Goal). Initially, we had several closed discussions about the subject, but we couldn't shake off a nagging feeling that we were doing it wrong. So we decided to do it differently, and make use of all the bright people in our company. 

The format we ended up with was an election. From our previous discussions, we had three rough outlines of possible goals, and asked three people to represent them. The candidates will gather campaign teams that will start the discussion to improve those rough goal outlines to their finalized form. During the campaign, we will discuss and try to answer questions like "What are the merits of this particular goal?", "Why does it fit Futurice's values?", "How do we know that we have reached the goal?", "How does this goal make the world a better place?", etc. After the discussion – which, of course will include an election debate – it is time to vote and set our long term goal. 

Why did we choose an election? Two reasons. First, it involves everybody. Everyone has the chance to have their voice heard as to what we should be striving for. The second and maybe most important reason is the resulting discussion. Discussion leads to discovery, and discovery leads to better decisions. The combination of the two ensures that the outcome has been thoroughly scrutinized and has broad support.

Your long term future is too important to be decided by a couple of people sealed off from everyone else. The discussion should be out in the open, involving everybody and the outcome should be supported by more than just management. We have a company which values trust and taking responsibility. We try to recruit the best and brightest with an interest reaching far beyond their own desk. It would simply be silly not to use that huge potential to shape our future.

Currently we are forming the campaign teams and defining the candidate goals. After the New Year we start the campaigns, and voting will most likely take place in March.

Follow our efforts to discover our future by following us on twitter http://twitter.com/futurice or keep an eye on this blog for updates on the Futurice goal election.

Posted by Peter Tennekes 

Mobile HTML5: Why and How?

Here is a quick 14 minute introduciton to mobile application development, why it is (finally) real and how to specify your projects and deploy your applications to best effect. This was an internal Futurice presentation from Helsinki, simulcast to Tampere and Berlin.

Posted by Paul Houghton 

Useful Django Resources

At Futurice, we use Django rather heavily for internal tools such as reporting, virtual machine management and integration between miscellaneous systems. Django enables very rapid development and includes a large number of modules and plugins. In addition, Django documentation is outstanding.

There are a few tools that I believe everyone using Django should be familiar with: South (database schema migrations), Sentry (error reporting) and Reversion (model version history).

South creates database migrations automatically with only a few commands. Without South, changes require running SQL ALTER statements manually or deleting database tables and recreating them (after creating a backup first, and then restoring it, of course). Taking South into use is really simple: just add "south" to the project settings (under INSTALLED_APPS) and run the initial schema migration, which just records current models. After changing models, applying changes to the database requires just two commands:

./manage.py schemamigration <app name> --auto
./manage.py migrate <app name>

This preserves all information in the database, assuming no field was truncated or deleted. So, for example, changing a field from integer to float is fine, but not necessarily the other way around.

South migrations are Python files stored inside the Django app, with names like "0012_auto__del_field_comments__chg_field_timestamp.py". That's the 12th migration that was automatically created which deletes the "comments" field and changes the "timestamp" field. South can also handle data migrations: for example, if the timestamp is stored in Unix time (seconds since 1.1.1970) in an integer field, a simple South migration can handle adding a proper DateTime field and converting the timestamps. One caveat with sqlite is that it doesn't support altering unique constraints. However, South gives a warning message when it encounters this - so it's not a hidden surprise to be detected later on.

Sentry is a generic interface for browsing exceptions thrown by Django or by any other Python application. By default, Django emails every single error report to the developer's email address. This is quite annoying with a busy web application: it might send hundreds of emails within a few minutes. Sentry handles this problem by grouping identical error messages as one. In Sentry, "identical" means an error with same traceback, not per client IP address or similar details.

Sentry is installed by adding it to INSTALLED_APPS and adding the middleware to catch exceptions. When running multiple Django applications, a centralized Sentry server is useful. In Futurice, one Sentry server provides access to nearly all Django application error reports (about 15 different applications). The Sentry UI works well, with added Ajax niceties. No system is perfect though: different versions of the Sentry server and client do not always work nicely, and, in case of problems, it fails silently.

Reversion handles version control for objects in the database. Basically, if any object is modified, Reversion saves modifications and allows reverting to old versions. Integration to other parts of applications goes through middleware (adding a single line to the project settings file) or with decorators (for saving changes only in specific methods) or by using "with" statements (for saving changes only in specific places). The easiest way to browse the version history is through the Django admin interface. Reversion even adds automatic comments to versions: for example "Changed description" when the description field was updated.

Of course, there's a long list of other useful packages and tools. Just to list a few: virtualenv, django-debug-toolbar, django-annoying and haystack.

Hopefully you found a new useful Django tool with the post that will make your development efforts easier in the future!

Posted by Olli Jarva 

Woo, our brand book is done!

We got our brand book done! We found that it was hard to catch the idea what the book should be like because examples are poorly available, so here is ours: http://www.futurice.com/brandbook.pdf . Hopefully this is useful to others.

The book has three purposes:

• To show the origin of our brand
• To clarify Futurice’s brand essence and brand personality
• To provide brand guidelines for our communication

Here is how the brand story goes:

Three engineers walked into a bar...

It all began with a few engineering students doing what they do best: creating interesting things through clever coding. This small group of friends had a passion for using the latest technology to create smart, convenient, and exciting solutions to everyday problems.

They were devoted to their creations and felt a sense of real ownership and responsibility for what they made and what it could do. Satisfied clients spread the word about the new, resourceful, and down-to-earth player in the market.

One engineer said...

The friends were excited to realize that the approach that they offered – fresh, unpretentious, clever – was one of the main reasons that people wanted to work with them.

They figured, “Let’s get this going. Let’s make it happen. But let’s promise never to get stuck on the corporate conveyor belt.” They wanted to stay inspired – to run a flexible, thoughtful, outward-looking business, not a code factory.

To get the best results they realized they’d need to create multi-talented teams made up of all sorts of skillful and gifted people.

When the engineers left the bar...

...they took a few friends with them, including, down-to-earth artists from the school of art and design, entrepreneurial businesspeople, and energetic individuals from all sorts of fields. Futurice emerged out of its modest beginnings and into the corporate world.

New, young, gifted students – not just engineers – start at Futurice every year: we take on people who are energetic, eager to learn, and who aren’t jaded by the industry.

Our roots are in engineering, but we see our engineers as designers, sculptors of ideas, and social architects. And regardless of our backgrounds, we’re all working together to engineer a new future with our customers.

They started a journey...

And it’s getting more and more interesting.

Because for Futurice, software design is not just about solving immediate problems, it’s about positively influencing the bigger picture for our clients. We want to provide options, broaden horizons, change mindsets, and give our clients new tools and new perspectives on the way they operate.

At the ten-year mark Futurice had around 150 employees and a global client base. Our designs continue to incorporate sensitivity and human understanding, and consider all angles of the user experience.

We consider the social impact of the designs we create, and we trust that intuitive design will stimulate renewal in the tech-driven engineering world.

But they stayed in touch with their roots.

While we continue to grow, and the future’s looking fantastic, our down-to-earth attitude and entrepreneurial spirit never changes.

Our capacity to constantly evolve, adapt, and evaluate our own work practices to better serve our clients makes us an eternal start-up, no matter how big we grow.

So, how many engineers (and their friends) does it take to change an industry?

We don’t know yet, but we’re dedicated to finding out.

To read more, download our brand book at http://www.futurice.com/brandbook.pdf

What is your own story? :)

Posted by Anni T. 

One Click Taxi Order

Ordering a taxi should be as easy as purchasing things from Amazon, right? That's what we made to our office lobby.

Pressing the button orders an SMS taxi to our office. Display shows order status and after taxi confirms the order, taxi number.

List of parts:

• Taxi post from Trafino, about 200€
• Mobile broadband USB stick (Huawei E230), for sending and receiving SMS messages, 80€
• Button from internet, 10€
• Arduino, for connecting button to computer, 20€
• Cable for connecting button to Arduino

In total about 310€ plus small desktop computer and display. Our display also shows bus timetables for nearby bus stops and weather information for our offices in Helsinki, Tampere and Berlin. Bus timetables require HSL API key. Weather information uses weatherbug API. 

We put up github repository for the code with some very short instructions. Whole system was put together just before our annual party, so it's not particularly production quality code. It's licensed with GPLv3, so feel free to use and modify it.

Posted by Olli Jarva 

Let’s contribute!

The drive to give something back to society–or to contribute–is not an isolated trend. There are countless examples out there of people contributing some of their time and resources to causes they believe in. Especially in a wealthy society like the Finnish one, and especially for people working in privileged fields like IT, it’s not uncommon to find people who just want to give something back, one way or another.

I was once more a witness of this growing trend last weekend, when a group of 20-or-so very inspiring individuals got together at Hub Helsinki and spent 48 hours coming up with new concepts on sustainability. It was the Global Sustainability Jam, and the group in Helsinki was one of the 42 groups taking part in the event all around the world.

As one of the organizers of the Helsinki event I wanted to see if there was anything Futurice, my company, could do to help us out. Some food and drinks never hurt in an event like this, and that was something easy to ask for. More importantly, though, I’m interested in finding a model in which companies can get involved in these events and do their share of contribution, and at the same time make it easier for people to contribute without compromising their work-life balance. So, some of my company time was another thing I wanted to ask for.

Knowing how careful we here at Futurice need to be with our budgets, I wasn’t expecting anything to be just handed out, so I prepared a good list of arguments of how a sponsorship might benefit our company. I made sure I put everything in terms of Futurice benefitting, and not in terms of pro bono contribution.

But to my surprise, I had jumped to conclusions way too fast. After a series of discussions about the project and our potential involvement, I was finally told: “Oh, now I understand. This is about contributing to a cause, not about marketing. Well, why didn’t you say so? Just take what you need as long as it’s reasonable”

As it turns out, contribution is a possibility with companies as well. Maybe it’s not always that visible, and maybe it’s not a value shared by everyone in a company, but it’s certainly possible!

So here is what I learned from this and wanted to share with all those “contribution enthusiasts” out there, be them in Futurice or any other company:

1. Ask and you shall receive. Don’t just assume that your company only cares about profits and whatever other business objectives. Just take initiative, and you might be surprised of the outcome.
2. There are many like you out there. Don’t think you’re the only one who wants to contribute in your company. You’ll be surprised at how many others might have similar motivations, even people in very high positions.
3. Let’s not keep this as a secret, there’s nothing to be ashamed of. I can only imagine the impact we could have if contribution was a bit more out in the open…

So, let's contribute more together and see you at the next jam!

Posted by Sebi Tauciuc 

The first production deployment is the hardest

It's funny how some traits in software development are always present, no matter how small the development effort. One of these is the ever-surprising difficulty of the first production deployment.

Last week, I updated the layout of this very blog. We had decided to add a couple of things, reposition something, update the fonts, and so on. With Posterous, all of the "advanced" modifications are a matter of editing the blog template—that is, a raw HTML and CSS file which dictates the layout.

As the old layout was not that far from the new one, I decided to start with the existing template and gradually evolve it to the new look. Obviously, the blog would appear horribly broken in between, so I set up a development environment of sorts: another blog on Posterous. I then copied the existing template to my fresh development environment, where I could upgrade and tweak the layout until the whole thing looked beautiful.

When I was content with the layout in the development environment, I copied the entire template back to production, i.e., our actual blog. And it didn't quite work.

Contrary to what I had assumed, not everything about the layout is determined by the template. A so called accent color is defined outside of the template, an innocuous tag caused the template to render differently if a standard header image was uploaded to Posterous even if the image wasn't used, the fonts were all quirky, and so on.

All of these issues were easily solved, but nevertheless a whole bunch of work popped up at the production deployment step, where I thought I was done save for a quick copy-paste. If the first production deployment caused so much unpredicted extra work in such a small project, imagine the consequences of postponing the first deployment in a large development project, where efforts are measured in weeks instead of hours.

So get that first production deployment out of the way as soon as possible, with just the smallest value-adding increment, and you can cross one major project risk off the list!

Posted by Olli Ahonen 

Backups at Futurice

Greetings from the IT team! I thought I'd quickly describe how we handle backups at Futurice. In short: we try to backup everything and keep a decent amount of history.

For servers and virtual machines, we have two backup servers running BackupPC, located in Helsinki and Espoo. All virtual servers - even "I'll just test this, it's not important at all" testing servers - are automatically backed up daily without doing anything manually. BackupPC deduplicates backups, meaning that identical files take up space only once. BackupPC keeps backups almost indefinitely, but the interval between backups grows. In our configuration, daily backups are kept from the previous week, bi-daily ones after that for a few weeks, then every four days for a few months, once a week for year, and finally once a month forever. Of course, we have special configurations for some hosts that require more or less backup history.

In addition to the BackupPC hosts, we make USB disk offline backups four times a year of all irreplaceable data: version control, network disk, wiki, issue trackers, configuration files. Those disks are transported to a bank safe. In case of a huge catastrophe (for example, simultaneous fires in Espoo and Lauttasaari), we would lose at most 3 months worth of data. This is, of course, a very bad situation, but it won't bring the whole company down.

For laptop backups we have a separate server with a large disk rack. Every employee can create new virtual backup disk with a simple web interface. It supports AFP and Samba for Mac OS X Time Machine or Windows Backup. The hardware is made up of a cheap disk rack with 16x 750GB SATA disks in RAID5 with one hot spare drive. The disk controller automatically tests disks and the hot spare periodically, so we shouldn't have an unpleasant surprise with both a broken RAID system and a broken spare disk.

For the BackupPC servers, we use 15TB of RAID5 storage running on slow SATA disks. Currently, we have 214 hosts backed up with almost 1500 full backups and 1000 incremental backups, totaling almost 67 000 000 files and 21TB of non-deduplicated backups. After deduplication and compression, this is reduced to less than 2TB. The rest of 15TB disk space is not wasted, since our surveillance camera images and other miscellaneous files go to the same servers.

Ages ago, our backup server was an old desktop computer with a large disk running in the corner of our office. Back then, there were only a few hundred gigabytes of backups. When the time came to find a larger solution, we evaluated different backup solutions. We decided that, for our environment, tapes or commercial backup software didn't offer us enough benefits to outweigh the costs. Using tapes requires more manual work - changing tapes, keeping track of used tapes and ensuring that restores are working. With BackupPC, restoring data for testing purposes is a straightforward task, and does not require any interruptions to running backups. A large enough tape library with a changing robot was prohibitively expensive. As for commercial backup software solutions, having secure, incremental, deduplicated backups on a Linux server was simply not available for a reasonable price. Also, the possibility to backup new virtual hosts automatically was not possible with a reasonable amount of effort. Our solution of having a server with large disks was much more flexible, easier to setup and more cost effective.

Posted by Olli Jarva 

Julkishallinnon tietotekniikka on päivitettävä 2010-luvulle

(This is a longer version of the letter published in Helsingin Sanomat on October 8th, 2011. In Finnish only, sorry.)

Viime viikkojen julkisen sektorin tietotekniikkauutiset ovat olleet karua luettavaa: VR:n uusi lipunmyyntijärjestelmä ei toiminut ja lisäsi junamatkaajien ahdistusta, ja terveydenhuollon sähköisten reseptien järjestelmä piti ottaa tuoreeltaan pois käytöstä. Miten on mahdollista, että Suomi, joka on monilla mittareilla tietoyhteiskuntien edelläkävijä, tuntuu haaskaavan verorahoja epäonnistuneisiin tietotekniikan jättihankkeisiin?

Kirjoituksessaan (HS Vieraskynä 23.9.2011) Pekka Abrahamsson ja Mikkonen tuovat osuvasti esille keskeisen piirteen tietotekniikasta osana liiketoimintaa: tietotekniikka ei ole enää pelkkä tukitoiminto vaan yhä useammin liiketoiminnan ytimessä. Kirjoittajat ehdottavat, että yritysten ei pidä ulkoistaa ydintoimintojensa tietotekniikan rakentamista, vaan tehdä asiat itse. Tämä on kuitenkin usein helpommin sanottu kuin tehty. Onko esimerkiksi VR:n kaltaisen yrityksen järkevää hankkia itselleen ja pitää itsellään tietoteknistä osaamista? Vai onko VR:n järkevämpää ulkoistaa tämä osaaminen muualta ja tehdä tiivistä yhteistyötä ohjelmistotoimittajien kanssa?

Viime aikaisten tietotekniikan kauhukertomusten taustalla olevat syyt eivät ole siinä, että ulkoistaminen olisi automaattisesti huono asia. Hyvä ulkoistaminen on yhteistyötä ja kumppanuutta, eikä ydinosaamisen siirtämistä alihankkijan ratkaistavaksi. Ulkoistamisen sijaan julkisen sektorin epäonnistumisen syynä on tietotekniikan nopea kehitys sekä julkishallinnon kilpailuttamissäännöt.

Epäonnistumisten taustalla on 1990-luvulle jämähtänyt käsitys tietotekniikasta. VR:n lippujärjestelmän sekä sähköisten reseptien tapauksessa kyse on jättimäisistä projekteista ja kymmenien miljoonien investoinneista, jotka liukuvat jäävirran nopeudella harmittavan usein kohti epäonnistumisia. Tilanne on kuin kaksikymmentä vuotta vanhasta tietotekniikan oppikirjasta, jossa hankkeille on tyypillistä paisuvat budjetit, kankeat toimintatavat, käyttäjien unohtuminen suunnittelussa ja kymmenien insinöörien ryhmät ratkaisemassa oman alueensa ongelmia ilman käsitystä kokonaisuudesta.

Tietotekniikka on muuttunut merkittävästi 1990-luvulta. Ohjelmistojen rakentamisen kynnys on madaltunut valtavasti ja nykyään lähes kuka tahansa voi alkaa ohjelmoida ja laittaa tuloksiaan myyntiin verkon sovelluskauppoihin. Kun nuorten muutaman hengen voimin rakentamista ohjelmista kasvaa maailmanlaajuisia, kuten suomalainen Habbo Hotel, niin on selvää että ohjelmistokehitys ei vaadi suuria alkuinvestointeja. Nopea ja kevyt rakentaminen tekee mahdolliseksi kokeilut ja muutokset, ja siten tietotekniikkaa voi suunnitella entistä enemmän käyttäjien ehdoilla. Lisäksi kun ohjelmoinnin työkalut ovat joko ilmaisia tai erittäin halpoja niin miljoonien budjetit ja vuosien aikataulut ovat historiaa – tai ainakin niiden pitäisi olla.

Tietotekniikan toimittajien maailmassa tämä muutos näkyy sukupolvenvaihdoksena niin sanotun vanhan koulukunnan ja uuden koulukunnan välillä. Vanhan koulukunnan edustajia ovat tyypillisesti suuret konsultti- ja alihankkijayritykset, jotka on perustettu vuosikymmeniä sitten. Uuden koulukunnan edustajat ovat 2000-luvun nuoria, joiden toimintatavat heijastavat nykyajan tietotekniikan ominaisuuksia: kevyttä, nopeaa ja käyttäjälähtöistä rakentamista, joka on edullista toteuttaa.

Uuden koulukunnan sukupolvi ja yrityskulttuuri on samaa kuin innovatiivisten startup-yritysten: työstä nautitaan ja korkea laatu sekä mutkaton toteuttaminen koetaan ammattiylpeytenä. Työstä nauttimisen ja korkean ammattietiikan seurauksena on, että hankkeet onnistuvat lähes aina ja asiakastyytyväisyys on huippuluokkaa.

Julkishallinnon tietotekniikan hankkeiden päivittäminen 2010-luvulle vaatii uuden tavan ajatella: pieniä matalan riskin projekteja, jotka kestävät kuukausia eikä vuosia, jotka maksavat murto-osan siitä mitä ennen, ja jotka valmistuessaan täyttävät oikeasti käyttäjien tarpeet. Tämä ajattelu mahdollistaa aivan uudenlaisen alihankinnan, esimerkiksi kilpailuttamalla useita toimittajia rinnakkain tai kokeilemalla mikä on paras mahdollinen vaihtoehto. Niillä investoinneilla, jotka esimerkiksi VR on laittanut lipunmyyntijärjestelmäänsä olisi voinut rakentaa tusinan uuden koulukunnan järjestelmiä.

Mikä estää julkishallinnon organisaatioita siirtymästä tietotekniikassaan 2010-luvulle? Vastaus on kilpailuttamis- ja hankintasäännöt, jotka suosivat vanhan koulukunnan jättihankkeita. Ja kuten Abrahamsson ja Mikkonen kirjoittavat, kiertääkseen nämä säännöt julkisen sektorin organisaatiot on pakotettu silppuamaan alihankintansa pieniksi paloiksi eri ohjelmistotoimittajille.

Vaikka uutisointi on viime aikoina keskittynyt kauhutarinoihin, ei tämä tarkoita, että kaikki julkisen sektorin toiminta olisi vanhanaikaista. Hyviä vastaesimerkkejä ovat Helsingin seudun julkisen liikenteen mobiilikisa, jossa haettiin innovatiivisia uusia ideoita joukkoliikenteeseen, ja Sitran viimevuotinen uudenlainen rinnakkainen kilpailutus. Toivoa antavat myös valtion entisen IT-johtajan, Yrjö Bensonin puheet, joissa hän on peräänkuuluttanut uusia työtapoja ja työkaluja valtion tietotekniikkahankintoihin.

Mutta jotain on pielessä julkisen sektorin jättijärjestelmissä ja jättihankinnoissa, kun niitä katsoo rinnan muun tietotekniikan kehityksen kanssa. Suomeen on kasvanut Nokian seurauksena suuri määrä nuoria ja innovatiivisia tietotekniikan yrityksiä ja ammattilaisia, ja tätä lahjakkuutta tulisi voida hyödyntää julkisen sektorin hankkeissa. Toisin sanoen, samaan aikaan kun kotimaisen raideliikenteen ja terveydenhuollon tietojärjestelmät epäonnistuvat suomalainen Angry Birds valloittaa maailmaa. Milloin Suomelle tulee ensimmäinen julkishallinnollinen tietojärjestelmähitti kansainvälisille markkinoille? Tai edes kotimaisille?

Risto Sarvas, tekniikan tohtori, Futurice Oy ja Aalto-yliopisto
Kim Weckström, yhteiskuntatieteiden lisensiaatti, Avaus Consulting Oy

Posted by Risto Sarvas