Liip Blog https://www.liip.ch/en/blog Kirby Tue, 12 Dec 2017 00:00:00 +0100 Latest articles from the Liip Blog en Liip achieved the top 5 medium-sized companies and therefore “Top Arbeitgeber 2018” https://www.liip.ch/en/blog/liip-unter-den-top-5-der-mittelstaendischen-arbeitnehmern https://www.liip.ch/en/blog/liip-unter-den-top-5-der-mittelstaendischen-arbeitnehmern Tue, 12 Dec 2017 00:00:00 +0100 In November 2017, Focus-Business distinguished the top employers of the DACH region. To determine the ranking of the 1,300 companies, Focus has worked closely with kununu.com, the employer evaluation platform and Media Market Insights as a research company. The ranking is based on approximately 13,000 data sets with more than 324,000 employer evaluations. After companies had fulfilled the regional criteria, they had to gain a rating above 4.12 on kununu.com aswell to reach the final selection. The final placement was awarded by a score value that is composed of the average rating, the number of ratings on Kununu and the number of employees. LIIP is the fifth best medium-sized employer with a score of 92.5 and is awarded second place in the Internet sector.

Commitment to self-determination
In October 2017, the company won the Prix Balance and now it is one of 5 in the Top Medium-sized Employer 2018 makes LIIP proud. "To receive such international recognition verifies us with the quality of our working conditions," says Gerhard Andrey partner and co-founder. At LIIP employees follow the Holacracy principle: there are no traditional hierarchies, but a sociocratic decentralised form of authority instead. "This shortens the decision-making process and prevents the creation of networks for the mutual furthering of careers," explains Gerhard Andrey. LIIP invests in its employees and they’re giving back a lot. The focus is on the atmosphere, the joint advancement of ideas and the implementation of projects. There are no external co-owners, therefore Almost half of LIIP's shareholders are employees. "We are financially independent," says Gerhard Andrey.

Liip - a top notch employer
"At LIIP we offer our employees motivating working conditions, this promotes the work-life-balance", explains Gerhard Andrey. In addition to gender equality, individually definable part-time hours, options for unpaid time off, it is the autonomy of all employees that creates a highly productive and at the same time considerate atmosphere. In order to avoid inequities in pay, the wage system at LIIP is transparent and is applied equally to all employees. "We are not finished by any stretch of the imagination! We will continue to increase the wellbeing of our employees," confirms Nadja Perroulaz, partner and co-founder after receiving the title Top Medium-sized Employer 2018.

]]>
L’agilité chez QoQa : interview avec Joann Dobler https://www.liip.ch/en/blog/l-agilite-chez-qoqa-interview-avec-joann-dobler https://www.liip.ch/en/blog/l-agilite-chez-qoqa-interview-avec-joann-dobler Tue, 12 Dec 2017 00:00:00 +0100 En décembre 2014, on recevait un appel de Joann Dobler qui est en charge des pôles multimédia et digital chez QoQa. Dans les grandes lignes, ça disait quelque chose comme “Salut Liip, on est en train de refaire tous nos sites et apps mobiles, et on cherche un partenaire pour nous aider à lancer le projet dans la bonne direction niveau méthodologie et techno. Ca vous tente ?”
En voyant l'opportunité de pouvoir pratiquer Scrum sur un chantier immense comme QoQa.ch, nous avons accepté sans hésitation.

Trois ans après cette discussion, leur nouvelle plateforme au nom de code “QoQa4” est désormais en ligne après de nombreux sprints, coups de gueule, montées en stress, sans oublier les fondues et choucroutes au Café Romand.
En voyant le chemin parcouru niveau méthodologie agile après plus de 70 sprints, je me suis dis que ça serait intéressant d’interviewer Joann pour avoir son retour d’expérience concret sur l’Agilité et Scrum, quelques années après avoir écrit sa première User Story.

Bienvenue à Joann Dobler, celui qui a introduit Scrum et ses outils assez carrés dans un environnement QoQasien où on pense que les règles sont plutôt faites pour être enfreintes !

Pourquoi toi, Joann, tu as pensé à l'agilité pour QoQa fin 2014 ? Quelles conditions t'ont amené à considérer cette méthodologie ?
En fait, je connaissais déjà l'agilité, et je savais qu’au vu de l'ampleur du projet et donc au temps de sa mise en place, nos priorités business et technologiques allaient évoluer. On devait donc choisir une méthode qui nous permette de nous adapter. De plus, pour une question d’état d’esprit, de partage, et de dynamisme au sein de l'équipe, on devait s’adapter, et donc dynamiser notre façon de travailler.

En résumé : il nous fallait un truc pour mieux nous adapter au business, faire face aux changements de priorités, offrir de la transparence, et amener un réel échange au sein de l’équipe.

Quelle méthodologie de gestion de projet utilisiez-vous avant chez QoQa ?
On utilisait une méthode traditionnelle, genre un agenda par étapes et jalons. Une fois les maquettes graphiques terminées, on débutait avec l’HTML… Pour les petits projets, ça pouvait jouer, mais dès que c’était plus conséquent, on finissait avec des délais jamais tenus, aucune flexibilité, et surtout un gros manque de dynamisme avec les équipes.
Si quelqu’un peut m’assurer un délai d’un gros projet un an à l’avance, je l’invite pour une bouffe afin qu’il m’explique sa technique — no joke !

Pourquoi avoir choisi Liip pour vous accompagner plutôt qu’un coach agile ? Autrement dit, quelle stratégie de montée en compétence recommanderais-tu à quelqu’un qui veut se lancer pour de bon dans Scrum et l’agilité ?
J'avais besoin d'experts dans le domaine pour nous accompagner à l'implémenter.
Je voulais une agence qui a de la bouteille, qui vit agile et qui connaît les avantages et les inconvénients de cette méthode. Je cherchais à ce qu’on se trouve en totale immersion.
Par dessus tout, je voulais bosser avec une agence “no-bullshit”. Du coup j’ai appelé Liip.

