DDevelopment & Design

TouK hackathon (TouKathon) – April 2022

Every now and then what a developer hopes for is a little break from their day-to-day work on the same project. And that’s where a hackathon comes in. In TouK it means two days of carefree (meaning not writing tests and doing code review) coding. You team up with developers from all over the company, find yourself a neat problem (or rather a challenge) to work on and just create a solution from scratch in languages and technologies of choice. That and good company coupled with lots of pizza, snacks, beer and other drinks results in time spent in an atmosphere tingling with fun and inspiration.

Summaries from each team about projects that were created during the first edition of this year’s TouKathon are presented below. Sixteen TouKs have worked on six exciting projects.

Football reflexometer

Authors: Patryk Majkrzak, Filip Michalski

Here at Touk we have a small community of football players. Lately, we were thinking about how to connect the worlds of sport and technology. Our friend Filip came up with the idea to build a football reflexometer – a device that tests your reaction time and shot precision. It’s basically a big polygon with indicators on the wall that light up when you hit them. The player stands in the centre and kicks the ball at the wall as quickly and precisely as he can.

football-concept Concept render

The basic version of our contraption would simply detect which wall has been hit and how quickly the player reacted. However, we thought that it would be fun to detect exactly where the point of impact was. We thought we could do this by triangulating the sensor data using cheap piezo discs which we glued to the corners of the office desk serving as a ‘wall’ (the ’hack’ in ‘hackathon’ is there for a reason).

football-piezo Piezo disc with detector circuit

We soon found out, however, that the piezo response has both too high a voltage and is too noisy for our Arduino, so we developed a simple peak detector with a Zener diode for protection from overvoltage.

football-circuit

Circuit schematics

football-response Example of a response

Sadly, after we connected everything up we found out that our microcontroller (16MHz Arduino Uno) is too slow to detect a difference in time of arrival of a sound wave. After some calculations, we concluded that at this speed our triangulation data would have too little precision to get anything meaningful out of it. In the future we want to change the microcontroller to a Teensy 4.1, which is approximately 40 times faster and would give us sub-centimetre precision, opening up possibilities for other sports like archery.

football-simulation-app Our simulation app

We also developed a simple app that takes a simulated ideal signal from a microcontroller and simulates how the sound waves propagate in the wall. We learned a lot in those two days and are excited to develop our project into something really great in the future.

Sebix @ Slack

Authors: Piotr Jagielski, Damian Święcki

We always dreamt about having a custom tailor-made bot on our communication channel. The journey started in 2015 when we built Janusz, which understood three basic commands. Janusz is a popular Polish meme participant, so for the sake of consistency we named our next attempt Sebix, after a nickname for an archetypal young male wearing sportswear and listening to dance music. During the previous hackathon, we managed to build it around Rocket.Chat that we were using at TouK in those days. However, in response to a number of requests, we’ve since moved our communication to Slack, so the next hackathon was a perfect time to move Sebix to Slack.

Currently, we have the following features implemented. You can:

  • Check how much holiday time you have left.
  • Set a reminder for a given task.
  • Log some work on a task and list previous logs.
  • Check the numbers to call to open our office gate.
  • Share a link to recent football highlights of your favourite team.

These were implemented using a simple “on message” Slack API. But we also managed to dig into Slack Apps API and built a more complicated command using a Bolt API and Block Kit for UI controls. The command lets you define a list of addresses for which you can check the travel time from our office at 9 Bohaterów Września Street:

sebix-wybierz-adres sebix-podroz

The project was built using Bolt for Kotlin, PostgreSQL and deployed on our internal cloud using Docker and Kubernetes.

More features are on the way!

Shots

Authors: Katarzyna Machowina, Monika Ruszczyk, Ula Trzaskowska, Przemek Bełczyk, Piotr Fus

Flashtalks are mini-conferences that we organise here at TouK. Each month three TouKs give a brief talk about an interesting concept from the IT world.

To make things more interesting, before the talk every speaker comes up with a single choice question. All those questions are then gathered in a Google Forms quiz and sent to participants at the end of a Flashtalks session.

So our hackathon team was wondering whether those quizzes could be even more fun. Definitely so, if we enrich them with some competitive spirit! This was achieved in two days thanks to a solution we called Shots (the name is a pun related to the name Flashtalks – in Polish we call Flashtalks “flaszki”, which means “bottles of liquor”).

The Shots project consists of two apps – one for the admin (Flashtalks organiser) and one for clients (Flashtalk attendees).

The idea is that the admin presents (e.g. on a shared screen) a question with possible answers. Participants have 15 seconds to select the correct answer on their devices with a client app. After each question the admin can show and summarise results for the completed question along with the names of the top responders. When all questions have been answered, the usernames of quiz champions are displayed on a podium, which is then flooded with triumphant confetti. And that concludes the Flashtalks, leaving winners with a sense of achievement and all others eager to participate in the next edition of the quiz.

