The Changelog: Software Development, Open Source - The democratization of spreadsheets (News)

Episode Date: November 11, 2024

Changelog Merch is now on sale, IronCalc sets out to democratize spreadsheets, Grant Slatton writes about algorithms we develop software by, Mark Rainey gives respect to the ultimate in debugging, Gitpod is leaving Kubernetes & Johannes Kaufmann’s html-to-markdown converts entire websites into Markdown.

What up nerds, I'm Jared and this is Changelog News for the week of Monday, November 11th, 2024. Merch alert! We are doing a first ever year end sale with discounts up to 40% off. There's never been a better time to grab yourself, or a friend, or a collaborator, or an open source maintainer, some fresh ChangeLog threads. Get in on it at merch.changelog.com. All threaded up? Sweet.

Let's get into this week's news. The democratization of spreadsheets. IronCalc is an MIT-licensed, work-in-progress spreadsheet engine written in Rust, but usable from a variety of programming languages like Python, JavaScript, via Wasm, Node.js, and possibly R, Julia, or Go. Here is why they're building it. accounts or suffer from performance and stability issues. Our mission, to fill the gaps left by the industry and empower every user with a robust, open-source spreadsheet engine that caters to diverse needs. End quote. Their ambition extends beyond code too.

They want to drive the spreadsheet industry forward through R&D, community building, and an awesome knowledge base. Cool stuff. Algorithms we develop software by. Grant Slatton outlines a cool feature development method he learned from another engineer. Quote, start working on the feature at the beginning of the day. If you don't finish by the end of the day, delete it and start over the next day. You're allowed to keep unit tests that you wrote. If after a a few days, you can't actually implement the feature, think of what groundwork, infrastructure, or refactoring would need to be done to enable it.

Use this method to implement that, then come back to the feature. End quote. I've never tried that method exactly, but it rhymes with techniques I've tried in the past. That got Grant thinking about other heuristics and generalizations, such as 1. Write everything twice. 2. Quantity has a quality all of its own. And 3. The gun-to-your-head method. That last one reminds me way too much of a particular scene from Swordfish.

If you know, you know. The ultimate in debugging. Here's Mark Rainey. Quote, engineers are currently debugging why the Voyager 1 spacecraft, which is 15 billion miles away, turned off its main radio and switched to a backup radio that hasn't been used in over 40 years. I've had some tricky debugging issues in the past, including finding compiler bugs and debugging code with no debugger that had been burnt into prompt packs for terminals. However, I have huge admiration for the engineers maintaining the operation of Voyager 1. Recently, they sent a command to the craft that caused it to shut off its main radio transmitter,

seemingly in an effort to preserve power and protect from faults. This prompted it to switch over to the backup radio transmitter that is lower power. Now they have regained communication, they are trying to determine the cause on hardware that's nearly 50 years old. Any communication takes days. When you think you have a difficult issue to debug, spare a thought for this team. End quote. In fact, end post. I just quoted it in its entirety. I guess I saved you a click. Sorry, Mark. I'll link to the source of the story he's talking about in newsletter. It's now time for sponsored news.

Kurt Mackey says, clouds generally suck. Our friends at Fly.io have a great YouTube channel, and they recently published a chat between Kurt Mackey and Annie Sexton about why public clouds generally suck. The main takeaway? Public clouds aren't really built for developers. Here's a taste of that conversation. Why does the cloud suck, Kurt? Well, there are a lot of clouds. Usually I'm lamenting when I say the cloud sucks, it's AWS and it's competitive.

Azure and GCP are just AWS again. Honestly, I think the clouds, those clouds suck for me because I'm a developer. I'm not like a person who wants to operate cloud components. I'd rather just build apps and make them run, like put them somewhere. I think that's a lot of people. Yeah. But that's not really what those clouds are for. And so the net effect is that if I launch like, I don't know, a Next app or a Rails app or a Phoenix app, as I would do lately,

I don't even know where to start with this necessarily on AWS at this point. Like, they have a catalog of, like, 400 products. You probably only need three of them, but you just got to figure out which ones and how to string them together. For, like, a Phoenix app on AWS, you're going to end up needing a VPC, which they'll give you by default these days. You need to know what a VPC is you need you need probably either a Fargate or their kubernetes setup to run the app of actual application you need RDS you need an elastic load balancer or an application load balancer running in front of it and on the other end of that you've got the Heroku effect which is like you can get a rails app running and this is like

2008 me was really excited about this you can get a rails app running really fast as long like 2008, and Amy was really excited about this. You can get a Rails app running really fast, as long as it's Rails, and as long as it uses Postgres, and as soon as you need to do something else, you're like back in the AWS quagmire. Follow the link in your chapter data or the newsletter to listen to the entire 15-minute convo, and thanks once again to Flight.io for sponsoring ChangeLog News. We're leaving Kubernetes. Gitpod's Christian Weichel and Alejandro de Brito Fontes tells the story of how they realized that Kubernetes is not the right choice

for building developer environments. Quote, this is not a story of whether or not to use Kubernetes for production workloads. This is the story of how not to build development environments in the cloud. End quote. Whatever you do, do not take this as generic Kubernetes bad advice.

Their findings are specific to building development environments, which are unique for many reasons, such as they are extremely stateful and interactive. Developers are deeply invested in their source code, and the changes they make, they have unpredictable resource usage patterns and they require far-reaching permissions and capabilities

so if you're building something that shares those characteristics you might really want to read their post before choosing kubernetes for the rest of us though this serves as a high quality deep dive into the trials and tribulations of their engineering team, just remember, quote, you are not choosing Kubernetes versus something else. You are choosing a system because it improves the experience for the teams you support. Convert entire websites to Markdown. There's a lot of tools out there that convert Markdown text to HTML. That's no surprise.

It's literally what John Gruber's original Markdown program was built to do. But there aren't many tools out there that go in the other direction, converting HTML to Markdown. Johannes Kaufmann's HTML to Markdown project does exactly that in the form of a fully extendable Go library, a CLI, a REST API, and a web page where you can copy and paste the inputs and outputs. The best part? It's built to handle entire websites, which makes it super useful for migrating a site, taking documentation offline, and decluttered reading.

Check it out in the chapter data and the newsletter. That is the news for now, but also, scan that companion changelog newsletter for even more news worth your attention, like how Vercel thinks about Next.js, will we care about frameworks in the future, everything I've learned so far about running local LLMs, being in tech means being a lifelong learner, and more, of course, which you can find in this episode's show notes or at changelog.com slash news. Now, this is episode number 120, so that means it's time once again for some Changelog++ shoutouts.

Shoutout to our newest members. We appreciate you for supporting our work with your hard-earned cash. If Change Log++ is new to you, that's our membership program that you can join to ditch the ads, get closer to the metal with bonus content, receive a free sticker pack in the mail, directly support our work, of course, and get shout-outs like the ones you just heard. Check it out at changelog.com slash plus plus. Change Log Plus Plus. It's better.

All right, have a great week. Leave us a five-star review if you like the show and I'll talk to you again real soon