Tomasz Dziurko

Świąteczna opowieść. Polska branża IT w 2023

Sat, 23 Dec 2023 12:01:35 +0000

Tuż przed Świętami 2023, w ramach łapania oddechu, pojawiłem się jako gość w podcaście Osobowości IT prowadzonym przez Agę Myśliwczyk, gdzie razem z Grażyną Dadej próbowaliśmy podsumować ultraciekawy w IT rok 2023, trochę wróżyliśmy, co nas czeka w 2024. Poza tym rozmawialiśmy o byciu dobrym liderem, przywództwie i ścieżkach kariery, które nas doprowadziły do miejsc, w których jesteśmy i jaką z tego można czerpać naukę.

Czy warto się specjalizować - mini wywiad w Brand w IT

Wed, 31 Aug 2022 12:00:00 +0000

W sierpniu Aleksandra Rajkowska, znajoma z branży IT, poprosiła mnie o wypowiedź na temat blasków i cieni specjalizowania się w naszym zawodzie.

Pierwsze kilka akapitów poniżej, a całość (w tym wypowiedzi Krzysztofa Kempińskiego i Oli Kunysz) można przeczytać na stronie Brand w IT.

Czy warto się specjalizować? Co byś doradził tym, którzy mają ten dylemat?

To zależy od wielu czynników, ale przede wszystkim od etapu kariery w naszej branży. Na samym początku skoncentrowałbym się na tym, co nas najbardziej kręci w tej ścieżce kariery: czy frontend, czy backend, czy może DevOps. Na miejscu zaczynających w IT wybrałbym sobie taką dziedzinę, język oraz 2-3 technologie towarzyszące. A następnie właśnie na te rzeczy położyłbym główny nacisk nauki.

Dlaczego akurat tak? Większość firm szukających juniorów koncentruje się na jakiejś specjalizacji, np. Junior Java Developer, Junior DevOps Engineer czy Junior Frontend Developer. Na takie ogłoszenie spływa do firmy kilkadziesiąt, a czasem kilkaset CV. Żeby się wybić, trzeba w tym CV mieć coś wyróżniającego się; coś, co sprawi, że przeglądający je zobaczy, że może i jest to osoba na początku swojej drogi w IT, ale przynajmniej wie już, jaka to droga.

Po drugie, im więcej będzie pasji w tym wyborze, tym łatwiej będzie przychodziła nauka, pisanie własnych projektów, poznawanie narzędzi i ogólnie pojęty rozwój. Jeśli nie odczuwasz satysfakcji po spędzeniu kilku godzin dziennie na pisaniu kodu, oglądaniu kursów, czytaniu dokumentacji, będzie Ci bardzo trudno zmotywować się do regularnej nauki, a tylko takie podejście może przynieść widoczne efekty i sukces w postaci zdobycia pierwszej czy drugiej pracy.

Pełny wywiad jest dostępny tutaj.

Nigdy nie mieliśmy biura. Case study SoftwareMill - artykuł i temat numeru w czasopiśmie HR Business Partner

Mon, 13 Jun 2022 12:00:00 +0000

W majowo-czerwcowym wydaniu czasopisma HR Business Partner jako temat numeru ukazał się mój artykuł “Nigdy nie mieliśmy biura. Case study SoftwareMill”, w którym opisuję nasze (SoftwareMill) podejście do budowania kultury organizacyjnej, zaangażowania oraz efektywności w ponad 80-osobowej firmie zdalnej.

Pierwsze kilka akapitów poniżej, a całość można przeczytać albo w wersji papierowej numeru, albo na stronie czasopisma.

Zaprogramowaliśmy się w SoftwareMill na 100-procentową pracę zdalną od dnia zero. Obecnie jesteśmy ponad 80-osobową organizacją, w której osoby z firmy znają się lepiej nawzajem, niż kiedy pracowały stacjonarnie w biurze. Oto, co u nas działa i pozwala budować przywiązanie do firmy na tak trudnym rynku pracownika, jakim jest branża IT.