shots-question Admin app: Question screen

shots-result Admin app: Question results screen

shots-all-results Admin app: Final quiz leaderboard

We wanted to easily communicate with client apps without the need for client polling. The ability to send the next question to all clients as soon as the admin displays it was paramount. That was achieved with WebSockets (backend and frontend), a technology we learned during the hackathon. Coding on the backend was a breeze thanks to our beloved Kotlin language along with Spring Boot. Our quiz and participants data is stored safely on a MySQL database run in a Docker container. A seamless user experience was provided with React (special thanks to react-canvas-confetti library).

Hopefully, Shots will soon be deployed to production where they will shine bright after every Flashtalk to come.

NLP @ Nussknacker

Authors: Rafał Solarski, Tomasz Wielga

nussknacker

The Nussknacker NLP project was an attempt to bring NLP abilities to diagrams of our Code-Less Tool (or codeless tool). During the hackathon we checked OpenNLP capabilities and integrated them as enrichment components to use on incoming calls transcriptions. To increase the fun factor we didn’t do any research before the day of the hackathon. Which is probably why a few times we hit a brick wall thanks to our foggy understanding of what is possible and what is not. In the end, we came up with Named Entity Recognition/Semantic Trees features and lots of ideas for the future.

DIY Drum Kit

Authors: Bartłomiej Tartanus, Rafał Golcz, Wojciech Decker

Here at Touk, we like to be eco and we like to play Guitar Hero. With this in mind, we collected a piece of plywood, some foam fillings and an Arduino to build our own electronic drum kit.

At its heart there’s a piezoelectric sensor that can convert force into electrical charge. With a few electronic components the signal generated by piezo is conditioned to be received by Arduino. In the basic setup, Arduino checks whether a signal on each channel is above some threshold and sends a signal to the laptop. In the extended version, Arduino can send MIDI signals and the whole device becomes an electronic drum kit. MIDI commands have a “velocity” parameter which directly corresponds to the force you will use when hitting a drum.

drum

The last hour of the hackathon we mainly spent practising Guitar Hero.

drum-btr

My kids got the idea as well…

drum-kids

Dodgeball v2

Authors: Jan Cieślak, Michał Hofman