Création du backlog QoQa4 de 300+ stories

Création du backlog QoQa4 de 300+ stories

Comment se sont passées les premières semaines avec Scrum ?
Au début c’était assez excitant, on avait nos post-its, notre board Jira, on faisait nos rétros/reviews et on pouvait se la raconter en interne : “Regardez on arrive avec une méthode révolutionnaire !” Mais c’est seulement après trois mois qu’on a rencontré nos premiers véritables soucis ; c’est une fois que le projet est 100% agile que tu comprends ce que veut dire agile.

Combien de sprints a-t-il fallu pour que tu te rendes compte de l’impact et de la réelle valeur ajoutée de Scrum ?
C’est difficile à dire...je dirais aux alentours de 4 sprints (i.e. 8 semaines) pour la communication et l’échange entre les équipes. Par contre bien plus en terme projet, je dirais environ une dizaine de sprints de deux semaines chacun.
Les premiers mois furent très difficiles car on n’avait pas compris ce que Scrum et l’agilité demandaient, à savoir faire preuve d’une énorme rigueur, et adopter un vrai changement philosophique (vs. “simplement” faire des sprints).
Concrètement, on a du beaucoup plus échanger, se dire les choses de manière transparente. La hiérarchie aussi en prend un coup.

Comment aurais-tu géré ces premières semaines si tu étais resté avec ton ancien modèle de gestion de projet ?
C’est simple, je n’aurais tout simplement plus de job ;)
J’aurais fait un magnifique planning, j’aurais découpé mes tâches, et j’aurais attribué mes tickets. Du coup, peu d’échanges, pas de mise à profit des compétences de tous les membres de l’équipe. Je pense sincèrement que cette méthode nous a permis d’écouter nos utilisateurs, d’analyser leurs vrais besoins, et de s’adapter au fur et à mesure.

Premier meeting d'estimation Scrum

Premier meeting d'estimation Scrum

Comment s’est passé l’adoption de l’Agilité/Scrum en interne ?
Au début, c’était super facile car ça paraissait tendance. Mais c’est quand les premiers problèmes surviennent qu’on se rend compte de la difficulté d’intégrer cette méthodologie. Pourquoi ? Car par exemple, lors de nos premières retros/reviews, on a dû se parler en toute transparence ; cela paraît ridicule mais ça change tout.
On n’avait plus de titres mais des rôles à jouer, alors la hiérarchie est rapidement mise de côté au profit de l’échange. On est passés par des périodes difficiles car le projet sur lequel on a démarré est simplement le plus gros de projet de QoQa de ces dix dernières années. Pression, choix à faire, décisions à prendre, implication de plusieurs départements, merci à la méthode qui nous a obligés à rester calme, à partager nos problèmes, et à trouver des solutions ensemble.
Et je dois dire qu’on a eu la GRANDE chance d’être soutenu par la Direction, enfin par la Loutre in Chief qui nous a fait confiance.

Je dois avouer que les débuts furent plus que difficiles, j’avais la sensation de griller du cash en meeting. Le rôle du PO n’est pas simple car on a le budget en tête et un planning que le business attend avec impatience. Alors moi qui suis un impulsif, j’ai vraiment eu la sensation de bosser avec une méthode à la mode. Mais là encore, grâce au soutien, j’y ai cru, j’ai changé ma façon de penser, et aujourd’hui j’en suis heureux. Il faut laisser le temps que tout se mette en place, faire confiance, garder la rigueur, et se faire épauler.

Si tu ne devais citer qu’une valeur ajoutée que Scrum a apporté à QoQa dans son ensemble, qu’est-ce que ça serait ?
La COMMUNICATION !
Sans déc, c’est incroyable les silos que ça a fait péter. Même les gars de la logistique ont adopté des outils de Scrum avec des meetings courts de synchronisation chaque matin

L'équipe cross-fonctionnelle QoQa-Liip

L'équipe cross-fonctionnelle QoQa-Liip — incluant développeurs, POs, et designers

Si tu ne devais citer qu’une valeur ajoutée que Scrum a apporté à toi le PO, qu’est-ce que ça serait ?
Apprendre à couper dans le gras ! Autrement dit savoir mettre des priorités et ne pas partir la tête dans le guidon en se disant que tout est indispensable.

Qu’est-ce que tu penses de la qualité délivrée par un projet en mode agile (i.e. la correspondance entre besoins utilisateurs et le produit développé) comparé à un projet en mode “waterfall” ?
Alors c’est tout simplement différent. Avant c’était moi le pro du web et je savais mieux ce dont l’utilisateur avait besoin. Maintenant, c’est l’utilisateur qui dicte mon métier. On y va étape par étape, on commence par le minimum, on analyse, on implique tous les acteurs. Toutes ces discussions font que tu économies du temps de production car tu testes, tu récoltes des infos du terrain, et seulement après tu construis par dessus. C’est fini la belle époque où on se disait “Je sais une année avant ce qu’il te faudra”.

Est-ce que Scrum a solutionné tous tes problèmes ? Si non, qu’est-ce que ça ne couvre pas ?
J’ai envie de dire OUI — ce que je ne disais pas il y a deux ans — même si on a encore beaucoup à expérimenter. Ce qui est vraiment cool c’est qu’on a un scénario agréable avec un gros projet en interne sur lequel on peut réellement prendre le temps d’itérer, et non juste se contenter de lancer des fonctionnalités l’une à la suite de l’autre.

Combien de sprints avez-vous fait jusqu’à maintenant ?
69 ;)

Rétrospectivement (on est agile après tout), quelles sont les raisons qui font qu’après une soixantaine de sprints vous n’étiez toujours pas en production au printemps dernier ? Et qu’est-ce que tu ferais différemment aujourd’hui avec les connaissances que tu as acquises ?
On aurait dû couper dans le gras. On a fait la pire des erreurs de vouloir tout, tout de suite, et en mieux qu’avant.

