🏗️ Projects

Browse through open source projects on OpenSourceHub.io, add your project to get more exposure and connect with other maintainers and contributors!

🖼️ Stable Diffusion 2.0

High-Resolution Image Synthesis with Latent Diffusion Models.

language: Python, stars: 4600, issues: 29, last commit: 2 days
repo: github.com/Stability-AI/stablediffusion
blog: stability.ai/blog/stable-diffusion-v2-release

🤝 public APIs

A collective list of free APIs for use in software and web development.

stars: 5637, issues: 9, last commit: 21 days
repo: github.com/public-api-lists/public-api-lists

⚡ Coolify

An open-source & self-hostable Heroku / Netlify alternative.

language: Svelte, stars: 5094, issues: 116, last commit: 4 days
repo: github.com/coollabsio/coolify
site: coolify.io

📬 Kill the Newsletter!

Convert email newsletters into Atom feeds.

language: JavaScript, stars: 1488, issues: last commit: Sept 6, 2021
repo: github.com/leafac/kill-the-newsletter
site: kill-the-newsletter.com

Join thousands of other open-source enthusiasts and developers in the Open Source Hub Discord server to continue the discussion on the projects in this week's email!

🎤 Interview With Leandro of Kill the Newsletter!

Hey Leandro! Thanks for joining us! Let us start with your background.

Sure. My pleasure. Thanks for having me. I was born in Brazil, went to grad school in the US, and now I live in Portugal. I started working as a web developer when I was about 15. Back then I worked in several places, including one of the biggest media groups in Brazil (UOL), and a couple startups in their early stages (which unfortunately are no longer around because the angel investor folded). Then I went to grad school to study programming language theory for about 6 years. Now I’m back into web development, and I’m also getting into programming software for audio & video production. And I’m doing daily livecoding streams on YouTube.

How did you learn to program?

First, by reading the books my father had lying around about JavaScript, PHP, and so forth. He wasn’t a programmer professionally, but that was one of his hobbies.

Then, in academia, by reading papers and the code produced by other researchers.

Now, mostly by reading lots of manuals creating my own things.

What languages or frameworks do you like?

Languages: I’m into programming language theory, so I’d be hard-pressed to mention a language that I don’t like.

I believe that the main point of a programming language is to communicate ideas about computation to other people, so I tend to use programming languages that are popular and relatively straightforward.

That’s why I use JavaScript/TypeScript for many projects.

I also write JSFX almost every day. JSFX is a language for real-time audio processing in an audio program called REAPER—it’s a simple language, but it lets you experiment fast.

I often write Lua for extensions in REAPER, Hammerspoon, and so forth.

I’m getting into C++ to develop audio effects for other audio programs besides REAPER.

In the past I did a lot of Ruby, Racket, and some Java, but these days not so much.

I also dabbled in Go, various LISP descendants, and so forth. The list goes on…

Frameworks: I’m a big fan of Express. It’s very accessible; most people find it straightforward to learn.

Other than that, I’m building my own “radically straightforward” tools: sqlite, html, css, javascript, caddy The documentation isn’t there yet, but I’m already using it on my day job and I’m very happy with the results: courselore.org

It’s using server-side rendering for everything and doing diffing of the (non-virtual) DOM in the browser. It can give you some of that real-time, app-like feel that people expect while maintaining the simple programming model of server-side rendering. I’m looking forward to polishing the documentation and showing this to more people.

Who or what are your biggest influences as a developer?

I keep returning to what I learned from Sandi Metz. I have read all her books and had the pleasure to meet her once. Ideas like “shameless green” and “duplication is cheaper than the wrong abstraction” really stuck with me.

What’s your most controversial programming opinion?

The notion that we should respect and avoid badmouthing any programming language.

Of course we should discuss the technical aspects of programming languages, but often this kind of conversation goes off the rails. I often hear comments like “people who use <programming language> tend to be bad programmers.” Sometimes these comments even come from programming languages researchers, who I would expect to be generally curious and respectful of the topic of their study.

