I had a wonderful time at Ruby On Ice! I gave a talk, that I loved to prepare to formulate the ideas the right way. You’ll see it focuses a lot on the problems, that’s intentional because if we’re not clear on the problems what good is a solution?
(in case you wonder why the first slide is a beer, the talk was given on Sunday Morning as the first talk after the party – welcoming people back was essential as I was a bit afraid not many would show up but they did!)
Tobias Pfeiffer is a clean coder, Full Stack developer, Benchmarker by passion, Rubyist, Elixir fan, learner, teacher and agile crafter by passion. He organizes the Ruby User Group Berlin, maintains Shoes and benchee as well as contributing to a variety of projects while thinking about new ideas to put into code and push boundaries. He loves collaboratively creating just about anything people enjoy. Currently he’s creating wonderful web applications, most recently with Elixir and Phoenix refreshing his perspective on web applications.
I gave my first ever keynote yesterday at Ruby on Ice, which was a lot of fun. A lot of the talk is based on my “Where do Rubyists go?”-survey but also researching and looking into languages. The talk looks into what programming languages Ruby developers learn for work or in their free time, what the major features of those languages are and how that compares to Ruby. What does it tell us about Ruby and our community?
When I was at the excellent Pivorak meetup I had the chance to give an “inspirtational” lightning talk. So I took this chance and prepared a lightning talk version of a talk I’ve been submitting to a lot of conferences but always got rejected. The talk is about “soft” skills, not the usual “hard” skills talks that you might be used to 🙂
The topic is very close to my heart as applications aren’t developed in a vacuum – they are developed with and for humans. I hope you enjoy it and that at some point I submit it to the “right” conference which will accept that type of talk 🙂
In the development world most people are striving for technical excellence: better code, faster run times, more convenient interfaces, better databases, faster deployments… But is that really what makes us better at developing software?
In the end software development is done by groups of people creating products together. To do that communication and collaboration between humans is essential – you can be the best programmer ever, if you can’t efficiently work with others what good does it do you?
This talk will give you a primer and food for further thought.
My slides & video from visiting the excellent WRUG (Warsaw Ruby Users Group). The talk is a variation of the similarly named elixir talk, but it is ever evolving and here more focused on Ruby. It covers mostly how to setup and run good benchmarks, traps you can fall into and tools you should use.
“What’s the fastest way of doing this?” – you might ask yourself during development. Sure, you can guess what’s fastest or how long something will take, but do you know? How long does it take to sort a list of 1 Million elements? Are tail-recursive functions always the fastest?
Benchmarking is here to answer these questions. However, there are many pitfalls around setting up a good benchmark and interpreting the results. This talk will guide you through, introduce best practices and show you some surprising benchmarking results along the way.
The following is the first part of my visit to Warsaw in April (sorry for the super late post!). As part of the visit, I also visited Visuality and spent an evening there giving a presentation and discussing the topics afterwards for a long time. We capped it off some board games 😉 I had a great time and the discussions were super interesting.
The talk is a reworked old goldie (“Code is read many more times than written” / “Optimizing for Readability”) and is about readable code and keeping readable code. It’s evolved as I evolve – I learn new things, assign differing importance to different topics and discover entirely new important topicss.
This year AlphaGo shocked the world by decisively beating the strongest human Go player, Lee Sedol. An accomplishment that wasn’t expected for years to come. How did AlphaGo do this? What algorithms did it use? What advances in AI made it possible? This talk will briefly introduce the game of Go, followed by the techniques and algorithms used by AlphaGo to answer these questions.
PS: Yes, Lee Sedol probably wasn’t THE STRONGEST human player – more like Top 3 or Top 5 at the time of the game (most people would probably call Ke Jie the strongest player at the moment). Lee Sedol is the dominant of the last decade though, and when the match was announced nobody on the computer-go mailing list complained about the opponent, so I just assumed he was the strongest or among the strongest but only found out after submitting the talk 🙂 . Plus, sadly “How did AlphaGo beat one of the top 5 Go Players” isn’t as catchy as a title.
A meetup is usually divided into a couple of phases: Before, Arrival, Main and Goodbye. To easily see what there’s to do, the format of this post is slightly different than the others. It’s not so much discussions but more of a check list for each of the phases, so you don’t forget anything.
As you might have noticed during the first two posts, most of the work done for a meetup happens before the meetup. The preparation is the real work, if it is good, then the meetup is mostly fun. The foundation for a great meetup is great preparation. Most of the things to prepare (online presence, atmosphere, talks, regular schedule, …) were discussed in previous posts. This is about what to do in the days leading up to the event.
Check with the hosts if everything is still set and clear up any questions (how many people are expected to come, how long the meetup will run, do they have a projector etc.) and remind them of important things (putting up signs etc.)
Check with the speakers if they are ready and everything is good to go for the meetup day and remind them of the CoC
See that you announce the meetup via the mailing list and twitter (I usually like to tweet about every talk individually to give the speakers some exposure and let interested attendees know what topics will be covered)
On the day of the meetup tweet again, make sure that the directions to the meetup are clear and let them know if there’s food at the meetup
For Arrival I like to be the first person at the venue, so I get there 30 to 45 minutes before the official meetup start. If the meetup involves presentations of any kind, be sure to bring your own laptop. The laptop of a speaker might break down, they don’t have their adapter with them… lots of things can happen, so it’s good to have a backup on your side.
For the Main part I’ll make sure I found enough speakers to fill the content before the break and then start relatively on time. Starting a bit late is fine, as people always arrive late. The Ruby User Group Berlin even has this “tradition” where we always start 15 minutes late (pssst).
First comes the welcome and an overview that should include:
thanks everyone for coming
quick introduction to the format (talks, lightning talks)
today’s topics and speakers
where are the bathrooms
where are food & drinks
wifi (also good to show on a projector or have signs around)
mention general rules such as the CoC
host & sponsors (if you have some), I usually give them maximum 5 minutes to introduce themselves while advising for a shorter time – people get bored easily
Then it goes on to announcing talks, as well as different parts of the meetup (break, lightning talks) and tell people that we are always looking for talks and encourage them to approach me to bounce talk ideas around.
If there are small pauses in between speakers (while connecting to the projector) I like to share some related news (new version of major library X released, security vulnerability in Y, conferences) and ask the audience if they also have any news to share. I just don’t like sustained periods of silence while the meetup is supposed to be running.
To get the attention of people and have them be silent a long extended “Shhhhhhh” while standing on the stage usually works best in my experience. Sometimes it’s just enough to stand there, wait and look like you are going to say something. Holding up one hand (maybe with a balloon) also has worked pretty well for me.
For the Goodbye the essential topics are mostly:
thanks for coming!
next meetup place + time
call for talks
if there’s an after party place, tell them where it is and where to form a group to get going there
ask kindly for help cleaning the space up (stacking chairs, collecting bottles etc.)
thank the speakers once again for their talks
And that’s basically it… but don’t forget – after the meetup is before the next meetup and it’s always a lot less stressful to have things already organized a long time in advance. I try to aim for having the venue and a couple of talks confirmed a month in advance, admittedly I often fail at that.
And that’s also an important takeaway here, nothing is ever perfect and it doesn’t have to be. Don’t worry if you don’t get all of this straight, if you forget something… it happens. I’ve been doing this for a long time and I still forget things but usually everything goes just fine. If I forget something, people remind me or ask. People also know that meetups are organized by volunteers, so they are forgiving and willing to help when something goes wrong.
So, let me know if this helped you or if I forgot to cover something and you have any remaining questions. This marks the end of this little series, so I hope that this helps you get your meetup started or that you got the insight into organizing meetups that your were looking for.
Go is a board game that is more than 2,500 years old (yes, this is not about the programming language!) and it is fascinating from multiple viewpoints. For instance, go bots still can’t beat professional players, unlike in chess.
This talk will show you what is so special about Go that computers still can’t beat humans. We will take a look at the most popular underlying algorithm and show you how the Monte Carlo method, basically random simulation, plays a vital role in conquering Go’s complexity and creating the strong Go bots of today.