This week Adam is taking the show off the beaten path to speak with Adam Miller, the founder and CEO of Revel Bikes. Yes that’s right, this episode features a founder of a bike brand, not a tech brand.

Adam Miller’s journey to create Revel Bikes is paved with many ups and many downs, a failed partnership, super scrappy weeks and months traveling the world to find the best manufacturing partners, the latest innovations in suspension tech and modern geometry to hit the mountain biking scene, a strong team that’s been with him every step of the way (many of which are as close as family), and truly some of the best premium bikes available on the market today.

BTW, Adam (host) is an owner of a Revel bike — he has a T1000 colorway Rascal that he’s ridden on downhill trails, all-day epics, and everything in-between. If you enjoy this episode, please us know in the comments.

Matched from the episode's transcript 👇

Deploying new applications can be tough. Deploying configuration management safely at scale with stores around the world is different. Martin Jackson joins us to discuss.

Matched from the episode's transcript 👇

GitLab has changed a lot over the past 8 years and so has Abubakar. Starting in the help desk he’s seen a lot and takes us through GitLab’s and his progression.

Matched from the episode's transcript 👇

Verónica López, Kubernetes SIG Release tech lead & distributed systems engineer, joins Justin & Autumn to share her experiences deploying services at scale.

Matched from the episode's transcript 👇

What’s the difference between productivity engineering and platform engineering? How can you continue to re-platform with a moving target? On this episode, we’re joined by Andy Glover, who spent ten years productivity engineering at Netflix, to discuss.

Matched from the episode's transcript 👇

KBall, Ali & Nick explore a new type of segment: “WTFJS” talking about wild and wooly “it’s not a bug it’s a feature” examples in the JavaScript language. They also dive into code maintainability, and end by discussing the whiplash shift in the tech industry from “hottest market for engineers in history” to “oh noes everything is stopping!”

Matched from the episode's transcript 👇

Redux maintainer Mark Erikson joins Jerod and Amal for an in-depth conversation around the React community’s fav state management solution. We learn how Mark came to be maintainer of Redux, why and how Redux Toolkit came about, when to go with Redux vs other options, and much more.

ALSO: prop drilling, the grep factor, & lasagna mode (oh my)

Matched from the episode's transcript 👇

Today we’re talking to Linus Lee about the practice of building software for yourself. Linus has several side projects we could talk about, but today’s show is focused on Linus’ dynamically typed functional programming language called Ink that he used to write his full text personal search engine called Monocle.

Linus is focused on writing software that solves his own needs, all of which is open source, to help him learn more deeply and organize the knowledge of his life.

Matched from the episode's transcript 👇

Kyle Quest joins the show to tell Autumn & Justin all about the evolution of DockerSlim & minimal container images. Why are small container images important? What are different strategies to make containers smaller? Let’s find out!

Matched from the episode's transcript 👇

This week on The Changelog we’re taking you to the hallway track of The Linux Foundation’s Open Source Summit North America 2023 in Vancouver, Canada. Today’s anthology episode features: Beyang Liu (Co-founder and CTO at Sourcegraph), Denny Lee (Developer Advocate at Databricks), and Stella Biderman (Executive Director and Head of Research at EleutherAI).

Special thanks to our friends at GitHub for sponsoring us to attend this conference as part of Maintainer Month.

Matched from the episode's transcript 👇

Go modules brought about quite a few changes to the Go ecosystem. One of those changes is semantic import versioning (SIV), which has a fairly pronounced effect on how libraries are identified. In this episode we are joined by Tim Heckman and Peter Bourgon to discuss some of the downsides to these changes and how it has lead to what a subset of the Go community refers to as the “v2+ problem.”

Matched from the episode's transcript 👇

In this episode we’re shinning our maintainer spotlight on Ned Batchelder. Ned is one of the lucky ones out there that gets to double-dip — his day job is working on open source at edX, working on the Open edX community team. Ned is also a “single maintainer” of coverage.py - a tool for measuring code coverage of Python programs. This episode with Ned kicks off the first of many in our maintainer spotlight series where we dig deep into the life of an open source software maintainer. We’re producing this series in partnership with Tidelift. Huge thanks to Tidelift for making this series possible.

Matched from the episode's transcript 👇

This week we’re joined by Christina Warren, Senior Developer Advocate at GitHub, and a true tech and pop culture connoisseur. From her days at Mashable covering the intersections of entertainment and technology, to Gizmodo, to Microsoft, and now her current role at GitHub we talk with Christina about her journey from journalist to developer, and the latest happenings coming out of GitHub Universe.