Od zawsze jesteśmy w pełni zdalni, działamy w modelu, który inni odkryli ponad 10 lat później. Tworzymy projekty IT dla całego świata, każdy z nas z własnego domu czy co-worku. Nigdy nie mieliśmy i nie planujemy mieć biura. A wszystko zaczęło się w 2009 r., gdy właściciele zachęceni wcześniejszymi doświadczeniami pracy zdalnej dla RedHata stworzyli SoftwareMill. Od tego czasu wypróbowaliśmy wiele sposobów na budowanie kultury w firmie, tak by zdalność nie przeszkadzała, a była wyróżnikiem i wspierała budowanie silnego zespołu. Wdrożyliśmy procesy i zasady, które pomagają nam pielęgnować relacje w zespole rozproszonym, a jednocześnie pozwalają korzystać z elastyczności, jaką daje telepraca. Wyróżniamy się na rynku pracodawców IT jako organizacja, która po prostu „umie w pracę zdalną”.

Organizacja pracy w 80-osobowej zdalnej firmie

W pełni zdalny model pracy to jedna z cech charakterystycznych SoftwareMill. W DNA organizacji mamy zapisane jeszcze zarówno płaską strukturę, która z czasem wyewoluowała w model wzorowany na holakracji, jak i pełną transparentność, także finansową. Te czynniki sprawiają, że w zakresie zarządzania zespołem i całą firmą różnimy się od klasycznych organizacji i konkurencji. By pokazać pełen kontekst, przedstawię odrobinę historii.

Od turkusu po (r)ewolucję

Gdy SoftwareMill miał około 25 osób – Zarząd, który ciągle chciał programować i brać udział w projektach, zdecydował się przejść na bardzo wtedy rewolucyjny model firmy, dziś nazywany „turkusowym”, z tzw. płaską strukturą.

Główne założenie było takie, by wszystkie decyzje podejmować jak najbliżej źródła problemu. Dzięki wprowadzeniu pełnej transparentności (w tym także wynagrodzeń oraz stawek dla klientów) zespoły projektowe mogły podejmować samodzielne decyzje na podstawie pełnego obrazu sytuacji. Do większych inicjatyw stworzyliśmy Grupy Robocze i opracowaliśmy zasady demokratycznych głosowań całej firmy nad wypracowaną w Grupie propozycją. Taki model zarządzania sprawdzał się u nas przez dobrych kilka lat.

Ciąg dalszy tutaj.

Holacracy in a software house

Thu, 29 Jul 2021 12:00:00 +0000

Part 2 of the interview with Tomek Dziurko, SoftwareMill’s VP of Engineering

Part 1 is available here

Kamila Stępniowska talks to Tomek Dziurko about how decisions are made at SoftwareMill, how guilds work, and why the company opted for their own version of holacracy.

Kamila Stępniowska (KS): The closer I got to know SoftwareMill, the more it began to remind me of Spotify in terms of its culture of organization. From what I know, that’s not where your inspiration came from, but Netflix is a kind of newly-discovered source of inspiration. You discussed Reed Hastings’ “No Rules Rules: Netflix and the Culture of Reinvention” at your reading club’s meetings. Are you thinking of implementing any of the organizational solutions presented in the book?

Tomasz Dziurko (TD): We’re planning to. What we really liked was the emphasis on feedback culture – very honest, regular feedback, focused on what can be done better. The book broadly describes a fairly developed system for giving feedback so that it’s constructive and not taken as a personal attack. At SoftwareMill, we work in a similar manner, however, we feel we can still improve in this area. We are aware that giving and receiving feedback is generally a tough nut to crack. I assume that little by little, we will get to where Netflix is: providing feedback as often as possible. Feedback that’s timely, delivered following a given situation is a lot more effective because both sides still remember all of it and it’s easier to communicate.

