Archive | November 2015

w00tcamp 2015 was een feestje

Afgelopen vrijdag en zaterdag was het weer tijd voor ons jaarlijkse w00tcamp. En het was weer een feestje. Er is niet per se een memo geweest, maar dit jaar stond w00tcamp in het teken van Internet of Things. Wat is er veel hardware gebruikt door alle teams! De resultaten liegen er dan ook niet om: elk team had een tastbare demo. Het kiezen van de winnaar was dus nog best een opgave. Maar de winnaars zijn bekend. Winnaars? Ja, winnaars! Dit jaar hadden we voor het eerst twee prijzen: de winnaar van w00tcamp en de winnaar van een eigen jumpstart. De winnaar van w00tcamp werd door iedereen gekozen, de winnaar van de jumpstart door een heuse vakjury bestaande uit: Martine de Ridder van Business Models Inc., Matt Feigal van Google en natuurlijk Kars Veling van Lesso... Ehhh Q42!

En de winnaar van w00tcamp 2015 is…

image
image

…team SuperSlidePicas! Nu tweet de glijbaan in Q020 niet alleen meer een filmpje van je glijbeurt. Maar kun je ook naar huis met bewijs in de vorm van een foto. Net de Efteling daar aan ’t IJ. Dank jullie wel, Thijs, Mathijs, Tom, Marc, Berend en Karen en gefeliciteerd met de winst!

En de Jumpstartwinnaar is…

image
image
image

…team ABle! En dat verwondert eigenlijk niemand, want wat is dat een mooi project. Echt zo eentje waar je een kras mee op de wereld gaat zetten. Johan, Niels, Vasilis, Thomas, Mark, Guido en Michiel hebben w00tcamp gebruikt om een tool te bouwen voor het gemakkelijk vinden en reserveren van aangepast vervoer voor mindervaliden. Gefeliciteerd ABle, op naar de jumpstart! We houden jullie in de gaten. 

En nu?

Ontstaat er geen leegte. Op het w00tcamp-blog kun je namelijk alles nog even nalezen van de andere teams en we beloven dat we jullie hier op de hoogte gaan houden hoe de teams nu verder gaan na w00tcamp. Hier alvast een voorproefje:

Little Big Pixel is taking over the interwebs!

image
image

Team Little Big Pixel had nog wat energie over zaterdagavond en schreven daarom gelijk een DIY. En niet zomaar eentje. Het staat op de frontpage van het internet: Reddit, met nu al meer dan 4400 upvotes. En het heeft bijna 500K views op Imgur! Gaaf, Jaap, Guus en Ted. Op naar een LED-muur :-)

Oh en wist je trouwens dat Jaap al bijna een miljoen keer bekeken is. Go Jaap!

Advertisements

ProDemos’ BinnenhofCheck: why to go with Meteor when your app has to run partially offline

ProDemos’ BinnenhofCheck app is a connected multiplayer quest for high school students around The Hague’s Binnenhof (the oldest House of Parliament in the world, still in use). While that doesn’t sound particularly extraordinary (ahem), the challenge this project encountered is. We built an interactive game with a crucial sidenote: players have no internet access for a considerable amount of time during the session. Meteor proved to be the perfect answer for a case like this.

No internet?

Yup, no internet. Because, ProDemos’ WiFi reaches to the door of the Binnenhof, but no further. And, because of security regulations that restrict WiFi at the Binnenhof itself, extending the signal wasn’t an option. “What about 4G?”, I hear you thinking. Sure, there’s 4G coverage at the Binnenhof, but giving 30 tablets 4G subscriptions will cost you. Besides, why spend so much when internet connectivity isn’t really a necessity anyway, because the solution can be so simple?

Meteor’s ‘elevator pitch’

Meteor convinced us rather conclusively, during what you can call a literal elevator pitch. Before this app, we built another Meteor app for ProDemos. During that project, the question of whether the app would still function when connection was temporarily lost came up. Remco was kind of sure it would, and tested it by stepping into the elevator. Because of course: the world of elevators is an offline one. And it did! Without internet connectivity he could still use all the app’s functions. In fact, stepping out of the elevator, the app synced automatically with the server again. That is what makes Meteor so powerful in a case like the BinnenhofCheck. Packages like MiniMongo and autopublish make it so that an app fully runs on the client, even when it’s offline. And then it automatically syncs with the server again when connectivity is back – without you having to set it up to do so yourself. That’s valuable time saved  to spend on user experience instead of trying to fix the problem of the lack of internet.