BTW, we’re planning to get Christina on Backstage in the new year to talk about Plex, MakeMKV, and all things that go into hosting your own media server. Drop a commment on this episode with a +1 if you want to see that happen.

Matched from the episode's transcript 👇

Debbie O’Brien –Senior Program Manager at Microsoft– joins Amal & Nick for a deep-dive on Playwright, an automation library for cross-browser end-to-end testing. Along the way, we learn why Microsoft decided to fork Puppeteer, Playwright’s unique value proposition, cool features like auto-waiting & the trace viewer, how it compares to Cypress & a lot more.

Matched from the episode's transcript 👇

An open platform for operating LLMs in production, working quickly is more important than it seems, imaginary problems are the root of bad software, Val Town is a social website to write and run code & Aaron Francis’ guide to finishing your projects.

Matched from the episode's transcript 👇

The Astro team releases a new documentation builder, legendary computer scientist Donald Knuth plays with ChatGPT, over 500 volunteer mods have signed an open letter to Stack Overflow Inc, Reddit faces a revolt due to their new API pricing & the Technology Innovation Institute release Falcon, a new open source LLM that’s topping Hugging Face’s leaderboard.

Matched from the episode's transcript 👇

Mat & Johnny interview everyone’s favorite LLM (Natalie with a special hat on) to see if it’d make a good hire as a Go dev. Also, Mat tries to turn it into his very own creepy robot by asking personal questions about his co-hosts. Things get weird. In a good way?

Matched from the episode's transcript 👇

Eight months ago, in 🎧 episode 49, Alex Sims (Solutions Architect & Senior Software Engineer at James & James) shared with us his ambition to help migrate a monolithic PHP app running on AWS EC2 to a more modern architecture. The idea was some serverless, some EKS, and many incremental improvements.

So how did all of this work out in practice? How did the improved system cope with the Black Friday peak, as well as all the following Christmas orders? Thank you Alex for sharing with us your Ship It! inspired Kaizen story. It’s a wonderful Christmas present! 🎄🎁

Matched from the episode's transcript 👇

Preact creator Jason Miller joins Jerod and Nick to discuss WMR– the tiny all-in-one development tool for modern web apps.

We ask Jason what “modern web app” means, how WMR fits in to the JS tooling landscape, why the Preact team created it in the first place, and dig into all it has to offer. Where’s My Roomba?

Matched from the episode's transcript 👇

This week we chatted with Kahlil Lechelt about mentorship. What types of mentorships are there, what makes a successful mentorship, and where can you find a mentor?

Matched from the episode's transcript 👇

We’ve mentioned ML/AI in the browser and in JS a bunch on this show, but we haven’t done a deep dive on the subject… until now! Victor Dibia helps us understand why people are interested in porting models to the browser and how people are using the functionality. We discuss TensorFlow.js and some applications built using TensorFlow.js

Matched from the episode's transcript 👇

Hello 2024! We’re kicking off the year with Dan Moore, author of ‘Letters to a New Developer’ — a blog series of letters of what Dan wished he had known when starting his developer career. We discuss the value of online communities for new developers, the importance of communication skills, and the need to stay relevant in a rapidly changing industry. Dan shares his best advice for new developers, including the importance of saying no, leaving code better than you found it, and the value of skill stacking. So much wisdom and advice in this episode!

Jim Nielsen:

I heard Paul Ford, a professional writer for Wired and other publications, say something on The Aboard Podcast, Episode 3 that resonated. Referring to a moment when lots of folks online were looking for the perfect writing environment, he said the software tool, workflow, environment, whatever, it didn’t matter. You could do it with pen and paper if you want.

The only technology that you need is deadlines.

Ooff. Yup, that resonates. That’s been the best piece of technology for making me productive too.

See also arbitrary deadlines are actually awesome by yours truly.

This is an excellent deep-dive on error message best practices by Jenni Nadler from Wix:

Error messages are part of our daily lives online. Every time a server is down or we don’t have internet, or we forget to add some info in a form, we get an error message. “Something went wrong” is the classic. But what went wrong? What happened? And, most importantly, how can I fix it?

Miguel Grinberg built a SQLite-backed web app for the blogging team at Twilio to track their effectiveness that started to respond slugishly when it grew much bigger than he expected (6.5 million individual daily traffic records, and with a user base that grew to over 200 employees).

He thought this might be a good time to switch to Postgres, but he wasn’t sure if the wins he expected would be realized:

