A Developers Toolbox: part 3
In my previous post I showed my git and vim configuration. This post will be about random small tools that I use, such as tooling for docker and kubernetes, or just some small utilities to make life a bit easier.
In my previous post I showed my git and vim configuration. This post will be about random small tools that I use, such as tooling for docker and kubernetes, or just some small utilities to make life a bit easier.
In my previous post I showed you my terminal and shell, with some of the configuration I like to use. This post of 'A Developers Toolbox' will be all about git and vim. I will show you the aliases I use, how you can set up git hooks, and a useful tool to view your git log. And I will share my vim configuration, with some tips and tricks on how to use it.
Personally I like to use the terminal as much as possible, and by doing so I have a few useful tools in my 'toolbox' for my day-to-day work as a developer. This blog is the first in a trilogy, covering all the tools that I use almost daily. This first part will be all about the terminal itself. Which terminal I use, which shell I use, and how I have customized its looks.
RevealJS is an awesome tool made with JavaScript, which allows you create slides for a presentation using HTML or if you use a plugin, Markdown. The great thing about that is, that you could have your slides in git, with proper version control. To run your slides, all you need is a web server which serves static content, for example you could do this locally using Python’s SimpleHttpServer. That’s where GitLab comes in, with GitLab pages you can host any static web content you want, so that’s what I will show in this blog, automatically hosting your RevealJS slides on GitLab with every commit of your slides.
On OSX and Windows, as you might know, directories are case insensitive. So the directory CaseSensitive and casesensitive are the same on those operating systems. But on Linux, they are different directories.
When creating a Spring Boot Rest service, you can configure Spring to convert a LocalDateTime to display as a ISO-8601 date string when returning a JSON response.
To get this working you have to do a few things.
Firstly, you need the following dependency: com.fasterxml.jackson.datatype:jackson-datatype-jsr310
This dependency has all the JSON serialisers and deserialisers for the Java 8 time API, and when you use Spring Boot with auto configuration, it should load all the correct serialisers. Secondly, you need to add the following to your application properties:
Normally when using swagger, you generate a swagger.yaml file for your API. But what if you already have a swagger.yaml file and you want to generate the API interface and models, like you would also do with a webservice using a WSDL file? To achieve this, swagger has a great tool: swagger-codegen. The tool has a CLI and a maven plugin, but no gradle plugin. So how do we use it with gradle?
Normally, forcing HTTPS with an .htaccess file is pretty straightforward, and not too difficult. You simply add the following to the top of your .htaccess file:
You have a RewriteCond that checks whether HTTPS is on or off, and after that you create a RewriteRule that redirects the user to the same host/URI, but with HTTPS instead of HTTP. The L flag prevents any other rule in the .htaccess file from being applied, and the R flag is a redirect (the 301 status code is for SEO optimization).
See this for documentation on rewrite module for Apache server.
So when you try this on an application hosted on Heroku (I’m using a Cedar stack), this won’t work because there will be a infinite redirect loop.
The reason for that is that our rewrite condition is always failing. This is because Heroku has a sweet load balancer between the client and the application. So the client connects with HTTP (or HTTPS) to the load balancer, not the application. The load balancer then connects to our application using TCP(as described here), causing the HTTPS variable to be set to off.
To resolve the issue, Heroku uses the header X-Forwarded-Proto to pass on the protocol that was used by the client.
X-Forwarded-Proto is a non-standard header which is commonly used by other services, like Amazon Web Services. |
With that knowledge, all we have to do is rewrite the RewriteCond to the following:
Now it should work. Please note that this won’t work on every server unless you set this header. If you want to make sure it works everywhere (for example your dev server), simply add both rewrite conditions:
My colleague, Erik Timmers, and I often have discussions about programming and related technologies. This blog post is the result of one of those discussions. We discovered that the function Promise.race didn’t exactly do what we expected. So we tested it, figured out how it worked, found out what we thought was wrong, and finally created a version of the Promise.race function that does what we expected. After that we went a little bit further…and added some functionality to the function. Please note that this code shouldn’t be used in production, or at the very least, it should be tested a bit more. We did it “because we could”, but also because we wanted to understand the functionality. If you would like to view, extend, learn from the actual code, the source code is also available on GitHub.