Are you or someone you know trying to move into the engineering department from a position that’s unrelated to software engineering at a company?

…I wanted to pursue computer engineering. I’d been at Artsy for a bit less than two years at that point, first as a marketing intern working on SEO and then as a coordinator on the CRM (read: email) team. I’d consistently been working on small technical projects; first doing some work on a tool for SEO optimization for our Editorial team, then building emails with MJML, and a few other bits and bobs. But I didn’t think of it as a serious pursuit.

It was Artsy’s Engineering team that convinced me that programming was something that I both wanted to and could do. Our engineers have always welcomed learners and been happy to answer questions and empower other teams to do technical work. I eventually realized that the parts of my work where I was coding were the parts I enjoyed the most, and that I would likely feel more fulfilled if I made programming my full-time occupation.

(Gosh, that opening sounds like the first line of a pharmaceutical commercial. Sorry about that!)

Rhys Arkins joined the show to talk about automating dependency updates using Renovate.

Renovate is an open source tool to keep source code dependencies up-to-date using automated Pull Requests.

We talked about who’s using it, the languages and environments that are supported, self-hosted vs SaaS and how that plays into supporting this open source, auto-merging, being a GitHub App and in the GitHub Marketplace, and building this as a business on someone else’s platform.

Matched from the episode's transcript 👇

KBall and Jason geek out on the ins and outs of Gatsby. They talked through the fundamentals of working with Gatsby, the development process, and look into the future of Gatsby.

Matched from the episode's transcript 👇

Puter puts an entire operating system in your web browser, the kapa.ai team write down how to structure your docs for LLMs, Daytona is an open source Codespaces alternative, Gleam v1.0 has been released & Rolldown is a JavaScript bundler written in Rust.

Matched from the episode's transcript 👇

We’re on the expo hall floor of OSCON 2019 talking with Eric Holscher, Ali Spittel, and Hong Phuc Dang. First up, we talk to Eric about his work at Write the Docs, ethical advertising, and the Pac-Man rule at conferences. Second, we talk with Ali about her passion for teaching developers, her passion for writing, and her new found love for podcasting. Last, we talk with Hong about her work at FOSSASIA, the disconnect between America and Asia in open source, and several of the cool open source projects they have on GitHub.

Matched from the episode's transcript 👇

You might have heard a lot about code generation tools using AI, but could LLMs and generative AI make our existing code better? In this episode, we sit down with Mike from TurinTech to hear about practical code optimizations using AI “translation” of slow to fast code. We learn about their process for accomplishing this task along with impressive results when automated code optimization is run on existing open source projects.

The bulk of this post by Brett Cannon is a detailed argument that Python makes sense to select even for projects with known performance concerns, but I got my money’s worth from the concept in the title and opener:

… it dawned on me that the problem is people are not treating language selection as potential form of premature optimization: if you select a programming language based on your preconceived notions of how a language performs, you will never know if the language that might be a better, more productive fit for your developers would have actually worked out.

In an effort to make my team write better SQL, I went over reports written by non-developers and code reviews, and gathered common mistakes and missed optimization opportunities in SQL.

Dividing integers, accidentally counting nullable columns, column position in GROUP BY and ORDER BY, and 9 other common gotchas. Don’t get got!

Donald Knuth famously said:

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

You’ve either a) learned this lesson the hard way, b) learned it the easy way (by listening to others’ tales of woe), or you c) should learn it now alongside Victor Zhou as he recounts how he ignored Knuth and wasted a lot of time because of it.

Emil Persson’s optimization tweet was so well received that he decided to turn its <ol> of rules into a full-on blog post:

Basically Programming Wisdom … posted a quote that basically suggested more or less that there’s never a good time to think about performance. Even experts should defer it until later! This is way worse advice than your usual “premature optimization is the root of all evil” tirade.

I’m not a fan of premature optimization, myself. So there’s lots to ponder in this post. 🤔

Thanks to work by Google and Yahoo, we’re all better informed about how to speed up our web pages. For those on Apache, Google has made it easier to implement these ideas at the Apache Module level. For those running on Ruby web frameworks, Julio Cesar offers up the same goodness as Rack middleware.

Rack Pagespeed offers some HTML output filters to help you implement page optimization best practices with minimal effort. To get started, install the gem:

gem install rack-pagespeed

For Sinatra, Rack, or Padrino apps, configure Rack Pagespeed in your config.ru Rackup file:

require 'rack/pagespeed'
require 'myapp'
use Rack::PageSpeed, :public => "/app/public/dir" do
  store :disk => Dir.tmpdir # require 'tmpdir'
  inline_javascript :max_size => 4000
  inline_css
  combine_javascripts
end
run Sinatra::Application