Having publicly professed my dislike of performance benchmarks, I resisted the urge to look up any comparisons online, and instead embarked on a series of experiments to accurately measure the performance of these two databases for the specific use cases of this application.

In this in-depth article on Twilio’s blog (no doubt being tracked by Miguel’s web app as we speak) he goes into the details of his efforts with lots of interesting findings along the way (even a plot twist!). I’ll leave you with this statement from the end:

If you are going to take one thing away from this article, I hope it is that the only benchmarks that are valuable are those that run on your own platform, with your own stack, with your own data, and with your own software. And even then, you may need to add custom optimizations to get the best performance.

CV Compiler is an online resume analysis tool designed exclusively for software engineers.

The review technology scans for keywords from the world of programming and how they are used in the resume, relative to the best practices in the industry.

CV Compiler was built using Python with libraries NLTK and spaCy for tokenization, lemmatization, and POS-tagging.

The internal analysis engine for large datasets (resumes, job descriptions) was built upon a Seq2Seq model in TensorFlow.

At some point you may have been asked to share your coding knowledge with friends, kids in your family, or just had a desire to teach others in the community. If you’re going to start with the basics of HTML, especially with younger students, it’s going to be so much easier with Thimble from Mozilla.

Thimble is a free online code editor that allows students to make changes to HTML code on the left side and see the result in real time on the right. The key to helping spark the curiosity is seeing that connection between their action and outcome. It seems like magic to them, they want to learn how it all works, and the desire to learn is ignited.

What makes Thimble useful

One of the neat aspects of this tool is that mistakes or code that is broken are highlighted. With this setting students can quickly self correct their own page and catch errors early on.

A deep dive into webmaker reveals it’s a larger collection of resources to encourage learning web literacy. As students start to learn core HTML skills they will earn badges from demonstrating that skill in their actual projects.

Why not just use an editor and browser?

Using a tool like Thimble eliminates the ramp up time and gets straight to learning. Students may be borrowing grandma’s laptop, some are using a mac, some are using various versions of Windows, etc. Rather than spend our entire time together working through computer setup differences we get straight to the code.

Why not use JSFiddle or CodePen?

Both JSFiddle and CodePen are fantastic tools but in the very beginning less is more. Eliminating distractions helps to focus on the skill challenge at hand rather than having beginners feel overwhelmed by seeing all the components they don’t know yet, like javascript or css.

The best way to get started

If you don’t know what to teach take a look at some of the Thimble remixes with step by step instructions on building new skills. I’ve tried several tools for enabling young beginners to learn HTML and Thimble is hands down my favorite starting point. Whether teaching family and friends, or hosting your own webmaker event, Thimble is a go to resource for creating excitement about building for the web.

When Meteor was first announced in April 2012, the announcement’s Hacker News thread quickly rose to the first spot on the homepage and remained there for a good while.

It ended up being one of the site’s most popular posts ever, gathering more than 1300 points. For those unfamiliar with Hacker News, you can usually count yourself lucky if your link gets more than 20 points with this hyper-critical audience. Of course, virtual points are no guarantee of real-world success, but this at least illustrates Meteor’s, ahem, meteoric rise to fame.

So one year later, what’s the verdict? Was there any substance behind all that hype? Since I’ve been using Meteor for the last 6 months (I released Telescope, one of the main Meteor open-source apps), I thought I’d take a moment to share my impressions.

First of all, a disclaimer: while I code with Meteor every day, most of my time is spend making Telescope more usable rather than digging deeper into Meteor’s guts. So I don’t pretend to be an expert on the underpinnings of the framework, and this overview will probably reflect that. But then again, I believe this also shows how effective Meteor can be even if you don’t master all of its intricacies.

A Smarter, Simpler Framework

If you’ve heard about Meteor at all, it was probably in the context of real-time web apps. But even though real-time is what Meteor is best known for, it’s far from its only advantage. When you first start using Meteor, the first thing you’ll notice is how it wants to make your life easier.

Installing Meteor only requires a single command line, and so does creating your first app.

Even deploying is made easy, thanks to Meteor providing you with free hosting so you can quickly push your experiments online.

Other small touches contribute to making getting up and running faster: for example, any JavaScript or CSS file included in your project directory will automatically get loaded, and Meteor also provides you with built-in user management, complete with a drop-in UI widget.

The Future is Real-Time

Of course, real-time is the framework’s big selling point. But while “real-time web-app” calls to mind images of multiplayer games and live collaborative document editing, using Meteor I quickly realized that real-time also had much more pragmatic applications, and in fact could very well become the default way we build web apps within a couple years.