Latency compensation

Writing your code for the client is clean and simple in Meteor. And because every Meteor client has an in-memory database cache, there is no need to manually cache data to dodge slowness in talking to the server, program detailed invalidation messages to every client when data changes or implement individual RPC endpoints.

The server publishes defined sets of data through publications, and the client subscribes to these sets through subscriptions. When the content of these sets change, the server updates them in the client’s cache too. The client code is extremely simplified, by using its cache as a fast local database. Therefore, for reading the subscribed sets of data, no connectivity to the server is needed. This saves time, and makes the app faster. You can easily make your client even snappier by turning subscriptions on and off to control the amount of data kept in cache and manage the network traffic. Turning one off means it will automatically delete all its data from your cache.

So the server automatically updates subscribed data on the client when data on the server changes. The client, as a MiniMongo, does something similar. When data is changed on the client, for example through an action of the user, it automatically sends a message to the server with a request to change it on the server too. The server checks its allow/deny rules, and when all those rules pass, it changes the data and updates the change to other clients with the same subscriptions too. No need for you to code this yourself.

In short, these methods realize latency compensation, which means you can still use the app locally in full function when connectivity is lost and it automatically updates the server when connectivity is back.

You can read about these techniques in more detail here.

Publications and subscriptions in the BinnenhofCheck

For the BinnenhofCheck app, built by Silvy, Jeroen and Remco, this means MongoDB is the database on the server at ProDemos. And the tablets (the clients) function as MiniMongo. At the start of the quest the supervisor creates a group and session in the dashboard of his or her tablet. This group then receives a code, and with this code the students can add themselves to it on their own tablets. Now the quest can begin. During the quest the tablets are offline, but still run the app in full function. Back at ProDemos, connectivity is back and automatically publishes all the changed data by the students to the server to see who has won the quest. After this, the supervisor presses ‘stop’ to end the session: this automatically archives the subscriptions and deletes the data from the caches of the tablets. Clean and ready to start with another group immediately.

Asset manager package

However, data like text is fine, but you don’t want to upload all the images and videos to the clients every single session. That would be a serious waste of time. So we weren’t there yet. We ended up fixing this by creating two different collections on the server. One for all the text, questions and locations (these types of data are small enough in size to quickly upload and delete every session through the publications and subscriptions) and the other one for the images and videos. For this collection we built an asset manager package. Through scheduled tasks, this collection synchronizes with the clients. You can find this asset manager package here.

We really enjoyed building this app in Meteor for ProDemos and are very proud of the result. If it’s up to us, this case proves building an app in Meteor is the simple solution when you’re facing a similar problem with connectivity in your projects.

PS We think a nice future addition would be to add GroundDB.

Jasper reads… Creativity, Inc.

Bookworm Jasper reads because it’s fun. And also because it’s something you can do at your own pace (his pace is fast though, reading every single night). You can let it sink in, understand and learn something new at your own speed. That’s something which can be more difficult with fast podcasts or videos like Ted Talks. Reading is not rare among Q’ers, being stereotypical nerds and all. But Jasper consistently puts inspirational stuff from books into action in his projects. So, that’s why we asked him what he’s read last and what he thinks we can use during our projects. This time it was Catmull’s Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration. You know, the Pixar book.

image

Creativity, Inc.

Pixar is the epitome of creativity. Few would disagree. So when lessons are to be learned about the subject, it’s no surprise you want to do that from someone like its co-founder Ed Catmull. And luckily for you, he wrote a book about it. The book uncovers theories and techniques he has used to build up and preserve Pixar’s creative culture. It also shows how he believes these ideas bring out the best in him and all of Pixar’s employees. A revealing look into story meetings, postmortems and ‘Braintrust’ sessions makes this book a valuable manual for managers and everyone who aspires originality and creativity.

Jasper is always on the lookout for techniques to improve the work and collaboration of his team during projects. He looks for practical tools, but he also looks for tools on the human level: the soft skills. How do you approach each other? Bring your team together? Treat problems? Keep everybody interested and curious for ways to innovate? This is an important theme of ‘Creativity, Inc.’, so it would be no shock he took out some points he will be using at Q.

1. You’re never finished improving

Ok, your last project was an absolute hit. That doesn’t mean you can sit back and relax now. To be and stay successful, you should keep improving. That’s hard. Why should you criticize something that was a success? Why shouldn’t you do it exactly the same next time? To keep improving you have to reinvent the wheel sometimes. Don’t be too proud to question your previous work.  

