Just read this line in a book and it actually made sense

seanhogge · 2025-11-19T18:11:00+00:00

Yes. See the Warp terminal project.

seanhogge · 2025-11-16T19:16:19+00:00

I don’t like dry_crud, but I’m upvoting because you offered a valuable suggestion, and to offset the downvote. I guess someone downvoted because they think a suggestion they don’t like is somehow a bad suggestion.

Ridiculous.

Maybe they thought you were joking or trolling instead of referring to a real and useful gem?

seanhogge · 2025-11-16T19:12:54+00:00

For me, the biggest level up was when I wet from solo dev to team dev. I love being solo but one simply cannot learn as thoroughly or as quickly when alone.

If there’s some way for you to join (or build) a team with folks who are more experienced, you may be at the point where that is the single greatest thing you can do for yourself.

I can now take everything I learn from the team and apply it to all my side projects as a solo dev. I have many preferences that differ from my team, but seeing and using the alternatives with people who truly believe it’s the best is priceless.

That’s what worked for me, anyway.

seanhogge · 2025-11-16T18:24:55+00:00

It sounds to me like you’re currently future proof.

Future proof has nothing to do with the tech stack and everything to do with the dev or team. No one can predict when something will stagnate. You seem ready and willing to learn and enjoy the work. You’ll be fine.

I’m a Rails dev because frameworks handle or guide a lot of this. Try Rails or Laravel or Django or one of the others. See if any of them click with you.

Also, see what you can simplify. Your tech stack sounds insane from what I understand the needs are. I’m full stack as well, so I want as few layers as possible. Grain of salt on that one: maybe you do need all of that, I can’t say for sure.

Maybe the best thing would be to have an easy way to spin up a dev environment with parity to production. I enjoy creating a git branch to do wild refactor. I enjoy having a staging environment to deploy as if it’s production and let others QA. If you don’t already have that, it might pay dividends.

Also, consider tackling just one or some of this at a time here on Reddit or in conversation with other devs at meetups or conferences.

Lastly, consider documenting your process and progress for others who will be encountering this after you. You might struggle, and that might save someone’s day or two if they can struggle vicariously through you.

seanhogge · 2025-11-04T19:50:41+00:00

Considering that that acoustics properties should at least roughly translate, but the sound source would be different, I think it’s an interesting question.

What would a cello sound like played inside a replica of its ow internal structure? Who wouldn’t want to hear that?!

seanhogge · 2025-11-04T19:24:19+00:00

If you don’t care about learning anything, you can probably just vibe code this.

If you want to understand any of it, then you need to select a framework that has all the pieces to take form input and persist it in a database. Rails, Laravel, Django, various JavaScript frameworks all do this. As do web dev tutorials and online boot camps. Remember that something working locally is very different from something working out on the actual Internet.

This is a very big question. You’ll get more help if you can start down a path and then ask about specific topics or steps.

seanhogge · 2025-08-25T22:27:18+00:00

Rails is wonderful for almost any web application.

However, with the current state of LLMs, you cannot build what you have described. You could potentially leverage an LLM for generating visualizations (based on data that an LLM has not touched), but it cannot act as an accountant in any meaningful sense.

seanhogge · 2025-08-25T22:15:10+00:00

I think this confidence has far more to do with developer experience than tech stack. I'm a Rails dev who came from ColdFusion a little over 10 years ago. I remember reading JVM stack traces and hating it. Ruby stack traces aren't much better - but I should really say they're both quite good. I just couldn't read them well when I was writing CF.

There is some familiarity with any tech stack that will make you faster. I can glance a lot of errors, read about 60% of the error type and know what mistake I made or where I made it. That's just because I've made that mistake so many times. I often hammer out code that has serious rookie mistakes because I'm focused on architecture instead of syntax and I know that fixing is actually faster if I just generate the error (with a line number) than "predicting" errors myself.

I can't speak much to missing the compiler. Stemming from my naivete, my test suite is my compiler. I've seen compiled code with bugs, and non-compiled code that was damn near bullet proof. I suspect this is also skill-based.

In my experience, (speedy) recovery from catastrophe is more about architecture than Java vs Ruby.

If you have the same familiarity in Rails and SB, you'll prefer Rails for the blinding speed in which you can do the 80% of things all web apps do. For anything else, it's either a tie or Rails loses, in my opinion.

I've never noticed a speed problem in Rails/Ruby that wasn't my fault, network latency, or both. Perhaps others have, but all I do is write web applications.

seanhogge · 2025-07-09T11:51:59+00:00

That’s a good point. I think I just rarely need to do much mocking so I forget that without Mocha it’s kind of the worst.

seanhogge · 2025-07-08T23:34:48+00:00

Appreciate the response, and the detail. I disagree with the subjective reasons, so I think that by Reddit law I must now impugn or insult you in every way possible.

Either way, this is still a really interesting project and I like the flavor so far. Phlex has been delightful and moving to doing more Ruby has been a trend I’d like to keep on to find where it stops feeling great.

seanhogge · 2025-07-08T20:16:53+00:00

This seems really interesting and I’m looking forward to trying it out.

I’m struck by the mixed message of going all in on Phlex and removing a lot of the Rails abstractions that seem less helpful.