To give you an example, think about the way your desktop file system works. If you open the same directory in two windows and delete a file in one of them, you’ll see the file disappear from the other one as well, without the need to “refresh” it.

In the context of the desktop, we don’t think of this as “real-time”. Yet it’s exactly the kind of interaction that frameworks like Meteor are making trivial to implement on the web as well.

Thinking in real time also influences your coding style. You no longer need page refreshes or specific callback logic to make your app react to changes: every single piece of data is now automatically monitored for you, and any UI element that depends on that data will be affected accordingly.

Here’s how this principle (known as reactivity) translates in practice. In this case we want to give a “disabled” class to an upvote button once somebody has voted:

Here is the template code (Meteor uses Handlebars):

<div class="post">
  <a href="#" class="upvote btn {{upvotedClass}}">⬆<a />
  <h3><a href="{{url}}">{{title}}</a></h3>
</div>

And here is the matching controller code:

Template.post.helpers({
  upvotedClass: function() {
    // test if user is logged in, and if their userId 
    // is included in the 'upvoters' array
    var userId = Meteor.userId();
    if (userId && !_.include(this.upvoters, userId)) {
      return 'upvoteable';
    } else {
      return 'disabled'
    }
  }
});

The beauty of this approach is that if the user’s userId is removed from the upvoters array for any reason (for example, we implement a “cancel upvote” button somewhere else), the change will automatically be reflected in the UI without writing any additional code!

Is it production-ready?

By now, you’re probably thinking something along the lines of “OK, this looks awesome, but can it be used for real-world apps?”.

The answer, as always, is “it depends”. Meteor can certainly be used for real-world apps. Telescope and Sidebar (which is based on Telescope) are perfect examples of it.

But Meteor can’t be used for all real-world apps just yet. Meteor doesn’t have server-side rendering yet, so it’s not ideal for sites that need to load very fast (like e-commerce sites) or work on underpowered devices (like older mobile phones).

Meteor obviously also has a lot more moving parts than static HTML templates. So there are more points of failure and more uncertainties, although the Meteor team generally does a good job of addressing any problem that crops up.

So I would say right now Meteor will be a perfect choice for a few apps (anything that strongly depends on real-time interactions), a great choice for most of them, and a very bad one for a few specific cases.

But the good thing is that since getting started with Meteor is so easy, you should be able to know pretty quickly in which bucket you fall.

The Meteor Book

Of course, I’m not totally impartial in all this. Along with Tom Coleman (one of the main contributors to the Meteor open-source ecosystem and creator of Meteor package manager Meteorite), I’m currently working on The Meteor Book, a book that will teach you the fundamentals of getting an app up and running with Meteor.

The book is not quite ready, but we’re regularly publishing tutorials and articles on the site, so go check it out and let us know what you think!

Discuss at Hacker News

As developers, it’s important that we have knowledge of intellectual property laws. Regardless of your opinion of them, (I’m very publicly outspoken about desiring an abolishment of IP) the law is the law. As a profession, programmers basically spend most of our time creating intellectual property, and so we need to have a good working knowledge of these issues.

Of course, this all comes with the giant disclaimer: I am not a lawyer. If you’re involved with any of this stuff, you should consult one.

One of the largest intellectual property laws in recent years is the Digital Millennium Copyright Act. A portion of it that’s particularly relevant to programmers is Title II which is also known as the Online Copyright Infringement Liability Limitation Act, which added Section 512 to Section 17. It’s best known as being the bill that introduced the ‘safe harbor’ provision, which affects online service providers such as GitHub. Here’s what the safe harbor means in laymen’s terms: if you have a website where users post content, you’re not liable for the things they post as long as you respond in a timely manner to ‘takedown notices’ from copyright holders. Hence, a ‘safe harbor’ for companies.

Due to the recent kerfluffle between Sony and the group of hackers who are hacking the PS3, Sony’s been on a tear to try and remove the code from the Internet. Of course, some people are hosting said code on GitHub, as well as many other public source code hosts. And so, Sony sent a takedown notice to GitHub. In light of this, GitHub has put up a page which clarifies their position regarding the DMCA. Of course, they’re responding to takedown notices. However, they’re also doing two really neat things: They’re publicly posting the text of these notices in this repository, and they’ve also provided a framework so that people who have had takedown notices sent about their repos can ‘counter-notify’ and have their content brought back up. All of this is laid out in a very straightforward manner in the law, but most companies simply delete the content and let that be it.

