Practices Icon

Practices

Development and business practices, methodologies, workflows, etc.
136 Stories
All Topics

Kubernetes github.com

Ensure your Kubernetes clusters are using best practices ✅

Polaris helps keep your cluster healthy. It runs a variety of checks to ensure that Kubernetes deployments are configured using best practices that will avoid potential problems in the future. Provides a dashboard with an overview of how your clusters are doing as well as an experimental “validating webhook” that can stop future deployments that don’t live up to the standards.

read more

Dave Kerr github.com

Hacker Laws 💻📖

From Conway’s Law, to The Law of Leaky Abstractions — you’ll find links to laws, theories, principles, and patterns useful to developers — curated by Dave Kerr. Conway’s Law — This law suggests that the technical boundaries of a system will reflect the structure of the organization. It is commonly referred to when looking at organization improvements, Conway’s Law suggests that if an organization is structured into many small, disconnected units, the software it produces will be. If an organization is built more around ‘verticals’ which are orientated around features or services, the software systems will also reflect this.

read more

Yegor Bugayenko yegor256.com

How to write an elegant README for your GitHub repo

Some time ago I wrote a blog post An Open Code Base Is Not Yet an Open Source Project where I suggested a few important qualities of a good open source repository/project. One of them was the well-written README file. Here I will try to give a few hints on how to create a good README file and what mistakes to avoid. A solid README is a must-have for all open source projects. Thankfully, many folks have been taking their READMEs more seriously as of late. If you’re one of ‘em, check out this post and see if there’s anything you can improve.

read more

Daniel Stenberg daniel.haxx.se

Why people use curl

You know we’re curl fanpeople around these parts, and we’re obviously not the only ones (it’s used by millions of people around the world!). In this brief post, Daniel Stenberg lays out seven common reasons people tell him why they use curl. This particular bit resonated with me: No other tool or library for internet transfers have even close to the same amount of documentation, examples available on the net, existing user base that can help out and friendly users to support you when you run into issues.

read more

Kira Booth blog.plaid.com

Growing our team with retrospectives

From Kira Booth writing on the Plaid blog. …we take an agile-like approach to how we think about process. If our team’s process isn’t working, we talk about it in a retrospective (aka “retro”) and figure out how to change it. Many companies don’t begin retros until they are large and have many processes in place, but we feel that retros are especially valuable at our size and rate of growth. Plaid’s engineering organization is rapidly growing. In the Salt Lake City office where I work, we have plans to grow from 20 to 60 engineers this year. Processes that worked just a few months ago may not work now. A culture of continuous process improvement helps us to stay ahead of growing pains like inefficient collaboration, error-prone coding practices, and interpersonal conflict.

read more

John D. Cook johndcook.com

The hard part in becoming a command line wizard

John D. Cook: I’ve long been impressed by shell one-liners. They seem like magical incantations. Pipe a few terse commands together, et voilà! Out pops the solution to a problem that would seem to require pages of code. Are these one-liners real or mythology? To some extent, they’re both. Below I’ll give a famous real example. Then I’ll argue that even though such examples do occur, they may create unrealistic expectations. I agree with his overall argument, but the good news about the command line is you don’t have to become a wizard to get value out of it. Start small and go from there.

read more

Nikita Prokopov tonsky.me

How not to hire a software engineer

Nikita Prokopov writes on his personal blog about eight (8) common sense practices to use when hiring software engineers. I’m not an expert in hiring for big companies, but I have extensive experience for small ones and a bit of common sense. If you are in a business of hiring software engineers, big companies’ practices are not your friends. Common sense, fairness, tolerance, real interest, and open-mindedness are.

read more

 Itamar Turner-Trauring codewithoutrules.com

On learning new technologies: why breadth beats depth

There’s always new technologies coming out, and learning them in-depth would take an impossible amount of time. But you can most of the benefit, and more efficiently, by focusing on learning just enough about a broad range of tools to know when they’re useful. You know I’ve been preaching breadth-first over depth-first for years now. In this post, Itamar breaks down why that’s a smart strategy for learning new technologies and lays out a few ways you can gain breadth of knowledge. Unfortunately, he omitted one of the best ways of gaining (and maintaining) breadth: listen to podcasts!

