Skip to main content

Posts

Showing posts with the label Basics

What We Want to See in Good Developer?

"Industries are saying It’s becoming more difficult to find good developers and developers are saying what you want to see in good developers."   Here are a few key points which I feel as a good developer are important. Attitude A positive attitude is one of the most important qualities of a good developer. Sometimes "getting shit done" attitude is much needed. you have to come out of your comfort zone. It can happen after all hard work and efforts, a good tester can still find defects in the code. In those cases, acknowledge the good tester and rethink yourself how you could make sure to avoid such a mistake in the future. How quick to learn Whatever you know is important but at the same time when got new things how quickly you learn is also equally important. The pace of learning new things and applying that knowledge is crucial.  Approach on a problem solving / Debugging Skills It shows a real picture when you stumbled into a problem a

The SOLID Design Principles

Classes are the building blocks of your java application. If these blocks are not strong, your building (i.e. application) is going to face the tough time in future. This essentially means that not so well-written can lead to very difficult situations when the application scope goes up or application faces certain design issues either in production or maintenance. In this article, I will list down most recommended design principles that you should keep in mind, while writing your classes. These design principles are called SOLID, in short. These principles Make easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to easily refactor code, avoid code smells and are also a part of the agile or adaptive software development. SOLID design principles are : S - Single-responsiblity principle O - Open-closed principle L - Liskov substitution principle I - Interface segregation principle D - Dependency

Why Dozer Framework (Bean Manipulation)

Why Dozer ? Let us think about a situation that you have a source bean which contains lot of fields and the source bean belongs to a different project or module. Now you want to expose the bean to  the outside world as a part of your web service REST service development. It is not advisable to do it. There may be the following reasons. The source bean is not serialized and a final class. The source system does not allow doing it because of security breach. The source bean is very heavy and contains lot of nested beans. The source bean has fields of different types which may not be required for other system. The source bean has lot of fields; some of them are not required. Scenario to use Dozer Suppose You want to make a REST call or web service call to get the minimal account details of a person. But the source system has a bean called “Acc0untBean” which contains many sensitive information like person’s internet banking passw0rd, PAN no or social securit