The synchronized keyword ensures that only a single thread can execute a method or block at one time. It should not be confused with a mutual exclusion concept, that prevents an object from being seen in an inconsistent state by one thread while it’s being modified by another. Proper use of synchronization keyword guarantees that no method will ever observe the object in an inconsistent state.

Exceptions improve a program’s readability, reliability and maintainability. Basically there are three kinds of throwables: checked exceptions, runtime exceptions and errors. The main rule of using checked exception is this: use checked exceptions for conditions from which the caller can reasonably be expected to recover. When the checked exception is thrown, the caller forced to handle the exception in a catch clause or to propagate it outward(forward the exception to upper caller).

Quite simple but interesting problem. First I have been thinking how to solve it, I was considering to apply stacks to hold the substrings while I’m flying around with start and end indexes. Then I have realized that I don’t actually have to show the longest substring. I just have to show the length of the longest substring.

Here I try to put up some of the usefull git commands. Refer to it whenever quick check is needed.

Last time when I read the book Effective Java I met that example about generics from Item-28. Authors have introduced quite a good example with Chooser class, where they are trying to convert it to generic from non-generic class. This time when I’m reading book again I met this example and decided to put it here.

I would like to share my experience working as a developer at TMon (TicketMonster), one of the top Korean E-commerce company. Originated back in 2010 by five guys as a startup, where only two of them were developers. I think the story of TMon can be considered one of the successful stories. Even though I haven’t worked for long (1 year and 13 days saying exactly) to judge TMon. I can tell “it is good place for Developers” (<– for TL;DRs)

Inheritance is a powerful feature of the OOP that is used to achieve code reusability. But it is not always the best tool for the job. It is safe to use inheriance within a same package, and the reason is because super and sub classes are under the control of the same team (Or even a same developer). The issues are started when the developer of the super class and sub classes are different teams. It may occur that super class has not been designed to being inherited. So what kind of problems may occur when we extend the class which is not devoted to be inherited.

When we use Spring Security in a standard way, it performs quite a standard actions. For example, Spring Security blocks the un-authenticated requests to the resource (URL resource) and redirects (with 302) to the /login page. But sometimes we want different behavior. Customized behavior such as if the requester is web-browser we want to redirect them to the /login page. But if the requester is not a browser and purely generates RestAPI type of request, then redirection would have no sense. Of course, we could have written some logic on the requester client side to consider 302 as non-authorized behavior.

I have found combination of these three is a quite interesting topic. Actually four, because usually Spring Session is used with Spring Security. There are many resources for Spring Session storing in Redis, but when it comes to storing session in Json format not many infos are there. I have found some but I felt they were not good enough to finish up practically.