Tux Machines

Programming Leftovers

Posted by Roy Schestowitz on Jul 13, 2023

=> Open Hardware and Linux Devices | FUD and Security

Advice for Operating a Public-Facing API

=> ↺ Advice for Operating a Public-Facing API

I've been operating Pushover's public-facing API for over a decade now and I thought I'd pass on some advice for those creating a new API.

Pushover's API might be unusual in that it is used by a wide range of devices (embedded IoT things, legacy servers, security cameras, etc.) and HTTP libraries, rather than mostly being accessed from JavaScript in the latest web browsers. It also doesn't process sensitive financial information, so the advice given here may not be applicable to something operating like Stripe's API.

Uncovering History with R – A Look at the HistData Package

=> ↺ Uncovering History with R – A Look at the HistData Package

Greetings, humanists, social and data scientists! Are you curious about how data analysis can enrich your research and understanding? Look no further! Today, we explore the world of historical data analysis using R’s powerful package: HistData. This package contains a collection of more than 30 datasets that can be used to explore historical trends and patterns.

What we talk about when we talk about System Design

=> ↺ What we talk about when we talk about System Design

Early in my research career, I had a chance to work with some of the best system researchers1 in the world on a number of really interesting system designs. One of the enjoyable aspects of research was the particular process used by researchers (particularly in the SOSP/OSDI community) to come up with novel yet practical designs. This design process can be characterized as “fighting complexity with abstraction”: in any complex environment, how do you corral that complexity into cleanly defined boxes (or more technically, abstractions) and then divide functionality across these boxes?

Later, when I switched to “real” jobs in industry (ranging from mission-critical production services to applied R&D), I found that the same design process worked quite well in solving real-world problems in production settings2. In these settings, the sources of complexity are varied (hardware, software, distributed protocols, org boundaries, deployment cycles, customers…) and so are the end-goals (reliability, scale, code velocity, performance, dollar cost); but abstraction-driven design still enabled my teams to hit production goals quickly and safely.

This post is a dump of some rules to follow in this particular design process.

Failover

=> ↺ Failover

To reduce the risk of miscommunication we need to distinguish between relevant terms because what you think may not be what you say and what you say may not be what is heard and what is heard may not be what is implemented!

=> gemini.tuxmachines.org