jsfest week 2014

(by )

rejectjs banner

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.

The 3 conference days were packed with interesting talks, quite a few parties and great food. JavaScript seems to be quite a nice language (sometimes) and people do awesome stuff with it. 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.

rejectjs badge

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 :(

But the two talks I did attend and where I was attentive where Hacking Sleep with JavaScript by Nick Rowe and Location-based Pokémon with Node.js by Stefanie Taepke.

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.

Day 1

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.

beanbag.js

JavaScript Level 9000 by Christoph Martens explained a lot of low-level stuff in JavaScript. I’m not that into JavaScript yet, so I didn’t take too much from it with me.

Next I watched Mathias Bynens talk about why JavaScript ♥ Unicode. There are quite a few changes how to properly handle Unicode in ECMAScript 6 and also a few libraries to make Unicode usage a lot easier today. Simply look through his notes and slides. For some 💩-humor watch the talk once it is out.

This was then followed by Parallel JavaScript from Jaswanth Sreeram. I’m currently writing my bachelor thesis in the field of high-performance computing and parallel computing, so this seemed quite relevant to me. Turns out: It might actually be relevant. JavaScript can be executed on GPUs to allow for multi-threaded computation. New APIs to make use of this are already in the making and the first implementation landed in Firefox Nightly. Once I’ve got some more time again I will check it out.

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.

party with nerds

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.

Just before the party really began, Tim Pietrusky showed his Nerd Disco. Nice what you can do with a small chip, some LEDs, an Ikea lamp and JavaScript. In fact I still have an LED strip lying around, I should definitely try this.

Day 2

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).

I missed the first talk, but was right on time for Javascript… Torrents… and Mad Science! with Mathias Buus Madsen. I saw his projects before, but I was still amazed at what he did. peerflix, peerwiki and torrent-mount are 3 really cool projects, now if only more legal things would be available via torrent…

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.

In == ? === ??? …#@^% Shirmung Bielefeld explained the small details one needs to know to not get confused when JavaScript once again decides to do type coercion.

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.

Even though I thought I knew a bit about JavaScript What the heck is the event loop anyway? by Philip Roberts explained a bit more to me. He used his tool Loupe (a hack built on hacks and more hacks) to visualize how certain things happen when run in the JavaScript environment. Apart from the topic we also got a good stretch from this talk.

Amy Palamountain showed us the Enemy of the State. Don’t build servers on the client. Slides are online.

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.

Thanks!

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.

<3 <3 <3


Update 21.09.2014:

More things appear online:

first experience with Rust

(by )


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.

It has:

That’s nearly all it takes for a programming language. Usage of the Ruby code looks like this:

>> Machine.new(
    Sequence.new(
      Assign.new(:x, Number.new(3)),
      Assign.new(:res, Add.new(Add.new(Number.new(38), Variable.new(:x)), Variable.new(:y)))
    )
    { :y => Number.new(1) }
  ).run
x = 3; res = 38 + x + y, {:y=>«1»}
do-nothing; res = 38 + x + y, {:y=>«1», :x=>«3»}
res = 38 + x + y, {:y=>«1», :x=>«3»}
res = 38 + 3 + y, {:y=>«1», :x=>«3»}
res = 41 + y, {:y=>«1», :x=>«3»}
res = 41 + 1, {:y=>«1», :x=>«3»}
res = 42, {:y=>«1», :x=>«3»}
do-nothing, {:y=>«1», :x=>«3», :res=>«42»}
=> nil

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:

let mut env = HashMap::new();
env.insert("y".to_string(), number!(1));

let mut m = 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.

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.

eurucamp 2014 - Video & Photos

(by )

Great short video documentation of eurucamp 2014 (by @polarblau):

eurucamp 2014 from Polarblau on Vimeo.

Some photos are uploaded to the eurucamp flickr group.

eurucamp 2014

(by )

eurucamp chalk

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.

Keynote

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:

  1. Simple, most of the time you can automate this away.
  2. Complicated. You have to think about the problem, but if you’re good you find a solution
  3. 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.

rin live-coding a game

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!

taking a brake in the shadow

Griebnitzsee

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.


Lightning Talks

@benlovell: Eurucamp is so awesome that actual lightning ended the lightning talks #ec14
(Twitter, 10:52 PM - 2 Aug 2014)

(That’s all it needs as a comment)

Beautfiul sunset over the venue's lawn

Utils is a Junk Drawer!

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.

Take note!

Såndra gave a short introduction how visual note taking can help to efficiently take notes and later also actually remember what you meant. Now if I could just draw better, but maybe with some practice I can do this better. Oh, and she had the most awesome slides of all talks!

Decentralize ALL THE THINGS

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.

