SCKRK the Ultimate – 100 meetings, 96 whitepapers, 5 years and more…

Repost from May 2016 from Konrad’s blog that’s gone under.

Over the last years I’ve been had the privilege of traveling quite a bit and been able to attend various conferences and user group meetings in various countries. Yet, I’m still to find another as awesome and life-changing (sic, not an over-statement) group as SCKRK – yet, you’ve probably never heard of it. Which is not surprising really since it’s a local and technically speaking small initiative.

This year was special for SCKRK, the so-called (and hold your judgement about what it is until you’ve finished reading) “Software Craftsmanship Kraków” group, as it marked some very special moments in its lifetime:

  • the 100th meeting,
  • the 96th read whitepaper,
  • 5 years of uninterrupted regular operation,
  • and reaching over 1000 members.

And we’re more than proud of that. Another thing I learnt over the last years is that: If you don’t mention great achievements, no-one will know – so we’ve set out to fix that.

So here’s a short video from the special celebratory meeting, with Adam Pohorecki (founder) and myself explaining what it’s all about:

Interested? Hope so! Read-on then to learn more about…

The formula

SCKRK meetings are different and actually useful to perfecting your skills because of their formula, which always was different from your typical Meetup group – we actually require some up-front preparation from attendees.

So while the name SCKRK may imply it’s about the “software craftsmanship” trend that was trendy a while ago (and now deteriorated in it’s meaning somewhat), SCKRK is a computer-science white-paper reading club, and it’s members striving for self-perfection through continuous learning all while avoiding the “smartest person in the room problem”.

“The smartest person in the room is a piece of paper” Konrad Malawski

I always use the quote “The smartest person in the room is a piece of paper” to describe what SCKRK is about. The formula we follow is a simple, yet effective one:

  • check the site to figure out what paper will be discussed next,
  • read the whitepaper at home
    • this is really the core of it. And if you don’t get some of the sections, take note of it so you can bring it up during the meeting. If you’re only just starting out reading papers a note like “what the hell is a vector clock” is also acceptable 🙂
  • Show up at the meetup.
    • You’ll easily find the group by waving pieces of paper around.
  • Discuss, ask questions, clarify!
    • Don’t worry, no-one will ask you to recite the paper from memory, nor write up formal proofs of it.
    • It’s a good idea to bring a printout (or some form of tablet) with you since we’ll be diving into the paper in depth at times, so a reference point such as a printout is definitely helpful (also, you did your notes on it, right?)
    • The most important part here is to realise that there are no dumb questions, so you should never be afraid to ask for clarification if you – the group is always happy to explain, even if you don’t know some basic thing.

Over the last years, the group attracted numerous bright thinkers, and even fostered some. People who first were afraid of discussing and debating over correctness of algorithms, over time became well versed in both the subjects we tackle, but also the fine art of human respectable discussion.

If that has not convinced you to come over for the next meetup, read-on, the following section will.

Congratulations SCKRK!

Here, I’d like to step back and thank the original founder of this group, and by now, a friend of mine – Adam Pohorecki, who back then first started it during NoSQL Summer, and then together with Sebastian Bełczyk and Andrzej Grzesik decided that the format is so nice, that we will want to continue with it – thus SCKRK was born.

I’ve been around pretty much since the beginning, and honestly have to say, my life was influenced a lot by the group and I would not be where I am now, if it wasn’t for it, and all the great friends made there, ever arguing over details of edge cases in consensus algorithms.