read more

Jon Skeet codeblog.jonskeet.uk

Storing UTC is not a silver bullet

This is a pretty long post from Jon Skeet on storing and converting UTC. For those interested in more of a tldr, the conclusion at the end of the post is “intended to be read in a standalone fashion.” When I read Stack Overflow questions involving time zones, there’s almost always someone giving the advice to only ever store UTC. Convert to UTC as soon as you can, and convert back to a target time zone as late as you can, for display purposes, and you’ll never have a time zone issue again, they say. This blog post is intended to provide a counterpoint to that advice. I’m certainly not saying storing UTC is always the wrong thing to do, but it’s not always the right thing to do either.

read more

Rod Johnson blog.atomist.com

In defense of YAML

Rod Johnson: I’m not against YAML, just against abuse of YAML. I want to help prevent people abusing YAML and being cruel to themselves and their coworkers in the process. YAML has bitten me once or twice over the years, but I am not repulsed by it as many folks seem to be. YAML’s strength is as a structured data format. Yes, it has issues. Whitespace is a minefield. Its syntax is surprisingly complex. It has gotchas: “Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway.” But YAML is human readable and supports comments: two key benefits that drive its popularity. If JSON supported comments it may have killed YAML by now. But alas… Rod makes a good defense of the format for certain uses.

read more

Amila Welihinda github.com

A checklist of things to consider before releasing your project

There’s lots of good advice here, covering: 🎨 Initial Presentation 💰 Value Proposition 💯 Project Quality 👑 Branding ✈️ Onboarding Methods 🧹 Code Conventions and Infrastructure 📣 Spread the Word 🤑 Funding If you read the Spread the Word section closely you’ll notice Amila is following his own advice. 😉

read more

Eevee eev.ee

On code elegance

A somewhat #longread on what “elegance” means when it comes to code: I get a gut feeling when something is elegant, and a different gut feeling altogether when something is hacky; I suspect most programmers experience the same. The strongest pattern I’ve found is this: Elegance is about expressing exactly what you mean — no more, no less. Conversely, I could define a hack as something that doesn’t remotely express what you mean, but happens to have a close-enough effect. Eevee goes on to disect some code examples. Thankfully, most of them are from video games. 😅

read more

Craig Kerstiens craigkerstiens.com

Give me back my monolith

It feels like we’re starting to pass the peak of the hype cycle of microservices. It’s no longer multiple times a week we now see a blog post of “How I migrated my monolith to 150 services”. Now I often hear a bit more of the counter: “I don’t hate my monolith, I just care that things stay performant” What follows is an excellent rundown of all the advantages that a monolith has over microservices. For a real-world case study, listen to the details of Segment’s transition back to a monorepo.

read more

Elixir github.com

Would you still pick Elixir in 2019?

The dwyl team went “all-in” on Elixir back in 2016 and are often asked if they would make the same choice again. Here’s the TLDR of their answer: The question of “Which Programming Language” is one we ask ourselves fairly regularly, and is the reason that lead us to discover and decide on using Elixir in 2016. We periodically survey the “up-and-coming” languages like Kotlin, Julia, Lua, etc. and keep concluding that our choice of Elixir is the one we would make again right now. Elixir is the “full package” from idea to deployment! Click through for their full reasoning, which includes why they switched from Node.js to Elixir in the first place, Elixir’s pros/cons they’ve learned along the way, and a list of other languages they would choose given different use cases.

read more

Max Böck mxb.dev

On simplicity

What are your thoughts on simplicity as a feature? Max Böck has this say… I think there’s a lot of value in actively questioning the need for complexity. Sometimes the smarter way to build things is to try and take some pieces away, rather than add more to it. For example… Static sites are on the rise again now, precisely because they are simple. They don’t try to manage server-side code with clever abstractions - they don’t have any. They don’t try to prevent security breaches with advanced firewalls - they get rid of the database entirely.

read more

0:00 / 0:00