KS: It seems that SoftwareMill is open to internal discussion. You don’t have departments but so-called guilds. I take it there’s more to that than just a different name?

TD: SoftwareMill used to be a flat company, so everyone could express themselves in any area. Whenever a decision had to be made, we asked for everyone’s opinion, and we made decisions together by a company-wide vote. And it was great, it worked well until we grew to about 40 people. It then turned out that not all decisions can be made together. Some people simply don’t have the knowledge or context to consciously vote for or against something. That’s when we decided that we need to narrow the groups down a little in terms of competences – to people who really want to contribute in a certain area, are interested in what’s going on, and are somewhat familiar with a given part of the company’s activity. We introduced a holacracy, or at least that was our starting point.

At SoftwareMill, as you mentioned, we have guilds – every area of the company’s activity has its own guild. It also has a guild master who coordinates activities and makes sure that the things that need to happen actually happen. At the moment, many smaller decisions concerning a specific area of activity of the company are made within the guilds. The decisions are made by people who really have the knowledge and context, and who know what the risks, consequences, business goals, and reasons for the course of action are. It’s important to note that anyone can belong to a guild – you simply need to express interest and consciously decide that “OK, I’m interested in this area of the company’s activity, so I want to do this, I want to and have the time to keep track of this.” We haven’t completely got rid of our flat structure. Decisions that impact the entire company are still made via voting by every member of the company. Here, we stick to the values SoftwareMill grew out of – everyone can do their own bit and shape the company.

Full article can be read at SoftwareMill’s Blog here.

VP of Engineering working in HR?

Wed, 21 Jul 2021 12:00:00 +0000

Can VP of Engineering handle recruitment processes too?

First part of an interview with Tomek Dziurko, SoftwareMill’s VP of Engineering

Part 2 is available here

Kamila Stępniowska (KS): Tomek, your title on your LinkedIn profile is VP of Engineering, but you also scout for new talents and watch over the recruitment process, so what’s going on here? ;)

Tomek Dziurko (TD): Yes, that’s right. Choosing the right people to join SoftwareMill is one of my most important responsibilities. The IT market is very demanding, especially when it comes to experienced specialists, so the help of a programmer with 13 years of experience can only help, both when it comes to finding the right people and to convincing them that SoftwareMill is a good place for them to develop further.

Luckily that’s not the only thing I work on, although I admit that it’s quite important.

KS: What else does your job involve?

TD: In product companies that build an app, the role of the VP of Engineering is much more closely tied to technical aspects. Such a person really supports the technological direction, working together with the CTO on selecting tools, languages, architecture – that is elements with strategic importance for the product’s development, and so for the existence of the whole company. Since most programmers work on developing the same application, the VP of Engineering also focuses on improving communication and collaboration between teams. All this increases the chances of the app’s success and the financial success of the company. After all, at the end of the day, it’s the most mundane mission of each company: to make money that can then be spent on pay rises or a new Ferrari for the CEO. Exactly in that order, of course :)

In the case of a software house, my role is a little different, although of course our CEO probably wouldn’t mind having a Ferrari either :) My main task, other than coordinating the recruitment process for different technical positions, is supporting teams in effective work, by which I mean: supporting the development of technical knowledge, creating paths for development in different technical positions together with senior developers and architects, and taking care of the development of soft skills in the team as well as supporting the exchange of experiences and know-how between teams.

KS: What does that mean in practice? How do you encourage the exchange of knowledge at SoftwareMill?

TD: When it comes to learning, I either organize or help to get different groups of knowledge exchange going within the company. We make sure that people who want to learn or – what’s even more valuable – share their experiences have plenty of opportunities to do so here. We currently have two groups preparing for certifications (AWS and Apache Kafka), a Technical Reading Club (currently discussing “Design It” and previously went over “Designing Data-Intensive Applications” by Martin Kleppmann), and a Soft Skills Reading Club, where we read more about the human aspect of leading teams and companies. We started by going over the classic “Peopleware: Productive Projects and Teams”, and then we read “No Rules Rules: Netflix and the Culture of Reinvention.”