The 100th meeting was special, as we visited a wine-bar Stoccagio to celebrate the anniversary with great wines and snacks. This was made possible by our generous sponsors, Lightbend the company I’m at (which is the steward of Akka, Scala, Play and many other projects making Reactive applications a THING on the JVM, as well as Ocado Technology a valued Lightbend partner and capable technology division of the Ocado brand.

The meeting was different for a change, as it consisted of our 4 older members picked their top 5 white-papers out of the ones read on SCKRK over the last 5 years. It was a fun and interesting travel in time, and reminder how some papers remain timeless. You can view 100th SCKRK Meeting slide deck to find out what our top papers where.

SCKRK, Banzai!

Next meeting this week

In order to encourage new people to attend the meetings, we’re currently re-visiting some of the most fun or important papers of the last years.

This week we’re hosting a session about the CAP theorem and our understanding of it has evolved over time. Be sure to drop by if you’re in the wonderful city of Kraków: Meetup #103 – CAP Theorem Revisited

Disclaimer again

Again: the content you read above is Konrad’s and it’s from 2016, but one of my targets for this year is having several SCKRK meetings, so if you’re interested, propose a topic in the comments or upvote topics already there.


Why bother with FP?

This is a short info page for my research project. I’ll try to provide backed by data (or at least reason) answer to eponymous question.

Why such project?

One of the first meetings of Lambda Lounge Kraków, back in early 2013, was dedicated to defining FP (Functional Programming) and finding the answers to following questions:

  • what makes a language “functional” one?
  • are functional languages out there in the real world and can one work (and earn well) in/with them?
  • is FP worthwhile just as pasture or as real career option?

The meeting was interesting and provided lots of information, but I felt the lack of data was really a problem, especially for last two questions.

Then, as a Lambda Lounge organizer I had my share of discourses about FP and it’s merits (not to mention those, where I was but a witness, because I ran away quickly enough NOT to be dragged in, or just closed the browser tab with disgust). Those discourses usually ran along very similar lines, and yet again I found myself with feeling that they lack data for claims they make (be it to disprove FP has merits or otherwise)

Finally, the now-trendy bashing OOP while in fact one is bashing procedural programming, irks me enough.

For all those reasons, I started researching FP merits for real and this led to me presenting some findings at LambdaDays conference, I heard that John Hughes himself said my abstract was promising and intriguing! Yay me! I sincerely hope my talk lived to it’s promise. However, this is by no means the end to my research and I found out quickly it extends far more than single blog post so… I’ll be sharing the work as I go, on GitHub, and will continue present next iterations during SFI and LambdaCon.


LambdaDays, why bother with FP version 1 slides:


GitHub repository with research:


Licence details:
Licencja Creative Commons
Why bother with FP by Tomasz Borek is licensed under a Creative Commons Uznanie autorstwa-Na tych samych warunkach 4.0 Międzynarodowe License.
Permissions beyond the scope of this license may be available at

Camunda Modeler first impression

Just a note really. I’m trying a neat modeling tool recently: Camunda Modeler. I like how easily you can set the model up, how easy is to create lanes, divide them, how arrow connectors work, etc.

I LOVE the simulation (Petri’s network rulez) mode. Though you lose colours when you switch.

Haven’t tried for long, will update the post later, once I know if the diagrams I did are shareable, for now I don’t think so.

Odśmiecanie w Jawach 9 – 15 na 4Developers

Właśnie skończyłem mówić na festiwalu 4Developers. Muszę przyznać, że czułem się jak w telewizji z wszystkimi przejściami, za kulisy, na scenę, do sesji pytań i odpowiedzi, wstępnej pogaduszki a przede wszystkim z racji na frazę “dziękuję, oddaję głos do studia”. Miłe uczucie!

4Developers logo: a green rhombus with a 4 done by an absence of green and a green word Developers under
logotyp 4Developers

Odsyłam do prezentacji: i postaram się opublikować sprawozdanie z wydarzenia. Prezentacja zawiera rzeczy z Jawy 15, która stała się publicznie dostępna 3 dni temu.

Epsilon wyleciał w Jawie 15? Pokrótce? Nie.

Guillherme zaskoczył mnie pytaniem: Dlaczego epsilon wyleciał w javie 15? Ponieważ spieszyłem się aktualizując prezkę (tak, wrzesień, oczywiście, że wyjdzie nowa Jawa po prostu ostatnie dni były… wariackie) to założyłem, że coś mnie ominęło. Po prezce z mety skoczyłem do stronki Jawy 15 i dowiedziałem się, że jednak nie.

  1. Brak powiadomień o ‘deprecjacji’.
  2. Żaden z JEPów dla 15 nie mówi o usuwaniu Epsilona.
  3. Nawet zrobiłem krótki test: pobrałem 15. z tar.gz-ów Oracle’a ze strony OpenJDK i odpaliłem program z Epsilonem, CMSem i szeregowym odśmiecaczem. Flaga CMS – jako nierozpoznana przez VMkę – położyła program. Epsilon wystartował.
Konsola eksperymentu z Epsilonem
Epsilon jest rozpoznawany, program z takim algo odśmiecania startuje (a próba użycia CMS skutkuje krachem)

New GC algo in Java 9 – 15 – 4Developers presentation

So I just finished speaking at 4Developers online. Must say, it felt like TV with all the jumps, backstage, on-stage, Q&A, preliminary chit-chat and most of all the phrase “and now, we’ll return to the studio”. I liked the feeling.

4Developers logo: a green rhombus with a 4 done by an absence of green and a green word Developers under
4Developers conference logo

Here is a presentation: and will try to publish a summary of the event later on.

Epsilon taken out in Java 15? Short answer? It wasn’t.

I got surprised there by a question: why was Epsilon taken out in Java 15 by Guillherme. Since I was updating the preso in a hurry when I learned of Java 15 being out (yeah, it’s September, it was obvious they’ll be out but last few days were just… hectic) I initially assumed that I missed something. After the preso I immediately went to Java 15 page and learned that I didn’t.

  1. There’s no depreciation notice.
  2. No JEP that made it in Java 15 is about taking Epsilon out.

I went further and did a short test: I’ve downloaded Java 15 from Oracle’s tar binaries from OpenJDK site and ran a program with EpsilonGC, CMS and Serial. CMS flag didn’t start: VM crashed cause the flag pointed to something that wasn’t a recognizable option. Epsilon started.

Experiment’s console log showcasing Epsilon being recognized by JDK 15

mvn clean install największym błędem w Twoim Mavenowym projekcie

Podczas JAlby 2019 znów spotkałem i porozmawiałem z szefem projektu Maven Robertem Scholte. Skorzystałem z okazji by spytać: jakie są najczęstsze błędy jakie napotykasz w cudzych projektach Mavenowych?

To proste – rzekł – `mvn clean install`

Robert Scholte, JAlba 2019

Pogadaliśmy więcej i sprowadza się to do:

  1. pisanie clean za każdym razem jest nadmiarowe. Czyszczenie było potrzebne w czasach Mavena 2. Dlaczego? Ponieważ były wtyczki, które nie sprzątały po sobie zatem miałeś ich rezultaty z poprzedniej budowy pokazujące Ci już nieprawidłowe wyniki (gorsze) lub uniemożliwiające tworzenie nowych rezultatów (słabe, lecz lepsze, przynajmniej od razu wiedziałeś że coś nie gra). Teraz wtyczki sprzątają po sobie całkiem nieźle, choć mogą być jakieś wyjątki.
  2. w większości przypadków install też jest nadmiarowe, wystarczyłoby Ci verify – czyli odpalenie wszelkich testów, sprawdzeń, upewnienie się że się buduje. Instalacja dodaje fazę installz jej operacjami dyskowymi – wydłużając proces budowy i czekanie na rezultaty budowy/testów, nie wspominając o nadpisywaniu plików na dysku bez potrzeby.

Zatem mvn verifyludki, albo nawet mvn test gdy nie macie testów integracyjnych.

Biggest error in your Maven project? mvn clean install

During JAlba 2019 I had again met and talked with Maven project chairman Robert Scholte. I’ve taken an opportunity to ask him: what are the most common errors you encounter in people’s Maven projects?

That’s easy – he said – `mvn clean install`

Robert Scholte at JAlba 2019

So we talked some more and it boils down to:

  1. using clean all the time is needless. Clean was needed in Maven 2 era. Why? Cause there were plug-ins which didn’t clean their results up so you could wind up with a result from a previous build showing things no longer true (worse) or interfering with creating a new result (bad, but better, you at least know immediately something’s wrong). Nowadays plug-ins are cleaning up rather well (though there may be exceptions).
  2. and most of the time you don’t want to install you just want to verify – run all the tests, checks, make sure it builds. Install unnecessarily adds the install phase (and related IO) and its plug-ins – lengthening the build process and your feedback loop and rewriting disk files without need.

So, mvn verify people, or mvn test even if you’re not into integration tests.

Good POM

WordPress is horrible and I suck at it. This is my fourth (4th, sic!) attempt at writing this post. I tried copying from PL version, saving, restoring revisions… Wasted hours. I’m officially looking for a good site where I could easily update the blog posts as ADOC files, from Vim, with Git and no pretentious and wannabe-fancy while restrictive and stifling UI. Loosing this content and the entire effort makes me feel gutted out. Seriously unpleasant experience.

POM for Project Object Model, XML file serving as a heart of any Maven project. This entry details what and why should be in such a POM and was created as a good reference point to sent people to when they ask me questions about it.

Titular POM is available as a Gist for your perusal and convenience, at your will, at:

Continue reading