Quid de la visibilité ? Mieux ? Moins bonne ? Niveau planning ?
Ce fut mon principal problème quand on a commencé l’intégration de l’agilité, avec tout le monde qui venait me dire “Alors on lance quand ces nouvelles plateformes ?”
J’ai dû geler le business pendant plus de deux ans, donc la question était tout à fait prévisible et je devais pouvoir y répondre. Mais au début, je n’en avais aucune idée avec notre backlog long comme le bras.
Grâce à Liip et leur méthodologie, j’ai pu finalement avoir ma réponse après ce qu’ils appellent une “speed estim”. En gros, on a pris les 300+ User Stories du backlog, et on les a estimé en moins de 3h30. C’était incroyable, j’avais enfin de la visibilité pour moi et les parties prenantes au projet.
Par contre, je me suis pris une grosse claque une fois qu’on a eu la somme totale de Story Points. Si je me fiais au estimation, on en avait pour deux fois plus de temps que notre roadmap initiale sur une année… Mais j’ai fini par comprendre qu’encore une fois je voyais trop gros, et que même si ça faisait mal, il fallait encore plus couper dans le gras.

Le meeting de review Scrum amène de la visibilité sur le travail réalisé, et ce chaque deux semaines

Le meeting de review Scrum amène de la visibilité sur le travail réalisé, et ce chaque deux semaines

Quid de la communication au management/reporting en interne ? Toujours Gantt ?
C’est quoi un Gantt !!? Ca répond à ta question ?

Sinon, vous avez eu des changements au niveau scope/business en cours de projet ? Comment les as-tu gérés ?
Yes complètement ! Je dirais que quelques mois avant la mise en production, on a dû faire des choix car il fallait bien se lancer un jour. La méthode permet une telle transparence que ces choix furent pris de manière vraiment cool. Je pense qu’on pourrait encore être en train de développer à l’heure qu’il est, et encore pour quelques années au vu de tout ce qu’on veut faire. Mais non, on s’est lancés à l’eau. Comment ? En gérant nos priorités et qui de mieux placé que nos QoQasiens pour nous dire ce qui leur manquent ? Du coup, pas mal de fonctionnalités abandonnées dans une première version, et on a tellement bien fait !

Niveau priorités des parties prenantes dans le projet, comment as-tu géré ça ? Intégration des besoins du chef, des départements ?
Après avoir défini les grandes lignes du scope de la V1 du projet, on a impliqué tous les utilisateurs par département dans les choix, les priorités, le design, et surtout les testing. Les grands axes eux furent validés lors de nos COPIL. La méthode permet une vision très détaillée de l’avancement du projet, ce qui facilite la prise de décision.
Mais c’est important de souligner qu’après environ 6 mois de projet, on était totalement perdus... On sera prêts dans un an, deux an, trois ans… Aucune idée et je peux vous avouer que je faisais pas le malin, et c’est là qu’il faut faire confiance à la méthode, et rassurer les équipes avec un peu de bullshit…
De nouveau : speed estim, couper dans le gras, se faire accompagner, et elle est belle :)

Quid de la rigueur de l’agilité (oui oui l’agilité c’est beaucoup de rigueur malgré le nom !) chez QoQa qui est plutôt freestyle d’habitude ?
C’est ce qu’on n’avait pas compris au départ : il faut de la rigueur sinon c’est mort. Pour moi qui suis un créatif, la rigueur fut difficile à accepter. Mais maintenant je peux le dire, cette rigueur nous rend plus créatif !!! Mais il faut le vivre pour comprendre.

Pause ping-pong, ou comment allier rigueur et freestyle !

Pause ping-pong, ou comment allier rigueur et freestyle !

Un mot sur les cérémonies Scrum de début de sprint, estim et planning ?
C’est le début d’un projet ou d’une nouvelle itération, alors c’est cool et motivant.
Côté estim, on ne parle plus d’heures de travail, mais de complexité. Ca parait fou mais c’est juste top — ce qui me paraissait irréaliste il y a encore deux ans.

Un mot sur les cérémonies Scrum de fin de sprint, review et rétrospective ?
C’est la fin du projet donc ça dépend du résultat, mais normalement c’est top car il n’y a jamais de surprises. Si surprises, c’est qu’il y a eu une mauvaise communication durant le sprint. C’est un vrai moment d’échanges et de partage. On se dit les choses et on essaie de les améliorer ; c’est dingue mais ça marche ! Au début quand je recevais des post-its rouge, j’avais de la peine à l'accepter... mais aujourd’hui j’adore, on s’améliore sans cesse.

Le meeting de rétrospective Scrum, un élément crucial pour l'amélioration continue

Le meeting de rétrospective Scrum, un élément crucial pour l'amélioration continue

Et le grooming en cours de sprint ? Vous l’utilisez ? Pourquoi ?
Le grooming est essentiel, il peut faire gagner tellement de temps comme on implique l’équipe très tôt dans le processus de création des User Stories. On détaille et on réfléchit ensemble, c’est très créatif. S’il y a un doute, alors la story n’est pas claire et ça nous pousse à être plus précis, et donc éviter les surprises. La boucle est bouclée.

Question finale: Si aujourd’hui tu devais recommencer un projet (pro ou perso d’ailleurs), tu t’y prendrais comment ?
Je débuterai par un Gantt évidemment ;)