For those Rails, create a rack_pagespeed.rb initializer with:

require 'rack/pagespeed' # somewhere
class Application < Rails::Application
  config.middleware.use Rack::PageSpeed, :public => Rails.public_path do
    store :disk => Dir.tmpdir # require 'tmpdir'
    inline_javascript :max_size => 4000
    inline_css
    combine_javascripts
  end
  # ...

Filters

Out of the box, Rack Pagespeed supports filters to:

• Inline JavaScript under 2kb
• Inline CSS under 2kb
• Bundle JavaScript files
• Minify JavaScript files
• Bundle CSS files
• Inline images using data-uri

You can even roll your own filters.

Storage

Rack Pagespeed currently supports two storage options: disk and memcached. See the well designed docs for advanced options.

[Source on GitHub] [Web site]

Joe detects performance bottlenecks and recommends optimizations from the comfort of your Slack team.

What is the model lifecycle like for experimenting with and then deploying generative AI models? Although there are some similarities, this lifecycle differs somewhat from previous data science practices in that models are typically not trained from scratch (or even fine-tuned). Chris and Daniel give a high level overview in this effort and discuss model optimization and serving.

There’s so much talk (and hype) these days about vector databases. We thought it would be timely and practical to have someone on the show that has been hands on with the various options and actually tried to build applications leveraging vector search. Prashanth Rao is a real practitioner that has spent and huge amount of time exploring the expanding set of vector database offerings. After introducing vector database and giving us a mental model of how they fit in with other datastores, Prashanth digs into the trade offs as related to indices, hosting options, embedding vs. query optimization, and more.

Model sizes are crazy these days with billions and billions of parameters. As Mark Kurtz explains in this episode, this makes inference slow and expensive despite the fact that up to 90%+ of the parameters don’t influence the outputs at all.

Mark helps us understand all of the practicalities and progress that is being made in model optimization and CPU inference, including the increasing opportunities to run LLMs and other Generative AI models on commodity hardware.

Russ Cox, for the Go team:

Today we celebrate the thirteenth birthday of the Go open source release. The Gopher is a teenager!

It’s been an eventful year for Go. The most significant event was the release of Go 1.18 in March, which brought many improvements but most notably Go workspaces, fuzzing, and generics.

He goes on to describe many of the other notable features and events of the past year and closes with a glance into Go’s future:

In Go’s 14th year, we’ll keep working to make Go the best environment for software engineering at scale. We plan to focus particularly on supply chain security, improved compatibility, and structured logging, all of which have been linked already in this post. And there will be plenty of other improvements as well, including profile-guided optimization.

Jeremy Brown:

It feels bizarre saying this, having spent so much of my life advocating for and selling a distribution of Kubernetes and consulting services to help folks get the most of out it, but here goes! YOU probably shouldn’t use Kubernetes and a bunch of other “cool” things for your product.

This post turns out to be less about Kubernetes and more about premature optimization and doing more with less. Also it’s about Kubernetes. 😉

Most Ruby engineers know the difference between symbols and strings from a usage perspective. So, in this article I look at them from a different angle.

You’ll learn about a cool compiler optimization called “string interning”, which is used in many languages. Also, you will understand what happens when (almost any) interpreter runs your code, take a look at the AST and take a peak at the symbols interpretation at the low level.

We all hear a lot about MLOps these days, but where does MLOps end and DevOps begin? Our friend Luis from OctoML joins us in this episode to discuss treating AI/ML models as regular software components (once they are trained and ready for deployment). We get into topics including optimization on various kinds of hardware and deployment of models at the edge.

Martin Heinz on the tools/techniques for finding bottlenecks in your Python code. And fixing them, fast.

The first rule of optimization is to not do it. If you really have to though, then optimize where appropriate. Use the above profiling tools to find bottlenecks, so you don’t waste time optimizing some inconsequential piece of code. It’s also useful to create a reproducible benchmark for the piece of code you’re trying to optimize, so that you can measure the actual improvement.

This is not a use-it-in-the-real-world kinda thing. It’s being written as a learning project, but may interest you if you want to learn about database internals. It includes:

• Raft-based distributed consensus engine for linearizable state machine replication.
• ACID-compliant transaction engine with MVCC-based snapshot isolation.
• Pluggable storage engine with B+tree and log-structured backends.
• Iterator-based query engine with heuristic optimization and time-travel support.
• SQL interface including projections, filters, joins, aggregates, and transactions.

David Sweet, author of “Tuning Up: From A/B testing to Bayesian optimization”, introduces Dan and Chris to system tuning, and takes them from A/B testing to response surface methodology, contextual bandit, and finally bayesian optimization. Along the way, we get fascinating insights into recommender systems and high-frequency trading!