I believe that some programming languages end up being more than just tools. In many cases they reflect the culture of a group of people and become part of their identity. Just think of people who present themselves as “<programming language>er” instead of “software developer.”

So I think that we should be respectful of programming languages the same way we should be respectful of natural languages (English, Portuguese, and so forth), the music of other cultures, the way they dress, and so forth.

From all my ideas about programming, this has been by far the one that has received the most pushback in conversation with other people 🤷

What is your favorite software tool?

Visual Studio Code. I spend most of my time on Earth staring at this thing, so I guess it’s natural that I end up liking it 🙃

The thing I like about it the most is that the defaults are pretty good. In the past I spent so much time tweaking text editors, and Visual Studio Code works well out of the box for me.

What is your favorite book and why?

Non-technical: Paper Towns, by John Green. It’s smart and fun throughout, and the last chapter is a masterpiece!

Technical: Sandi Metz’s books. All of them.

If I gave you $10 million to invest in one thing right now, where would you put it?

Containing the spread of misinformation: Content moderation, fact-checking, and so forth.

I think that the return of investment wouldn’t be monetary, but it would be huge.

What are you currently learning?

How to measure response times in a web application without falling into statistics pitfalls. And how to profile the application to find performance bottlenecks.

Why was Kill the Newsletter started?

I go back and forth between trying to be more organized and letting things get messy.

At one point about 8 years ago I was trying to be more organized, and I thought: Email should be only for personal communication, and I should consume content via RSS/Atom.

But some of the content in which I was interested was available via newsletters only. I looked around and found many services that would do RSS/Atom → email, but not the other way around.

Back then I was also running my own email server, so it was relatively straightforward to put Kill the Newsletter! together.

How does Kill the Newsletter work?

It’s a web application and an email server.

It uses Node.js these days, but I have re-implemented Kill the Newsletter! a couple times using Ruby & Sinatra, Ruby on Rails, Go, and so forth. It’s actually one of the reasons why I like it: It’s a great testbed for technologies in which I’m interested—neither too trivial nor too complex.

In any case, the web application lets you create an inbox, which ends up being a row in an SQLite database. In the past I even used the filesystem as a database, which was fun, even though dealing with race conditions was a bit complicated.

The email server receives email and stores it in the SQLite database as well.

The web application serves Atom feeds created from these SQLite tables.

Nothing too fancy 🤷

Has the popularity and usage of RSS come down or go up since you started the project? Did you notice any trends?

I don’t track usage too closely, but judging by the server costs usage has gone up in the first couple years of the project and plateaued a couple years ago.

I suppose the use of RSS overall has come down significantly. Google Reader was a big player in that space, and it closed. Social networks came about…

I, for one, stopped using RSS and Kill the Newsletter! many years ago. But don’t worry, I’m committed to continue working on it because many people find it useful, so I think of it like retribution for all the awesome open-source stuff I use every day. Also, as I mentioned, it’s a great way to experiment with different tools and techniques.

Do you have any guesses on the number of people using the hosted version?

No. I don’t track these numbers. I suppose it’d be complicated to do that because there isn’t even a notion of a “user” in Kill the Newsletter!: you just come in, create an inbox, and go.

I can tell you that:

1. There are 146043 feeds and 850610 entries right now.

2. The database is about 26GB.

3. The application transfers about 2TB per month.

But keep in mind that many feeds may have been created by the same people. I suppose some power users may have hundreds of feeds.

Also keep in mind that there’s no way to delete a feed, so many of these may have been abandoned.

How did the project become popular?

I don’t really know, but I suppose it was because it was the only tool around at that point that would do this very specific thing. Even these days it may be the only free option—I think that Feedly has something like Kill the Newsletter!, but only in paid plans.

