Changelog

Sam Soffes Jekyll’s a little differently. This iteration is built on top of Jekyll, a static site generator written in Ruby. Since I write my posts differently than Jekyll expects, I had to write several plugins to make things work correctly. You might wonder why I don’t just write my posts the way Jekyll wants instead of doing all of this work. I want to keep the details of my blogging engine separate from my content. I’d love to hear from you about your blogging stack in the discussion below. Like Sam, I’m also using Jekyll hosted on Netlify, but I’m new to his plugins.

read more

You might be on the fence with CSS-in-JS — especially after hearing from Rich Harris about Svelte on The Changelog #332. Max Stoiber writing on his personal blog with his take on the matter: Primarily, CSS-in-JS boosts my confidence. I can add, change and delete CSS without any unexpected consequences. My changes to the styling of a component will not affect anything else. If I delete a component, I delete its CSS too. No more append-only stylesheets!

read more

Consider adding these mechanisms to your services and making them clearly visible and usable in the README. The poor soul having to solve problems late at night will thank you.

read more

Yegor Bugayenko: As you most probably know, I advocate for a dictatorship role of a software architect. All decisions are made by the architect must be final and non-disputable. However, the obvious question is: What happens if the architect is wrong? Does it mean the entire project is at risk of failure? And isn’t it better to make the whole team responsible for the result, instead of having one single point of failure? On the other hand, if the architect happens to be Will Ferrell…

read more

Stripe Atlas has a wide array of guides to running an internet business that are totally open and free for everyone. This guide is on “scaling engineering organizations” and covers everything from recruiting and hiring, training and on-boarding, to retention. If you haven’t checked this out yet, it’s a 15 minutes or less read.

read more

Megan O’Keefe, developer relations engineer at Google, shares her setup for Kubernetes as well as some very helpful tips and tricks from her Terminal setup, navigating clusters, and how she gave kubectl superpowers. As a developer relations engineer for Kubernetes, I work a lot with demo code, samples, and sandbox clusters. This can get interesting to keep track of (read: total chaos). So in this post I’ll show some of the tools that make my Kubernetes life a lot better. This environment can work no matter what flavor of Kubernetes you’re running.

read more

Dig in as Russ Cox goes deep on our software dependency problem. For decades, discussion of software reuse was far more common than actual software reuse. Today, the situation is reversed: developers reuse software written by others every day, in the form of software dependencies, and the situation goes mostly unexamined. … Software dependencies carry with them serious risks that are too often overlooked. The shift to easy, fine-grained software reuse has happened so quickly that we do not yet understand the best practices for choosing and using dependencies effectively, or even for deciding when they are appropriate and when not. My purpose in writing this article is to raise awareness of the risks and encourage more investigation of solutions.

read more

This is a great article that covers the 🐛 gamut: spotting bugs reporting bugs reproducing bugs fixing bugs I love the “lifehack” snippets Nikita sprinkles in as well. Like this little gem right here: Lifehack: sometimes you might want to submit a broken code to your branch so it will trigger a CI build. After the build, it will be saved in your project. And your colleagues will be able to link to this problem. Your next commit will have to solve the issue.

read more

Itamar Turner-Trauring: How do you get a programming job with work/life balance when it seems like everyone else is willing to work long hours? By realizing that long hours are the opposite of productive, and that employment is a negotiated relationship.

read more

For the final show of 2018 I’m talking with Travis Kimmel, the CEO of GitPrime. Travis has spent years as an engineering manager. Travis’s mission at GitPrime is to bring crystal clear visibility into the software development process and bridge the communication gap between engineering and stakeholders. This communication gap is often an ongoing plague in product development lifecycle. We talked through focus, tech debt, leading teams, predictability, and more.

read more

Automated tests are immensely useful, but passing tests don’t mean your software is correct. Correctness requires applying human judgement before, during, and after coding, which is why you need additional development techniques beyond just tests. Tests are 💯 a tool in your tool belt, not a silver bullet.

read more

Aaron Turner (UXE at Google) says “WebAssembly is fast” and has conducted a real-world benchmark between WebAssembly and ES6 to showcase Wasm’s performance on different browsers, devices, and cores. …this benchmark will be utilizing the WasmBoy benchmarking tool (source code). The benchmark features three different cores as of today. AssemblyScript (WebAssembly built with the AssemblyScript compiler), JavaScript (ESNext output by the TypeScript compiler), and the previous JavaScript core except run through Google’s Closure Compiler…

read more

I love the way Charity Majors, CEO of Honeycomb.io, opens up this post… What should one pay for observability? How much observability is enough? How much is too much, or is there such a thing? Is it better to pay for one product that claims (dubiously) to do everything, or twenty products that are each optimized to do a different part of the problem super well? It’s almost enough to make a busy engineer say “Screw it, I’m spinning up Nagios”. (Hey, I said almost.)

read more

In this blog post we will introduce you to some of out internal best practices we have developed or discovered to simplify and speed up working on open-source and other projects. There’s nothing revolutionary in here for those experienced in open source maintenance, but it’s a good rundown nonetheless. It’s also interesting to see how many teams are now using (and recommending) dependency update services such as dependabot and Greenkeeper.

