Bookmark

TinyLetter

tinyletter.com/, posted Mar '21 by peter in development email free online

TinyLetter is a personal newsletter service brought to you by the people behind Mailchimp. People use it to send updates, digests, and dispatches to their fans and friends.

Though they're built on the same infrastructure, TinyLetter is for people who don't need all the business features that come along with Mailchimp. Simplicity is at the heart of everything we do at TinyLetter.

TinyLetter is a completely free service.

WHIP is a high performance web application server based on the excellent httpbeast and routing provided by nest with some additional optimizations.

WHIP is still in development and is not recommended for production use. Much is still missing or untested but for basic API use cases however, the performance numbers look pretty good so far.

This is a different way to learn about crypto than taking a class or reading a book. We give you problems to solve. They're derived from weaknesses in real-world systems and modern cryptographic constructions. We give you enough info to learn about the underlying crypto concepts yourself. When you're finished, you'll not only have learned a good deal about how cryptosystems are built, but you'll also understand how they're attacked.

Axe is an accessibility testing engine for websites and other HTML-based user interfaces. It's fast, secure, lightweight, and was built to seamlessly integrate with any existing test environment so you can automate accessibility testing alongside your regular functional testing.

But it turns out that Firecracker is relatively straightforward to use (or at least as straightforward as anything else that's for running VMs), the documentation and examples are pretty clear, you definitely don't need to be a cloud provider to use it, and as advertised, it starts VMs really fast!

So I wanted to write about using Firecracker from a more DIY "I just want to run some VMs" perspective.

I'll start out by talking about what I'm using it for, and then I'll explain a few things I learned about it along the way.

Bookmark

SOUL

https://soul.dev/, posted Jan '21 by peter in audio development music opensource software

The SOUL project is creating a new language and infrastructure for writing and deploying audio code. It aims to unlock improvements in latency, performance, portability and ease-of-development that aren't possible with the current mainstream techniques that are being used.

Nim is a powerful statically typed language that allows the programmer expressiveness without compromising run-time performance. As a general purpose programming language, it gives the same sort of power and performance as C++, but in a nicer package and with even more powerful tools!

Greetings fellow Nim adventurers! Below you will find 16 handy Nim tips & tricks I came across while developing a medium-sized GUI program this year, Gridmonger (and related libraries). Some of them are about less known or undocumented Nim features or standard library functions, a few are workarounds for some rough edges of the language, and there’s also a handful of useful techniques I read about in forums or have invented on my own.

The goal of this book is to document commonly-known and lesser-known methods of doing various tasks using only built-in POSIX sh features. Using the snippets from this bible can help remove unneeded dependencies from scripts and in most cases make them faster. I came across these tips and discovered a few while developing KISS Linux and other smaller projects.

When asked what stops them from safely and regularly deploying every change into production environments - everybody seems to have their own reasons. Organizational, cultural, historical, technical, contractual.. Some go as far into denial as saying : "Oh, we don't need continuous delivery. In fact most companies out there don't really need it." But the underlying reason is of course the lack of confidence. Nobody wants to be the culprit for a system outage. According to a number of industry surveys the average cost of one hour of downtime is around 75000 USD. There's a lot at stake! So instead we choose to move slower, to add controlled handoffs and build home-grown guardrails. To hire more Ops engineers and call them SRE to feel more secure. Rarely discussing the price of establishing and maintaining all of these over time.

...

Engineers who've experienced true CD can't really fathom any other way of delivering software. As @giltayar puts it "CD ... is a total game changer. It changes how you perceive software development and delivering features... I did CD and EVERYTHING about how I developed changed. It was magical."

|< First   < Previous   11–20 (497)   Next >   Last >|