Full article can be read at SoftwareMill’s Blog here.

O wspieraniu rozwoju i integracji programistów w czasach koronawirusa - 4Developers 2021

Thu, 27 May 2021 12:00:00 +0000

Moje wystąpienie na konferencji 4Developers 2021 na temat jak to robimy, że jesteśmy zgraną drużyną, pracując w 100% zdalnie? Jakie aktywności i rozwiązania wypracowaliśmy przez prawie 10 lat pracy zdalnej, które mogą wam, waszym zespołom czy nawet firmom, pomóc w czasach pracy zdalnej zadbać zarówno o integrację ludzi, jak i wspieranie ich rozwoju.

Lobotomy to your object-oriented thinking - "Elegant Objects, volume 1" book review

Wed, 26 Jul 2017 00:00:00 +0000

Step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy.

– David West

This is the first sentence in “Elegant Objects, volume 1” book by Yegor Bugayenko and after reading it from cover to cover I could not agree more. This book will not leave you neutral, you will either strongly agree or disagree with claims stated there, but it is definitely worth your time. It will challenge what you know about programming, it will challenge what you think a proper object-oriented design is and it will challenge many old, well-established so called “good practices” you have seen during your career. Fasten your belts, move your coffee mug away from your keyboard and keep reading.

Image from http://simpsons.wikia.com

Content

“Elegant Objects, vol. 1” in over 200 pages gives you 23 practical tips for developers to write more object-oriented, thus more maintainable code. The author uses a very interesting allegory by treating every object as a human being and splitting these suggestions into four anthropomorphized chapters: birth, school, employment, and retirement.

The Birth chapter is rather short and covers object creation, starting from naming strategies through suggestions how to keep constructors clean and easy to test. Education and Employment are the core of the book and contain paragraphs describing how to build encapsulated, immutable and easy to test objects, how to use interfaces with stub implementations to simplify testing without mocking hell. Then we could read some rants about “encapsulation by getters/setters”, sections about the clear distinction between data structures known from procedural languages and well-defined classes and objects from OO programming. Last paragraph Retirement is about avoiding nulls, using only checked (yes, yes, no typo here :) ) exceptions and recovering from errors.

Each suggestion is clearly described with code snippets showing bad, and then, proper approaches to solve the discussed topic. There are also links to discussions on author’s blog so you could read what others have to say about each suggestion. Most paragraphs are short so the reader could split reading sessions into smaller ones without the need to re-read several pages. Paragraphs are also rather autonomous so you could read them in any order, even if there is a reference to something covered elsewhere, it will be a direct reference to paragraph number where the reader should look for mentioned information.

My Notes

During the reading, I put many sticky notes with sentences worth remembering, below the most important or intriguing ones.

Avoid names ending with “-er”, it suggests that such an object is only a collection of procedures that manipulate data and not a fully-independent entity that is capable of acting on its own
Each class should have only one primary constructor with initialization logic there, non-primary (secondary) constructors should only prepare data (params conversion, etc.) and call a primary one.
Each class should have a maximum of four properties. Author makes an analogy to coordinates in the universe (x, y, z and time)
Instantiation should be strictly separated from execution, new operator is allowed only inside secondary constructors
Every public method must be a part of some interface. Why? See note below.
Avoid mocking hell by using no mocks, provide default (fake) implementations of all interfaces that could be later used in your tests. This way other developers won’t have to set up everything in each test, they could simply use fake implementations that need to be written once.
Avoid mutable state.

Mutable objects are an abuse of the entire object-oriented paradigm.

