This is a story about how I leveraged some of the Python’s lesser known capabilities to my advantage in solving a regular expression problem in a rather esoteric way (as we’ll see) on a popular coding platform called Hackerrank.

It’s been 5 years since and I think I can finally come out of the closet and reveal to the world what I did that day.

Year 2016, January. The 7th.

I was in the third year of my Computer Science undergrad when I came across the Regular Expresso challenge on Hackerrank. I found it intriguing that I had to solve…

Explore the various ways to tackle unoptimised MySQL queries.

Many times you’d like to profile the query that is being executed. This could be due to a myriad of reasons.

• Current execution is latent and we need to optimize.
• To figure out unused indexes or to determine if indexes are even potentially on the query path or not.
• To figure out the query execution plans.
• To profile the time taken for the queries at the server.

Slow Query Logs

If you are experiencing misbehaving or slow queries, first and foremost, the server should be set to log them. …

And how to make the most of them for non trivial use cases in production

Logs are the lifeline of any non trivial application running on production. Any one who has been an on-call at their workplace can corroborate the significance of proper application logging when things go south at 3 AM.

For applications built atop the JAX-RS framework with an implementation such as Jersey, the solution is usually to register the Logging Feature with the environment. This works both on the client side and the server side.

environment.jersey().register(
  new LoggingFeature(
     Logger.getLogger(LoggingFeature.DEFAULT_LOGGER_NAME),
     Level.INFO,
     LoggingFeature.Verbosity.PAYLOAD_ANY, 
     1000
   )
);

With this simple…

In this article, we continue our journey of building the support for Unit Of Work for JDBI in Dropwizard.

Having described how the Jdbi Handle Manager, Event listeners, Transaction Aspect and the resource layers work in liaison, we now turn our attention to the possible implementations for the handle manager.

Recall, the contract for a Jdbi Handle Manager.

In this article, we continue our journey of building the support for Unit Of Work for JDBI in Dropwizard.

Recall the plan that we were supposed to follow:

Dropwizard provides a very slick UnitOfWork annotation that provides a declarative method of scoping transactional boundaries across requests.

It provides a very convenient no frills way for the developers to simply focus on the logic and rely on Dropwizard that the work performed will be done as a unit. Anything goes wrong (more on that later) in this transaction and it will be rolled back else it commits. Fine and dandy.

We wish to leverage Dropwizard metrics for async callbacks. The likes of @Timed or @ExceptionMetered for methods that return Futures or CompletableFutures or Callbacks.

Codahale metrics is an amazing library that provides various instrumentation tools. The default metrics registry used in Dropwizard applications is from Codahale metrics.

These annotation for marking a method of an annotated object make the code much more readable and separate the unnecessary boilerplate of marking metrics from the business logic.

However, the second approach won’t produce correct results as if the calling thread dispatches the work to another thread in the fork join pool and…

Recently, in our projects, we had a requirement to handle validations on the fields in the Java models sent by the client from the UI as a JSON response.

For the purposes of demonstration, let’s take a sampleDto as our model object. It kind of looks like this

@Getter
@Setter
public class SampleDto {    public Integer sampleInteger;
    public String sampleString;
    public List<Integer> sampleList;}

Fairly simple. Notice the use of Lombok For @Getter @Setter annotations which have been used to emphasise brevity. Consider a typical MVC type architecture. This dto/model will be passed in from the user as a JSON…