Tag: open-source

locport – Manage localhost ports

Posted on by Robert Starsi

There are many solutions to the problem of running multiple (web) applications on the same machine, during development. You can use various proxies (puma-dev, localcan, traefik, nginx…) and DNS to set up custom hostnames. Which is something I’ve been doing in the past. But there is a more direct and simpler approach.

Modern browsers all support .localhost domains and treat it as a secure context (like it would be served over HTTPS), which is required for things like copy to clipboard from JavaScript. You can freely assign names to you apps, like app1.localhost, app2.localhost, but each one needs a unique port too.

If you have lots of apps, you need to keep track of all these ports and prevent conflicts. This is where locport comes in. It’s a simple command line program. It introduces a .localhost file convention, which you place in each project’s folder and define the hostnames and ports there. locport indexes these files and gives you an overview of all your apps and let’s you know if there are any conflicts.

If you have Ruby installed, you can just:

gem install locport

# Show usage instructions
locport help

Learn more over at GitHub.

tinyups3 – streaming S3 uploader

Posted on by Robert Starsi

Working with the official AWS S3 CLI, as well tools like s5cmd I quickly realized they aren’t optimized for resource constrained systems, rather more towards uploading as fast as possible and in parallel. This is great for most use cases, but not when you want to minimize the impact on the system, like during frequent backup operations and on a system with half a gig of memory for example.

I dusted off my Go tools and build a simple tool to serve this purpose. Say hello to tinyups3 – streaming S3 uploader optimized for minimum CPU and RAM usage. It’s a single binary, open sourced under the MIT license.

Head over to GitHub for installation and usage instructions.

Happy uploading!

testerobly – lightweight automatic test runner

Posted on by Robert Starsi

I’ve been running into issues, like intermittent crashes, with guard, which is a favorite amongst Rubyists, when it comes to automatically running unit tests on a file change. I’ve decided it would be a fun exercise to create my own tool, addressing my needs specifically:

  • Listen for file changes and run matching tests.
  • Customize configuration per project.
  • Pause during git operations like checkout.
  • Run all tests with Enter press.
  • Fast, simple, stable and resource efficient.
  • Can be used together with interactive debug mode.

I’ve achieved that goal with testerobly which I published as a Ruby gem, under the MIT license.

I’ve been using it for many months now, on quite a few projects and it has been delightful. It does exactly what it says it does and gets out of the way.

Go check it out.

Dockerized Percona MySQL Server with automated replication, tools & tests

Posted on by Robert Starsi

Docker & Percona Server I developed this container to solve specific needs and alleviate pain points present when dealing with deployment and administration of MySQL on servers that I manage.

I decided to look into Docker during a migration from MySQL 5.5 to 5.6 on one of the production servers. The server hosts multiple applications and services and is running in a hot spare configuration (another server mirrors this server, acts as the MySQL slave, etc.). Thus I wanted a migration strategy where I can have the 5.6 installation ready and running on the server, so that I can test it with production data and when ready just turn the switch to replace the old 5.5. Docker turned out to be the cleanest solution.

Since the MySQL server is such a critical part of the infrastructure I decided to develop the container utilizing test driven development. This allowed me to quickly add new features, like performance optimization and replication over a ssh tunnel (to support servers in different public clouds). Having this functionality in a standalone, tested and isolated unit is amazing. Before, all this complexity would be managed by Chef provisioning, which is much harder to test and experiment with on the production server. Having this functionality contained in a Docker container allows me to just use Chef for orchestration and deployment of the containers themselves, witch requires much simpler logic, compared to provisioning a full MySQL server install, configuration, replication and upgrading.

  • Code is available at Github.

This project is released under the MIT license.