Montag, 17. Juni 2019

Intellij Order Of Imports

IntelliJ sometimes changes the appearance of imports in the code on checkout when organizing imports.

To control that, one can adjust the settings:

Settings -> Editor -> Code Style -> Java -> Layout static imports separately

Change the order as you need, IntelliJ will sort the imports accordingly.

Getting Gradle Dependencies in IntelliJ IDEA

Gradle Project Import


  1. Import the project as a Gradle project from within Idea.
  2. When you add a dependency you need to open the Gradle window and perform a refresh

Gradle Wrapper

  1. IntelliJ will ask you to auto-import Gradle in some cases. This can be done.
  2. Gradle Wrapper - many environments will use this wrapper to maintain the same standard between the different environments and stages. How to:


Ctrl + Shift + Alt + S → Import Module → Import Module from external model → Choose Gradle → 
For Gradle Home: Use gradle 'wrapper' task configuration.



Donnerstag, 13. Juni 2019

Kafka vs. MQ + JMS - Difference Apache Kafka and MQ, RabbitMQ, ActiveMQ, JMS

Kafka is a messaging system. From the ground up it has been designed to provide high throughput, fast performance, scalability and high availability.
Here are the basics:
  • Producers of the messages publishes to the Topics
  • Consumers subscribes to the Topics
  • Messages are array of bytes. They can be JSON objects, Strings etc
  • Topics are logs of messages
  • Kafka is run as a Cluster of servers each of which is called a Broker



1. Kafka has no P2P model. Message order will remain.
In Kafka there is no concept of Queue and hence no send or receive for putting/getting messages from the queue. Publish-subscribe is the only paradigm available as a messaging model. Producers of the messages Publisha message to the Topic and Consumer receives messages by Subscribing to the topic. This publish-subscribe paradigm is very similar between MQ/JMS and Kafka - the difference is under the covers that we will discuss next.

2. Message Persistence
Typical JMS providers (IBM MQ, Rabbit MQ, Active MQ ..) implement the topics in a such way that the messages published to the topic are sent to a common storage (memory or/and persistent store) from where they are picked up by the subscribers. In MQ/JMS systems once the message is read it is removed from the storage and is no more available. Kafka retains the messages even after all the subscribers have read the message. The rentention period is a configurable parameter.
In a typical MQ/JMS consumer implementation, the message is deleted by the messaging system on receiving an ACK/Commit. If for some reason the message gets processed but fails before the ACK/Commit, it would lead to message being read more than once. This problem has been addressed by Kafka by way of message retention and state management based on the consumer offset.

3. Topic partitioning
Kafka has implemented the topics as partitioned logs. A partition is an ordered, immutable sequence of messages that is continually appended to. This is similar to database log, for that reason the partition is also referred to as the commit-log. This is one of the biggest difference between MQ/JMS and Kafka. The partitioning of the topic leads to its high throughput (and parallelism). 

·         Partitions for the same topic are distributed across multiple brokers in the cluster
·         Partitions are replicated across multiple servers; number of replicas is a configurable parameter
·         Each Partition has one server as a leader and a number of servers as followers
·         Each Server acts a leader for some of its partitions and as a follower for some other
·         The Producers are responsible for choosing which message to assign to which partition within the topic based on key assigned to message.

5. Message sequencing
In MQ/JMS there is no gurantee that the messages will be received in a sequence in which they were sent. In Kafka though the sequence is maintained at a partition level. In other words if the topic is configured with a single partition then the messages are received in the same order that they were sent in. 

6. Message reads
The consumer of the messages in Kafka issues a fetch request to the broker leading the partition it wants to consume. As part of the fetch, consumer specifies the offset from which the message in the log is read from. This is very different from the MQ/JMS messaging system where First In First Out (FIFO) is the way messages are read off the queue/topic. The other thing that happens is that with offset based control, the consumer can re-read the same message which is not possible in MQ/JMS (yes you can do it with browse but that is not what it is intended for).
This rewinding mechanism can be very handy in some situation. E.g., if you received a batch of messages and processed it with buggy code, you may fix the code and re-run the processing on the messages by resetting the offset.

