Last week Girl Code decided to shake things up a little. Instead of your regular talks only meetup; Ineke, Katja and Kristin organised a hands-on meetup to take place at our HQ in The Hague. After some noodles and a quick intro everybody went on to code their very own game of Tic Tac Toe in MeteorJS. All levels were welcome.
Because MeteorJS is so accessible, it is just the right framework for a workshop suited for all levels. With the right tutorial someone who hasn’t ever coded before can code their first Tic Tac Toe quite easily and get a taste of how much fun programming is. While at the same time, professional developers can easily go deeper and get more familiar with Meteor and code an advanced Tic Tac Toe.
We had a full house and the workshop proved to be so much fun even the first time programmers were behaving like proper nerd developers: everyone was buried in their screen, coding the ultimate Tic Tac Toe and forgot to take care of themselves. The amount of candy bars and drinks we’ve got left is proof of that, lol. Girl Coders at the meetup told us this hands-on meetup was a welcome and a cool alternative to the regular talks-only-meetups. So this is one to get a rerun.
A rerun like on tv and as good as any good old Friends rerun. We want to offer a second chance to everybody who couldn’t make the first Girl Code meets Meteor because it was in The Hague. So this night will be at our Amsterdam office and we hope you all join us there. We also would like to re-invite everybody who did come already and just want to do the workshop again or want to go on with their Tic Tac Toe they’ve coded last week. Whilst enjoying the good company of other Girl Coders and Meteor tutors of course. You can RSVP here: Girl Code meets Meteor Rerun at Q42 Amsterdam.
Learning to code
If you’re just starting out learning to code it can be hard to know where to start. That’s why we made this list with tools and websites which offer ways to learn how to code at home:
Thanks to all the Girl Coders who joined us: you made this night a real success!
Update March 18 2016:
Meanwhile, Girl Code meets Meteor Rerun at Q42 Amsterdam is also behind us. And wow! What a turnout. 50(!) of you joined us for a night of coding. And we have pictures to prove it :-D Thank you all for coming!
You can finish or start the Girl Code meets Meteor Tic Tac Toe tutorial here.
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.
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.
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.