In the last four months I did not produce much open-source code. I was busy writing my Bachelor Thesis.
But I was active in the community, I attended several conferences, I read a lot of stuff and I wrote down a lot more things to do.
One of these things was “learn Rust”, as you might figure (and writing more).
Well, I submitted my thesis on Monday and went on to write some actual Rust code.
So I created lzf-rs, a wrapper around LibLZF, a super small and fast compression library, originally written by Marc Lehmann.
LibLZF consists of just 4 files and is super-easy to compile as a small library.
LibLZF itself is used by Redis for compressing strings in the RDB,
that’s how I got to know it. I still don’t know how it works, but I want to learn it now (and maybe port the whole code to Rust instead of using a wrapper around the C library?)
I used Rust’s Foreign Function Interface to write the wrapper. Accessing C code from within Rust is quite simple.
The hard part is choosing the right data types and writing the API in a safe and usable way.
I’m not 100% happy with the current API of lzf-rs, so expect it to change.
I’m still in the process of figuring out what to expose and what not.
And now, enough of the talking. This is how to use the library:
Last week I had the opportunity to spend a long weekend in the beautiful capital of Germany for jsfest.berlin.
What should I say? It was amazing.
After eurucamp set quite a basis for “great conference”,
reject.js and jsconfeu had no easy start, but the people, the organization, the venue and the talks totally made up for the less good weather.
From sleep-hacking over making music and animations to making gifs even more awesome. Oh, and some stuff others would consider more useful in work life too.
The only downside was that I in fact didn’t really have time for a whole 4 days off, so I wasn’t too focused on the reject.js talks and I might have missed good things from it :(
Nick built himself a nice smart home powered by node.js, with automatic light dimming for an even better sleep. Definitely an interesting topic, though his setup isn’t the cheapest one.
Stefanie built a prototype of a Location-based Pokémon game. There’s an online Pokédex you can use if you want to do something similar: Pokéapi - The Pokémon RESTful API.
For jsconfeu I was more focused and I tried to take at least a few notes per talk to remember all the stuff I heard. I did manage to tweet a photo of each talk I attended, so if you’re into that check my twitter stream from Saturday and Sunday.
Following are a few short notes per talk.
After a nice intro (wait for the videos),
Jake Archibald started with The ServiceWorker is coming; look busy. With this new addition to the browser stack web app can finally easily compete with native apps when it comes to notifications, background sync and offline-first. Definitely worth a watch.
The talk was followed by We Will All Be Game Programmers from Hunter Loftis. Today’s apps use a lot of the ideas that were used in games years ago, maybe we should have a look at game developing techniques and tooling a bit more to see what’s relevant for modern web app programming.
Sitting nice and comfy at beanbag.js I watched Supercharging Node with Kraken from Tim. PayPal transitioned most of their apps from a C++/Java-stack over to node.js, replacing apps one by one. They now have smaller teams, are able to more quickly adopt the apps as needed. They also make heavy use of npm together with a company-internal package registry to distribute common modules for security, logging, monitoring and other things.
After skipping two talks, James Coglan entered the stage with Practical functional programming: pick two. I followed his twitter stream in the past weeks where he already shared lots of his research and learning. Functional programming is quite an interesting topic with lots of good ideas (ooooh, what would I give to have immutability in my thesis project right now). James showed how even just a few functional ideas can make code a lot easier to reason about. Recommended watch! The slides are online.
Raul Fraile followed with How GZIP compression works. He explained the basic principles behind compression and GZIP. It’s not really my topic though.
Michael Donohoe talked about how to Deep-link to Anything on the Web. Working as a developer for journalistic sites he implemented multiple solutions to help linking to sections of an article, annotating it as needed and how to combine that with the backend.
After another coffee break (there were a lot coffee breaks that weekend)
Mathieu Henri showed Monster Audio-Visual demos in a TCP packet, a short introduction into the demo scene and the techniques he uses to build demos in as few bytes as possible. I wish I was more creative with visuals and audio.
Day 2 began early, far too early as the party the evening before was long into the night (well, and maybe I had one or two gin tonic).
Still a little hangover I sat down at beanbag.js and watched Got make? by Rob Ashton. His live-demo talk was a little bit confusing.
What followed next (after one round of skipped talks) was Lena Reinhard’s talk This is bigger than us: Building a future for Open Source. WATCH IT! It’s worth it! Slides and notes are on speakerdeck.
Sebastien Cevey followed up with Server-less applications powered by Web Components. He combined web components to build up a dashboard showing stats from his servers at work.
Sebastian Markbage from Facebook talked about Minimal API Surface Area - Learning patterns instead of frameworks. We should focus less on complete framework solutions and instead rely on reusable patterns. That’s exactly what they try to focus on in React.
What followed was The Linguistic Relativity of Programming Languages by Jenna Zeigen. We are heavily influenced by the programming languages and tools we use. From time to time we should look at different paradigms, different programming languages, different tools simply to broaden our view and to get new and better ideas how to solve problems, even if we then come back to our main programming language.
Again from the comfy of beanbag.js, I watched Realtime in the browser using XMPP by Lloyd Watkin. He thinks XMPP “allows us to easily rebuild the decentralized web”. Slides are online.
Coming to an end, the organizers held back two really good talks:
The first one was GIFs vs Web Components. Glen Maddern implemented a library to control GIFs in every imaginable way. Born was the <x-gif> tag. See for yourself.
Followed by Know Your /’s in which Lindsay Eyink gave an overview over the early history of Silicon Valley. I can’t properly summarize it myself, so go watch the video when it is available.
The day was then coming to an end at yet another party, this time on a boat!
There are photos of the conference and the parties on flickr. More to come for sure.
The videos should be available on YouTube in the following weeks, I will probably link to them then.
Here’s the full schedule for reject.js and the schedule for jsconfeu.
I had an amazing time and would love to come back next year for a full week of jsfest. Hope I can manage it somehow.
Thanks to the organizers of both conferences, thanks to all the awesome speakers, thanks for the people I met and talked too. Thanks to all attendees for making both these conferences such a joy!
Special thanks to Ola and Hendrik, who made it possible for me to attend the jsconfeu in the first place.
And a shout-out to Jane, for whom this was the very first tech conference. Head over to her blog to read about her experience.
tl;dr: Rust code for the SIMPLE language available in a git-repo.
I had some spare time yesterday after I finished my last-ever bachelor exam (yey!) so I took my chances and started to write some Rust.
Just two days ago I also started to read Tom Stuart’s book “Understanding Computation”.
In Chapter 1, “The Meaning of Programs”, he introduces a small and simple programming language called SIMPLE. By using a small-step approach and Ruby as the language of implementation he builds up the virtual machine to execute an already built AST. Go read the first chapter, it’s in the sample (and thus free) to get a better idea.
The original code is some simple to understand Ruby, just under 200 lines.
Addition and Multiplication
That’s nearly all it takes for a programming language.
Usage of the Ruby code looks like this:
Because we build the AST by ourself instead of taking a lexer/parser to do the job, the example takes a bit more code than you would think.
But it still is simple enough to grasp.
Now the same small sample “programm” in Rust:
letmutenv=HashMap::new();env.insert("y".to_string(),number!(1));letmutm=Machine::new(sequence!(assign!("x",number!(3)),assign!("res",add!(add!(number!(38),variable!("x")),variable!("y")))),env);m.run();// Add this point `res` in the HashMap will be `Number(42)`
Yep, not much of a difference. It will even output the same steps as above (but without the environment hash).
The full code is available in a git repository.
I don’t want to explain each and every peace of that code, but instead focus on what I learned about Rust.
Use the docs
There are API docs as well as a Reference Manual and even more general documentation
(all links are the nightly versions as I use that).
But Rust is in active development. Things are changing fast. Documentation on features might be outdated (especially older blog posts or StackOverflow answers) or even missing (but it gets better with Steven Klabnik working full-time at it).
Get familiar with the Standard Library and its docs. Often you need to read that to fully understand how to use a certain data structure or how to implement a specific trait for your code.
Document your code. Rust makes that real easy. Comments are parsed as markdown (you know that already, don’t you?) and rustdoc generates a static HTML site from your code (all the API docs are generated this way).
Don’t fear the errors
The error and warning messages of the Rust compiler are great. Most often they actually find simple mistakes (wrong variable name, missing self) and actually tell you how to fix it.
Other times, even though the message is quite clear, it’s not clear how to properly fix your code to compile.
But when it compiles, it actually did what I wanted it to do.
Most of my errors or “design mistakes” were caught by the explicit type system and safeness checks.
Everytime I googled an error message I ended up in the GitHub issue tracker of Rust. Sometimes this helped as it clearly discussed the problem and gave useful answers.
Test your stuff
Rust comes with in-built test support. Simply tag code with #[test] and it will only be compiled and run if you pass the --test flag to the compiler (or use cargo test).
It was the first time that I actually ended up doing TDD: First a small test, see it fail, fix the code, see the test pass, refactor if needed. Extend tests.
Just super convenient, but make sure to extract your tests in larger code bases (huge files won’t help anyone).
Use language features
Pattern matching is nice. It often saves you one or two more if statements. Just deconstruct your object right in the pattern match.
Macros are a nice addition, too. The pure Rust syntax might be a little bit verbose sometimes, so just save some keystrokes for your convenience and use a short macro (please, don’t over-do it, the docs explicitely say that macros are harder to debug than pure Rust code).
Make sure you’re editor has proper language support, rust.vim worked quite good for me and did everything right from the start.
I still need to learn about a few Rust features.
I still don’t know how to properly seperate your stuff in modules and seperate source files
I have no idea about proper pointer borrowing and other safety features
I’ve got no idea how lifetimes work and the syntax is not the best in my opinion (' as the marker to indicate a lifetime name).
Summing it all up
Yes, Rust is more verbose than Ruby. Yes, it’s much more strict than C or Ruby. Yes, it’s not yet ready and changing fast.
But its concepts are nice. More safe and robust code just by more explicit type checks and immutable by default make you think more about the actual application design. They catch errors before you even run the code and make it easy to explicitely state the intent of your code (“code should be self-documenting” ;)).
I don’t see me writing lots of Rust code in the near future, but it certainly helps to once in a while have a look at different systems to learn.
I’m just heading back to Aachen from eurucamp 2014.
And all I can say is: What an awesome conference!
I met a lot of great people, had nice chats with a lot of new people, heard a lot of great and inspiring talks
and had a lot of fun.
Besides the usual stuff you expected at a tech conference. there were also a lot activities happening.
It started with the conference party Friday evening.
Saturday noon was reserved for lots of activities, kayaking on the Griebnitzsee, with a jump into the sea afterwards of course,
a slip’n’slide on the venue’s lawn and some football there as well.
During the talks I took some notes, just to remember things for myself, but I think it’s also a good idea to write these down publicly.
There was also the Camp Compressor, the eurucamp’s own podcast, with interviews of speakers and attendees.
Listen to it to get even more cool discussions and information. (Hint: I was interviewed for Episode 3 ;))
Workshop: How to do Static Analysis Driven Refactoring
Friday afternoon I went to the Workshop How to do Static Analysis Driven Refactoring.
Christophe showed us how a few tools can help to improve and refactor your existing code base. The whole list of tools is listed in a Gist.
He made it clear how these tools lead to better code quality, especially if you’re a small team or even working alone. I will definitely try to use some of them.
In the evening the real conference began with nusco’s keynote.
He told us about how to be a really great developer. There are 3 stages in most things:
Simple, most of the time you can automate this away.
Complicated. You have to think about the problem, but if you’re good you find a solution
Complex. These are the hard and most interesting problems. If you want to be a great developer you need to tackle these. For this you have to always learn.
But it is especially important to don’t just work on problems in one category. No one is a great developer from day one.
Learn everyday. Be a great developer at the end of the day.
Culture Eats Products For Breakfast
Saturday started early. Laura told us how Culture influences your product.
If you already have a project it’s not that easy to get it into a new market in a new country with a complete different culture.
The audience for your product has completely different expectations, the country may have different laws. All these things need to be considered to be successfull.
Let’s build a game with Ruby
Right after that, Rin gave a short live coding session in which she created a
small side-scroller game using Gosu, a 2D game development library.
Quite fun and easy it seems.
It Takes a Village to Make a Programmer
After a short coffee break Michele told us her story. She attended eurucamp last year and
with the help of some great people from the community she managed to switch careers in less than a year.
She encouraged all of us to give back to the community, help other people, mentor people or help people in otherways.
Internet of Dusty Things
Daniel talked about his DIY air purifier. Unhappy with the available proprietary and expensive products he sat down,
purchased the necessary hardware and built a remote-controlled air purifier using
mruby, a lightweight implementation of the Ruby language and some stripped-down libaries.
RubyMotion and Accessibility
One of the best talks for me was the one about Accessibility held by Austin, a blind developer.
He’s using both an iPhone and a Mac, because all of these Apple systems have built-in accessibility features, like Voice Over, the screen reader in iOS and OS X.
He also wrote software for RubyMotion to make accessibility-testing even easier and
showed how easy it is to make iPhone apps more accessible. It’s build in by default anyway,
adding information and labels is already a great improvement for every app. Test these things!
Refactoring Ruby with Monads (or, Monads: The Good Parts)
Tom gave one of the funniest and simplest introduction to Monads I heard.
With just a few lines of Ruby code it’s possible to implement Monads, which are just an “abstract data type”.
The code is available as a gem and on GitHub.
Day 2 once again started early. Frank took a look at what’s in the project’s utils folder, often it’s junk.
The speaker was interviewed in the Camp Compressor, Day One. As I heard that on the train ride to the venue I didn’t listen too much in the talk, sorry!
The Scientific Method of Troubleshooting
Blithe explained how the Scientific Method of Troubleshooting will help in software development as well.
When troubleshooting, sometimes take a step back. Solving each and every problem by googling or looking at StackOverflow won’t help.
Instead think about the problem, try to understand why it happened, how it can be fixed correctly and how to avoid it to happen again.
Document your troubleshooting, improve the documentation of your project so problems that were fixed won’t happen again. And get help!
If you can’t solve the problem alone, talk to others. Sometimes that is all it needs.
The last talk I (really) heard was by Jan. He talked about how all these centralized services are bad in nearly every aspect.
But it’s not only about self-hosting all your stuff (because that’s not an option ever),
it’s also about decentralising our organisations and businesses to make the internet resilient against any kinds of threats again.