There’s only three notices so far, but I applaud GitHub for being transparent and fair about this whole thing. Good stuff!

Apologies for the loaded headline. It’s a hat tip to the Twitter how-to articles that taught us the benefits of setting our avatars, writing a witty bios, setting a location, engaging your audience, and oh yeah, adding value. As a team that digs through a mountain of open source projects each week, so that you don’t have to, we’ve learned some concrete ways to build a community around your codez. Here’s our top ten list of things you can do to promote your Open Source project, or ten reasons I don’t fork your project.

1. You don’t have a friggin’ Readme

For a lot of projects, especially those hosted on GitHub, the Readme is often the first look someone has at your project. Tom Preston-Warner says the Readme is so important that you should write it first. I’ve started doing this for recent projects and have found it focuses my thinking and helps me communicate project goals to others. GitHub’s support for Markdown, Textile, RDoc, and others means rich formatted Readme files that can contain links, tables, and code snippets.

So what makes a good Readme? Here are some critical items you should consider:

• Description - I’m surprised at how many times I land on a project page that is obviously popular (because Twitter told me so) but I have no idea why because the project owners don’t tell me plainly what the project is or why I should care.
• Installation instructions - Tell me where to get the bits and how to install them
• Where to get help - Link to the docs, mailing list, wiki, etc.
• Contribution guidelines - Tell me how I can help out including wanted features and code standards
• Contributor list - List the humans behind the project
• Credits, Inspiration, Alternatives - Tell me if this is a fork of or otherwise inspired by another project. I won’t think you’re a douche when I find out later.

2. You don’t include tests, specs, features, examples

A project without tests is harder to trust, contribute to, and looks more like a hobbyish hack. More than that, though, tests cut down on support requests. I don’t have to ask you or Google, I can look at the codez. An examples folder with scenario-based code show me rather than telling me.

3. You have no project home page

As good as GitHub’s project pages are, they suck for SEO and branding. Create an attention-getting project home page. The GitHub Pages feature makes it dead simple to create simple project home page complete with custom domain support.

4. You need design help

If you’re not blessed with pixel-fu, find a designer who is and pay, trade, or barter with them to give your project an attractive brand and style. Stay away from contests and other “crowd sourcing” sites. Say no to spec work because you wouldn’t want to code a project for someone in hopes your code would be “selected.”

5. You don’t have a domain name

A nice looking home page is nice, but why not shell out ten bucks and make it easier for folks to find it? If the .com is not available for you project name, try a service like Domai.nr to find a creative alternative. We used Domai.nr to find our short domain.

6. You don’t have a Twitter Account

You’re probably already using Twitter to spread the word about your projects, but have you considered a dedicated project account? Erik Michaels-Ober creatively snagged the @gem username for the Ruby Twitter Gem, from which we post updates and answer support questions. @modernizr, @mongodb, and @octokit are other examples. Even if you’re not the project owner, perhaps you could create an unofficial account to help evangelize the project, like Trevor Burnham did with @CoffeeScript.

7. Your licensing is unclear

Just because code is published online doesn’t mean it’s free for the taking in the public domain. For me to use your code, I need to know the stipulations for doing so. Make it easy for me to know the terms under which I can use it by including a LICENSE file or section in the Readme.

8. You don’t reach out to me

Twitter lets you follow people in your niche easily, but perhaps the greater power is the ability to follow a topic. Search for and follow the hashtags related to your project. Find people asking questions or expressing frustration with problems that your project aims to solve. Chris Eppstein and I often reach out to people with #CSS3 questions and extol the benefits of Compass’ CSS3 module.

If your project is large enough, consider creating your own IRC channel. #node.js and #redis, are great examples of active, project-focused channels.

9. You don’t speak about your project at conferences and meetups

Nothing gives the illusion of expertise like a six inch elevated stage and a lanyard. If you want to grab the attention of potential users and contributors, submit a talk to conferences or meetups in your technology community. If you don’t get accepted, go anyway and organize a birds-of-a-feather session where you can meet personally with users, answer questions, and get feedback.

10. You didn’t submit it to The Changelog

If you want to tell the world about your new open source code hotness, one of the best venues is this blog. We strive to stay on the bleeding edge of open source, but we can’t find everything. Want to announce your new project? Submit an issue here thechangelog/ping. That's our defacto list to work from and each week we promote things submitted on the blog, Twitter, or even the podcast! It's also open to the community as well, so folks can step in and ask questions too.

Your turn

Now it’s your turn. We’d like to know what makes you follow and participate in on open source project. Tell us on Hacker News.