java

Dropwizard Deep Dive – Part 3: Multitenancy

Hello once again! This is Part 3 of a three-part series on extending Dropwizard to have custom authentication, authorization, and multitenancy. In Part 1, we set up custom authentication in Dropwizard, and in Part 2, we extended that to have role-based authorization. For this final part, we are going to diverge slightly and tackle the related but different concept of multitenancy.
Read more on Dropwizard Deep Dive – Part 3: Multitenancy…

Dropwizard Deep Dive – Part 2: Authorization

Welcome back! This is Part 2 of a three-part series on extending Dropwizard to have custom authentication, authorization, and multitenancy. In Part 1, we set up custom authentication. When we left off, we had just used the Java annotations @RolesAllowed and @PermitAll to authenticate our resource methods, so they will only run for credentialed users. In this part, we’ll cover Dropwizard authorization. We are going to extend the code we added to check the role assigned to a user and further restrict our methods based on whether that matches.
Read more on Dropwizard Deep Dive – Part 2: Authorization…

Unsubscribing from an RxJava Observable Mid-Stream

Imagine a scenario where you need to create an Observable sequence that will acquire a resource, do some processing, and release the resource when unsubscribed from. An example of something like this might be an Observable that acquires a lock and releases it when unsubscribed from. That “lock” signal could be merged with a second signal that does some work that should only be done after the lock has been acquired.

Read more on Unsubscribing from an RxJava Observable Mid-Stream…

More Typing, Less Testing: TDD with Static Types, Part 2

In part 1 of this post I claimed it’s easy to test-drive our way into a poor design. We looked at some techniques for using types with TDD, but the examples were simple. Today I’ll walk through Kent Beck’s Money example showing where the design fails and how it can be improved with types. Read more on More Typing, Less Testing: TDD with Static Types, Part 2…

More Typing, Less Testing: TDD with Static Types, Part 1

I learned test-driven development from Kent Beck’s book Test-Driven Development By Example. It’s an excellent introduction that whets the appetite for one of my other favorites, Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce.

Both of these books have a blind spot, though: they are completely silent about how modern static type systems might augment or even replace tests. After reading these books, it’s easy to think that “typing” mainly has something to do with keyboards. Read more on More Typing, Less Testing: TDD with Static Types, Part 1…

Serving Static Assets with DropWizard

Over the last few months, I’ve had the opportunity to do a lot of work with DropWizard, an awesome Java web framework for developing RESTful web services.

I was recently prototyping a small application, and I wanted to serve static files directly from DropWizard. While this isn’t what DropWizard is primarily designed to do, I didn’t want to go through the process of setting up another web server just to serve static assets for a prototype. While DropWizard has some out-of-the-box support for serving static assets, I found the documentation surrounding it to be incomplete and confusing. It actually took me a couple hours of debugging to figure out how to do exactly what I wanted, So I thought I would document what I learned here.

My end goal was to serve a small single page JavaScript app on the root of my DropWizard application, while having my DropWizard REST endpoints available at /api. The limited documentation around serving assets in DropWizard suggest that setting up an AssetsBundle for / and changing the application context path in your config file should be enough to achieve this, but that did not work for me. I had to do the following steps: Read more on Serving Static Assets with DropWizard…

Simple Flow Control Made Easy

We are currently working on a product that utilizes a long-range and low-bandwidth network. Moreover, the devices that are being communicated with are severely limited with regard to memory availability and CPU cycles. Given these constraints, it’s important that the network and devices are not overwhelmed with traffic.

Recently, we encountered an acute problem where the network and devices could easily be overwhelmed if they are powered on and join the network at approximately the same time.

Problem

When the devices join they communicate with a server, informing it that it has just joined and that it needs to be configured (name, time, etc.). It will continue to send these configuration requests at a steady rate until it receives all of the necessary configuration information. The problem is that the server would gladly respond to every request, even if the information it is sending is duplicated.

We had to make sure that duplicate messages were dropped within a certain time period. Read more on Simple Flow Control Made Easy…

Floating Point Numbers & Currency Rounding Errors

A reminder to those who learned this lesson long ago, and a warning to those that have not learned it for themselves: Don’t use floating point numbers for money.

When doing any kind of calculation with currency, accuracy is extremely important. And floating point numbers (floats and doubles) don’t have an accurate enough representation to prevent rounding errors from accumulating when doing arithmetic with monetary values.

An excellent StackOverflow response that explains the issue states:

Representing money as a double or float will probably look good at first as the software rounds off the tiny errors, but as you perform more additions, subtractions, multiplications and divisions on inexact numbers, you’ll lose more and more precision as the errors add up. This makes floats and doubles inadequate for dealing with money, where perfect accuracy for multiples of base 10 powers is required.

Ways it Can Go Wrong

When it comes to dealing with money in a computer program, a developer needs to stay ever-vigilant. Just because you, or a previous developer, made the right call by using a DECIMAL column when creating the database schema, doesn’t mean that accuracy can’t be lost before the result of some calculation is displayed to an end user. It’s all too easy to slip up and lose the necessary accuracy without even realizing it. Read more on Floating Point Numbers & Currency Rounding Errors…