Avoid temporal coupling between lines: with immutable objects you do not have two separate phases of object instantiation and object initialization (first “new”, then multiple setters) so we cannot accidentally put any logic before the object is fully ready to use. The immutable object is either non-existing or fully initialized entity ready to work for you, so reordering lines won’t have any effect on application logic, the same immutable object will be used.
Show your respect to others by writing code that assumes they are junior programmers. Not by showing off and demonstrating your skills but by writing simple and easy to follow code.
Favor small objects with the well-defined scope and responsibility -> max four public/protected methods. If this number goes above five, think carefully as probably this class has more than one responsibility.

Static methods are like a cancer to your objects.

You can’t trust objects returning null, every time at some point you will have to check for nullability.

As you can see some of them are only a bit more strict rules that we used to apply during our daily job, but some are quite radical. If you want to understand them better or read if readers agree or disagree with presented approach you could use a link to the discussion on Yegor’s blog (e.g. Don’t mock, use fakes). I am not sure that applying all of them is possible, but in my opinion, the more you try the better your code will be.

Summary

Without any doubt, I am placing “Elegant Objects, vol. 1” next to my other favorite programming books like “Clean Coder”, “Clean Code”, “Software Craftsman” and “The Pragmatic Programmer: From Journeyman to Master” (some of them have reviews here on my blog). It shows a very different point of view to object-oriented programming and challenges much stuff we all take for granted. It presents something I would call a Radical Object-Oriented paradigm that will broaden your horizons and make you think twice before following any standard approach. There is a second part named “Elegant Objects, volume 2” that I am planning to read as well.

Confitura 2017 – greatness delivered

Tue, 04 Jul 2017 00:00:00 +0000

Last weekend, I attended Confitura 2017. This year’s conference had about 1,400 attendees, 5 tracks, and 35 presentations; everyone could find something interesting to listen to and learn from. This post is a review of that great event.

A Bit of History

Confitura 2017 was the 11th edition of this Java/JVM/programming conference in Poland. When I realized the event has been around for so long, I checked my notes and found that I have only missed the first two editions. This was my 9th Confitura: twice as an organizer, once as a speaker (2nd best talk in 2015, yay!), once as a volunteer, and the rest as a regular attendee.

Confitura started in 2007 as Javarsovia. However, due to a mysterious company trying to ban the word, it was renamed to its current brand. It has grown from a single-track event to the biggest free-to-attend (with a small donation to charity) JVM conference in the country, featuring 5 tracks and over thirty speakers.

The Talks

When I reached the conference venue, I was surprised by the very short queues at the registration desks. Everything went smoothly—perhaps thanks to the use of QR codes as e-tickets. Within a minute, I had my bag, which even included a trendy fidget spinner toy! 🙂

Keep IT clean: mid-sized building blocks and hexagonal architecture in real life by Jakub Nabrdalik

Every time you attend one of Jakub’s talks, you can be sure your time won’t be wasted. This time was no different: a very good presentation on limiting class visibility as a step toward cleaner architecture, better testability, and happier developers. He also covered packages and subpackages, managing the visibility of Spring beans, and a high-level look at CQRS architecture. With Kuba’s talk, Confitura started with some very “meaty” technical content. Link to the slides

Studium przypadku wystarczająco dobrej architektury by Jakub Kubryński

The story of a startup and a CEO who needs to balance the eagerness to refactor with the cost of doing so. It included many useful tips on how to apply a “good enough” approach to a project, what to automate, and which metrics to measure to understand what is happening in your system. Kuba explained how they ensure microservices can communicate with each other (Spring Cloud Contract), why end-to-end tests should only cover the most critical paths, and why your users are often your best testers. Link to the slides

Reactive web services by Kamil Szymański

A live coding demo showing how to introduce a reactive approach to your project without using too many external libraries (using only the latest Spring and Hibernate). I respect all speakers who are brave enough to write code during a talk, and Kamil did it well, with only one or two minor pauses. He covered Mono and Flux from Reactive Spring as well as features from the latest Hibernate.

Evolving Architecture by Daniel Pokusa

