More from Good Enough
As we’re building Jelly, we have found ourselves looking at lots of raw emails. In particular, we’ve spent a lot of time with email headers. If you’ve ever had cause to do the same, you know it can lead to lots of scanning and squinting. There’s got to be a better way! And here it is: Prettier Email Headers. With the help of AI, I threw together this tool that accepts a raw email paste. Then it shows those headers and header values in a format that is easier on the eyes. I also asked AI to do some research into the definition of each header and include citations. As always, I practiced the “don’t trust and verify” method when working with AI. If you ever find yourself staring at email headers, I think you should give Prettier Email Headers a try! If you liked this post, maybe you’ll like Jelly, our new email collaboration app for small teams!
The London Ruby User Group is one of the longest-running technology user groups in the world, having held a monthly meeting almost every single month since late 2006. It’s no small feat to have kept a local community running for so long, especially since everyone involved is a volunteer. Jelly is the foundational tool that helps LRUG’s organisers keep things running smoothly. The beating heart of LRUG is the mailing list, and the team regularly puts out a call for members to give presentations at the monthly LRUG meet-up. Those submissions are sent to an email address which forwards directly into Jelly. All of the volunteer organisational team can see each talk proposal conversation, and can respond directly or privately discuss the talk right in that thread. And, most importantly, anyone can quickly get up to speed with where a talk proposal is because the whole history of the conversation is right there. This is particularly important for a volunteer-led organisation like LRUG, because at any time one of the organisation team might be on vacation or busy with life and work; but because any other member can jump in and seamlessly pick up a conversation, LRUG never stumbles. Jelly helps the LRUG team make sure that no conversation is accidentally ignored, because it’s always clear who’s got what. As well as talk proposals, LRUG uses Jelly to coordinate with venues, to field questions from community members and attendees, and to coordinate with other user groups. Jelly acts as a shared inbox for all of LRUG’s communication, with specific email addresses for sponsors, job posting to the mailing list, and general organisational matters. Jelly handles everything. LRUG’s longest-running organiser, Murray Steele, says: We looked at other more "complete" support tools like ZenDesk and HelpScout, but they are way more expensive (you have to pay per user) and more complex than we need. Jelly presents email just like email, and there's a flat cost which means we don't get penalised whenever someone new joins our team. If you liked this post, maybe you’ll like Jelly, our new email collaboration app for small teams!
For your small business to survive, you need customers. Not just to buy once. You need them to come back, tell their friends, and trust you over time. And yet, too many small businesses make it weirdly hard to talk to them. Well, duh, right? I agree, yet I see small businesses fumbling this over and over. All the attention when discussing business is about giant corporations. Whether they’re selling servers or vehicles or every product under the sun, millions of dollars pass through their doors every day. Yet it is folly to apply the methodologies of giant companies to our small businesses. It sounds obvious, but I constantly see small businesses making it hard for customers to get in touch. If a customer does get through the “contact us” gauntlet, that small business often uses needlessly complicated enterprise software to talk with customers. Small businesses don’t get the spotlight, but they are the engine of the economy. To wit, in the United States: 99.9% of businesses are small Nearly half the private workforce is employed by small businesses They generate over 43% of the country’s GDP And beyond the stats, small businesses are who we turn to every day: your corner coffee shop, your local cleaner, your neighborhood software team. And don’t forget that every big business started small. Small businesses are the genesis of innovation. We all need small businesses to succeed. Most small teams aren’t trying to become giant corporations. They want to make a living doing work for a fair return. Many of them work hard in hopes of moving the needle from a fair return to a comfortable life, and maybe even some riches down the road. Yet it’s amazing how often it’s forgotten: you need customers to succeed. Success in small business starts with human conversation. While talking effectively with your customers does not guarantee success, it is certainly a requirement. Here’s what that looks like: a customer has a question and your team responds kindly, clearly, and quickly. Or sometimes your team wants to reach out with a question for a customer. It’s a simple, human interaction that cannot be done effectively by automation or AI. It’s the air your small business is breathing. Starve that air, and everything else suffers. Your product or service is almost secondary to building a healthy relationship with each of your customers. Big business doesn’t operate this way. We shouldn’t expect it to show us how to build real relationships. We’re doing our best here at Good Enough to build healthy, happy customer relationships. Whenever you write to us about any of our products, someone on the team is going to reply to offer help or an explanation or an alternative. Fact is, if you write to us about anything, we’re going to reply to offer help or an explanation or an alternative. As an online business, we’re talking with customers primarily over email. For us, Jelly makes those conversations easy to have—human, not hectic. Actual customer support is remarkable. Actual, healthy human relationships are important. Actual customer conversations are a key to small business success. Choose your actions and tools accordingly. If you liked this post, maybe you’ll like Jelly, our new email collaboration app for small teams!
We put a lot of ourselves into our work, and it occurs to us that you, dear reader, might not know much about us. So we’re descending deeper, ever deeper, into the Q&A column introduce ourselves, one-at-a-time. Desperate to keep things interesting, James tried to spice up the interview format... https://lazyatom.com https://interblah.net https://goodenough.us https://goodenough.us/blog Once you've done that, I want you to conduct a question-by-question interview with me, to form the basis of a "James is Good Enough" post. Ask me one question at a time, and then use my answer to evolve the interview. We should aim for about 8 questions in total. Don't be boring. Use the existing posts as inspiration, but I want the post about me to be unique. I'd be cool if it went in a strange tangent. Q1: If your inner monologue were a programming language, what would it be, and why? E_WHAT_THE_HELL_ARE_YOU_TALKING_ABOUT_THIS_IS_NONSENSE Fantastic. You’ve got a reflective meta-loop keeping everything in check. Let’s follow that thought deeper: Q2: What’s one recurring loop or thought-process that’s currently being tagged by your inner supervisor as E_WHAT_THE_HELL_ARE_YOU_TALKING_ABOUT_THIS_IS_NONSENSE? Fair enough—let’s rewind a bit and start from a more grounded place. Q3: OK James, tell me a bit about who you are, what you’re doing these days, and how you fit into the Good Enough story? How do I fit into the Good Enough story? My friend Patrick, who I met when we both lived in Austin, TX, had always been trying to persuade me to work with him. A few jobs later, he succeeded! I was the 6th person to join the team, in mid 2023, and I love being a part of this team. It's long been my dream to build great products with love, and at Good Enough we are lucky to have that opportunity. That’s perfect; let’s build on that a bit. Q4: You mentioned it’s long been your dream to build great products with love. What does “building with love” mean for you personally—especially after two decades of programming? Great! Let’s push into this tension a bit more: Q5: Loving your users is admirable, but what’s a memorable example of when loving users conflicted with practical realities—like deadlines, budgets, or even your team’s sanity? How did you navigate that? Alright, let’s throw practicalities aside and pivot into something more colorful. Q5 (take two): If Good Enough were secretly a front for a mysterious cult, what strange rituals or beliefs would you and your teammates secretly adhere to, and why would you be tempted to join in? Q6: If Tony the Pony, Zalgo, and Y2K emerged through your DVD player at midnight and demanded you justify your existence in precisely one feature you’ve built or contributed to, which one would you pick, and how would you convince them to spare humanity based on it? Jelly -- it's an idea I've wanted to develop properly for a very long time. That, and an unreleased application I made called Chicken. Excellent—Jelly and Chicken it is. Clearly, we’ve entered culinary territory now. Q7: If Jelly and Chicken were literally dishes on a menu at the Good Enough café (the front for the aforementioned cult, obviously), how would you describe their flavors and textures to customers who wander in, unsuspecting of their metaphysical implications? Q7 (revised): What is it about Jelly, as an idea, that resonated with you deeply enough that it stuck around in your mind until you could finally build it at Good Enough? It should be a simple thing! But all these big software products make it complicated, smother it in bells and whistles -- and now AI, no offence GPT. There should be a "no-brainer" answer for a group that wants to use email together. I think Jelly can be that answer. Let’s wrap this up neatly: Final Question (Q8): You’ve spent your career advocating for simplicity in software. Do you think there’s a deeper personal philosophy beneath that, something you’re trying to express beyond just “good software design”? At this point ChatGPT tried to summarise the whole thing into a coherent post and, to be honest, it was garbage. So, instead, you get the raw interview. Judge me harshly, for I deserve it. If you liked this post, maybe you’ll like Jelly, our new email collaboration app for small teams!
More in technology
In the worlds of programming and robotics, turtles are entities — either virtual or physical robots— that follow commands to move around a 2D plane. Those are usually very simple commands, such as “move forward 10 units” or “rotate 90 degrees clockwise,” and they help people learn some programming fundamentals (like Logo in the ’80s!) […] The post Turtle bots, Gestalt principles, and emergent art appeared first on Arduino Blog.
It was probably going to happen sooner or later, but Microsoft has officially released the source code for 6502 BASIC. The specific revision is very Commodore-centric: it's the 1977 "8K" BASIC variant "1.1," which Commodore users know better as BASIC V2.0, the same BASIC used in the early PET and with later spot changes from Commodore (including removing Bill Gates' famous Easter egg) in the VIC-20 and Commodore 64. I put "8K" in quotes because the 40-bit Microsoft Binary Format version, which is most familiar as the native floating point format for most 8-bit BASICs derived from Microsoft's and all Commodore BASICs from the PET on up, actually starts at 9K in size. In the C64, because there is RAM and I/O between the BASIC ROM and the Kernal ROM, there is an extra JMP at the end of the BASIC ROM to continue to the routine in the lowest portions of the Kernal ROM. The jump doesn't exist in the VIC-20 where the ROM is contiguous and as a result everything past that point is shifted by three bytes on the C64, the length of the instruction. This is, of course, the same BASIC that Gates wanted a percentage of but Jack Tramiel famously refused to budge on the $25,000 one-time fee, claiming "I'm already married." Gates yielded to Tramiel, as most people did then, but I suspect the slight was never forgotten. Not until the 128 did Microsoft officially appear in the credits for Commodore BASIC, and then likely only as a way to push its bona fides as a low-end business computer. Microsoft's source release also includes changes from Commodore's own John Feagans, who rewrote the garbage collection routine, and was the original developer of the Commodore Kernal and later Magic Desk. The source code is all in one big file (typical for the time) and supports six machine models, the first most likely a vapourware 6502 system never finished by Canadian company Semi-Tech Microelectronics (STM) better known for the CP/M-based Pied Piper, then the Apple II, the Commodore (in this case PET 2001), the Ohio Scientific (OSI) Challenger, the Commodore/MOS KIM-1, and most intriguingly a PDP-10-based simulator written by Paul Allen. The source code, in fact, was cross-assembled on a PDP-10 using MACRO-10, and when assembled for the PDP-10 emulator it actually emits a PDP-10 executable that traps on every instruction into the simulator linked with it — an interesting way of effectively accomplishing threaded code. A similar setup was used for their 8080 emulator. Unfortunately, I don't believe Allen's code has been released anywhere, though I'd love to be proven wrong if people know otherwise. Note that they presently don't even mention the STM port in the Github README, possibly because no one was sure what it did. While MACRO-10 source for 6502 BASIC has circulated before and been analysed in detail, most notably by Michael Steil, this is nevertheless the first official release where it is truly open-source under the MIT license and Microsoft should be commended for doing so. This also makes it much easier to pull a BASIC up for your own 6502 homebrew system — there's nothing like the original.