I was recently setting up remote backups for my QNAP NAS and came across a problem.
QNAP NAS by default doesn’t seem to be able to create backups of the TMBackup directory it uses to store TimeMachine backups. You are unable to sync this directory with remote server or cloud storage/backup service.
I was googling around and noticed that few people had this problem, for example here and I have found a solution.
The following post is a quick tutorial how to use Trezor hardware wallet with Bitcoin Testnet.
Connect your Trezor like you normally would Click on “Wallet settings” Delete contents of this field and enter “https://testnet-bitcore1.trezor.io/" instead Click “Save & Reload” This is how the wallet page should look Notice that in the right left corner it says “Custom backend”, this is expected. I already have 0.20 testnet BTC there.
This is how “Receive” tab looks like, there is information that you are running on testnet This is how “Send” tab looks like, there is information that you are running on testnet Unfortunately there’s no way for the Trezor wallet to remember this setting and you are required to repeat those steps every time you plug in your wallet into computer.
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.