Iurii dev.sweatco.in

Why we ended up with a centralized logging solution

In the process of moving to our ideal logging system, we constantly discussed the pros and cons of different solutions, and each of us defended the requirement close to them or changed the configuration parameters they needed, asked intriguing questions or sent us back to the original set of requirements.

I love write-ups like this one from the trenches where people share their journey to deciding on a particular solution. Every decision has a context and many blog posts gloss over that, resulting in silver bullet-y hand waving. That’s not super useful when trying to make your own decisions. What is super-useful is being able to understand the circumstances in which others made a choice. That way you can decide if your situation is close enough to theirs to make a similar decision… or not.

npm sambleckley.com

Worrying about the npm ecosystem

Sam Bleckley:

The npm ecosystem seems unwell. If you are concerned with security, reliability, or long-term maintenance, it is almost impossible to pick a suitable package to use — both because there are 1.3 million packages available, and even if you find one that is well documented and maintained, it might depend on hundreds of other packages, with dependency trees stretching ten or more levels deep — as one developer, it’s impossible to validate them all.

He then spends some time measuring the extent of the problem.

DigitalOcean Icon DigitalOcean – Sponsored

Free Python machine learning projects ebook

logged by @logbot permalink

As machine learning is increasingly leveraged to find patterns, conduct analysis, and make decisions — sometimes without final input from humans who may be impacted by these findings — it is crucial to invest in bringing more stakeholders into the fold.

This a free book of Python projects in machine learning from Lisa Tagliaferri and Brian Boucheron (DigitalOcean) tries to do just that: to equip the developers of today and tomorrow with tools they can use to better understand, evaluate, and shape machine learning to help ensure that it is serving us all.

Joab Jackson The New Stack

Microsoft gradually switching to Rust to build its infrastructure software

No matter how much investment software companies may put into tooling and training their developers, “C++, at its core, is not a safe language,” said Ryan Levick, Microsoft cloud developer advocate, during the AllThingsOpen virtual conference last month, explaining, in a virtual talk, why Microsoft is gradually switching to Rust to build its infrastructure software, away from C/C++. And it is encouraging other software industry giants to consider the same.

This sounds SO familiar, as heard from Josh Aas recently on The Changelog (listen here).

We certainly should not be writing any new code in C and C++. The opportunity for vulnerabilities – I mean, it absolutely will have vulnerabilities, and we need to get that type of code away from our networks to start with, and then probably away from most other things, too… So I would hope that in 10-20 years we think it’s crazy to be deploying major (or maybe even minor) pieces of software that are written in languages that are not memory-safe.

So we’re trying to remove code written in C and C++ from our infrastructure at Let’s Encrypt. I think that’s just a basic part of diligence applied to secure infrastructure. If your stack is some giant pile of C++ or C at the network edge, followed by OpenSSL written in C, followed by a Linux kernel written in C, glibc - your whole pathway has got all this code that you just know is full of security holes. It absolutely is. You just can’t claim that those are even close to secure systems. They’re absolutely not. We’re gonna look back on this and say “That was crazy. We have better options today.”

HTML htmx.org

High powered tools for HTML

htmx allows you to access AJAX, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext.

htmx is small (~7kb gzipped), dependency-free, and even IE11 compatible. It’s the successor to intercooler.js and even comes bundled with a very nice haiku:

javascript fatigue:
longing for a hypertext
already in hand

Zach Leatherman zachleat.com

Use Speedlify to continuously measure site performance

Zach Leatherman:

Instantaneous measurement is a good first step. But how do we ensure that the site maintains good performance and best practices when deploys are happening every day? How do we keep the web site fast? The second step is continuous measurement. This is where Speedlify comes in. It’s an Eleventy-generated web site published as an open source repository to help automate continuous performance measurements.

Demo here.

Use Speedlify to continuously measure site performance

 Itamar Turner-Trauring codewithoutrules.com

Your dev environment matters less than you think

I knew I was going to nod my head in approval before I even landed on Itamar’s website:

Imagine you’re training to become a chef. You will need to learn how to use a knife correctly, to chop and dice safely and quickly.

And yes, you need a sharp knife. But when you’re starting out, it doesn’t matter which knife you use: just pick something sharp and good enough, and move on. After all, the knife is just a tool.

The people eating the food you cook don’t care about which knife you used: they care how the food tastes and looks.

After six months in the kitchen, you’ll start understanding how you personally use a knife, what cuisines you want to pursue, what techniques you want to vary. And then you’ll have the knowledge to pick a specific knife or knives exactly suited to your needs.

But remember: the people eating your food still won’t care which knife you used.

I’ll just leave this right here.

Nikola Đuza pragmaticpineapple.com

Don't follow JavaScript trends

How’s the saying go? Choose well-understood, “boring technologies”…we often reach for the new and shiny just for the joy of tinkering with something.

Psst, I have invented the time machine (don’t tell anyone)! Let us quickly travel back in time to 2016. SWOOSH! We are there. JavaScript landscape looks like this:

If you are using a JavaScript framework or want to use a framework, Angular.js is probably something you would choose. But, the news about Angular 2 that will make you rewrite almost everything is just around the corner. Also, this new kid on the block - React.js is coming up and getting ripe. Of course, Vanilla JS and no-framework-folks are there. Not using a framework is still a popular opinion in 2016, but is slowly fading.

