I had the opportunity to run a workshop on the Reactive Extensions library with the Sydney Women Who Code group earlier this year. Rx is something I’m passionate about – it really has the power to change the way you approach your data and application design to open up a lot of possibilities.

This post gives some details about the workshop, but is mostly about the process of creating it and some insights into how it went. The workshop and code are on github if you want to check it out.

Workshops are harder to prepare than talks… but better

I’ve given a couple of Rx talks already, but never felt I’d done a great job of it. Women Who Code mostly run hands on workshops, rather than talks, so it was an opportunity to come at presenting Rx from a different angle. Though it needed a lot more preparation!

Using tweets as an example stream

I wanted to make a workshop around a live stream of tweets. Working with tweet streams gave the the workshop a context that everyone could understand. It’s also something you see a lot of in live tv broadcasts with curated tweet streams and stats on shows such as Q&A, etc.

However, hooking up to a live stream of tweets in the workshop had downsides:

• You need to have a live topic that’s active enough to make for an interesting demo
• Streaming tweets is flaky if your network connection isn’t amazing – Twitter will boot you off the stream if you fall behind in processing
• Adding elements of non-determinism is a good way to make a bad workshop 😉

Curating a useful tweet stream

I decided to record live tweets when I knew there would be heavy traffic. I wanted tweets about the Oscars ceremony, which would have mentions of actors, directors and movies, tweets from celebrities, etc. Or to see if you could spot the moment Madonna fell over at the Baftas just from watching the twitter traffic. But sadly, I was too late for these.

Instead I went for the Cricket World Cup semi final between Australia and India. Less fun than the Oscars, but I was still getting 2000+ tweets per minute during the match – so much that I had to cut the data down for the workshop.

With the recorded tweets, I could replay them as a stream such that it appeared as though the tweets were live. Even further, the replayed stream could be sped up, which helps when people were writing operations that take minutes of tweets at a time.

Designing some interesting exercises

Now I needed to come up with some ideas for what people could do with the stream. There are lots of things you can do with a tweet stream:

• Time based operations – stats on the level of activity, etc
• Grouping operations to look at tweets by hashtag, mentions, location, etc
• Filtering operations to look for interesting tweets – retweets, celebrity tweets, etc
• Combinations of the above to create some really specific scenarios

Coming up with a set of exercises was tricky. They had to be in the goldilocks zone of not too easy and not too hard, otherwise it’d just be wasting people’s time. I wanted each exercise to take about 10 minutes or so, and I wanted people to be able to play with partial solutions, rather than it being a case of it either works or it falls apart.

I went for two sets of exercises – one to give a quick, simple introduction to some of the basic operators, and another to use the tweet stream to build something more interesting. This also gave me a chance to accelerate if people found it easy, or slow down if they found it hard.

So how did it go?

Very well! I was afraid it wouldn’t be clear enough, or that people wouldn’t find the “aha!” moment where things clicked into place. But the group picked it up really well and flew through the exercises.

I got a lot of great questions as people got their heads wrapped around the topic, and some people were asking for more. I had some ideas for some harder tasks included at the end of the workshop, but not as well defined as the main exercises. The questions people asked made me think I should have expanded a couple of them for people who really wanted to dive in.

Some final reflections

• Given Rx’s large learning curve, a working demo helps people get the “why?” quicker than starting with core fundamentals.
• Doing is far better than watching. People picked up a much better understanding of Rx than in the talks I’d given previously, the questions were a lot more in-depth.
• I had to think about how people could make self-progress without waiting for me. I found a lot of helpful resources I hadn’t been aware of.
• Helping someone one-to-one is a lot more successful than hoping everyone is following your slides.
• I wish I’d had more prepared on some deeper topics or examples.
• Rxjs is a good option for teaching – async, callbacks and new libraries are second nature for Javascript devs. Rxjs also avoids the initially confusing type names and generics syntax of Rx.Net, which helps you focus more on what the code does.

It was a great opportunity to show some smart people through a topic I’m really passionate about. Thanks to the Women Who Code Sydney group, and to Daphne, Lucy and Peggy for organising. And lastly, thanks to Daphne for putting in a lot of work and patient suggestions to keep the workshop on the rails 😉