Published

Ultimately though a business needs a product. Textual has always been a solution in search of a problem. And while there are plenty of problems to which Textual is a fantastic solution, we weren’t able to find a shared problem or pain-point to build a viable business around.

I can totally see this. Finding a marketable business idea is not easy, working in the developer space where everyone wants to do it themselves is no better. Textual specifically I could see, I really wanted to build things on it as it came out, I had ideas, it was hard to use at the time and changing, so I took a break, got busy with far too many other things, and really I ’m good with rich most of the time.

I daily use k9s, its absolutely amazing at what it does and appreciate that I could build something like it in python, its just hard to justify the time investment for the things I tend to work on.

Which is why Textualize, the company, will be wrapping up in the next few weeks.

...

So it’s back to plan A: taking a year off. I plan on using this time to focus on my health–something I haven’t prioritized while working as a CEO / Founder of a startup.

Wish you the best Will, you have given us textual and rich, and from what I can tell left it in some great hands.

All I can say for certain is that I would like to write more. Writing scratches many of the same itches as software development, and it is a skill I’d like to nurture.

Go get em Will, write to your hearts desire, and resist the urge to make an SSG company this time.

Now “too much magic” is not the same thing as “bad magic”, although they are often conflated. Bad magic is when the implementation details leak out from the level below. This can manifest itself as cryptic errors that reference the magic’s implementation.

Dang Strong takes against markdown here with a strong push for bespoke content models/structures. This idea is completely foreign and wild to me. I get it that markdown has its issues with flavors, add ons and what not, but overall its mostly transportable, its a skill that works most content sites and writing tools. I am so far on the other side that I seek out tools with markdown as an option and lean away from wsiwyg tools with specialized data formats on the backend.

I’ll end with, I’m also a dev that creates very simplified content and maybe seeing the backend of a site with lots of custom fields would be very eye opening for me.

Last year I attempted to do some newsletter-style link aggregation… that good intention imploded spectacularly. But I switched to Obsidian this month and now I have a better system for aggregating links (post on that coming later). Inside this issue you’ll find some games, some homelab server hardware, some AI discourse™, some musical instruments, and more.

This hits so close to home, I even went through the effort of making a weeknotes script, one weeknote post. I also was inspired by obsidian but it didn’t work out for me, so my script uses data from markata.

Do you remember regression models from college: given some data, you find a best fit line that allows you to predict Y given X. At the end of the day, ChatGPT, and LLMs in general, are the same thing as the regression model – it’s just that ChatGPT is the largest and fanciest model we currently have to model language and information.

I really am coming to the idea of calling it a “word calculator”, this seems to be the most succinct description of llms that the lay person can comprehend and relate to.

ChatGPT does not hallucinate or become unhinged

I think Steve goes much deeper on this in his intervew on fafo.fm. They describe it more as a pleaser or “yes man” essentially all the companies that are building these models want to give the “best” answer, better than their competitors. With this comes the risk of it being completely wrong, they are designed to always give an answer.

...

I’ll triple down on the link-blog chain here, see this one going around all over this week and finally had time to read through when it hit my rss reader via Chris.

It should come as no surprise that nearly every vibe-coded app on the Internet struggles with security issues; look no further than the vibe-coded recipe app that leaks its OpenAI keys. Every time one generates code by prompt, they create a new stillborn program; vibe coding is the art of stitching together their corpses into Frankenstein’s monster.

Damn, that is a strong statement, stitching together the corpses, strong statement here. The OpenAI key thing feels kind of obvious to me, every set of docs, blogs and examples on the internet need to be runnable for people to learn and try out new tech easy, putting secrets in the wrong place is easy, putting them somewhere that you can decode them without sharing them is hard team specific, app specific, and so nuanced to your architecture that its rarely...

...

Under 2000 everything is happy, green field. Any decision you have made is relatively easy to back out of (barring you making a library with downstream users), but as you go, regret kicks in. Regret we didn’t make that pydantic 2 upgrade earlier, as new features become more apealing. Regret that we chose sqlite for simplicity, speed, agility, and now we might need robust and distributed. Regret that you chose a front end framework, or to have a front end at all to a backend problem. Regret that you put 6 layers of abstraction on your db early on and now that you understand the problem you want different abstractions, but all of your endpoints deeply depend on the current one.

Vibe coding will not save you, it will only make these wrong decisions for you without the context that you have. You will hate it’s decisions more because you had no input into some of them.

“Gradually roll out your releases to a small group of people”

~ roughly what prime said (I’m listening live)

This really hit home with me, tests can be so good at making sure that we dont repeat bugs and that laser focused things work, tests are generally small and focused, but this does not replace some sort of integration testing. These days very few things are written as a monolith, and hence there are a lot of interactions that really need to play well together accross various systems.

They call out Crowdstrike here, which took down the world blue screening critical windows systems everywhere in 2024. It was revealed that a small changed was rushed through and skipped critical rollout paths since it seemed like a small change. Crowdstrike also runs at a super low kernel level of access and a small memory bug can kill the system.

I’m trying to level up my sre game. I’m trying to set up grafana dashboards for everything and it is such a wide surface area. It’s never just one thing you have to have 3 or more things hooked together in order for the data to flow.

I’m really getting not invented here vibes, and thoughts that I can just build this myself. Not grafana and it’s scalability necessarily, but small components of observability.

This is a really great guide to setting up kubernetes monitoring with helm, it uses loki as a log datasource and alloy as a collector of kubernetes logs, events, and nodes. The charts are setup really well to start collecting logs from all your kubernetes pods.

Really helpful article to getting tempo datasource setup in grafana, this enables you to see span and trace data within grafana. This data helps debug and work through issues that you might come into with performance and need to see the timing of requests along with logs.

I’m trying to learn proper logs, monitoring, otel, and grafana. Today I imported a bunch of pre-made k8s dashboards and made a few of my own for specific apps, and it made me want to know how I can turn my own custom dashboards into infrastructure as code. Turns out grafana makes it pretty easy to do this, if you have the grafana dashboard sidecar running. It will pick up any ConfigMap with the grafana_dashboard label and import it.

Go to Dashboards -> Pick a Dashboard -> Export -> JSON.

Just starred postiz-app by gitroomhq. It’s an exciting project with a lot to offer.

📨 The ultimate social media scheduling tool, with a bunch of AI 🤖

I recently discovered wezterm by wezterm, and it’s truly impressive.

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

Steve is such a great listen, the neurospicy 🌶️ rambles this episode goes on is so relatable. I feel like I really missed out on some great takes on intellij vs neovim, but got some really great knowledge about vector db’s, embedding, text compression, similarities to vector algegra like infinite craft.

Just popped open infinitecraft and I’ve definitely played this with my kids before, super fun, just could not remember the name of this one. I do remember an android one as well that is alchemist or something like that, which we have also played a lot.

This episode really got me thinking about the difference between HA and DR and my approach to each one. They talk about it from the perspective of a cach cow kind of app rather than a homelab or internal tooling, but think of HA as 9’s how many 9s are we willing to pay for, tink of DR as dollars how many dollars will we loose during the period of recovery. So much more in the episode, a lot of talk around cloud vendors and what they give you vs a purpose build platform with HA and DR in mind.

Just starred kubero by kubero-dev. It’s an exciting project with a lot to offer.

A free and self-hosted PaaS alternative to Heroku / Netlify / Coolify / Vercel / Dokku / Portainer running on Kubernetes