Getting Stomp working using Spring was very easy. It didn’t seem that easy to me because I tested my implementation with an integration test which seemed to fail at least as much as it succeeded. In this post I will take you through my journey of getting a stable integration test on Spring Websockets.
Congratulations! Someone has made the wise decision to hire you as the new technical lead. It is an exciting time. You start in a new environment, will be working with a new team and maybe even have to learn new technologies along the way. This can be quite challenging. In the first article I wrote about introducing change. In this second article I want to share my personal views on shaping great teams. As team lead, there are certain values that are just part of me and they way I think about leadership. Fortunately, in JDriven I found a company that matches my values step by step. These values are #commit, #develop and #share. In this article I want to go into some of the values that I consider important to create a great team.
I consider sharing knowledge one of the most important values. Teams consist of people with different experience levels and backgrounds. It should be everyone’s goal to help each other grow and develop. You can share knowledge in many ways. Some examples are pair programming, help troubleshooting/debugging, collaborate on a design or technical sessions or writing articles. By doing this we grow as a team. Where one gains technical skills the other gains leadership skills or new insights. Also don’t forget that even experienced architects can learn about new technologies from new programmers. Asking for help from others also shows that you’re not some all knowing dictator and one man team. Working on complex projects is a team effort that benefits from actively helping each other.
With the release of Java 9, and the introduction of Project Jigsaw (the Java Platform Module System), we no longer have the need for a full-blown JRE to run our Java applications. It is now possible to construct a stripped-down Java Runtime, containing the minimum set of required modules. This allows us to create slim Docker containers without excess baggage. The source code belonging to this blog post can be found at: https://github.com/rlippolis/java9-runtime-image
Our example application consists of two Java 9 modules (basically two JARs, with a module-info.java).
We assume the concept of modules is familiar to the reader.
If not, you can learn more about it e.g. here: http://openjdk.java.net/projects/jigsaw/
Firstly, we have a backend module consisting of a class which provides us with a String (to keep it simple).
The backend module has no explicit dependencies on other modules (only an implicit dependency on java.base).
Secondly, we have a frontend module consisting of an executable main class.
This class gets the String from the backend and prints it to System.out (again, very straightforward).
This module has an explicit dependency on backend, and an implicit dependency on java.base.
To see the application in action, build it with Maven (mvn clean package), and run it from the command line:
(or use the provided run-app.sh) The -p option sets the module path (similar to the 'old' classpath).
The -m option specifies the module and class to run.
Congratulations! Someone has made the wise decision to hire you as the new technical lead. It is an exciting time. You start in a new environment, will be working with a new team and maybe even have to learn new technologies along the way. This can be quite challenging. In this two-part article I want to share my personal views regarding Introducing change and shaping teams as a technical lead.
When starting in this new environment you probably bring lots of energy and want to leverage your experience to change things for the better. In my opinion introducing changes in a new environment requires some consideration.
