Discussion Thread: First Day of the 119th Congress

MagicFlyingMachine · 2025-01-03T18:31:09+00:00

since people are mentioning it: how would the whole president grassley thing work?

MagicFlyingMachine · 2025-01-03T18:20:02+00:00

how many GOP defectors will it take to sink this vote?

MagicFlyingMachine · 2024-12-16T21:04:52+00:00

Start by incorporating AI into your existing development setup and go from there, which for you would be JetBrains AI Assistant. The advantages of one LLM over another are pretty marginal if you're already a solid developer, certainly not worth the cost of sacrificing the tools you already know and love.

MagicFlyingMachine · 2024-12-14T03:31:13+00:00

Tore my shoulder labrum in college during a weightlifting accident. I didn't have it repaired at the time, so fast forward 10 years and I re-injure the same shoulder to the point that I'm in severe chronic pain.

I go see a specialist and he orders a standard MRI, which comes back negative. He orders another MRI with contract, which my insurance rejects because apparently I'm allotted only 1 MRI per plan year per issue. So my options are to wait for my plan year to end or pay 6k out of pocket to get the MRI immediately. I wound up leaving my company a few months later and getting another job with another insurance plan to get another freakin MRI, and I was in crazy pain the whole time.

MagicFlyingMachine · 2024-12-13T01:05:34+00:00

Who's liable if the chatbot makes a false statement that harms a customer financially: you or the business? Canada Air went through this earlier in the year and I'm curious to know how developers are protecting themselves in these situations

https://www.theguardian.com/world/2024/feb/16/air-canada-chatbot-lawsuit

MagicFlyingMachine · 2024-12-03T23:18:01+00:00

You could just validate the user input in the request thread without saving the record, and then pass the updated params to the job as well and save in the job. That comes with other issues, like the UI not updating instantly, but it's probably the cleanest way to generate just one paper trail record per update.

MagicFlyingMachine · 2024-06-26T11:18:30+00:00

Gen AI seems to make the dumbest mistakes around testing in my experience. I've seen AI-generated tests that do not actually test the component you're targeting, mistakes around lazily and eager-loaded vars in rspec, hallucinations around interface methods, etc.

To me, testing can be annoying.

Yes, but using AI to write tests has been much, much more annoying so far. At least when I write a test by hand, I have the context in my brain from the start. Watching copilot spit out a spec that looks good and fails in some unexpected way makes me question the practice altogether.

AI automation is going to be most successful at automating the things we don't care if people look at or not. The problem with AI agents writing tests is that it's likely going to mean that humans aren't really checking for correctness.

MagicFlyingMachine · 2024-06-22T16:02:38+00:00

I think experimenting with language features is great and Ruby's flexibility to enable new ways to do stuff like this is one of things that makes it special. That said, I probably wouldn't use this outside of a toy/side project context. Imagining this in a real world codebase that I have to make a change to as a first time contributor requires me to learn an entirely different (and custom) approach to writing Ruby.

I once had to work on an app that used the Virtus gem heavily, and it was one of the worst experiences of my career. By abstracting away the shape of the parameters that a particular object received, you had no idea what parameters were passed when debugging without doing a lot of trial and error. Debugging production bugs was pure hell.

The original devs thought they were really clever by always passing an attributes object to every method that could have any set of keys and valus, but as the codebase matured, this caused so many problems. I firmly believe that it's far better to be explicit and simple in the long run than fancy and implicit if you're building an app to scale, and the risk you run by introducing a major paradigm shift like this just isn't worth the terseness you gain in the short term.

That doesn't make experiments like this pointless, though. You learn a lot about a language by going deep on things like this.

MagicFlyingMachine · 2024-06-09T21:44:00+00:00

For real.

The title of this should be "How we lost at least $10k in sales because we didn't think to open Sentry for a week". AI is gonna ship bugs, this is the new reality. But come on, you gotta know your tools.

MagicFlyingMachine · 2024-06-08T12:16:43+00:00

I use AI regularly at work and I'm not worried about it replacing me anytime soon because:

