The Changelog: Software Development, Open Source
The democratization of spreadsheets (News)
Mon, 11 Nov 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. For over 40 years, spreadsheets have been integral to countless applications.
Despite numerous proprietary and open-source options, finding a universally accessible, reliable, and high-quality engine remains a challenge. Many existing solutions are expensive, require 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 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.
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 the 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 its competitors, Azure and GCP are just AWS again. Honestly, I think 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 gotta 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 probably either a Fargate or their Kubernetes setup to run the 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 2000. 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. 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 webpage 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, Brian F., Benjamin M., Carrie K., Aiden M., Johannes R., Carl M.,
Mark A, Shemislav B, Simon S, Paul S, Jesse T, Pool H, Sid K, Justin D, and Warren Y. We appreciate you for supporting our work with your hard-earned cash.
If ChangeLog++ 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. ChangeLog++. 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.