As a reminder our key values are authenticity, accessibility and openness, so let’s put ourselves in openness-mode and have a close look into a recent Swiss blockchain project that was rewarded with the first price of the SRG /SSR Hackdaysin Zurich namely : “Blockchain Reporter” - originally conceived by Marko Nalis who teamed up with a few developers at the event and with whom he elaborated the project during the 13 hours the Hackathon took place.

“306” – in reference to the number of journalist imprisoned in Jan / Feb 2018 worldwide

Introducing his presentation with an intriguing image displaying the number “306”, Marko Nalis explained that this is the number of journalists imprisoned during the two first months of the year only. They are imprisoned in countries where free speech is not granted. Yes there are still a lot of those… ;-(

Starting from the recognition that journalists and reporters are exposed to persecution when personally identified (#1) and considering that they also suffer from a constant reduction of their financial means (#2) in a media landscape where advertising funds erode, the team came up with this cutting-edge blockchain concept : a decentralized peer-to-peer platform that enables journalists and readers to connect directly while injecting value into the ecosystem through tokenization & network effect.

There is more : through the magic touch of decentralized blockchain technology, other features are addressed too:

• anonymity of journalists,
• guarantee of safe payment,
• avoidance of censorship,
• authenticity of publications,
• prevention of fake news
• protection of the platform against arbitrary shut down by a totalitarian government (because decentralization prevents action against a unique IP server ;-).

Removal of the “middleman”

At this stage it’s already amazing to see how blockchain’s decentralization effect (i.e. removing the “middleman” – here the press agency –), simultaneously solves numerous parameters of the equation.
But let’s dive a little deeper into the functioning of the “token economy” (i.e. how publications and rewards are made possible by the community).
Nota Bene: this might become a little technical but we will try to guide you to illustrate the three elements, that are technically bound together to allow all parts to talk/interact.

Part 1 : ever heard of “Smart Contracts”?

Smart Contracts are independent, self-executing pieces of codes that are immutable, not controlled by anyone and can’t be manipulated – unless 51% on the users would own the blockchain – which is most unlikely on popular blockchains like Ethereum and Bitcoin.
Smart Contracts will fulfil some kind of “contract” a given condition is fulfilled once (it’s similar to the principle of IFTTT rules /“if this - then that” attribution rules, but more complex).
Mostly run on Ethereum which supports more opportunities than the Bitcoin blockchain (where you basically can transfer value only), these Smart Contracts don’t belong to somebody and will preserve the anonymity of journalists.

Part 2 : Linking the reference of the Smart Contract to a Public Address.

Let’s say a journalist filmed a given footage and wants to share it on the platform anonymously. Therefore he will use a dedicated android-based APP which allows uploading the content to a decentralized file-system called IPFS (=InterPlanetary File System).
IPFS uses a merkle tree architecture allowing the uploaded content to be split in chunks of data that are distributed on the network. The architecture ensures immutability and no single point of failure. (The blockchain itself not being efficient to store rich content, -due to transaction speed and cost-, it is used solely to publish a reference to the content in a specific Smart Contract).

Inside the Smart Contract the Public Address of a journalist is linked to his content and cryptographically signed. Thanks to the public address, the platform user will always be sure that the content of a given journalist is authentic - without even needing to know his real identity.

PART 3 : a “DAPP” / decentralized APP – linking the platform to Ethereum

Last the system needs a way to allow you “talking” to the Ethereum online wallet of the user/member.
A browser using HTML/ Javascript, adding Web 3 objects through a plug-in called Metamask. Web 3 enables you to make calls to the Ethereum network and call smart contract functions in Javascript. As these interactions with the blockchain will cost (as any open-source system Ethereum needs to be sustained) a small fee called “gas” charged to get the transactions through the network.
The system allows users to donate ether currency to journalists through the smart code. These donations are also used to rate the popularity of journalists : the more donations for a given article, the better is the rating.

Finally, a dedicated Ethereum framework called “Truffle” offers many tools to compile and deploy Smart Contracts and to set-up a test network. Its language is called “Solidity” and can be applied by any developer mastering Javascript, - in theory (although this quickly gets “a little complicated” as Marko Nalis says with a touch of understatement ;-)

In a nutshell – what’s in it for me?

So beyond the technical aspect of this analysis that will rather interest our Full Stack Developers, what innovation brings this “Blockchain Reporter” project?
Blockchain Reporter appears as a real-life use-case designing concrete and applicable value-transferring models in an interesting vertical (the press industry).

It was thrilling and uplifting to see how every parameter of the complex equation inherited its own place in the ecosystem organically (the donation/ranking logic, the token economy, the protection of the journalist). This is definitely a lesson for Liipers as this can help us design or deploy further models in other verticals.
It demonstrated that blockchain technology is not only meant for worldwide corporate companies, but it helps defend human values such a free speech and liberty.

We’re wishing long life and great success to the project “Blockchain Reporter”!

Here is the full LiipTalk from Marko Nalis : youtube.com/watch?v=P2CyfuC5EKA

For further interest about these topics of attribution and valutation of content in the medias, here is an interesting interview from a former journalist from Huffington Post who joined the startup Po.et aiming to create the first globally-verifiable record of digital media assets: https://bit.ly/2FEw2yh

What is a game jam? It's a challenge to create a video game from scratch in a short amount of time. There are a lot of different ones being run; for Ludum Dare you and your team have 72 hours to make and submit your game. Although that may sound impossible, game jams are popular exactly because they force you to be creative instead of dithering about the details of what you want to make.

Ludum Dare

Ludum Dare has been running for fifteen years now, and this was the 39th edition. Thousands of people across the world participated, all creating games on the same theme—which was not announced until the start of the jam. You can always participate at home, but getting together with other jammers is much more fun. It also lets you meet new people and form new teams. That's very necessary, because making a game requires so many different skills.

In Zürich, the local game developers' group Gamespace organises meetups for Ludum Dare, and this was the second time Liip has hosted them. It's much easier to jam if you have a big space where you're not disturbing anyone by spreading out electronics and making weird sounds.

The Jam

We started on Saturday morning with croissants and orange juice and discussed the theme: Running out of power. A good jam theme should have lots of different possible interpretations, and our group discussed running out of computing or graphics power, the Spoon Theory, losing political power, losing magical powers, or having to constantly charge your mobile phone in the game. In the end we split into two groups. One decided to make a story game about coping with depression, and the other started on a platformer about a magical creature giving up their powers to become more human.

The groups got down to business and began writing code and using graphics tablets to make the artwork. Both games were programmed using the Unity engine, a popular choice because of its broad feature set and visual editor.

For the game Dryad, which I worked on with David Stark, we wanted to come up with all our sound effects from scratch. This meant repurposing whatever office supplies we could find in unexpected ways! The sound of sticky tape being pulled off the roll became the sound of a magical spell. Riffling a block of post-its, we got the sound of a crossbow firing a bolt. The noise of triumph when you reach the end of a level comes from a table football trophy being struck!

The Results

By the end of Sunday night, our games were mostly complete and only needed the finishing touches to be submitted on Monday. Both of them are available to play online: Dryad and 03:00 AM. We'll discuss the creation process at a future Gamespace meetup. In the meantime, the games from the Ludum Dare 38 jam (also held at Liip Zürich) are available here:

• Turtle Rider
• Annulus
• Ghost Story
• Herbarium
• Escape from the Bottle

If I talk about a “squads doing Drupal”, then don't think of Developers only, but also of Project Owners, UXers, Business Developers, Designers, Analytics Specialists and so on. With such squads in Zürich and Fribourg, things are done differently. Different sitebuilding, different workflows, different opinions and finally also different projects. This is on the one hand very interesting but on the other hand… weird. Being in the same company, doing the same kind of work but not the same way while not using the same toolbox and processes.

Inter-office knowledge transfer

To give freedom to the different Drupal squads but also profit from the huge knowledge in both offices, we started to have quarterly Hackdays. During these Hackdays, we spend a whole day exchanging and discussing a wide variety of topics. Last Monday, October 10, we had another Drupal Hackday in our new office in Berne:

To have something to talk about (or not waste time), we usually gather possible topics beforehand and vote for them. As an example, this time the following topics were on our list:

• Product owners: The wave model or how we do Jira in Fribourg
• Front-End: Possibilities in Drupal 8, Scalable CSS for Drupal, Styleguide vs. Drupal, Motion design, Browsersync and gulp for Drupal
• Site Building: To Display Suite or not?
• Composer / Drupal Console / Drush / Git and CMI
• Commerce: State of the thing …
• BizDev: Streamline offering process
• Development: Caching (BigPipe, Redis, Varnish etc.)
• Bundrupal: Fixing current issues, working on content types, creating ckeditor styles etc.
• Migrate in Drupal 8: Insights in Migrate 8 with JSON

For sure we could not cover everything in one day. But the next Drupal Hackday is just around the corner. But for this time, the “Pain Points” were quickly addressed. Let's look a bit deeper in my two favourite sessions:

Drupal 8: Share experiences and practices from a bigger project

The main focus was (once again) on Drupal 8 and how to use the “New kids on the Block” like Composer, Drupal Console, Configuration Management and all the other nice things finally available on the Drupal-Island. Furthermore, the experiences and thoughts from a bigger project are worth sharing, as they bring all of us forward. Since the squad in Fribourg did not do a lot of Drupal 8 projects yet, we could profit a lot from the Zürich developers. Uncertainties in terms of setup and workflow could be resolved and the people in Fribourg are (even more) eager to adapt this and maybe also improve on our future stack. The reason why we in Fribourg hesitated adopting those new tools was that we have a very well developed toolbox we use for earlier versions of Drupal. Quite a shift for us, but anyway worth to get our hands dirty with the new fancy stuff available in Drupal 8.

Business Development: Streamline estimations

In another session, the Fribourg squad could share their way of estimating Drupal projects. Since we had some differences in the past, we wanted to make sure we all estimate projects with the same parameters and the same understanding for an estimate. What's included and what's not? What base numbers and options do we have and so on. This session involved almost every role from the squad and was discussed very openly. We could find a way and defined actions to improve right away and to adapt and improve fastly if needed (depending on the needs in each office). A test-estimation round using this tool led us on a fictional project to almost exactly the same number. Surprise for everybody but also a success for the tool. Differences in estimations can be spotted and addressed easily. Together, we found a way to make project estimations easier and if needed even comparable across our offices.

And many more …

So on one side a very heavy developer session (with lots of buzzwords, code and console), on the other side also a “hot” discussion amongst almost all roles with a fair amount of knowledge transfer from Fribourg to Zürich and vice versa.

Besides that, we also talked a lot to each other between the Sessions. Projects, tools, modules, issues and so on. Backends where shown, ideas spread and solutions given. Other Sessions involved Front-End presentations and discussions about living Styleguides. Other people played around with the Drupal 8 Rest API possibilities or tried new possible base themes (like Zen for example).

Sharing is caring and how we improved

When I started at Liip 3 years back, we did not have a lot of communication between the squads doing Drupal. People in Fribourg for sure knew the people doing Drupal in Zürich. There was for sure some communication. But a real “Knowledge transfer” or something similar did not exist at this time.

The situation already improved by switching to Slack instead of mailing lists and Skype. The Slack channel we use to exchange in our Drupal-Guild makes collaboration and knowledge sharing easy and eased the inter-office discussion about problems. The Hackdays in addition are a very good possibility to visit other offices and to see each other in person. My impression is, that everybody really enjoys these days and many people are very passionate about Drupal and to show what has been done or can be done to improve even more.

The existence of those independent Drupal squads is from my point of view very valuable. Every squad can do their way of working and with the Drupal Hackday in place, we exchange our experiences like different companies would do. I think this is no disadvantage at all and helps us to adapt the good ideas and practices for each squad in whatever office individually.

I'm very much looking forward to the next Drupal Hackdays. Even if the Drupal Hackdays are mainly an “Internal” thing, we also welcome customers and other people interested in Drupal. So if you want to join a Hackday or if you're curious if Drupal is the right tool for you, drop us a line and we will show you how we do Drupal @ Liip!