2. Be truly honest to each other

We should all fight for our project together. That’s why everyone should be able to be truly honest to literally everyone. No matter what your role, reputation and relation to that person is. Be it a customer to a developer and the other way around. Or a programmer to the project manager. In this way you’ll get the most valuable feedback on what you’ve built or designed. Feedback you can really use to get better. An example of when more honesty can be very helpful is during demos to the customer. There’s no bad intent, but when you’re proud of what you’re making, you want to show the customer exactly that. Makes sense. But that also means you can unintentionally hide some issues, to fix later. Be proud, but try to hide nothing. You will lag behind because of it.  

3. A daily ‘daily’ vs. Scrum’s standup

When Pixar is in the process of making a movie, the team meets daily. But not like your normal Scrum standup. This ‘daily’ takes an hour and it’s all about looking at everything what was made the day before with a critical eye. What’s good, what’s not, what’s their next step and what are they going to adjust? So when the team meets they really dive into the material. This is exactly the opposite of daily standups, where you let your team know what you are working on now, but avoid saying anything in-depth. This inspired Jasper to turn it around. Daily standups can be done via Slack, asynchronously, to keep the team in the loop about process. During the moments the team meets in person, it’s all about diving into the material and giving and receiving valuable feedback.

4. Get it, one level deeper than you need

Sure, you can code without knowing how to build a computer. But we’re sure you agree when we say your code will get better when you know how a computer works. And if you want to code HTML and CSS only, you should be able to code some JavaScript too, to fully understand what you’re doing. In short: if you know a little more than you need, your work will be of higher quality. For this reason, Pixar started Pixar University. The first course they offered was a drawing class, not only for its art directors but especially for its programmers and marketers. During a drawing class you learn to look at the world in a specific way, a way that will help to make your work for Pixar better. Therefore, Jasper’s dream is a Q University, with courses on typography, interaction design, code and writing. It will enrich us and our work in a way you can’t imagine until it’s there.

Oh, and also…

…post-mortems. A technique to review your project when it’s finished in order to decide: what are five things you would do exactly the same next time and what are five things you absolutely won’t. It’s a great way to discover a useful plan of action for next time.

…research trips. Pixar for example took the Ratatouille team to Paris for two weeks. Dining at Michelin-starred restaurants, tasting haute cuisine, looking in their kitchens, interviewing cooks and taking pictures. They immersed themselves in this world and this provided them with details they could use in their movie that they wouldn’t be able to without this literal look inside the kitchen.

So these are the lessons Jasper takes from Creativity Inc. and is now incorporating in his current project. We’re curious what he’ll be reading next!

Curious about the book? You can order it here.

Kortste diepte-interview met Lukas

image

Zeg Lukas, je bent wel heel erg aan het multitasken nu. Drie laptops tegelijk!?

“Ik geef vanmiddag samen met Thijs vluchtelingen in Amsterdam een opleiding tot gastdocent voor CodeUur! Microsoft heeft ons daarvoor een boel Surfaces gegeven, dus daar ben ik nu Scratch (scratch.mit.edu) op aan het installeren.”

image
image

Kortste diepte-interview met Sjoerd, Guido en Martin

Hallo? Wat doen jullie, Sjoerd, Guido en Martin?

“We zijn halverwege het bij elkaar coden van een fasttracker/sequencer voor kids. En we beginnen al beats te horen! HMM PSSJ HMM PSSJ”

We had a blast at the Lovies

Pics or it didn’t happen. And oh, how it happened! Yesterday Martin, Kars and Michiel spent the evening in London to pick up our Lovies at The Lovie Awards for Design Museum and 0hn0 together with Sarah and Josephine from Design Museum and Wouter and Martijn from Fabrique. So, here some pics:

image
image
image

And we don’t just have pics, we’ve got video proof too! Enjoy our ‘Declaration of Lovies’:

Q42 @ Border Sessions 2015

image

Time flies when you’re having fun! En dat is dus precies wat de tijd deed de afgelopen twee dagen bij Border Sessions. Alle twee onze LoRa network workshops leverden hele gave nieuwe ideeën op, zoals: Emergency Balls, humanitaire hulp, zwarte markt handel, gezondheids notificaties en Ember Alert. En bij onze http://micr.io/ stand was het ook een feestje.

Thanks Border Sessions!

image
image
image