Knowing all this, what would you do? Which path would you choose and why?

Julia Evans jvns.ca

A little bit of plain JavaScript can do a lot

Julia Evans:

I was pretty surprised by how much I could get done with just plain JS. I ended up writing about 50 lines of JS to do everything I wanted to do, plus a bit extra to collect some anonymous metrics about what folks were learning.

Listeners of JS Party know I’m an advocate for JavaScript sprinkles. Not on every site, but on most sites I think that’s the best way to start out.

Now more than ever, you can get a lot done with what’s right there in the browser. Wait until you feel the pain before you solve the problem. Who knows, maybe you’ll never have to…

Jon Bodner capitalone.com

Go is boring...and that’s fantastic!

Jon Bodner shared a deep dive into why the world depends on simple, reliable, well-understood technologies like Go.

The one exciting thing that Go has is built-in concurrency support via goroutines, channels, and select. However, it is based on ideas from CSP, communicating sequential processes, which was first described in 1978.

This doesn’t sound like a programming language from the 21st century, does it?

And yet, Go is the 3rd most wanted and (maybe not coincidentally) the 3rd highest paying language, according to Stack Overflow. Every startup in Silicon Valley is using Go to build their infrastructure. Docker, Kubernetes, etcd, Terraform, Vault, Consul, Traefik and lots of other cutting-edge projects are written in Go. So what’s going on? Why is everyone interested in this boring language?

As a fun aside, I searched the Go Time transcripts for the word “boring” and found this gem from Kelsey Hightower on Go Time #114

When infrastructure gets boring, something else will become exciting above it.

…which makes sense why Go being boring is fantastic, because there’s so many exciting things being built with it.

Tim O'Reilly O'Reilly Media

Welcome to the 21st century

This lengthly post from Tim O’Reilly is a must read in my opinion. His perspective is that the 21st hadn’t really begun until this year, 2020, “when the COVID19 pandemic took hold.”

…when we look back, we will understand that the 21st century truly began this year, when the COVID19 pandemic took hold. We are entering the century of being blindsided by things that we have been warned about for decades but never took seriously enough to prepare for, the century of lurching from crisis to crisis until, at last, we shake ourselves from the illusion that our world will go back to the comfortable way it was and begin the process of rebuilding our society from the ground up.

Tim goes on to ask and answer questions like: “What might be gone, never to return? What might come, now completely unexpected?” He also shares insight as “news from the future” regarding the direction of trend lines.

…to understand whether a trend like work-from-home is becoming the start of a new normal, sometimes the trend just hits you in the face. First Twitter, then Facebook announcing a commitment to new work from home policies even after the crisis is an obvious sign.

Jose Browne josebrowne.com

On coding, ego, and attention

How you think has everything to do with the quality of your thinking. Great writing Jose 👏

If being a good software engineer means being a good thinker, then becoming a better one should mean improving the way we think… right? Well, no little shame in saying that it’s taken me more than a decade of coding to get this. To finally focus my attention on improving the way I think instead of learning yet another library, framework or programming language.

At a certain point, the things that got in the way of my growth had nothing to do with problem solving and everything to do with what was actually happening in my mind when I was engaged should have been engaging with a problem.

Terminal github.com

A futuristic terminal emulator inspired by TRON Legacy

the eDEX-UI project was originally meant to be DEX-UI with less « art » and more « distributable software »”. While keeping a futuristic look and feel, it strives to maintain a certain level of functionality and to be usable in real-life scenarios, with the larger goal of bringing science-fiction UXs to the mainstream.

It might or might not be a joke taken too seriously.

Confession: I’ve shared this before. Sorry not sorry. It’s too cool!

A futuristic terminal emulator inspired by TRON Legacy

Raul Jordan rauljordan.com

This is why Go’s error handling is awesome

// In controllers/user.go
if err := database.CreateUser(); err != nil {
    log.Errorf("Could not create user: %v", err)
}

// In database/user.go
func CreateUser() error {
    if err := db.SQLQuery(userExistsQuery); err != nil {
        return fmt.Errorf("could not check if user already exists in db: %v", err)
    }
    ...
}

// In database/sql.go
func SQLQuery() error {
    if err := sql.Connected(); err != nil {
        return fmt.Errorf("could not establish db connection: %v", err)
    }
    ...
}

// in sql/sql.go
func Connected() error {
    if noInternet {
        return errors.New("no internet connection")
    }
    ...
}

The beauty of the code above is that each of these errors are completely namespaced by their respective function, are informative, and only handle responsibility for what they are aware of. This sort of error chaining using fmt.Errorf("something went wrong: %v", err) makes it trivial to build awesome error messages that can tell you exactly what went wrong based on how you defined it.

Go github.com

Rob Pike's toy Lisp interpreter in Go

This program was a joy to put together. Its purpose was fun and education, and in no way to create a modern or even realistic Lisp implementation. The goal was to turn that marvelous page 13 into a working interpreter using clean, direct Go code.

If you’re interested in what one of Go’s creators believes is “clean, direct Go code”, then you’re interested in this repo.

0:00 / 0:00