A talk about the career of a software developer trying to understand what makes a “good” architecture and how to build such a system, while making some costly mistakes along the way. It was a very good talk, especially for junior developers; those more experienced might find some of the material familiar. Daniel mentioned several excellent books to read; I personally added the free Cloud Design Patterns from Microsoft to my reading list. Link to the slides

Visa Developer Center by Tomasz Cisowski

This was a sponsored presentation, so I didn’t expect too much, but the topic was interesting. I have some experience integrating payment providers and wanted to see what Visa has to offer. In short: visit developer.visa.com to check their documentation; they have many different APIs to experiment with.

Testy wydajności z Gatlingiem by Andrzej Ludwikowski

My colleague from SoftwareMill retold the familiar story that measuring performance is hard. However, with Gatling—a tool written in Scala, Akka, and Netty—performing these tests using its elegant DSL should no longer be a pain (we all remember the “great” UX of JMeter). Link to the slides

7 things which you should care about before release your code to production by Mateusz Dyminski

A solid talk about things like API versioning (especially important for mobile app backends), database migration versioning, and learning how to profile your code before you go to production. Lots of useful practical advice! Link to the slides

Plantacje programistów – kolonializm XXI wieku by Wojciech Seliga

I skipped this to do some networking instead, but I had seen this talk at GeeCON earlier this year. Wojtek argued that being “just a coder” is no longer enough; we should strive to understand the business better. We need to be more than someone who just writes code (which is becoming a commodity) and instead understand the product and the organization to bring extra value. He suggested that instead of just software engineering, we should focus on “product engineering,” which involves user experience, market research, data analysis, and more. It was a great talk with many interesting insights. Link to the slides

After-party

I cannot emphasize this enough: after-parties are at least one-third of the value of any technical event. If you have the chance to attend, never hesitate. You will meet speakers, organizers, JUG leaders, and many other fascinating people. You can talk to them about anything: their presentations, their open-source projects, or off-topic subjects like cars, kids, Lego sets, or even the strangest place you’ve ever pushed a Git commit from.

The atmosphere is relaxed, and since no one is rushing to the next session, networking is easy. Just grab a drink and join a group. “Spoina,” the party after Confitura, was great as usual. This time, we had an entire barge to ourselves in a very atmospheric location, with good food, plenty of drinks, and no loud music to drown out the conversation.

Of course, we didn’t finish there and eventually moved to the city center for the next phase of socializing! 🙂

Summary

As usual, Confitura delivered: great talks and even greater people. I saw many old friends and met some new faces too. The old venue (with its upgraded air conditioning) held up surprisingly well. Honestly, aside from there being too many interesting talks to attend and the breaks being too short to talk to everyone I wanted, I couldn’t find any drawbacks. If you are into programming, this event is definitely for you.

Credits: photos by @bartekzdanowski and miejsce.to

Java word banned once and for all?

Fri, 21 Apr 2017 00:00:00 +0000

This article is my reaction to the recent Javaslang changing name to Vavr. Please be aware that all content is completely fictitious and in many cases ironic.

Reports are coming in from all over the world that some mysterious man in a dark suit contacted various companies strongly suggesting that they should stop using the word “Java” in any form or “bad things might happen”.

By now we were not aware of the number of such incidents but recently many people from different countries and various industries contacted us to share their stories. Below we present some of them:

Javaslang

One of the core contributors of this library told us anonymously that a few weeks ago the team behind Javaslang was approached by a serious-looking man who told them that they should stop using the “Java” word as a part of their library name. He also added that his corporation already has an internal slang called javaslang so nothing with the same name should exist. He even gave one example of one phrase they coined:

“postponed to the next major release” means “not gonna happen”

Java, the island