…and that’s it.

The whole weekend ended with some beers at the eurucamp after party, again talking to a lot of different people, and a lot of different topics. I hope there will be a eurucamp 2015, because we’re already planning things for next year.

Thanks to the whole eurucamp team, thanks to all speakers and thanks to all the great attendees! Hope to see some of you at RedFrog Conf in just 2 weeks or at RailsCamp Germany in September.

Extending Redis with Lua packages

(by )

Warning: If you patch your Redis as stated below, you won’t get much support from the Community.
Do not run this in production! You have been warned.


Redis comes with in-built support for Lua scripts. Using eval (or evalsha) it is possible to execute scripts right in the context of the Redis server. Redis provides some guarantees for these Lua scripts: Lua scripts are atomic and do not interfere with other scripts or normal commands. Redis tries its best to provide a sandbox you’re scripts are evaluated in, but it won’t stop you from doing stupid things.

This sandboxed mechanism also means that access to any external resources is not allowed. No IO, no external libraries (except thus already provided) and especially no compiled modules.

But what if you want to use a library anyway? Well, it’s actually not that hard. Three days ago a user came to the IRC channel (#redis on freenode) to ask how to use LGMP, an adapter to the GNU multiple precision arithmetic library, in Redis.

After some fiddling around I provided a solution:

First patch your local Redis checkout with the following patch:

diff --git i/deps/Makefile w/deps/Makefile
index 5a95545..9ec62be 100644
--- i/deps/Makefile
+++ w/deps/Makefile
@@ -58,8 +58,8 @@ ifeq ($(uname_S),SunOS)
  LUA_CFLAGS= -D__C99FEATURES__=1
 endif
 
-LUA_CFLAGS+= -O2 -Wall -DLUA_ANSI $(CFLAGS)
-LUA_LDFLAGS+= $(LDFLAGS)
+LUA_CFLAGS+= -O2 -Wall -DLUA_ANSI -DLUA_USE_DLOPEN $(CFLAGS)
+LUA_LDFLAGS+= -ldl $(LDFLAGS)
 
 lua: .make-prerequisites
  @printf '%b %b\n' $(MAKECOLOR)MAKE$(ENDCOLOR) $(BINCOLOR)$@$(ENDCOLOR)
diff --git i/src/scripting.c w/src/scripting.c
index ef00eed..c7f3735 100644
--- i/src/scripting.c
+++ w/src/scripting.c
@@ -549,10 +549,8 @@ void luaLoadLibraries(lua_State *lua) {
     luaLoadLib(lua, "struct", luaopen_struct);
     luaLoadLib(lua, "cmsgpack", luaopen_cmsgpack);
 
-#if 0 /* Stuff that we don't load currently, for sandboxing concerns. */
     luaLoadLib(lua, LUA_LOADLIBNAME, luaopen_package);
     luaLoadLib(lua, LUA_OSLIBNAME, luaopen_os);
-#endif
 
}
 
 /* Remove a functions that we don't want to expose to the Redis scripting

This makes sure the provided Lua is compiled with support to load modules and it actually enables the package module in the embedded Lua interpreter (it also enables the OS module). The package module will then provide the require method used to load external modules.

Next compile your Redis as usual:

make distclean # Just in case it was compiled before
make

Next, grab a copy of the LGMP files from Wim Couwenberg (Direct link, .tar.bz2, make sure to grab the Lua 5.1 sources). Unpack it to a location, e.g. ~/code/lgmp and compile it:

gcc -O2 -Wall -lgmp -o c-gmp.so lgmp.c -shared -fPIC -L ~/code/redis/deps/lua/src/ -I ~/code/redis/deps/lua/src

Adjust the paths for -L and -I to point to the Lua bundled with Redis.

Once this is done, just start the Redis server (but make sure you do it from the directory with the gmp.lua and c-gmp.so):

~/code/redis/src/redis-server &

Alternatively copy gmp.lua and c-gmp.so to the libraries the following command gives you:

$ ~/code/redis/src/redis-cli eval "return {package.cpath, package.path}" 0
1) "./?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so"
2) "./?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua"

As the last step, use the library:

$ ~/code/redis/src/redis-cli
127.0.0.1:6379> eval "local gmp=require'gmp'; return gmp.version" 0
"6.0.0"
127.0.0.1:6379> eval "local gmp=require'gmp'; local x = gmp.z(123); local y = gmp.z(456); return x:add(y):__tostring()"  0
"579"

And that’s it. That’s how you can load external modules into the embedded Lua interpreter. Again: Do not run this in production! It may break at any time, it may erase your hard drive or kill kittens.

(These instructions are also available in a short Gist.)