Aug 18

I have tried finding an example implementation for this online and to my surprise nothing I found did the trick. Therefore I am sharing my solution here in case anyone else runs into this in the future. I am new to Spring Boot and it's possible there are other, better ways to go about it, but something is better than nothing.

The problem

You want to make an http call from your server to another server, but you don't want to block your thread waiting for the other server to respond. How do you do that in Spring Boot?

The solution

WebClient does the trick. Check out the following implementation:

public CompletableFuture<String> loadDataFromAPI() {
    CompletableFuture<String> future = new CompletableFuture<>();
    try {
    } catch (Exception e) {
        LOGGER.error("Failed loading data from API", e);
    return future;

I won't go over this code line by line as it should be self explanatory. There is no error handling here, I just wanted to provide a barebone working example for you to build upon.

May 17
Unless you are a one person team, you are working with a process. It can be an explicit and defined process like Scrum or Kanban, it can be something of your own concoction, or even just a set of unspoken rules and expectations among you and your coworkers.
The thing about processes is that they can either be the best thing for your team's productivity, or they can be the reason your team never delivers anything on time. Sadly, most processes tend to gravitate towards the inefficiency end of this spectrum. That's why when people think of processes they usually have an alarm bell going off in their head. They perceive the process as something that gets in their way, stops their flow, dictates their actions and generally just slows them down. And with good reason: Who among us was not victimized by coma inducing meetings, or conventions that consume precious time without actually producing any tangible value?
Process tends to become inefficient in a similar way to how software tends to become bloated: It contains bugs, it accumulates useless features over time, and it gets filled with ad hoc solutions to problems that no longer exist. Process, like software, can easily become cumbersome to the point of embarrassment. Unless, that is, someone cares enough to stop every now and then and clean it up.
This is true no matter what kind of process you have in place. This is why you need to hold retrospectives at regular intervals.

Read more »

Sep 16

Habitmint.com is a hobby project that intends to provide a nonsense-free, cross-device assistance in tracking your daily habits and goals. I've been using it personally for months now and I'm very happy with the outcome.


Read more »

Oct 15

I find myself keep needing this, so I'm posting it for my future reference and perhaps yours.




The short of it:


mklink /J [target-folder] [source-folder]




mklink /J C:\Users\Matthew\Desktop\Dropbox C:\Users\Matthew\Documents\Dropbox
Sep 15

While working on a new pet project I ran into an annoying problem with Foundation Zurb 5's top bar dropdown. I couldn't find any solution on the web so I thought I'd share a workaround.

The Problem

The top bar dropdown is shown and hidden using CSS in a way that prevents the click event propogation. If you want your menu items to do something other than an href, like listening to a click and doing something programmatically, you're out of luck - the event won't fire.

Here's a JSBin with the problem demonstrated:I've added click listeners on the menu items that should open an alert window when clicked. Try clicking on dropdown->link, nothing will happen. This is because the element is hidden before the event can trigger.

The Workaround

I wanted to keep Foundation's hiding CSS because in the comments it is said to support accessibility. I assume there is some learned knowledge sunk into it so I prefer not to touch it directly, but manipulate around it with code.

Therefore I won't call it a solution because it's not elegant enough, but it works and should get you out of the bind if you're in it. I'm using the scss version so I'll describe what I did there. At the bottom of the post I've linked a JSBin with the solution in plain CSS.

Open _top-bar.scss, and find the following snippet:



The @include represents the following CSS:



(plus a display:block)

Move the @include into a new class (give it whatever name you see fit)


Now, in your HTML, add the class to the dropdown. I am using Ember so the following is a Handlebars template:


The unelegant part is that you need to control the dropdown visibility from code. It shouldn't be super dirty; if you listen to clicks on the dropdown and toggle the hiding class it should do most of the trick.


Here's a JSBin with the solution with plain CSS


If you have a nice CSS only solution for this please share in the comments.

Aug 15



The purpose of the technical overview is to present approaches for tackling and solving challenges from start to finish. I am aiming this series for intermediate level developers. This means that I expect the readers to be fairly familiar with programming and some web technologies (i.e. not complete beginners), and I will spend very little time delving into implementation details, so very experienced developers may be familiar with most of the content.

Read more »

Aug 15

Despite being a blasphemous Windows user, I still  love using the git bash. It's way quicker than GUI for many operations, and it allows me to immediately check which branch I'm on. Combined with the knowledge of a few keyboard shortcuts, I can also perform quick operations on multiple repositories in sequence by having several bash instances open. This flexibility is simply unrivaled by GUI.

There are some operations, though, where the power of GUI really shines through. When committing changes, for example, I like to go over every file I changed and  go over the changes quickly to make sure there are no stray debugging leftovers, surprise code changes that I didn't expect, or commented out sections that need to be uncommented. I find this habit to be a valuable tool in reducing bugs. Via Bash, it is much harder to quickly scan large amounts of code. Another example where GUI is better is when resolving merge conflicts. Again, the ability to see large amounts of code, in this case side by side, makes Bash the lesser tool when compared to GUI. Finally, viewing the changes log is something I do often; GUIs tend to have log features that the default git log command doesn't support: A graph showing how the branches are connected, changed files for each commit, etc.

Therefore, I came up with a few shortcuts that trigger the GUI from Bash, winning me both the flexibility of command line and the ease of use of large graphical screens when I need them. In this tip I will be demonstrating with the TortoiseGit GUI, but the same principle can apply to any GUI that offers command line arguments.

Read more »