From May to October I was busy working on my Bachelor Thesis.
I finally handed it in right on time on the 13th of October. But especially the last 4 weeks were the busiest and hardest of 3 years of studying.
As with everything you do, you have a lot of plans when you start; you make a time schedule, you promise to take notes, you promise to work on it every day.
I broke each and every promise I made before.
Now that I’m done I know that I could have done better and so in the following I will expand on all the things I encountered in these 5 months of work.
The first and most important advice I can give: Start writing from day 1. Whatever you write will probably not end up in the final thesis, your writing doesn’t even need to be on topic, but getting 50 pages written is not an easy task if you don’t train for it.
Writing technical texts is different from a novel or a short blog post. Work on that.
The next thing: buy a paper notebook dedicated for your notes on the thesis topic. I kept mine with me and actually used it. Keeping meeting minutes, tasks to do for the week, simulation results or general ideas (though most of the stuff was added in the last 4 weeks).
Once you know your topic, start the research. That includes finding documentation, papers and whatever seems necessary for your topic.
Make sure to note down your sources immediately. Read papers and summarize them for yourself and discuss them with your supervisor or other students.
Get familiar with scholar.google.com and other paper search sites. Keep bookmarks to sites you visited and might need.
Consider saving them offline just to be safe.
What helped me a lot in understanding the topic and getting ideas how to write about it was explaining it to other people, especially non-tech people.
People without any background in your topic will be absolutely clueless, they can point out missing pieces or inaccurities in your explanations
and they tend to ask the most basic question, which you would otherwise skip (because you know the answer right away).
Of course this won’t help when it comes to the details of your actual topic. For this, find students working on similar topics. Discuss your approach with them.
My supervisor forced us to have a meeting once a week. We were 4 thesis students with the same broader topic.
Even though these meetings tend to be quite long, we often could help each other in nailing down a good solution to an implementation problem.
At the beginning of my thesis I had to hold a talk at the chair introducing my topic and laying out a basic time schedule.
I planned 2 months for the implementation and another 6-8 weeks for the actual writing. In the end I had about 4 weeks for writing, while at the same time I was still chasing bugs in my implementation and kicking of the evaluation runs.
That resulted in really long working days.
My advice: keep track of your time. Note down how long you worked each day and what you did. 12 or more hours working a day don’t help. You get much more done in 8 productive hours, with breaks and some free time in between.
I guess no matter what you do, the last weeks will still be busy. What got me most focussed on the task at hand is the Pomodoro technique. 25 minutes of concentrated work, no distractions, no drinking, no eating, no running around. 5 minutes break. Check Twitter, Facebook, Mails, whatever. Then repeat.
I use this technique for 3 years of studying now, and it also works for coding and writing.
I had to write my thesis in English, but I’m far from a perfect English speaker or writer.
I now know that I should practice much more often (and I try to do that by getting more blog posts out).
Together with the first books on the topic I got from the university library I also got a book on proper technical writing.
This small book had a lot of tips on how to phrase things, on typical mistakes, be it grammar or spelling.
And don’t forget to use spell checking tools. They can catch simple typos, british/american differences and just wrong words.
If you write at a technical university it is not unlikely you will use LaTeX for your thesis.
Make sure to set up your build chain early. You don’t want to deal with weird errors, broken packages and all sorts of layout fuckups 2 days before you need to submit your thesis.
One last important thing: Conferences are awesome. You meet nice people, you learn about a lot of interesting stuff and you most often get great motivation.
But 5 conferences in 2 months, when you should be writing your thesis, might not be the best idea.
I did this. I went to Berlin twice, I was in St. Augustin for a whole weekend and in Cologne for another. I got near to nothing done for the thesis (besides having a great summer :D).
So keep this in mind when planning ahead.
In the end I got my thesis finished and I am now a Bachelor of Science. The last 3 years were a great time and I plan to extend it with atleast another 2 years reaching for a Master’s degree.
In the mid of October I was approached by Packt Publishing asking if
I would be willing to review a newly released eBook called Redis Applied Design Patterns by Arun Chinnachamy.
I agreed to review the 100 page eBook given that I’m free to criticize the book as I see fit.
It took me some time to finish the book, but flights to Salzburg, New York and Honolulu meant enough (offline) time to read everything in detail
and write the review. So here it is.
What is it about?
The book gives an overview of different use cases of Redis.
It is definitely not for beginners, but for people that are already familiar how to setup Redis and how to use it.
The books starts with the basics of a key-value store and how it differs from relational databases.
It then goes on to discuss a wide variety of use cases.
From using Redis as a cache store, using it as the main data store for e-commerce inventories or a comment system
to using it for autosuggestion, real-time analysis and game leaderboards.
Each chapter of the book discusses one of the named use cases, explaining the used Redis commands and
showing code and ideas on how to implement the given system.
The good things
Having different use cases documented and accessible in a concise way is really useful.
The book shows a wide range of these use cases and not only discusses the simplest implementation,
but also tries to give an outlook on further iterations for the given requirements, building a increasingly complex system step by step.
It doesn’t focus on a single aspect of Redis and shows off a lot of the available commands and data types.
Included are explanations of the used commands as they are described on redis.io,
as well as links to the documentation for people that want a deeper understanding.
The included code samples are kept short and are a mix of PHP code, implementing the discussed use case,
and single Redis commands, showing how they work and what values they return.
Even for programmers without knowledge of PHP, it should be possible to understand the implementation and adopt it for the language of choice.
The chapters are short and self-contained and the book is short enough to be read in just one afternoon (it took me longer because I took a lot of notes to come up with this review).
The not so good things
Quickly after I started reading the book I was a bit baffled about the overall text and code quality.
The very first thing I noticed was that some of the code examples used slightly different key names as the describing text itself.
This didn’t block the understanding of the overall concept, but is certainly a thing that needs to be improved.
Slightly off-putting are the code samples itself, especially the ones that are larger than just a couple of lines.
They use an inconsistent code style (CamelCase vs. snake_case in one single line) and could use just a little more explanations here and there
(or the text should refer to lines more directly).
Some code examples are just plain wrong.
The more advanced problem solutions are only briefly mentioned in the text and no code examples are shown.
It is nice to have the used Redis commands explained once, but the book mostly copies the official documentation for this.
It also mentions the time complexity of each command, but nowhere in the book it is explained what O(n) actually means (Big O notation explained in the Wikipedia).
As mentioned, the chapters are mostly independent of each other, which makes it easy to just jump in and read them in whatever order you want.
But as the first 3 chapters explain how things work in Redis, other chapters could easily refer back to them.
Instead latter chapters discuss things again or link only to the online documentation.
One chapter is actually re-implementing the same stuff as in the chapter before.
Plain references between chapters could save this duplication and help the reader to jump between chapters.
I won’t discuss each chapter in detail, but there are two things that I need to mention here.
First, the chapter about an auto-suggest system uses the old approach of using n-grams in Sorted Sets,
but since version 2.8.9 (released in April 2014) Redis has powerful lexicographic commands like ZRANGEBYLEX,
which are not mentioned in the book at all (though I don’t know when the book was written, maybe a future version can include this).
Second, the summary of the last chapter talks about scaling Redis across multiple machines and mentions Sentinel as under development and usable for this, which is just incorrect (for the ones that don’t know: Sentinel is considered stable since 2.8 and is used for monitoring and failover, if you want to shard your data use Redis Cluster).
There are a few other minor incorrect things or explanations that leave out some important details.
If you are already familiar with Redis, these things are obvious, but if you only know the basics and want to read up on possible implementations, the errors and mistakes will misguide you.
This makes it hard to recommend the book as a useful resource on Redis design patterns.
Redis Applied Design Patterns is a short little book explaining different use cases of Redis.
It gives insight into different techniques and implementations of high-level features.
But don’t expect to be a super Redis pro after reading it.
The given examples are only touching the surface and show the most basic implementations.
The book should definitely be revised to fix several issues in quality and correctness.
A more in-depth discussion on more complex implementations and revised examples would make it recommendable,
but at this stage it is not.
In case you want to buy the book anyway, use this link.
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.