Encore un grand merci à Joann d'avoir pris le temps de partager son retour d'expérience.
Chez Liip, ce qu'on retient le plus de cette aventure, c'est que "couper dans le gras" est l'une des clés de la réussite d'un projet.
On se réjouit de continuer à collaborer avec l'équipe des loutres pour échanger sur leurs expérimentations de Scrum.

]]>
Speeding up Composer based deployments on AWS Elastic Beanstalk https://www.liip.ch/en/blog/speeding-up-composer-based-deployments-on-aws-elastic-beanstalk https://www.liip.ch/en/blog/speeding-up-composer-based-deployments-on-aws-elastic-beanstalk Mon, 11 Dec 2017 00:00:00 +0100 Some of our applications are deployed to Amazaon Elastic Beanstalk. They are based on PHP, Symfony and of course use composer for downloading their dependencies. This can take a while, approx. 2 minutes on our application when starting on a fresh instance. This can be annyoingly long, especially when you're upscaling for more instances due to for example a traffic spike.

You could include the vendor directory when you do eb deploy, but then Beanstalk doesn't do a composer install at all anymore, so you have to make sure the local vendor directory has the right dependencies. There's other caveats with doing that, so was not a real solution for us.

Composer cache to the rescue. Sharing the composer cache between instances (with a simple up and download to an s3 bucket) brought the deployment time for composer install down from about 2 minutes to 10 seconds.

For that to work, we have this on a file called .ebextensions/composer.config:

commands:
  01updateComposer:
    command: export COMPOSER_HOME=/root && /usr/bin/composer.phar self-update
  02extractComposerCache:
    command: "aws s3 cp s3://your-bucket/composer-cache.tgz /tmp/composer-cache.tgz && rm -rf /root/cache && tar -C / -xf /tmp/composer-cache.tgz && rm -f /tmp/composer-cache.tgz"
    ignoreErrors: true

container_commands:
  upload_composer_cache:
    command: "tar -C / -czf composer-cache.tgz /root/cache && aws s3 cp composer-cache.tgz s3://your-bucket/ && rm -f composer-cache.tgz"
    leader_only: true
    ignoreErrors: true

option_settings:
  - namespace: aws:elasticbeanstalk:application:environment
    option_name: COMPOSER_HOME
    value: /root

It downloads the composer-cache.tgz on every instance before running composer install and extracts that to /root/cache. And after a new deployment is through, it creates a new tar file from that directory on the "deployment leader" only and uploads that again to S3. Ready for the next deployment or instances.

One caveat we currently didn't solve yet. That .tgz file will grow over time (since it will have old dependencies also in that file). Some process should clear it from time to time or just delete it on S3 when it gets too big. The ignoreErrors options above make sure that the deployment doesn't fail, when that tgz file doesn't exist or is corrupted.

]]>
Liip recognised in the Meilleur du Web awards https://www.liip.ch/en/blog/meilleur-du-web-2017 https://www.liip.ch/en/blog/meilleur-du-web-2017 Thu, 07 Dec 2017 00:00:00 +0100 The Meilleur du Web awards: an unmissable event

The Meilleur du Web awards have rewarded the work of digital agencies in the French speaking part of Switzerland since 2011. The prize shines a spotlight on numerous projects. It is a source of inspiration for businesses in French-speaking Switzerland, and gives companies the opportunity to explore projects in digital communications, e-commerce and performance.
“We are delighted to see our work rewarded! These prizes are a mark of recognition for the teams involved in these projects. It is a celebration of teamwork, which includes our User Experience,Design and Development teams,” explains Laurent Prodon, Product Owner for the tooyoo project.

QoQa: working agile and collaboratively

The collaboration between Liip and QoQa started three years ago. Liip and QoQa worked together closely, particularly to train QoQa’s teams in working agile. QoQa employees spent two months with Liip’s development team in the Lausanne office. Liip shared each stage of its agile methodology, reflecting its commitment to offering long-term support to its client.
The QoQa application won the prizes of the category Technology, Business Efficiency and Mobile.

Tooyoo: sensitive support for bereavement

Tooyoo is a sage, online storage platform, dedicated to secure wills. It uses targeted questionnaires to define its users’ final wishes. Sensitive data are only communicated after the person died.
Tooyoo supports the relatives of deceased persons through the various procedures step by step. Therefore making the administiv process as simple as possible .
Ease of use and security are at the heart of the project. We have implemented a complex encryption system to ensure the security of the data transmitted. Using tests and methods such as empathy maps, we have worked in stages using a user-centred approach.
Our tooyoo project reaches the finals in the category Technology.

]]>
Shapefiles - Of avalanches and ibexes https://www.liip.ch/en/blog/shapefiles-of-avalanches-and-ibexes https://www.liip.ch/en/blog/shapefiles-of-avalanches-and-ibexes Wed, 06 Dec 2017 00:00:00 +0100 At Liip, we recently completed an application for architecture students that uses shapefiles as its backbone data to deliver information about building plots in the city of Zurich. They are displayed on a map and can be inspected by the user. A similar project was done by a student team, of which I was part, for the FHNW HT project track: A fun-to-use web application that teaches children in primary school about their commune.

But not only can shapefiles help to enhance the user experience, they also contain data, that, when brought into context, can yield some interesting insight. So let's see, what I can find out by digging into some shapefiles and building a small app to explore them.

In this blog post, I'm taking a practical approach to working with shapefiles and show you how you can get started working with them as well!

Alpine Convention

The first hurdles of working with shapefiles are understanding what they actually are and acquiring them in the first place.

Shapefiles are binary files that contain geographical data. They usually come in groups of at least 3 different files that all have the same name, their only difference is their file ending: .shp, .shx and .dbf. However, a complete data set can contain many more files. The data format was developed by Esri and introduced in the early 1990s. Shapefiles contain so called features, some geometrical shape with its metadata. A feature could be a point (single X/Y coordinates) and a text of what this point is. Or a polygon, consisting of several X/Y points, a single line, a multi-line, etc.

To acquire some shapefiles to work with, I have a look at OpenData.swiss. OpenData offers a total of 102 (as of November 2017) different shapefile data sets. I only need to download and start to work with them. For this example, I chose a rather small shapefile: Alpine convention consisting of the perimeters of the Alpine Convention in Switzerland.