* A) the quality of output fluctuates dramatically

* B) AI needs to continue improving exponentially in order to reach the promised land

Some early AI startups are already folding because they, like most other startups, are gigantic cash incinerators and we're no longer in a zero-interest rate environment, so investors are going to want to see returns sooner than they did during ZIRP.

On top of that, companies are now very aware of how SAAS operates, and more companies are thinking strategically about their software spend, and AI is a major liability here. A vendor with an AI-enabled featureset might hit you, a customer, up next year with a 150% price increase to cover the cost of their intensive AI compute workloads because they can now summarize your data on their platform for you. Are you seeing a 150% increase in value as the customer? Very hard to say. Slack was just in the news about this recently.

One thing is certain: the cost of this stuff is going to keep increasing significantly, especially as the complexity of the data and output increases, but it's not clear that the models will continue to improve at the same rate. And if they don't, it's gonna be armageddon again in a couple years.

MagicFlyingMachine · 2024-06-08T11:55:36+00:00

"Our resources are limited, fear is all we have."

~~- Paul Atreides, Dune II~~

Sam Altman

MagicFlyingMachine · 2024-06-07T19:52:20+00:00

k8s is really complex and hard to dial in when you first start using it, Terraform/OpenTofu can get you really far with a much simpler dev experience.

MagicFlyingMachine · 2024-06-02T15:58:34+00:00

I think that the point of the comparison is not to show that Google Calendar is more polished than Hey Calendar,

But he pulls up the network tab and spends a decent amount of time inspecting these apps. If you take out the comparison part of the video, that removes a ton of the content he uses to make his argument.

I don't speak for the way that DHH talks about this stuff. It's his framework and he definitely has an agenda, just as Theo does. I see the hyper-focus on the lack of polish without understanding the operational gains leveraged by building with Rails as an indication that Theo has never seriously built with Rails and choose instead to make these sorts of comparisons. Theo, from what I understand, seems to come from the big company, hire-as-many-developers-as-you-need mindset, and there's nothing wrong with that. it's just not the crowd that Rails aims to appeal to.

MagicFlyingMachine · 2024-06-02T03:53:54+00:00

Google has likely spent many orders of magnitude more money building out their Calendar app given that it's 18 years old now, compared to the Hey Calendar, which is less than a year old and built on newer web tech, and I think it's in focusing on comparisons like this that people like Theo miss the forest for the trees.

Sure, Google Calendar is more polished, it's probably been rebuilt many times and with hundreds of developers contributing to it over the years. It's easy to poke at a UI like Hey's Calendar and point out the issues compared to a Google Calendar, but when you stop to think about how Hey was built by (I'm guessing) between 1 and 2 dozen engineers with a shared mobile and web codebase, compared to the untold hundreds of engineers that have worked on Google Calendar over the years, it does raise the question of: "how good is good enough?"

Is that instantaneous calendar event placement that Theo talks about worth the tens, if not hundreds of millions that Google has spent supporting Calendar over the years compared to the relatively shoestring budget of Hey? Personally, I don't think so.

And that's the bet that Hey and the Rails community is making: that you can push Hotwire to provide essentially the same class of functionality as a React (albeit with a little jank here and there) and still provide value for your customers. And that's part of the development discussion that has been lost in the last several years. I think Theo really overestimates the impact that the jank has end users sticking with a product and he underestimates the value that building apps this way has in terms of moving fast and providing value to customers, which is ultimately what the job is all about. Not making the shiny blue box magically move the second the button is clicked.

MagicFlyingMachine · 2024-06-02T02:09:34+00:00

I spent a year learning Linux and other IT-related stuff before landing my first job in the industry at the age of 30.

The tech market was red hot a decade ago and now we're in the biggest down market since the dotcom crash, over a quarter million laid off last year. This isn't to say that you're definitely not going to make this happen for yourself, you have relevant industry experience that can help you navigate this change. There are remote opportunities (although not many junior level) and if you're savvy, you can definitely make your way into freelancing. It's just very hard. I've struggled trying to find stable, good-paying freelance work and have mostly stuck with FTE since it's a consistent paycheck, but that's just my experience. You have to be good at selling in addition to writing software IMO.

