PostgreSQL dok.community

Why you should be deploying Postgres primarily on Kubernetes

This is a ~15 minute presentation (with transcript) by Álvaro Hernández at a Data on Kubernetes Community event about why he believes Kubernetes solves a big problem with running Postgres in production.

Running a Postgres installation, with or without containers, is trivial. However, setting up a production environment is a whole different matter. Postgres is not by itself a production-ready software: it requires a set of side tools to complement its functionality: connection pooling, monitoring, backup tools, high availability software, you name it. This is called the “Stack Problem”. This brief talk discusses the Stack Problem, understanding how Kubernetes is the platform that best solves it, and what the main advantages (and disadvantages!) are of running Postgres on Kubernetes.

HTML github.com

A tool like jq, but for HTML

htmlq uses CSS selectors to extract bits of content from HTML files. Mozilla’s MDN has a good reference for CSS selector syntax.

This looks super handy. Examples!

// Find part of a page by ID
curl --silent https://www.rust-lang.org/ | htmlq '#get-help'

// Find all links in a page
curl --silent https://www.rust-lang.org/ | htmlq --attribute href a

// Get the text content of a post
curl --silent https://nixos.org/nixos/about.html | htmlq  --text .main

Rust github.com

These TODOs will self-destruct in 10... 9...

Problem: TODOs as comments are too often forgotten or neglected

Solution: TODOs as code that triggers compile errors based on set criteria

// trigger a compile error if we're past a certain date
todo_or_die::after_date!(3000, 1, 1); // its the year 3000!

// or a GitHub issue has closed
todo_or_die::issue_closed!("rust-lang", "rust", 44265); // GATs are here!

// or the latest version of a crate matches some expression
todo_or_die::crates_io!("serde", ">1.0.9000"); // its over 9000!

Medium Icon Medium

An attempt to answer the question, “If software engineering is in demand, why is it so hard to get a software engineering job?”

I’ve often wondered this as well. My conclusion, after not thinking too deeply about the issue, was that it’s a combination of the difficulty in match making and poor tooling. (There are many startups trying to solve those problems, but it doesn’t seem like anybody has cracked the nut yet).

There’s lots of wisdom in this post by Curt Corginia:

A wise, mature person would treat the software engineer interview process as a pure learning experience. He, or she, would enjoy learning about companies out there for the sake of research, interacting with key players, and mastering the art of whiteboarding. It would just be like a fun game.

I don’t think of it like that, but a mature person would. Do what I say, not what I do.

Martin Heinz martinheinz.dev

A solution to software supply chain security

In the recent months there’s been a lot of noise in the area of supply chain security because of increase in attacks, with notable ones like Microsoft Exchange Server or SolarWinds breach. These attacks could have been prevented with proper tools in place, yet finding the right tool for the job might be difficult as this area is hard to navigate and most of us - developers - aren’t security experts. There’s however a project that can solve this. Its name is sigstore and in this article we will look at what it does, why we need it and how it fits into landscape of existing tools in this area.

Cory Etzkorn notion.so

Notion's journey to Next.js

What Vercel has enabled teams to do with Next.js is next level, and it’s truly evident when you read stories like this one from Cory Etzkorn on Notion migrating their marketing site to Next.js.

We rebuilt our entire marketing site from scratch, choosing to go with a statically generated architecture over our former purely client-rendered approach. Two months and 109 React components later, we’ve now fully migrated to our framework of choice, Next.js, and couldn’t be happier with our decision. Here’s how we got there.

Notion's journey to Next.js

Jonas Lundberg github.com

Ain is a terminal API client (alternative to Postman, Paw, Insomnia)

Ain was born out of the frustration of working with many API endpoints in GUI clients.

While pretty, I could’t use any shell-scripts or commands such as uuidgen as input to the endpoints without copy pasting from a terminal. And I had to copy-paste the resulting output back into the terminal to further slice and dice it.

I had become a human pipe and my ctrl+c, ctrl+v fingers were hurting. By using curl and/or httpie for the heavy lifting, Ain removes you from the piping of input and output. With Ain, you can:

  • Organize API endpoints using files and folders
  • Use shell-scripts and executables anywhere
  • Put things that change in environment-variables or .env files
  • Share the resulting curl or http(ie)-call with friends and foes
  • Pipe any output for further processing

Docker gitlab.com

Harbormaster – easily deploy many Docker-Compose apps on a single host

Here’s their pitch:

Do you have a home server you want to run a few apps on, but don’t want everything to
break every time you upgrade the OS? Do you want automatic updates but don’t want to buy
an extra 4 servers so you can run Kubernetes?

Do you have a work server that you want to run a few small services on, but don’t want
to have to manually manage it? Do you find that having every deployment action be in
a git repo more tidy?

Harbormaster is for you.

You create a YAML config file with all the git repos you want it to include and it’ll watch them for changes (on a timer) and do the necessary cloning/pulling, service restarting, etc. that needs doing to make it all run. Simple. Neat!

Niels Leenheer nielsleenheer.com

Why Electron apps are fine

From Niels Leenheer:

It is not difficult to find some incredibly shitty takes on Electron, and every time it boils down to: It’s slow. Downloads are huge, and it uses a lot of memory. Electron apps are just websites. Developers that are using Electron are taking the lazy or easy approach to cross-platform development. Native apps are just better in every single way.

And somehow, these arguments often come from Apple fans when they discover one of their apps isn’t “native” or when a macOS favourite is considering moving to Electron. How dare they!

And on the surface, I agree with pretty much everything that people say about Electron. And at the same time, I don’t care at all. And neither should you.

Niels goes on to explain why you shouldn’t care. But, where’s the evidence for those shitty takes on Electron? Let’s use the recent example of 1Password.

Some have said that 1Password has “simply decided that the Mac isn’t important enough,” which we’re hoping to uncover in our upcoming dual podcast series with 1Password Founder Dave Teare on Founders Talk and Mitchell Cohen and Andrew Beyer on JS Party.

Drop some comments if you have questions/topics we should bring up.

Ryan Dahl deno.com

Deno Deploy Beta 2

Big news from Deno today.

Today we are releasing Deploy Beta 2. This is the second in a series of beta releases that will be made over the coming months. Each release will add features and refine the programming model. The releases will culminate in a General Availability announcement that we estimate will happen in Q4 2021.

Over the past eight months, we have been quietly designing this hosted service to supplement workflows with the open source Deno CLI. Deploy does not run on AWS Lambda nor does it use Cloudflare Workers; this is a new system with a unique design. We encourage people to look past the rough initial UI and explore this new JavaScript runtime.

What’s next: A general availability (GA) release is expected Q4 2021.

0:00 / 0:00