Since these files are binaries and I cannot look at them in some text editor, I need some tool to have a look at what I just downloaded.

Introducing QGIS - A Free and Open Source Geographic Information System

QGIS is an extensive solution for all kinds of GIS. It can be downloaded and installed for free, has a lot of plugins and an active community. I'm going to use it to have a look at my previously downloaded shapefile.

For this example, I installed QGIS with the OpenLayers plugin. This is what it looks like, when started up:

1blank

To get some reference on where I actually am and where my data goes, I add OpenStreetMap as a layer. I also pan and zoom the map, so I have Switzerland in focus.

2osmlayer

The next step would be to actually open the shapefile, so QGIS can display it on top of the map. For that I can simply double-click the .shp file in the file browser on the left.

3alpineconvention

This view already gives me some information about the shapefile I'm dealing with, on what area it covers, and how many features there are. The Alpine Convention shapefile seems to only consist of one feature, a big polygon, which is enough, given that it only shows the perimeters of the Alpine Convention in Switzerland.

To see, what areas and/or details it covers, I can alter the style of the layer, making it transparent. I also zoom in more, to see if the shape is accurate. Its edges should exactly cover the Swiss borders.

4layerstyle

Marvelous. Now that I've seen the shape of the feature, I'll have a look at the metadata the shapefile offers. They can be inspected by opening the attributes table of the shapefile in the bottom left browser.

5attributetable

This file also doesn't offer much metadata, but now I can see that there's actually two features in there. Anyways, there might be more interesting shapefiles out there to work with.

But I'm going to stick with the alpine topic.

Of avalanches and ibexes

Digging through OpenData's shapefile repository a bit more, I found two more shapefiles that could potentially yield interesting data: The distribution of ibex colonies and the state of natural hazard mapping by communes for avalanches.

As awesome as QGIS is for examining the data at hand, I want to build my own explorer, maybe even built upon multiple shapefiles and in my own design. For this, there's multiple libraries for all kinds of languages. For web development, the three most interesting ones would be for PHP, Python and JavaScript.

For my example, I'll build a small frontend application in JavaScript to display my three shapefiles: The alpine convention, the ibex colonies and the avalanche mapping. For this I'm going to use a JavaScript package simply called "shapefile" and leafletjs to display the polygons from the features. But first things first.

Reading out the features

Disclaimer: The following code examples are using ES6 and imply a webpack/babel setup. They're not exactly copy/paste-able, but they show how to work with the tools at hand.

First, I try to load the alpine convention shapefile and log it into the console. The shapefile package mentioned above comes with two examples in the README, so for simplicity, I just roll with this approach:

import { open } from 'shapefile'

open('assets/shapefiles/alpine-convention/shapefile.shp').then(source => {
  source.read().then(function apply (result) { // Read feature from the shapefile
    if (result.done) { // If there's no features left, abort
      return
    }

    console.log(result)

    return source.read().then(apply) // Iterate over result
  })
})
log1

Works like a charm! This yields the two features of the shapefile in the console. What I see here already, is that the properties of each feature, normally stored in separate files, are already included in the feature. This is the result of the library fetching both files and processing them together:

log2

Now I have a look at the coordinates that are attached to the first feature. The first thing that occurs is that there's two different arrays, implying two different sets of coordinates, but I'm going to ignore the second one for now.

log3

And there's the first pitfall. These coordinates look nothing like WGS84 (Latitude/Longitude), but rather something different. Coordinates in WGS84 should be some floating point number, ideally starting with 47 and 8 for Switzerland, so this shapefile confronted me with a different coordinate reference system (or short: CRS). In order to correctly display the shape on top of a map, or use it with other data, I would want to convert these coordinates to WGS84 first, but in order to do that, I need to figure out, which CRS this shapefile is using. Since this shapefile is coming from the Federal Office for Spatial Development ARE, the CRS used is most likely CH1903(+), aka the "Swiss coordinate system".

So in order to convert that, I need some maths. Searching the web a bit, I can find a JavaScript solution to calculate back and forth between CH1903 and WGS84. But I only need some parts of it, so I copy and alter the code a bit:

// Inspired by https://raw.githubusercontent.com/ValentinMinder/Swisstopo-WGS84-LV03/master/scripts/js/wgs84_ch1903.js

/**
 * Converts CH1903(+) to Latitude
 * @param y
 * @param x
 * @return {number}
 * @constructor
 */
const CHtoWGSlat = (y, x) => {
  // Converts military to civil and to unit = 1000km
  // Auxiliary values (% Bern)
  const yAux = (y - 600000) / 1000000
  const xAux = (x - 200000) / 1000000

  // Process lat
  const lat = 16.9023892 +
    (3.238272 * xAux) -
    (0.270978 * Math.pow(yAux, 2)) -
    (0.002528 * Math.pow(xAux, 2)) -
    (0.0447 * Math.pow(yAux, 2) * xAux) -
    (0.0140 * Math.pow(xAux, 3))

  // Unit 10000" to 1" and converts seconds to degrees (dec)
  return lat * 100 / 36
}

/**
 * Converts CH1903(+) to Longitude
 * @param y
 * @param x
 * @return {number}
 * @constructor
 */
const CHtoWGSlng = (y, x) => {
  // Auxiliary values (% Bern)
  const yAux = (y - 600000) / 1000000
  const xAux = (x - 200000) / 1000000

  // Process lng
  const lng = 2.6779094 +
    (4.728982 * yAux) +
    (0.791484 * yAux * xAux) +
    (0.1306 * yAux * Math.pow(xAux, 2)) -
    (0.0436 * Math.pow(yAux, 3))

  // Unit 10000" to 1 " and converts seconds to degrees (dec)
  return lng * 100 / 36
}

/**
 * Convert CH1903(+) to WGS84 (Latitude/Longitude)
 * @param y
 * @param x
 */