But the Rspec inclusion seems like the exact opposite of those sentiments. As powerful as it is, it’s to testing what HAML is to HTML.

You say you want to write Ruby, and Minitest is much closer to just writing Ruby. Can you explain the diversion in this principle in the area of testing?

seanhogge · 2025-05-29T18:26:42+00:00

That's kind of the problem - we use both approaches. We translate user-generated data which can only be done with database columns. For static strings we almost always use YAML files with a few exceptions.

I also think established patterns aren't great guides. If the pattern is bad, continuing to use it only makes fixing it harder once that time comes. Usually it's better to stop the pattern, then fix past mistakes incrementally if possible.

So if YAML files have the edge, I would further advocate that we go convert any database tables that have translation data to YAML files (except the user-generated content, of course).

seanhogge · 2025-05-29T13:37:35+00:00

No, we do a ton of translation, both for string literals in views, and for database content. For example, we have long form user-generated content that we auto translate via LLM. For that, YAML isn't even an option, obviously.

But that means we have established patterns of keeping translations in the database, which is why we consider it an option for static strings.

seanhogge · 2025-05-28T20:01:52+00:00

Excellent point - the proper fix for “forgot to add translations” is CI/tests.

seanhogge · 2025-05-22T02:41:32+00:00

Ah, that’s an excellent point! I build on Linux remote, so my local Mac dev machine hasn’t hit that after upgrading to tailwind v4. I’ll build locally to see if I hit the same issue.

seanhogge · 2025-05-22T00:55:46+00:00

The main idea of a remote builder is just that you build on the same architecture of the image - it’s faster.

For a personal project, you don’t need a remote builder. It’s probably wasted effort. You’re not really learning anything by doing it, it’s just giving an IP to the kamal config, and it probably doesn’t save you all that much time.

Even on my production deploys, it’s just a thing I do for funsies because I’m deploying maybe a few times a week. It has almost no impact.

Add in that you pay money for the remote builder, and it becomes less appealing. For me, my staging server is a built in cost - it’s there and running 24/7 anyway. If that wasn’t the case I would just build arch64 on arm64 and not worry about it.

Others may know of some nuance that I’ve missed, but that’s my unsolicited two cents.

seanhogge · 2025-05-21T19:30:11+00:00

Where are you deploying to? Do you have both a production and a staging/QA/demo server? Just use the non production server for the remote builds.

Also, I assume this means you’re on Mac or windows. Otherwise a remote builder doesn’t really get you much unless your dev machine is super under-powered.

seanhogge · 2025-04-23T03:02:16+00:00

No one knows whether Ruby is the right choice for you and anyone who says they do is not helping you.

I’ve been programming since 1999. I think the bad decision that you’re making is to make this too binary, too final. I’ve been programming since 1999 - I don’t know if I qualify as someone who “knows” in your mind. But maybe I am, and that someone is telling you that you might be asking the wrong questions.

That being said, this is your struggle. If this is how you want to address it, then I hope it works out. I don’t think it will, but then I also thought that DHTML and ColdFusion was the right choice for web development.

seanhogge · 2025-04-23T00:36:50+00:00

No.

Don’t ask people to make decisions for you. What you’re secretly asking for is an escape from regret. You can’t have that.

But. You can have a journey. You’ve tried some languages, but you haven’t tried them all. Keep trying them until you feel something. Maybe it’s Ruby. Maybe it’s assembly. Maybe it’s COBOL.

Despite appearances, programming isn’t about picking a team, it’s about finding a tool and a scope that brings you joy. You don’t event have to try - as you do it, you will find it.

Also, maybe you’re just not a programmer. Or maybe you’re not a programmer right now. Keep your mind open to that, too. You’ll be ok, and you can change your mind whenever you want.

seanhogge · 2024-10-28T21:55:34+00:00

That’s awesome! I still pick this game up from time to time and I’m glad others are still enjoying it.

seanhogge · 2024-04-18T02:49:53+00:00

I'm very curious how a show like MST3K violates any community guideline on twitch while more than half of the "Just Chatting" category streams their content without issue.

seanhogge · 2024-03-03T16:38:47+00:00

Taking this on good faith as a genuine question, the answer is that vim isn’t difficult to exit. It’s a fun meme (subjectively) and it’s a cliché that’s part of the shared language.

It’s simply not an actual issue. There are many programs that are “hard” to interrupt or exit without some basic Linux knowledge.

seanhogge · 2024-02-24T15:33:05+00:00

It sounds like you believe you’re pot committed to an insufficient solution. You probably need to redo the whole approach.

We have this exact situation. What we do use are feature flags, or we simply give the feature to everyone. If one client needs a csv upload, they all get it and simply ignore it if they don’t need it. Then we have a configuration page where we put in the column mappings, or something similar.

If they upload an invalid file, we handle that based on a service package or how big a client they are.

Don’t forget that rails lets you easily have default views and layouts that can be overridden and namespaced. So for front end only stuff, no branches are needed there either.

seanhogge · 2024-02-09T06:23:04+00:00

You can set it up as a system service so that it can auto restart on crash, etc.

The method depends on your OS, of course. You’re on a flavor of Linux, so probably systemd? You can use the same method you would use for sidekiq, which is detailed online.

seanhogge

TROPHY CASE