It turns out that not only regular people are approached by these mysterious individuals. Our source in the Indonesian government told us that they also had a very similar situation: a tall man wearing an expensive black suit contacted their delegation during a visit to San Escobar. He urged that nothing could be called Java except their product. When he heard “But we can not change the name of an island, that would force over 140 million of our citizens to change their IDs, addresses and as a result would push our country into chaos” in response, he shouted “But over 3 billion devices use OUR Java! This is much more!”.

Javart, the company

Individuals, governments, but also companies were on the radar of this unknown and mysterious corporation. A former employee of Javart, a Polish software house, called us to share his relation. During a short session over Skype he claimed that their board was forced to change the name of the company because it contained the “Java” word. He also said that the man in a suit told them that

Javart name suggests that Java has something in common with the art and that is an obvious lie.

Jawa, the motorbike

Another company that was contacted by “Java word defenders” was a Czech motorbike manufacturer named Jawa. In this case a phrase describing their latest model “The fastest Jawa in the history” was the reason why a suited man appeared in their headquarters near Prague claiming that

the fastest Java in the history is the incoming Java 9 and they should change their slogan immediately

Javapolis, the conference

Many of you might have heard about Devoxx conference originating from Belgium, but not many probably know that its original name was Javapolis. But, according to one of the former members of the team behind this event, the name was also affected by external pressure: “Java is a brand known widely in the many countries, many people don’t know English well and

someone might think that Javapolis is a secret Java Police department in our corporation responsible for hunting for incorrect usages of ‘Java’ word which is of course ridiculous and might show our company in a bad light

Spartak Myjava, the football club

All presented incidents are strange, but we have kept the best one until the end of this article. Please read a message we have found in our email box:

I am the chairman of Spartak Myjava, a small football club in Slovakia. We planned to build a new stadium, improve youth facilities but it was very difficult to find a sponsor willing to help us. Then suddenly, a company called Lightbend contacted us willing to pay 1 million Euro each year for becoming our main sponsor. The only thing they wanted is that club should be renamed to Lightbend MyJava. At first I was reluctant to do so, but our supporters convinced the board that it would allow us to move to a higher level, maybe even qualify to the Champions League so I agreed. Everything was ready, the contract was waiting only for the signature of the Lightbend CEO, but suddenly everything collapsed. After several calls to find out what had happened, the only thing we were able to get from them (of course off the record) was that another company threatened to sue them if the Lightbend name appeared close to ‘Java’ word.

We leave it without a comment.

Summary

We have seen many different things but recent attempts to practically ban one word from usage in the many countries, by different companies, places and people are very strange and hard to explain. We think that examples presented above are not the only ones and more will come. We promise to keep you updated. And of course, if you know any other examples, please let us know.

Image credits: Pexels.com and Wikipedia

Forcing Wicket to place JavaScript files at the bottom

Tue, 21 Feb 2017 00:00:00 +0000

When you add any Wicket component library, e.g. Wicket-Bootstrap to your project, usually it adds some JavaScript and CSS resources to every page or panel. But the problem is that these JS files are added in the <head> section of your page while all Internet knowledge says that JS should be placed at the bottom of the page for better performance and faster loading times. In this post I will show how we could configure Wicket to place JS files wherever we want.

Initial project setup

Let’s start with a simple one-page-one-form Wicket application counting days from the user’s birthday:

It has a dependency on the earlier mentioned Wicket-Bootstrap because we need its DatePicker component:

<dependency>
  <groupId>de.agilecoders.wicket</groupId>
  <artifactId>wicket-bootstrap-core</artifactId>
  <version>0.10.11</version>
</dependency>
<dependency>
  <groupId>de.agilecoders.wicket</groupId>
  <artifactId>wicket-bootstrap-extensions</artifactId>
  <version>0.10.6</version>
</dependency>

Our web page contains a form, one text field and one date picker:

public class HomePage extends WebPage {

	private String name;
	private Date birthDate;

