The democratization of spreadsheets (News)

0:28What up nerds? 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. Quote, 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.

1:16Many 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 Slatin outlines a cool feature development method he learned from another engineer. Quote, start working on the feature at the beginning of the day.

1:57If 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. 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.

2:33And 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 prompacks for terminals. However, I have huge admiration for the engineers maintaining the operation of Voyager 1.

3:16Recently, 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.

3:54It'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 competitor. 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.

4:35I'd rather just build apps and make them, 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 at 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 gonna end up needing you're getting a VPC, which will 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 actual application.

5:13You 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, he 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 Flyto.io for sponsoring ChangeLog News.

5:42We'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.

6:24They 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.

7:01That'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 Kaufman'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.

7:37That 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. Shout out 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., Poole H., Sid K., Justin D., and Warren Y.

8:34We 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 shoutouts 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.

9:13Game on.