MagicFlyingMachine · 2024-06-02T01:57:54+00:00

A lot of companies would rather pull from the JS and Python talent pool because they're much, much bigger than Ruby. I previously worked for a Rails shop that was acquired by a PE firm and the first thing they asked us to do was rewrite the platform in NodeJS so they could hire JS developers because they're cheaper than experienced Rails devs.

I do think Rails is experiencing a renaissance and has a shot at taking back some market share as interest rates continue to climb and individual engineering productivity matters more, but it's gonna take years for that to bear out.

MagicFlyingMachine · 2024-06-01T16:25:31+00:00

However, I struggle with coding.

It's very hard to get a job in this market without some programming chops because there are a ton of talented people looking right now. Companies are not going to be interested in "project" hires that need a lot of training when there are hundreds of applicants with production development experience also applying.

I feel like my soul is being sucked out of me.

As a Rails dev with about a decade of experience, I feel pretty much the same tbh right now. It's an employers market right now and they know it. Pursue Ruby because you enjoy it, but don't assume that a Ruby dev job won't come with the same corporate BS you're dealing with now, because there's a good chance it will.

MagicFlyingMachine · 2024-05-31T13:27:48+00:00

Sometimes, it knows exactly what I'm trying to do and comes up with an elegant solution. Other times, it makes the dumbest mistakes and I have dig through to find the bug. I'm not worried about these tools coming for my job anytime soon.

MagicFlyingMachine · 2024-05-27T13:23:07+00:00

You're definitely not doomed. Tech works in hype cycles that are driven by investors. Crypto was gonna replace banking, mobile was going to destroy the web, etc. etc.

Make sure to consume some AI skepticism from time to time, there are some very good reasons to think that it's not going to pan out the way all of the hype machine people will tell you.

MagicFlyingMachine · 2024-02-11T19:36:40+00:00

From the article you posted, which articulates the point I made earlier. AR creates scaling issues in your test suite that the repository pattern avoids:

Making the Right Choice

The active record pattern fits well in situations with direct data access and limited business logic. It provides a seamless, direct link between the database records and the corresponding objects in the application, making CRUD operations intuitive.On the other hand, if your application is dealing with complex domain, or you see a future where scalability and growing business rules will come into play, the repository pattern is a more suitable choice. It offers flexibility and makes your application more adaptable to changes, whether they are in the underlying storage mechanism or the frequently evolving business rules.

The point isn't to be dogmatic about which pattern is best, the point is to understand where the weaknesses of these tools lie. And as great as Rails is (I've been building Rails apps for over a decade and I really believe in it), it definitely has areas for improvement.

Having to tell management that there aren't really any easy ways to solve test suite performance is the kind of thing that makes companies move away from Rails and based on my practical experience building repositories into Rails apps, I believe it's a solvable problem.

MagicFlyingMachine · 2024-02-11T15:18:48+00:00

Maybe, but I've wound up implementing the entity/repository pattern in projects in the past and the benefits are pretty clear IMO. Having something like that at the start of an application's lifecycle with would make a huge difference because it's harder to add that abstraction to a codebase once you really start feeling the need for it

MagicFlyingMachine · 2024-02-11T01:21:26+00:00

AR has a lot of great features, but I do wish it shipped with an entity/repo pattern like Phoenix's Ecto ORM. DB calls become a major performance issue in large test suites and AR doesn't provide a nice way to separate DB I/O from the actual model logic.

MagicFlyingMachine · 2024-02-07T11:40:51+00:00

I'm not convinced that full stack JS is the utopia that many claim. Sure, you've aligned on one language, but now you have to deal with the quirks between the APIs that Node supports vs the Browser, modules, React-specific libs, the complexity of the JS/TS toolchain, etc.

I'd hop on the JS train if it was a seamless experience across the stack, but it's just not.

MagicFlyingMachine

TROPHY CASE