When I created Kill the Newsletter! I posted it to Hacker News and things like that, but it didn’t get any traction. To my surprise, much later someone else posted it again, and that time it got to the front page for a couple hours and received some nice comments. Thank you, internet friend 😁

How much does it cost to run the service?

Approximately $20/month. The application itself is pretty light, so it runs on an inexpensive machine. What drives up the cost a bit is the data transfer.

What is the most challenging problem that’s been solved in Kill the Newsletter, so far (code links encouraged)?

Keeping the cost down 🙃

At some point I was using Amazon S3 for storage, SendGrid for email processing, and so forth (https://github.com/leafac/kill-the-newsletter/tree/service-oriented). That was when Kill the Newsletter! was getting more popular, so the costs went up really fast.

I had to rewrite everything to run on a DigitalOcean machine, on which the data transfer is priced more reasonably. I think it’s a much better design anyway, and much simpler to setup for people who want to run Kill the Newsletter! on their own servers.

What was the most surprising thing you learned while working on Kill the Newsletter?

Race conditions aren’t just a theoretical problem. Even on a relatively small application like Kill the Newsletter! it’s still possible for two emails to arrive at exactly the same time for the same inbox.

When I was using the filesystem as a database two inboxes were corrupted because of this 🤷

How do you balance your work on open-source with your day job and other responsibilities?

Shameless plug: My day job is also open-source: courselore.org

I work from Monday to Saturday. Every day I have three work sessions that last two hours each. Two go to my day job, and the third goes to open-source projects, livestreams, music production, and so forth.

The rest of the time I spend with my family.

Have you ever experienced burnout? How did you deal with it?

I suppose I sometimes burn out on one project, yes.

But I keep many plates spinning. So when that happens, I go to another project. Some projects I keep returning to, like Kill the Newsletter!; some projects may go unfinished for a while.

Luckily, I haven’t experienced burnout of the whole endeavor.

If you plan to continue developing Kill the Newsletter, where do you see the project heading next?

I do plan to continue developing Kill the Newsletter!, yes!

Right now I’m in the middle of changing the way we deal with TLS certificates: Instead of doing everything in the Node.js process we’ll introduce Caddy as a reverse proxy.

I’m taking the opportunity to rework many other technical aspects of Kill the Newsletter!, for example, using multiple Node.js processes to leverage all CPU cores.

In terms of features, I think it’s pretty much complete at this point. One thing that I consider adding is a way to confirm subscriptions by sending an email, which is necessary for some newsletters. But sending emails is much harder than receiving, because you must make sure that you don’t become a spammer by accident. We’ll see…

People who want to follow along can participate on my livestreams at https://youtube.com/@leafac

Are there any other projects besides Kill the Newsletter that you’re working on?

Yes! My day job at courselore.org

Daily coding livestreams at https://youtube.com/@leafac

caxa, a way to package Node.js application into a single executable: https://github.com/leafac/caxa

Audio effects and scripts for REAPER: https://github.com/leafac/reaper

This week I started a tool to do data bending (for example, using audio effects in a video file): https://github.com/leafac/data-bender

And I’m always producing original music, which you can also find in my YouTube channel.

Do you have any other project ideas that you haven’t started?

Plenty! Lately I’ve been getting my feet wet in electronics. Particularly for audio. So I’ve been dabbling into making guitar pedals, synthesizers, and so forth. For the time being I’m trying out other people’s schematics and learning how to solder. It’s a fascinating field!

What is one question you would like to ask another open-source developer that I didn’t ask you?

Ways to make the work sustainable.

In my case, I’m lucky to have people who support my work. From my day job at courselore.org and to all the supporters on Patreon, GitHub Sponsors, and so forth (see leafac.com).

It’s important to think of this part of the equation to make sure that you can work on longer and more ambitious projects, especially after the initial spark of excitement.

Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!

Leave a comment

Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at osh@codesee.io or mention us @ConsoleWeekly!