read more

Yegor Bugayenko: Now here is a simple, plain list of recommendations for you: what you should do if you want to be a more successful programmer. Not a better algorithm designer, even though that’s important. Not a funnier team player, even though that’s also important. But a more successful software engineer, both financially and socially. Of the 14 recommendations, I’m happy to report that I regularly engage in 10 of them! The only one that I’m diametrically opposed to is Earn Certificates. No thanks! What do you think of Yegor’s recommendations?

read more

Martin Fowler’s TellDontAsk principle is very useful in object-oriented programming. However, it is not enough to follow only this idea: we also need to be very careful in order to not break the interface of the object, otherwise we won’t be able to keep telling it what to do later and we will end up asking for data again.

read more

Do you love programming for its own sake, or do you just program for the outcomes it enables? Depending on which describes you best you will face different problems in your career as a software developer. Enthusiasts code out of love. If you’re an enthusiast you’d write software just for fun, but one day you discovered your hobby could also be your career, and now you get paid to do what you love. Pragmatists may enjoy coding, but they do it for the outcomes. If you’re a pragmatist, you write software because it’s a good career, or for what it enables you to do and build. Which is your camp and why?

read more

This is a spectacularly thoughtful and insightful piece by Eugen Kiss on testing: Different kinds of tests have different costs and benefits. You have finite resources to distribute into testing. You want to get the most out of your tests, so use the most economic testing approach. He goes on to describe why he believes that integration tests provide better ROI than unit tests and end-to-end tests. Then he turns his aim on unit tests in particular: There is the claim that making your code unit-testable will improve its quality. Many arguments and some empirical evidence in favor of that claim exist so I will put light on the other side… Unit tests ossify the internal structure of the code. Click through to read his whole argument, but I will say in my experience unit tests only ossify the structure when I do them poorly. In other words, the better I get at unit testing, the more useful they become. In light of that, Eugen’s big takeaway at the end might be 💯 on point: If you desire clear, albeit unnuanced, instructions, here is what you should do: Use a typed language. Focus on integration and end-to-end tests. Use unit tests only where they make sense (e.g. pure algorithmic code with complex corner cases). Be economic. Be lean.

read more

We recently talked with Daniel Stenberg about HTTP/2 and QUIC, so this news comes with little surprise looking back on that conversation with hindsight. The protocol that’s been called HTTP-over-QUIC for quite some time has now changed name and will officially become HTTP/3. This was triggered by this original suggestion by Mark Nottingham. On November 7, 2018 Dmitri of Litespeed announced that they and Facebook had successfully done the first interop ever between two HTTP/3 implementations. Mike Bihop’s follow-up presentation in the HTTPbis session on the topic can be seen here. The consensus in the end of that meeting said the new name is HTTP/3!

read more

My biggest take away from this epic announcement from ZEIT? The support of the majestic monorepo! …Now 2.0 enables what we will call The Majestic Monorepo, inspired by a similarly named essay by DHH, creator of Ruby on Rails (The Majestic Monolith). We don’t agree that you should be orchestrating a big server abstraction (a monolith), but we believe you should be able to collocate your APIs and your business logic in a single place, with a cohesive deployment story. It looks, feels and deploys like a monolith, with none of its downsides. …but there is SO MUCH MORE to this announcement. Also, we talked a bit about David’s idea of The Majestic Monolith on The Changelog #286.

read more

There’s some seriously interesting thoughts shared here for building out a multi-CDN strategy. Having had issues with how to best use and leverage a CDN to get the best performance benefits, I can see how having a multi-CDN implementation would allow us to choose the right CDN for a given region of the world, as well as a whole host of other options based on things like cost, performance, and of course redundancy for when things go wrong. Murphy’s law, right? This summer, the 2018 World Cup set an all-time streaming record – tripling its own 2014 record – with over 22 Tbps measured by Akamai at peak, but the event wasn’t smooth sailing for everyone. In a highly competitive market, and in an age where streaming failures make headlines, redundancy and quality of experience have never been more crucial for content publishers. Drop a comment below if there are other resources out there on this subject that we should check out.

read more

How do you balance delivering on time and the frustration of seeing messy, out-of-date code? In this article you’ll learn a set of heuristics to help you decide when—and why—to cleanup to your code.

read more

Derrick Camerino: As developers there are some many things to work on. We must learn how to prioritize our tasks and focus on the most important things. Our time is a valuable asset. In this post, I discuss some ways to increase leverage and get more impact from your efforts.

read more

The fight against complexity is analogous to the fight against contentment. Find contentment and you will find yourself at the end of a project. Hint: we will never be fully content. We live in a dynamic world of infinite, and never-ending change. There will always be a critique to offer. Perfection is an illusion. We’ve all worked on projects that never seem to end. Every time you think you’re done, you realize you’re not. There’s “one more thing” you or your client wants to add. Somehow, you get exhausted and your work suffers. Sometimes you simply burn out and move on to something else. Why does this happen? Why do we consistently underestimate how much extra work it is to do “one more thing?”

read more

A look at the difference between Indirection and Abstraction, with the focus of understanding how to evolve a system to make it more maintainable and easy to develop.

read more