Dodgeball v2 is a continuation of an idea from the previous hackathon to make a dodgeball game that everyone could play at the end of this year’s edition. Last time round, we used python, pygame and grpc. Although we kinda succeeded, managing to produce a playable game in two days, because of time constraints we had to make some sacrifices and so didn’t deploy the game :(. At this hackathon, we wanted to achieve the same goal of making a multiplayer game, but this time we also wanted to deploy it.

The project was started from the ground up and this time we took a different approach and used:

  • A different language (Go – just for learning purposes, but we wanted to see how the server would look in this language, because it’s widely used in performant backend services. In the game development world it’s used in Riot Games for Valorant server side).
  • Udp and tcp networking protocols for client-server communication, because it turned out grpc is not a good candidate (at least for udp replacement).
  • Concepts from the book “Multiplayer Game Programming” by Joshua Glazer, e.g. client-side interpolation and prediction.

We succeeded in deploying a playable game, because we had more time and some of the code to work with at the start. Dodgeball v2 was started before the hackathon and was a playground for me (Jan) to study, implement and test concepts and patterns from the book mentioned above. We don’t want to stop here and we’re planning to expand this project and make a fully-featured game with lobbies, groups, tournaments, etc.

I want to thank Michał for the current and Adrian for the previous hackathon <3. dodge

Summary

As you can see TouKathon resulted in:

  • Lots of fun and inspiration.
  • New technologies explored.
  • Several impressive useful products.
  • A chance to enjoy a new project with colleagues we don’t code with in our day-to-day work.

Additionally, our internal campaign inviting all TouK employees to the hackathon was a special one. We’ve created this entertaining video and matching advertisement posters. We can proudly say that the reception of both was overwhelmingly positive. szpachla

See the post about the previous edition of hackathon here.

— Previous article

Real-life Ansible - chapter one - how to run playbooks on production (more) safely

Next article —

Confitura 2022 Summary

You May Also Like
DDevelopment & Design

33rd Degree day 2 review

Second day of 33rd had no keynotes, and thus was even more intense. A good conference is a conference, where every hour you have a hard dilemma, because there are just too many interesting presentations to see. 33rd was definitely such a conference, and the seconds day really shined.

There were two workshops going on through the day, one about JEE6 and another about parallel programming in Java. I was considering both, but decided to go for presentations instead. Being on the Spring side of the force, I know just as much JEE as I need, and with fantastic GPars (which has Fork/Join, actors, STM , and much more), I won't need to go back to Java concurrency for a while.

GEB - Very Groovy browser automation

Luke Daley works for Gradleware, and apart from being cheerful Australian, he's a commiter to Grails, Spock and a guy behind Geb, a  browser automation lib using WebDriver, similar to Selenium a bit (though without IDE and other features).

I have to admit, there was a time where I really hated Selenium. It just felt so wrong to be writing tests that way, slow, unproductive and against the beauty of TDD. For years I've been treating frontend as a completely different animal. Uncle Bob once said at a Ruby conference: "I'll tell you what my solution to frontend tests is: I just don't". But then, you can only go so far with complex GUIs without tests, and once I've started working with Wicket and its test framework, my perspective changed. If Wicked has one thing done right, it's the frontend testing framework. Sure tests are slow, on par with integration tests, but it is way better than anything where the browser has to start up front, and I could finally do TDD with it.

Working with Grails lately, I was more than eager to learn a proper way to do these kind of tests with Groovy.

GEB looks great. You build your own API for every page you have, using CSS selectors, very similar to jQuery, and then write your tests using your own DSL. Sounds a bit complicated, but assuming you are not doing simple HTML pages, this is probably the way to go fast. I'd have to verify that on a project though, since with frontend, too many things look good on paper and than fall out in code.

The presentation was great, Luke managed to answer all the questions and get people interested. On a side note, WebDriver may become a W3C standard soon, which would really easy browser manipulation for us. Apart from thing I expected Geb to have, there are some nice surprises like working with remote browsers (e.g. IE on remote machine), dumping HTML at the end of the test and even making screenshots (assuming you are not working with headless browser).

Micro services - Java, the Unix Way

James Lewis works for ThoughtWorks and gave a presentation, for which alone it was worth to go to Krakow. No, seriously, that was a gem I really didn't see coming. Let me explain what it was about and then why it was such a mind-opener.
ThoughtWorks had a client, a big investment bank, lots of cash, lots of requirements. They spent five weeks getting the analysis done on the highest possible level, without getting into details yet (JEDI: just enough design initially). The numbers were clear: it was enormous, it will take them forever to finish, and what's worse, requirements were contradictory. The system had to have all three guarantees of the CAP theorem, a thing which is PROVED to be impossible.
So how do you deal with such a request? Being ThoughtWorks you probably never say "we can't", and having an investment bank for a client, you already smell the mountains of freshly printed money. This isn't something you don't want to try, it's just scary and challenging as much as it gets.
And then, looking at the requirements and drawing initial architecture, they've reflected, that there is a way to see the light in this darkness, and not to end up with one, monstrous application, which would be hard to finish and impossible to maintain. They have analyzed flows of data, and came up with an idea.
What if we create several applications, each so small, that you can literally "fit it in your head", each communicating with a simple web protocol (Atom), each doing one thing and one thing only, each with it's own simple embedded web server, each working on it's own port, and finding out other services through some location mechanism. What if we don't treat the web as an external environment for our application, but instead build the system as if it was inside the web, with the advantages of all the web solutions, like proxies, caches, just adding a small queue before each service, to be able to turn it off and on, without loosing anything. And we could even use a different technology, with different pair of CAP guarantees, for each of those services/applications.
Now let me tell you why it's so important for me.
If you read this blog, you may have noticed the subtitle "fighting chaos in the Dark Age of Technology". It's there, because for my whole IT life I've been pursuing one goal: to be able to build things, that would be easy to maintain. Programming is a pure pleasure, and as long as you stay near the "hello world" kind of complexity, you have nothing but fun. If we ever feel burned out, demotivated or puzzled, it's when our systems grow so much, that we can no longer understand what's going on. We lose control. And from that point, it's usually just a way downward, towards complete chaos and pain.
All the architecture, all the ideas, practices and patterns, are there for just this reason - to move the border of complexity further, to make the size of "possible to fit in your head" larger. To postpone going into chaos. To bring order and understanding into our systems.
And that really works. With TDD, DDD, CQRS I can build things which are larger in terms of features, and simpler in terms of complexity. After discovering and understanding the methods (XP, Scrum/Kanbad) my next mental shift came with Domain Driven Design. I've learned the building block, the ideas and the main concept of Bounded Contexts. And that you can and should use a different architecture/tools for each of them, simplifying the code with the usage patterns of that specific context in your ming.
That has changed a lot in my life. No longer I have to choose one database, one language and one architecture for the whole application. I can divide and conquer, choose what I want to sacrifice and what advantages I want here, in this specific place of my app, not worrying about other places where it won't fit.
But there is one problem in here: the limit of technologies I'm using, to keep the system simple, and not require omnipotence to be able to maintain, to fix bugs or implement Change Requests.
And here is the accidental solution, ThoughtWorks' micro services bring: if you system is build of the web, of small services that do one thing only, and communicate through simple protocol (like Atom), there is little code to understand, and in case of bugs or Change Requests, you can just tear down one of the services. and build it anew.
James called that "Small enough to throw them away. Rewrite over maintain". Now, isn't that a brilliant idea? Say you have a system like that, build over seven years ago, and you've got a big bag of new requests from your client. Instead of re-learning old technologies, or paying extra effort to try to bring them up-to-date (which is often simply impossible), you decide which services you are going to rewrite using the best tools of your times, and you do it, never having to dig into the original code, except for specification tests.
Too good to be true? Well, there are caveats. First, you need DevOps in your teams, to get the benefits of the web inside your system, and to build in the we as opposite to against it. Second, integration can be tricky. Third, there is not enough of experience with this architecture, to make it safe. Unless... unless you realize, that UNIX was build this way, with small tools and pipes.
That, perhaps. is the best recommendation possible.

Concurrency without Pain in Pure Java

Throughout the whole conference, Grzegorz Duda had a publicly accessible wall, with sticky notes and two sides: what's bad and what's good. One of the note on the "bad" side was saying: "Sławek Sobótka and Paweł Lipiński at the same time? WTF?". 
I had the same thought. I wanted to see both. I was luckier though, since I'm pretty sure I'll yet be able too see their presentations this year, as 33rd is the first conference in a long run of conferences planned for 2012. Not being able to decide which one to see, I've decided to go for Venkat Subramaniam and his talk about concurrency. Unless we are lucky at 4Developers, we probably won't see Venkat again this year.
Unfortunately for me, the talk ("show" seems like a more proper word), was very basic, and while very entertaining, not deep enough for me. Venkat used Closure STM to show how bad concurrency is in pure Java, and how easy it is with STM. What can I say, it's been repeated so often, it's kind of obvious by now.
Venkat didn't have enough time to show the Actor model in Java. That's sad, as the further his talk, the more interesting it was. Perhaps there should be a few 90min sessions next year?

Smarter Testing with Spock

After the lunch, I had a chance to go for Sławek Sobótka again, but this time I've decided to listen to one of the commiters of Spock, the best thing in testing world since Mockito. 
Not really convinced? Gradle is using Spock (not surprisingly), Spring is starting to use Spock. I've had some experience with Spock, and it was fabulous. We even had a Spock workshop at TouK, lately. I wanted to see what Luke Daley can teach me in an hour. 
That was a time well spent. Apart from things I knew already, Luke explained how to share state between tests (@Shared), how to verify exceptions (thrown()), keep old values of variables (old()), how to parametrize description with @Unroll and #parameterName, how to set up data from db or whatever with <<, and a bit more advanced trick with mocking mechanism. Stubbing with closures was especially interesting.

What's new in Groovy 2.0?

Guillaume Laforge is the project lead of Groovy and his presentation was the opposite to what we could see earlier about next versions of Java. Most visible changes were already done in 1.8, with all the AST transformations, and Guillaume spent some time re-introducing them, but then he moved to 2.0, and here apart from multicatch in "throw", the major thing is static compilation and type checking.
We are in the days, were the performance difference between Java and Groovy falls to a mere 20%.  That's really little compared to where it all started from (orders of magnitude). That's cool. Also, after reading some posts and successful stories about Groovy++ use, I'd really like to try static compilation with this language
Someone from the audience asked a good question. Why not use Groovy++ as the base for static compilation instead. It turned out that Groovy++ author was also there. The main reason Guillaume gave, were small differences in how they want to handle internal things. If static compilation works fine with 2.0, Groovy++ may soon die, I guess.

Scala for the Intrigued


For the last talk this day, I've chosen a bit of Scala, by Venkat Subramaniam. That was unfortunately a completely basic introduction, and after spending 15 minutes listening about differences between var and val, I've left to get prepared to the BOF session, which I had with Maciek Próchniak.

BOF: Beautiful failures


I'm not in the position to review my own talk, and conclude whether it's failure was beautiful or not, but there is one things I've learned from it.
Never, under none circumstances, never drink five coffees the day you give a talk. To keep my mind active without being overwhelmed by all the interesting knowledge, I drank those five coffees, and to my surprise, when the talk started, the adrenaline shot brought me over the level, where you loose your breath, your pulse, and you start to loose control over your own voice. Not a really nice experience. I've had the effects of caffeine intoxication for the next two days. Lesson learned, I'm staying away from black beans for some time.
If you want the slides, you can find them here.
And that was the end of the day. We went to the party, to the afterparty, we got drunk, we got the soft-reset of our caches, and there came another day of the conference.

You can find my review from the last day in here.