	public HomePage(final PageParameters parameters) {
	  super(parameters);

	  add(new FeedbackPanel("feedbackPanel"));
          Form<HomePage> form = new Form<HomePage>("form", new CompoundPropertyModel<>(this)) {
            @Override
            protected void onSubmit() {
                info(format("Hello %s. It's nice to meet you! You are %d days old!", name, calculateDaysSinceBirthDay(birthDate)));
            }
          };

          form.add(new TextField("name").setRequired(true).setLabel(Model.of("Name")));
          form.add(new DateTextField("birthDate", new DateTextFieldConfig()
                .autoClose(true)
                .withLanguage("pl")
                .withFormat("dd/MM/yyyy"))
            .setLabel(Model.of("Date of birth"))
            .setRequired(true)
          );
          add(form);
      }

      private int calculateDaysSinceBirthDay(Date birthDate) {
        return Days.daysBetween(LocalDate.fromDateFields(birthDate), LocalDate.now()).getDays();
      }

}

Problem

When we run our application we will see that all Bootstrap related JS files are placed in the page header:

<head>
  <!-- ... -->
  <script type="text/javascript" src="./wicket/resource/de.agilecoders.wicket.extensions.markup.html.bootstrap.references.BootstrapDatepickerJsReference/js/datepicker-ver-1484131947646.js"></script>
  <script type="text/javascript" src="./wicket/resource/de.agilecoders.wicket.extensions.markup.html.bootstrap.references.BootstrapDatepickerLangJsReference/js/lang/bootstrap-datepicker.pl-ver-1484131947646.js"></script>
  <script type="text/javascript" id="bootstrap-js" src="./wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJavaScriptResourceReference/webjars/bootstrap/3.3.7-1/js/bootstrap-ver-1484131946909.js"></script>
  <!-- ... -->
</head>

It is not what we wanted, so we need to configure our application to add JS files somewhere at the bottom.

Solution

First, let’s start with some background. Each time a component wants to add something to the page header (for example using IHeaderContributor) it creates a new instance of HeaderItem object. By default all HeaderItems are rendered in <head>, but we could modify this behaviour using IHeaderResponseDecorator and FilteringHeaderResponse to separate HeaderItems into two places to render: header and a defined place in our page body.

First, we should define a place where all JS files should be rendered by adding a <wicket:container> element with id:

<!DOCTYPE html>
<html xmlns:wicket="http://wicket.apache.org">
	<body>
		<!-- ... -->
		<wicket:container wicket:id="footer-container"/>

	</body>
</html>

and add it to the Page class:

add(new HeaderResponseContainer("footer-container", "footer-container"));

The next step is to configure a response decorator and response filter that will direct some items to our footer-container bucket. This should be done in the init() method of our WicketApplication class:

@Override
public void init()
{
    super.init();

    IBootstrapSettings settings = new BootstrapSettings();
    Bootstrap.install(this, settings);

    setHeaderResponseDecorator(new JavaScriptToBucketResponseDecorator("footer-container"));
}

Our decorator should use a filter that is already in Wicket core module, a JavaScriptFilteredIntoFooterHeaderResponse that does exactly what we need:

A header response that creates two buckets. The header bucket will contain all references to CSS and markup from the <head> section from the page. The other bucket will contain all other header items, and you will need to add a HeaderResponseContainer to the footer of your page (typically just before the end body tag) to render those items.

So it will split all our HeaderItems into two buckets, one (default) that will be rendered in the page header and the second rendered where we placed footer-container element. The working version of our decorator looks as presented below:

public class JavaScriptToBucketResponseDecorator implements IHeaderResponseDecorator {
    private String bucketName;

    public JavaScriptToBucketResponseDecorator(String bucketName) {
        this.bucketName = bucketName;
    }

    @Override
    public IHeaderResponse decorate(IHeaderResponse response) {
        return new JavaScriptFilteredIntoFooterHeaderResponse(response, bucketName);
    }
}

After that we can rebuild our application and see that all our Bootstrap related JS files are rendered at the bottom of our page, improving performance and the overall experience of our users.