When working on the swagger documentation, several different tools can be used. The ‘official’ editor developed by the Swagger community is Swagger Editor, live preview: https://editor.swagger.io/, I have found it quite quick and easy to use, but for larger project it gets cumbersome. Additionally it doesn’t support ability to have multiple files that will reference each other. This post is a quick demonstration of the workflow I’m using when working on the large, multi-file swagger documentations.
There is a tendency for the Scala projects to prefer more explicit programming style. The biggest aspect of that is in my opinion the type system of the Scala language, programmers often start writing their functions by defining types of the arguments and type of the result, only to write the body of the function as last step. That’s also because we have the Scala compiler to help us. I recently stumbled on a snippet that contradicts this rule and can be a source of hard to spot bugs for the person unfamiliar with the code.
This post is attempts cover some of best practices in using Flyway, the database migration tool, that I have learned or established after using it in few projects. It’s aimed at users already familiar with Flyway or any other database migration tools, so I’ll try to skip over the very basics. I’m focusing on Flyway here, but I think the best practices will apply to majority of other database migration tools.
JSON API specification is a tool that greatly helps and simplifies the process of designing RESTful JSON based APIs and very frequently serves as great anti-bikeshedding tool that limits unnecessary discussions in any team. In my opinion it doesn’t get it’s deserved attention and this post aims to provide good introduction to that topic. My goal is also not to repeat official documentation, but rather try to add something new to the topic.
GitFlow is a convention that says how you should structure your development process. It tells you when you should branch and merge your changes and helps you with hotfixes. By organizing branches effectively it unblocks developers allowing them to stay effective Key characteristics Work happens in parallel Each developer is free to work on his individual features, all is required to branch off develop branch and once the feature is done create a PR back to develop
This month it will be my 5 year anniversary as a remote worker. During that time I have been working for different companies, some were fully remote, some were partially remote. In some cases I have worked with teams with almost no time overlap (9 hours difference), in some cases all of us were in the same time zone. This post is an attempt to summarize my thoughts from the 5 year perspective, but also I’d like to share tips for both people who are remote members in their teams as well as for people who are working exclusively on-site while some of their peers are remote.
I have recently been involved in implementing ETags and Last-Modified header support in one of the services based on Akka-http. I have prepared a quite comprehensive example project that shows how to implement those capabilities in Akka-http based projects. In this post I’ll describe in a practical manner what ETags are and how to support them in your own projects. Side note: I’ll focus on ETags and have a section on Last-Modified header at the end.
This post is a collection of tips and notes I gathered while working on microservices-based applications for last couple of months. The notes are divided in a couple of sections that focus on the different areas during development and running your services. I have decided to write more low level notes/tips to focus on specific problems, for more high-level overview see: The Twelve-Factor App Project Setup Each service should be a self-contained project, hosted in a separate repository.
Over last few weeks I have been playing around with creating docker container to host a Tor node on one of my VPS servers. As a result of those efforts I created a Github repository: https://github.com/wlk/docker-tor-relay with the Docker image, it’s also hosted on DockerHub here: https://hub.docker.com/r/wlkx/docker-tor-relay/ (and configured as automated build) Both DockerHub and Github README provide enough information on how to use it, so I won’t go into details here, but I’ll focus on 2 Docker features that I used in this toy project.
This post is a description of a small project idea developed by a friend of mine: Przemysław Pokrywka, I’m just writing down the idea as a blog post. There are many ways one can execute Scala code, most people use sbt to create a some kind of build, for example fat jar or something similar or just sbt-native-packager to build the application in more native formats. But what options do you have in case you want to write Scala scripts?