by on

In one of the spring web applications we decided to use Log4J2 with SLF4J; when we deployed the web app in tomcat server along with the required jars we stumbled on the issue multiple binding for SLF4J and spring dependencies not getting satisfied. We had used Gradle and there were transitive dependencies which included log4j-12xx.jar and slf4j-log4j.jar as some of the dependencies in the project were using log4j version 1 for logging. Here is how we were able to start logging using log4j2.

Exclude the log4j-12xx.jar and slf4j-log modules from the gradle build

configurations {
 all*.exclude group: "org.slf4j", module: "slf4j-log4j12"
 all*.exclude group: "log4j", module: "log4j"
}

Add the following jars

org.slf4j:log4j-over-slf4j|route all the log4j v1 to slf4j
org.slf4j:slf4j-api|slf4j api
org.apache.logging.log4j:log4j-slf4j-impl|log4j2 bridge
org.apache.logging.log4j:log4j-core|log4j2 core
org.apache.logging.log4j:log4j-api|log4j2 api

Add the log4j2.xml configurations to the classpath or as specified at log4j manual

by on

What does a boom in an industry bring in? It brings in a shortage of talent.

What does shortage of talent bring in? It brings in a great demand for the talent.

What does great demand mean in a shortage of talent? It increases the supply in an inorganic manner and inverse vandalism occurs.

In a country called Noviland, carpentry was an expensive business dictated by undersupply of wood as the wood cutters only had access to axes. This kept carpentry and arts related to wood accessible only to the elite and the academics who studied carpentry. This brought in many skilled and intelligent people to the field who were well respected and well paid, people were committed to workmanship. Even though the forest cover was huge in Noviland, technology of axes led to a limited supply.

A wood cutter’s daughter invents a circular saw that can be driven through the bicycle gears which helps to cut trees at 10 times the pace they were used to. Suddenly the supply of wood increased ten fold and there were not enough carpenters. The demand for carpenters grew way too much that it drove their paychecks very high, prompting people to switch careers. Those who learnt other trades, tools and works now did a simple study of hammer, nails & saw and jumped into the profession.

Maintaining old work was easy as everything was in place and simple maintenance tasks were all required to keep up. New work is were all the hell broke loose. People were now getting furniture that does not last long, wooden bridges collapsed on a few days of exposure to heat and rain. People who wanted to replace their furniture dreaded at the cost of replacement and replacement failures. There were way too many carpenters and finding passionate people was next to impossible. Carpentry became a high paying job where no passion or study was required, all it matters was to know about hammer, nails and saw. Some of them who did exceptionally well were immediately made a manager and given interns to manage thereby killing passionate carpenters in the interest of scale.

Software engineering in a few countries is at this state, merely having a crash course in Java and understanding of few libraries are enough to be called as a programmer. Programming is not just writing code, it is solving a communication problem which involves many aspects. Lots of productivity is lost because of the failure to understand and implement good engineering practices. Some people pick agile as a tool to enhance productivity but do nothing to improve the capability of the developers. There are so many practices which can help us develop and release software in days & weeks but many of us are still stuck at the timescale of months & years because of the ignorance of practices as well as reduced progression on the skill level.

Below is a table which helps us to find where we stand in terms of skills, I can say with confidence that even with 10 years of experience many of us will not rate ourselves proficient. We should let skill and passion dominate engineering fields.

 Table source: http://science.raphael.poss.name/programming-levels.html

 

by on

If you want to walk fast, walk alone; if you want to walk far, walk together

When I talk about pair programming, I am confronted with things like return on investment, efficiency etc. The arguments which come against are with very simple programs and simple domains where it does not matter you pair to program or test drive the code. Beyond the fibonacci and measurement problems there are complex domains which people get involved to solve problems and pair programming helps there.

A good analogy is racing. Racing falls into circuit racing and rallies, if we note that circuit racing like Formula-1 or driving around in circles like in NASCAR has only one driver. These ones are repetitive with relatively very few unknowns and parameters for the driver to take care. The moment you know about the car condition and the track conditions and few laps taken then the driver’s mind is on autopilot. Rally unlike circuit racing has lots of challenges, we just roughly know the route and it could be riddled with lots of surprises and obstacles. There is no way that a driver without a co-driver (navigator) could win the race.

Pair Programming

Programming at work is like rally driving, many of the examples which people take up for classroom sessions are similar to Formula-1 or NASCAR driving; which is the primary reason that most of them fail to see the potential benefits of pair programming. Depending on the nature of the task at hand we should be able to decide if we need work in pairs, group or alone to find a solution to the problem. Having a blanket rule to always program in pairs or avoid pair programming will force us to fit into one of the styles of work which may prove counter productive. Always failures are taken as strong examples than successes and if we fail in choosing the wrong approach, chances are high that the approach itself will be called a failure.

Image courtesy of patrisyu / FreeDigitalPhotos.net