export default (y, x) => [
  CHtoWGSlat(y, x),
  CHtoWGSlng(y, x)
]

And this I can now use in my main app:

import { open } from 'shapefile'
import ch1903ToWgs from './js/ch1903ToWgs'

open('assets/shapefiles/alpine-convention/shapefile.shp').then(source => {
  source.read().then(function apply (result) { // Read feature from the shapefile
    if (result.done) { // If there's no features left, abort
      return
    }

    // Convert CH1903 to WGS84
    const coords = result.value.geometry.coordinates[0].map(coordPair => {
      return ch1903ToWgs(coordPair[0], coordPair[1])
    })

    console.log(coords)

    return source.read().then(apply) // Iterate over result
  })
})

Which yields the following adjusted coordinates:

log4

A lot better. Now I'll throw them on top of a map, so I have something I can actually look at.

Making things visible

For that, I add leaflet to the app together with the Positron (lite) tiles from CartoDB. The Positron (lite) theme is light grey/white, which provides a good contrast to the features I'm going to display over them. OpenStreetMap is awesome, but too colourful, so the polygons are not visible enough.

import leaflet from 'leaflet'
import { open } from 'shapefile'
import ch1903ToWgs from './js/ch1903ToWgs'

/**
 * Add the map
 */
const map = new leaflet.Map(document.querySelector('#map'), {
  zoomControl: false, // Disable default one to re-add custom one
}).setView([46.8182, 8.2275], 9) // Show Switzerland by default

// Move zoom control to bottom right corner
map.addControl(leaflet.control.zoom({position: 'bottomright'}))

// Add the tiles
const tileLayer = new leaflet.TileLayer('//cartodb-basemaps-{s}.global.ssl.fastly.net/light_all/{z}/{x}/{y}.png', {
  minZoom: 9,
  maxZoom: 20,
  attribution: '© CartoDB basemaps'
}).addTo(map)

map.addLayer(tileLayer)

/**
 * Process the shapefile
 */
open('assets/shapefiles/alpine-convention/shapefile.shp').then(source => {
  source.read().then(function apply (result) { // Read feature from the shapefile
    if (result.done) { // If there's no features left, abort
      return
    }

    // Convert CH1903 to WGS84
    const coords = result.value.geometry.coordinates[0].map(coordPair => {
      return ch1903ToWgs(coordPair[0], coordPair[1])
    })

    console.log(coords)

    return source.read().then(apply) // Iterate over result
  })
})

This already shows me a nice looking map I can work with:

map1

The next step step is to hook up the map with the shapefile loading. For this, I create leaflet polygons out of the coordinates I transformed to WGS84 earlier:

// ...

// Convert CH1903 to WGS84
const coords = result.value.geometry.coordinates[0].map(coordPair => {
  return ch1903ToWgs(coordPair[0], coordPair[1])
})

const leafletPolygon = new leaflet.Polygon(coords, {
  weight: 0.5,
  color: '#757575',
  fillOpacity: 0.3,
  opcacity: 0.3,
})

leafletPolygon.addTo(map)

// ...

And I have a look at the result:

map2

Nice!

The end result

With some more UI and adding a toggle for the the multiple shapefiles, I downloaded earlier, I can build a little app that shows me the hazard zones for avalanches and where in Switzerland ibexes are living:

map3

We can see the two shapefiles in action: The light green, green, yellow and red polygons are communes with some hazard of avalanches (light green = low, green = mid-low, yellow = mid, red = high), the darker polygons on top are the ibex colonies.

This map already gives a good insight on the behaviour of ibexes: apparently they're living in low-hazard to mid-low-hazard zones for avalanches only. They also tend to avoid mid-hazard and high-hazard zones. Since ibexes prefer alpine terrain and such terrain usually bears some danger of avalanches, this is plausible, but now I've got some visible data to actually support this claim!

The finished app can be found in action here, its source code can be found in this repository.

The pitfalls

Although shapefiles are a mighty way to handle GIS data, there's some pitfalls to avoid. One I've already mentioned is an unexpected CRS. In most cases, it can be identified at the point of usage, but checking, which CRS a shapefile uses when inspecting it, is recommended. The second big pitfall is the size of the shapefiles. When using some shapefiles with JavaScript in the browser directly, the browser might crash while trying to handle the huge amount of polygons. There's several solutions, though: One can either simplify the shapefile by removing unnecessary polygons or pre-process it and store its polygons in some kind of database and only query the polygons currently in sight.

Takeaway thoughts

Personally, I love working with shapefiles. There's a lot of use cases for them and exploring the data they hold is something really exciting. Even though there might be a pitfall or two, in general it's a bliss, as one can get something up and running with little effort. The OpenData community is using shapefiles quite a lot, so it is a well established standard and there's a lot of libraries and tools out there that make working with shapefiles as awesome as it is.

]]>
The road ahead for iterative practices in Swiss government https://www.liip.ch/en/blog/iterative-practices-for-government-the-road-ahead-in-switzerland https://www.liip.ch/en/blog/iterative-practices-for-government-the-road-ahead-in-switzerland Tue, 05 Dec 2017 00:00:00 +0100 When I say ‹relevant›, I mean those government processes, regulations and laws which have got relevance for drafting, procuring, building and running government digital services. And which in that respect probably are generating uncertainty, if iterative methods can be applied without violating existing processes or laws.

Why government can[not] build digital services iteratively

I wrote a thesis on the topic, and tried to condense my findings in a 20 minutes’ presentation as a PDF on speakerdeck, and as a Google-Presentation, which includes my speaker notes, too.

dna-of-government-and-iterative-methods

My thesis got accepted, but I will invest some time until the end of 2017 to revise it, before it is going to be published in early 2018. I will add it to this blogpost, when it's ready.

What is your experience with iterating in government?