Tudor Girba unpacks the statement “developers spend most of their time figuring the system out.”

…reading is just the means through which information is gathered from data. It also happens to be the most manual possible way to do that, so this lends itself to an important opportunity for optimization.

Before you can do something significant about anything, you have to name it. Otherwise it’s like with Voldemort. Many winters ago, I called the effort of “figuring the system out to know what to do next” assessment. And I claimed we should optimize development around it. For a whole decade my colleagues and I explored this idea. And it led us to what we now call moldable development.

Agniva De Sarker:

This is the story of an (apparently) smart optimization to a SQL query that backfired spectacularly and how we finally fixed it.

An excellent tale told in two parts. Stick around for the finale for a solid mic drop moment.

From Rob Pike on Google’s Open Source Blog:

In the past year, we’ve posted sixteen case studies from end users around the world talking about how they use Go to build fast, reliable, and efficient software at scale. Today, we are adding three new case studies from teams inside Google:

• Core Data Solutions: Google’s Core Data team replaced a monolithic indexing pipeline written in C++ with a more flexible system of microservices, the majority of them written in Go, that help support Google Search.
• Google Chrome: Mobile users of Google Chrome in lite mode rely on the Chrome Optimization Guide server to deliver hints for optimizing page loads of well-known sites in their geographic area. That server, written in Go, helps deliver faster page loads and lowered data usage to millions of users daily.
• Firebase: Google Cloud customers turn to Firebase as their mobile and web hosting platform of choice. After joining Google, the team completely migrated its backend servers from Node.js to Go, for the easy concurrency and efficient execution.

Want to share your story about how your team or organization uses Go? Share your story here.

The TLDR of their reasoning is Go’s garbage collection was causing performance problems at scale. Since Rust doesn’t have a garbage collector, it allowed the team to manage their memory use more effectively. Their results were… uplifting:

Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go.

This is not a Go sucks switch to Rust story. It is a well-reasoned argument for using one technology over the other when it makes sense to do so.

When starting a new project or software component, we consider using Rust. Of course, we only use it where it makes sense.

PyTorch3d is designed to integrate smoothly with deep learning methods for predicting and manipulating 3D data. For this reason, all operators in PyTorch3d:

• Are implemented using PyTorch tensors
• Can handle minibatches of hetereogenous data
• Can be differentiated
• Can utilize GPUs for acceleration

Get started with tutorials on deforming a sphere mesh into a dolphin, rendering textured meshes, camera position optimization, and more.

We continue to use bundlers even though ES Modules (the new JavaScript module system) runs natively on the web. Why?

Over the last several years, JavaScript bundling has morphed from a production-only optimization into a required build step for most web applications. Whether you love this or hate it, it’s hard to deny that bundlers have added a ton of new complexity to web development – a field of development that has always taken pride in its view-source, easy-to-get-started ethos.

Related ~> JS Party #69

From writing and optimizing Go code to common gotchas with the Go standard library, Damian Gryski shared his thoughts on Go performance optimization and outlined best practices for writing high-performance Go code. Available in English, 中文, and Español.

When and where to optimize — Every optimization has a cost. Generally this cost is expressed in terms of code complexity or cognitive load – optimized code is rarely simpler than the unoptimized version. But there’s another side that I’ll call the economics of optimization. As a programmer, your time is valuable. There’s the opportunity cost of what else you could be working on for your project, which bugs to fix, which features to add. Optimizing things is fun, but it’s not always the right task to choose. Performance is a feature, but so is shipping, and so is correctness.

Brian Brazil:

The informal design goal of the Prometheus 2.x TSDB startup was that it should take no more than about a minute. Over the past few months there’s been reports of it taking quite a bit more than this, which is a problem if your Prometheus restarts for some reason. Almost all of that time is loading the WAL (write ahead log), which are the samples in the last few hours which have yet to be compacted into a block. I finally got a chance to dig into this at the end of October, and the outcome was PR#440 which reduced CPU time by 6.5x and walltime by 4x. Let’s look at how I arrived at these improvements.

I’ve been meaning to get more familiar with pprof, the Go profiling tool, as my job revolves around working on and around Go microservices. My team has been able to see the impact of the Go experts who can quickly find issues buried in a stack of profiles collected on a service.

Brian’s post is a great example of 1) identifying the an issue, 2) diagnosing said issue and 3) observing the implemented improvements using pprof. His parting paragraph is particularly insightful, specifically:

I did spend quite a bit of time pouring over the code, and had several dead ends such as removing the call to NumSamples, doing reading and decoding in separate threads, and a few variants of how the processWALSamples sharding worked

Profiling and optimization is a mix of knowing your codebase and being able to identifying false leads. A tool like pprof is invaluable when identifying both issues and improvements in a measurable way.