I recently had the opportunity to talk distributed systems and rqlite at the Hacker Nights NYC Meetup. It was great chance to speak with some folks, and discuss rqlite, its design, and how it operates.
rqlite is a lightweight, open-source, distributed relational database written in Go, which uses SQLite as its storage engine and Raft for distributed consensus. Release 7.0 is out now and introduces the first wave of new Node Discovery and Automatic Clustering features.
rqlite is a lightweight, open-source, distributed relational database written in Go, which uses SQLite as its storage engine. v6.0.0 is out now and makes clustering more robust. It also lays the foundation for more important features.
There is a popular image out there, among the general public, that small startups — particularly small software startups — are a hotbed of technical innovation, constantly creating new technology. But is it true?
If you work in the logging, monitoring — or even Observability — space long enough, you eventually end up on team that tries to build a system that handles both logs and time series in a high-performant and cost-efficient manner.
Well, it’s a lot harder than it sounds — because logs and time-series are not the same.
This is a post following up on my Monitorama Baltimore 2019 talk.
Logging and Monitoring systems — Observability Systems, if you prefer — often seem to struggle to meet the needs of their users.
Monitoring — the measurement of your system, the gathering of telemetry, and alerting when it behaves anomalously — is key to running large-scale, modern computer systems. But what many developers today don’t realise is that monitoring can be a key part of your design cycle too.
I’ve been programming for many years, and have spent most of the last few years managing development teams. I’ve written plenty of closed source software, and for a time made my living writing open source software too.
One thing stands out: a shared code base does not a software team make.
Slack: Where work happens
Something is happening at companies that use Slack. Slack, the company, may claim it’s work, but it’s less and less productive work, and it’s having a destructive affect upon my own field of software development.
Some fellow developers, using Go for the first time, recently asked me how to organise a Go project and for some high-level guidance on programming using the language.
I thought the most effective way to answer this question was to build a simple Go HTTP service, that provides a key-value store. It also includes a README, outlining my most important guidelines for Go programming. You can check it out here.