I am thankful for any feedback on the topic. Please get in contact with me via the following channels:

]]>
Informatik in der Sekundarschule - ein Trugschluss? https://www.liip.ch/en/blog/informatik-in-der-sekundarschule-ein-trugschluss https://www.liip.ch/en/blog/informatik-in-der-sekundarschule-ein-trugschluss Tue, 05 Dec 2017 00:00:00 +0100 Erfahrungsbericht von Tim Keller - Lernender der Liip AG
Als ich zu Beginn des dritten Sekundarschuljahres in unserem Wahlfachangebot Informatik sah, erhoffte ich mir, viel zu lernen. Weil ich eine Informatikerlehre plante, meldete ich mich direkt an.

Im Gespräch mit Freunden erfuhr ich, dass es nichts mit Informatik, wie ich es mir vorstelle, zu tun hat: gelehrt wird die Formatierung irgendwelcher Word Dokumente. Dass ich mich gegen dieses Fach entschied, ist selbstredend. Was aber muss eine Sekundarschule den Schülern bieten, um sie im Fach Informatik für die Zukunft zu rüsten?

Die Grundlagen meiner Generation
Im Informatikunterricht der Oberstufe lernen wir Grundlegendes über Computerbedienung und die Office Programme. Für die Zukunft ist es praktisch, wenn ich weiss, wie ich einen Computer einschalte und mit den Microsoft Office Programmen umgehen kann – zum Beispiel wenn ich eine Kaufmännischen Lehre absolvieren will.

Ich finde den Namen des Faches falsch gewählt. In unserer Generation wachsen alle, die ich kenne, mit Computern auf. Ich habe unzählige Vorträge und Dokumente in Microsoft Word geschrieben – was meine Eltern noch mit Plakaten oder handgeschriebenen Briefen erledigten. Uns hätte zu diesem Zeitpunkt allerdings alle interessiert, mehr über das Internet und das Programmieren zu erfahren.

Kollegen an anderen Schulen bauten im Informatikunterricht eigene Webseiten mit JavaScript Elementen. So etwas hätte auch ich mir gewünscht. Bei uns mussten die Schüler lernen wie der Zeilenabstand in einem Word Dokument um einen Millimeter vergrössert werden kann. Zusätzlich gab es auch noch Prüfungen, welche grosse Vorbereitung erforderten.

Bereit fürs Berufsleben?
Als ich meine Lehre zum Informatiker mit der Fachrichtung Applikationsentwicklung bei Liip begonnen habe, bestätigte sich mein Gedanke, dass unser Schulfach besser „Office Grundkurs“ genannt werden sollte. Oder der Inhalt des Faches grundlegend geändert werden sollte. Seit ich in der Lehre bin, musste ich noch nie in einem Dokument den Zeilenabstand erhöhen oder in einer Excel Tabelle zwei Felder zusammenfügen. Vielmehr arbeite ich an Webseiten und mit verschiedenen CMS und Frameworks.

All diese, doch sehr interessanten Dinge, wurden in unserem Informatikunterricht nicht einmal erwähnt. Dabei wären Grundkenntnisse in verschiedenen Programmier- und Script-Sprachen interessant und nützlich für den Lehrbeginn als Informatiker.

Was ist also mein Anspruch an die Sekundarschulen?
Ich bin der Meinung , dass an meiner Schule zwei verschiedene Wahlfächer angeboten werden sollten. Der Office Grundkurs ist sicher etwas Nützliches, insbesondere wenn man eine kaufmännische Lehre plant und wird Schüler während ihrer gesamten Lehr- und Arbeitszeit helfen . Sei es für Projektarbeiten, Dokumentationen, einen Lebenslauf oder für Präsentationen.

Wenn die Schule jedoch ein Fach Informatik anbietet, sollte es auch Themen der Informatik beinhalten. Dies bedeutet, uns Schülern Einblicke in die Welt der Informatik zu geben. Was mir nicht bekannt war, und ich auch in der Schule nicht erfahren habe, ist, wie abwechslungsreich der Beruf ist. Keiner meiner Mitschüler in der Berufsschule arbeitet an derselben Aufgabe wie ein anderer.

Es sollte schon in der Sekundarschule gezeigt werden, wie viele Möglichkeiten und Weiterbildungswege es in der Informatik gibt. Und zudem würde es uns im Berufsleben sicher nicht schaden, wenn wir schon einmal selber ein paar Zeilen Code geschrieben und vor allem logisch an Probleme herangegangen wären und sie gelöst hätten.

]]>
Happy Birthday PHP 7 https://www.liip.ch/en/blog/happy-birthday-php-7 https://www.liip.ch/en/blog/happy-birthday-php-7 Mon, 04 Dec 2017 00:00:00 +0100 PHP is one of the most used languages at Liip, but also on the internet at large. An update is always a big thing, and a larger one happened when PHP 7 was released on the 3rd of December 2015. With PHP 7 now 2 years old, and version 7.1 slightly older than a year (1st December 2016) and also 7.2 just released on the 30th of November 2017, I found it a good time to have a look back at what PHP 7 has brought to daily work at Liip for my colleagues and me.

I started coding with PHP before the year 2000 when PHP 3 was still a thing and files ended in .php3 as well. With PHP 4 I finally had classes available to me, something I was familiar with from early Visual Basic days. Though it was a "special" implementation, it did the job well enough. PHP 5 gave real classes into the mix, later adding traits and many more things that today I can't work without in a modern PHP application. The version 5 of the language served a long while as the pinnacle but also spawned a lot of side shows, like HHVM and lots of optimization tools. Already complex applications got even more complex and sometimes more fragile.

Thankfully PHP 7 arrived in late 2015. Its speed improvements came down from the improved Zend Engine 3, which forms the heart of PHP. The potential pitfalls of HHVM incompatibilities no longer plagued me and I still got faster applications, nice.