7. Load balancing
In the case of MQ/JMS the load balancing required messaging systems to be designed using some clustering mechanism and the onus of distributing the load across the cluster members was on the producer sending the messages. The Kafka nodes publish the metadata which tells the producer which servers are alive in the cluster, where the leader for the partitions are. This allows the client to send message to the appropriate server (and partition) thus distributing the message load across the cluster members.

8. Automatic failover & High availability
Traditional MQ/JMS implementations did not have the concept of message replication but some systems built it over a period of time; those replication features at most times were not leveraged in favor of simplicity. In Kafka, as decribed earlier the messages are replicated (leader-followers) for each topic's partitions across a configurable number of servers. This inherently leads to an architecture that provides automatic failover to replica thus leading to high availability.

Zookeeper
Zookeeper plays a central role in this replication mechanism. The follower servers maintain a session to zookeeper and respond to the heartbeat messages. The slaves/replicas continuously read messages from the leader as fast as they can as to not fall behind. The leader if discovers that the slave is lagging removes it as the replica; this is determined by way of configurable parameters. The message is considered committed when all replicas are in sync with the leader. This sync aspect is also configurable.
The state of the replication is managed by the leader server and leader may drop the replica/slave if the replica is lagging too far behind or is unresponsive.


Montag, 27. Mai 2019

My Advice to Founders + Anyone Starting Their Own Business


Here is my advice when you are about to start your own business.

No matter what business you start, at a certain level it is all the same. 

#1 Get a Coach

Look for someone who is able to help you out by giving advice to you. The best thing was if this person has already achieved what you want to achieve. For instance, my own Coach is successfully running multiple companies. It may cost you money but investing in yourself is the best thing you can do!

#2 Manage yourself as a boss and employee in one. 

Enjoy the freedom and flexibility regarding time, appointments and mindset - you are your own boss now. Because of this: negotiate clever and be tough as nails regarding your ressource planning, even more with yourself ;)

#3 Go with the flow 

It is easier for me to accept the limits or moods of my employees than accepting my own. But if I hit the floor because of sleep deprivation or anxiety, my business will go down, too. Thus: 

#4 Be kind to yourself

... as you do already have proven that you have the courage to walk your own path. Being kind to yourself will help you to not crack under the pressure. 

#5 Fun is the most important thing

Life is too short. Never forget that stress is a powerful force. Do always remember that fun is what this is about. The rest will follow - #lawOfAttraction 

Wish you much success with your business and all the best! 
Tim

Montag, 29. April 2019

Spring Security - get User Name

If you want to retrieve the name of  a logged in user, do this:


import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.core.userdetails.UserDetails;
private String getUserName() {
    Object principal = SecurityContextHolder
          .getContext()
          .getAuthentication()
          .getPrincipal();

    String userName;

    if (principal instanceof UserDetails) {
        userName = ((UserDetails)principal).getUsername();
    } else {
        userName = principal.toString();
    }
    return userName;
}

Mittwoch, 24. April 2019

Recover and Restore System Properties with Java - JUnit and more - Free program

Sometimes it is necessary to change System Properties. Maybe for a Test or something else. This program and test will recover and restore the System Properties to their initial state.
The program and test may be used freely under GNU General Public License Version and is brought to you by Harder IT Consulting www.harder-it-consulting.de
  

Mittwoch, 17. April 2019

Mock static methods with Mockito in Java (mock, static, method, java)


import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.BDDMockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;


@RunWith(PowerMockRunner.class)
@PrepareForTest(MyStatic.class)
...


@Test
public void someTest() {
    
    //given    
    PowerMockito.mockStatic(MyStatic.class);
    BDDMockito.given(MyStatic.someStaticMethod()).willReturn(...);

    //when
    ...

    //then     
    PowerMockito.verifyStatic();
    MyStatic.someStaticMethod();

    assertThat(//your further asserts....

DOCKER - No Space Left on Device // How to clean Docker on Linux

Sometimes Docker will simply claim to much space. Time for a clean up ;) docker system prune -a -f