Recently, I used AWS ElasticBeanstalk a lot to deploy a few applications and it is always a pain to configure all the environment variables I need to run my applications.

To solve this problem, I published a small application that enables you to manipulate your environment directly from your configuration files: ebenv.

When I write an Angular application, I usually create a constant module to store my environment variables:

angular.module("myApp").constant("Config", {
  API_URL: "http://localhost:8080/",
  GITHUB_CLIENT_ID: "xxxxxxxxxxxxxxx",
  ...
});

I can then inject my config anywhere in the application and use those variables.

These variables can change based on where the app is deployed and I needed a simple way to define several environments. Since I use Grunt to build, test and deploy my javascript apps, I wanted to find something that would be seamlessly integrated in my build process.

A few weeks ago, I released a first version of emoji-java on maven central! The lightweight library helps you easily handle emojis in your code.

Find the code on Github and spread the world ;)

Since I moved to the US, I’m constantly checking the time it is around the world: sometimes in France to contact my friends, sometimes in New York where some coworkers are, etc. The thing I need the most is the UTC time. All our database and deployment timestamps are UTC and I don’t really enjoy the mental gymnastics I have to perform to get the right time :)

The Mac dashboard doesn’t provide a UTC clock widget so I decided to create one!

As I told you a few days ago, I launched a new service called userinfo.io that helps you get the geolocation information of your user in no time.

When I was writing the javascript library for userinfo.io, I wanted anyone to be able to use it easily.

Most of the developers simply include the scripts in their pages:

<script type="text/javascript" src="myscript.js"></script>

But when you are writing more important javascript projects, it is frequent to use a dependency mechanism such as requirejs, which is based on the AMD API.
Instead of assigning your module to a global variable, you can define an AMD module which will be imported in the project under the name the developer will choose.

In one of my projects, I needed a reliable way to get a visitor’s IP address and his location in Javascript, without a server. There is a wonderful thread on StackOverflow which gives a lot of solutions but when I tried them, they were either not working (400/500 errors) or not returning the data I needed.

So I decided it would be fun to write a small webservice to do just that: http://userinfo.io.

I recently discovered a very useful chrome plugin called Octotree.

Whenever you’ll visit a repository on Github, it will open a sidebar with a file tree which will help you navigate easily in the contents!

These days, I spend a lot of time writing documentation and procedures in order to share my knowledge of Ubleam’s system and help the team handling the servers when my contract will be over.

I decided to use markdown since I think the syntax is really easy to learn (anyone will be able to edit my work) and it compiles to HTML (providing a good way to visualize the content).

The drawback is that even if a lot of text editors handle the markdown compilation, I would have to make sure that my HTML files were updated each time I made a modification in a markdown.

Then I discovered grunt-markdown.

I just refreshed the design of this site for something more colorful. The theme was inspired by Hyde, a delightful Jekyll theme by @mdo.

I didn’t fork directly the Hyde project because I wanted to dive in the less code to experiment some new concepts. Basing my structure on something made by one of the creator of Bootstrap is a good way to learn ;)

The points I wanted to explore were mainly:

• The media queries: how to adapt my layout and my design to the different devices.
• The less code structure: how to organize my code.
• The less mixins: how to create useful functions that can be reused across the stylesheets.

When I was learning how to do that, I found the Code Guide by @mdo. It contains a great amount of useful recommendations on how to write and organise your code. Check it out!

If you want to take a look at the code of this blog, you can find it on github.

Yesterday, I wrote about custom Mockito matchers and this article is an example of a real usage of these matchers. In my code, I often use wrapper services that call distant APIs. The service builds a JSONObject that will be sent to the server so I need to make sure that it is correct. In order to do that, I need a custom JSON Mockito matcher.

Mockito is an awesome mocking framework that helps you simulate objects and services which have a complex or non-deterministic behavior in your unit tests.

When I check if there are interactions with some of the mocks, I sometimes want to perform custom verifications. In order to do that, let’s see how to write custom matchers with Mockito!

The debate is as old as Java itself: should we use checked or unchecked exceptions when there is an error? After reading A LOT of posts on the subject and chatting with lots of developers, I concluded that there is no right answer.

In my apps, I chose to fail fast. Let’s see what it means.

Yesterday, I attended an awesome conference at the Toulouse JUG [FR] (an association of Java-lovers in the city of Toulouse, see Java User Group).

The talk was given by Jose Paumard. The subject was Java 8 and more precisely, the Lambdas, the Stream API and the impact on the use of the Collection API. Here are the main points I remembered from this talk.

In the last few months, I often connected my Java applications to remote REST APIs: Facebook Graph API, private servers, Twitter API, etc. Each time I have to write a lot of boilerplate code to build the requests, handle the errors, map the responses to my own Java objects, etc.

That is the reason why I worked as a side project on APIPixie. APIPixie is a Java library which enables you to set up a communication with a distant REST API in minutes.

An API is a machine-to-machine interface which enables our applications to interact with each other. But it is also an interface for the developers that will connect those applications.

That’s a good reason to spend some time working on your documentation.

As a developer, I want the documentation of the APIs I use to be crystal clear, easy to understand and straight-to-the-point. I think that you may have built the better API in the world, if your documentation is poor, unexplicit or hideous (yes, design matters), nobody will ever use it.

Here are some thoughts about how to create a developer-friendly documentation that will boost the interest (and the revenues!) of your API.

One of my previous posts presented how to quickly build a Node-based webapp with a templating system. Today, let’s use the same technology stack to build our first REST Web API.

In my job and my personal projects, I alternatively take the positions of frontend and backend developer. In order to separate the responsabilities of each part of the job, the best way is to define an interface. Providing a web API for a service enables us to plug in any frontend display (websites, mobile apps, etc.).

As I told you before in my Hello World, again, I love APIs and the service oriented web. This is my first post on this topic and it is the beginning of a long series. I will sometimes make technical posts giving you hints and feedback on my work with APIs. Some others, like this one, may be a little more focused on the concepts and the ecosystem.

At Ubleam, I often need to prototype small webapps for our clients. The goal is to create a specific product in the shortest possible period of time in order to test the market on a feature.

I choose not to integrate those apps directly in our main API because it would require too much work to meet the quality of service I expect: response times, stress tests, graphic integration in our services, etc. I prefer to build small and flexible apps and invest time and efforts to integrate them when we feel the market is ready.

I often develop those apps on a Node.js base because it’s an easy way to get tangible results in a very short time. In this post, I will show you how to set up a basic webapp using Node.js, Express.js and Jade.

Hi everyone, I’m back!

It’s been a long time since I posted something on the internet!

Between the end of my studies at INSA, my startup experience at Plixee, my relocation in Toulouse and the fact that I started working for Ubleam, it’s been an exciting but dense couple of years!