One of the bigger changes that first took me a bit to get used to and now are second nature, are type hints, of common scalars. Before PHP 7, it was only possible to use classes (and interfaces) as type hints, alongside arrays (though nothing more precise, such as a vector type or something like that). Where I had to write a lot of checks to make sure that the parameter a function got is truly what I want, now the type hint makes sure I get an integer or string, making my code cleaner, easier to understand and less error prone.

Many times already scalar type hints have shown me mistakes and bugs before I even opened a merge request for my code changes. It has also helped with a mindset of being more precise in many instances, making testing more effective and easier to do overall.

And of course there are return type hints too now. With 7.1 improving that even more, I can specify what exactly a function returns. What I had to document in extra blocks before, the function now explains often all just by its signature. I know that I can trust a function to return only one thing and again a lot of checking code goes away.

PHP 7 second year birthday attendees

PHP 7 has made my daily life as a developer better, brought more performance to my customers and makes me hopeful for the even brighter future of the language as a whole.

Thank you PHP and happy birthday!

]]>
Meetup E-Commerce - Chaos im Warenhaus, Nasty Data und flexible Monolithen https://www.liip.ch/en/blog/chaos-im-warenhaus-nasty-data-und-flexible-monolithen-4-meetup-e-commerce https://www.liip.ch/en/blog/chaos-im-warenhaus-nasty-data-und-flexible-monolithen-4-meetup-e-commerce Mon, 27 Nov 2017 00:00:00 +0100 Event Highlights
Die lokale E-Commerce-Community lebt vom regen Austausch miteinander. Um diesen zu unterstützen haben wir Mitte Oktober zu einem weiteren Meetup eingeladen. Rund 40 E-Händler und Interessierte liessen sich in unserer Liip Arena von drei Branchenexperten inspirieren.

Den Auftakt machte Sebastien Pellet von Amazon. Er führte das Publikum in die Welt der Logistik ein. „Die Stellschrauben für das Wachstum bei Amazon sind Kostenstruktur und Customer Experience“, berichtete er „und an beidem kann man im Warehouse Management arbeiten.“ Neben Details zum Thema Shipping Cost Optimization und „Collating“; also der Frage wann genau eine Kundenbestellung bearbeitet werden sollte, erzählte er auch von der scheinbaren Unordnung in den Lagerhäusern von Amazon. Produkte scheinen wahllos an mehreren Orten in der Lagerhalle platziert. Alles mit der Idee, dass sie dadurch schneller auffindbar sind. So reduzieren sich die Kosten der Auftragsabwicklung und die Zeit, bis der Kunde seine Bestellung erhält.

Als nächstes folgte Onedot-CTO Tobias Widmer, der über Produktdaten sprach. Als „small and nasty“ bezeichnete er Produktdaten - im Gegensatz zum Schlagwort „Big data“ das potenzielle Benzin für den stockenden Retail-Motor.Onedot nutzt ein eigenes Data Model, um die Daten für die Auswertung vorzubereiten. Das Startup verwendet zudem “Machine Learning” auf Basis von User Feedback: „Die perfekte Künstliche Intelligenz gibt es nicht – vielleicht noch nicht – aber wir erzielen Ergebnisse mit 70% Accuracy”, meint er.

Den Abschluss bildete die B2B-Marktübersicht unseres Liipers Lukas Smith. „Jedes E-Commerce Projekt sollte mit einem Monolithen beginnen“, erklärt er und verweist auch auf einen weiterführenden Beitrag von Martin Fowler „die Kunst ist nur einen zu finden, der flexibel genug ist, sich einer Veränderung in den Anforderungen oder im Projektumfang anzupassen. Neben den Vorzügen und Nachteilen der aktuellen Anbieter verriet Lukas auch, welches Produkt er am speziellsten findet: Spryker - das sollten E-Händler definitiv im Auge behalten. Seine Gedanken zu verschiedenen anderen Angeboten auf dem Markt findet man auch in seinem Blogbeitrag.

Wir bedanken uns bei den Speakern, allen Teilnehmern und Silvia von Bello Buono für das tolle italienische Catering.

Links zu den Folien der Vortragenden:
Sebastien Pellet: How does Amazon use its logistic to create a competitive advantage?
Tobias Widmer: Automated product data preparation
Lukas Smith: Headless B2B marketplace?

]]>
Liip reaches the finals of the SME Trophy https://www.liip.ch/en/blog/prix-trophee-pme https://www.liip.ch/en/blog/prix-trophee-pme Fri, 24 Nov 2017 00:00:00 +0100 City of Fribourg SME Trophies

“Our businesses are remarkable. We reward them!” That’s the slogan the City of Fribourg used to launch the new SME Trophies in May. The competition aims to reward the dynamic and creative businesses, producing a positive impact on the regional economy and raise their profile.
The applications were assessed on the following criteria: dynamism, creative strength, the business’s sustainability and its roots in the geographical region.

Liip’s commitment

“Here at Liip, we are convinced of the importance of putting down firm, long-term roots in the region. We focus on local partnerships and personal, individual relationships with each of our clients,” explains partner and co-founder Gerhard Andrey. Liip undertakes to train apprentices and support renewable energies and environmentally friendly transportation, for example.
Liip is also committed to motivating working conditions and achieving a positive work-life balance. Among other things, employees benefit from a continuing training budget and options for unpaid leave and part-time working.

Liip and regional roots

Liip’s regional roots are manifested in a variety of ways. For example, the offices are split across five central locations that are easily accessible by public transport. As a result, employees can live close to their workplace, helping to build a close and strong relationship with clients. Education is taken serious through apprenticeships and courses, enhancing technical or commercial knowledge and skills. “We are proud and honoured to have been shortlisted and will continue along a path that so greatly benefits our clients and partners as well as our employees. We warmly congratulate everyone who has taken part in the trophy,” concludes Gerhard Andrey.

trophy-fr]]>