RangerScience

For that, I’d just use Rails, and the connect AI/ML tools over an api or (riskier) direct to the DB.

The stuff I looked at ages ago was for literally embedding Python code in Ruby code. I never used any of it either, so I don’t have any recommendations.

Edit: Actually, rather than have Python connect to the Rails DB, have Rails also connect to the Python DB (note that this can be on the same db server, etc). Rails can then handle all the “I’m a product” stuff (user accounts, etc) and then read the Python data for the rest. Would that work?

Do you (or a GP) know how I can donate already-extracted stem cells for this?

Pro tip 1: Potluck! Cooking and organizing can be a lot of work.

Pro tip 1a: Hot pot! You supply the pot and broth; guests bring the rest.

Pro tip 2: The first one will be waaay harder; then it’ll get easier, as you get a track record and you don’t need to recruit (or “train”) guests; they’re already in and already trained :)

Pro tip 3: They get easier, fast, as you both 1) get practice and 2) learn what doesn’t matter

Pro tip 3: The first people to show up will ask to help; plan something for them to do (I do a make-a-pizza party; I have them grate the mozzarella)

Six can be a bit of magic number for a table in a larger crowd, because people tend to be in groups of 2 or 4, so a table for six (apparently) means you’re inviting/ causing groups to mix.

Ah! Then we're in agreement :)

And yes, Rails makes it easy to make "unthinking" mistakes - like, you should prep your ActiveRecord objects in the controller so they've got all their data for the view, but, because you don't have to...

Blessing and a curse. You can turn it on and pretty much immediately get started, but that doesn't mean you know what you're doing...

> your domain objects and your persistence

Hmm. Thinking over my career...

Maybe I don't know what you mean by "domain objects", "separation", and "persistence", but when I think over the stuff I've worked on in my career, and the problems I've seen in codebases...

Yeah, I think I'm with them on this - your domain objects and your persistence should pretty much be the same thing. There's gonna be a few exceptions (and, ofc, you can do a shit job building the models), but I expect those to be short-lived and small.

Otherwise, you shouldn't have domain _objects_ doing all that, you should have functions operating on data, and the data is pretty much always going to be either (1) some incoming hash or (2) some database record; then you group the functions into handy modules for humans. And then they're not domain _objects_.

Do you have a good example of a "domain object" that you think really _should_ be heavily separated from persistence?

PS - The one time that comes to mind that might fit, the data I wanted to persist was essentially logging data on the operation that was performed on other data.

PPS - N+1 queries are kinda trivial to resolve in most cases in Rails? There's core ORM functionality for it.

PPPS - Yeah, don't put your confirmation mail logic in the model callback, that's a bad plan.

Fake edit: Like, you either have data you want to persist, or you have data you're transforming. If you're transforming it, it's temporary, and either I don't understand what a "domain object" is, or I think you'd make a mistake to make your temporary data into a domain object.

FYI, there’s a few projects out there for interoperability between Ruby and Python - stuff like putting one language in another.

Also, Jupyter and Zeppelin notebooks allow for interoperability, although I don’t know how.

(Oh, lastly, if there’s a JVM implementation of Python you could probably use alongside JRuby)

The Rails apps I’ve worked with where there was an ORM mess (which yeah… is all of them) it’s extremely clear that the mess is the normal “too fast” software development mess. Sure, it’s worse because it’s the ORM (and/or sharp knives), but it’s also always been the case that I can clean it up with better use of Actuve Record.

Also, I’ve worked with some pretty gnarly pure-SQL systems that had essentially the same kinds of problems.

It’s all just variations on “saving hours of planning with months of work” kind of things.

Yes. You learn unique, transferable things from every language and framework; usually, techniques and perspectives, but also confidence and theory.

I’d also contest your statement that learning Python and Django have a “much higher ROI” - but, I don’t actually want to get into it.

I've seen both, although rarely for either.

The worse trash fires were the homebrewed systems, but maybe that's because I could dig in and see how bad they were.

But I'd actually agree with you - as bad as those were, I'd rather them than a shitty 3rd party something. At least I can theoretically do something about the in-house one, and, all the ones I've seen were smaller in scope than any SaaS product.

Large commits are (IMO) a symptom - lack of a plan, a plan that doesn’t work out, etc. Which is fine! You have to figure it all out somewhere.

One thing you can do to address them is to stash the large commit to the side, then piece by piece pull it into a new branch as a series of smaller commits. This also give a good opportunity to refactor before delivery, now that you know what the code is going to do and how.

Came across the idea of "probe" (awhile ago) as a name for this.

> thought they could cut corners to speed up iteration

Anecdotally, I find you can get about 3 days of speed from cutting corners - after that, as you say, you get slowed down more than you got sped up. First day, you get massive speed from going haphazard; second day, you're running out of corners to cut, and on the third day you start running into problems you created for yourself on the first day.

IME, “young” correlates with health b/c less time has been spent making it a mess… but, what’s really going on is the company’s culture and how it relates to quality work, aka, whether engineers are given the time to perform deep maintenance as the iteration concludes.

Maybe… to put it another way, it’s that time spent on quality isn’t time spent on discovery, but it’s only time spent on quality that gets you quality. So while a company is heavily focused on discovery - iteration, p/m fit, engineers figuring it out, etc - it’s not making a good codebase, and if they never carve out time to focus on quality, that won’t change.

That’s not entirely true - IMO, there’s a synergistic, not exclusionary relationship between the two - but it gets the idea across, I think.

Eh, it’s been kinda nice to just hit tab-to-complete on things like formulaic (but comprehensive) test suites, etc.

I never wanted the LLM to take over the (fun) part - thinking through the hard/unusual parts of the problem - but you’re also not wrong that they’re needed the least for the boilerplate. It’s still nice :)

There’s a thousand things waiting to be written once… because they’re each coping with something else that was written once.

Write it twice, then you can use it a dozen ways, and now you’ve got a hundred things to write instead of a thousand.

AFAICT, three of the prior four elections also went to “change” (Obama, Obama, trump).

While it would not be conductive to the discussion for me express my judgment of some of that change; it does feel like the most active and vocal people (who in turn gain followers) are the ones talking about not maintaining the status quo.

To be clear: that’s additional votes this election versus last, and so is counting absolute turnout, rather than percentage-of-the-population?

It’s good to know the absolute numbers, but I feel like they’re less significant than the relative numbers (what % of the population voted)

Snark aside… only sort of?

If I remember right about how these ecosystems work, you need the controlled burns so that the underbrush goes up but the trees don’t. Without the controlled burns, the trees also go up, and then “next year” all you have is the new underbrush… and the problem repeats.

AA is really just some wrapper and glue around some other tools… which aren’t super well documented either, but it definitely does mean that a) you can do weird/custom stuff, and that it’s a PITA to figure out how.

There’s actually a couple really good ways to embed React in a Rails template. Let’s you have something really interactive when you need it.

Rails, ironically, doesn’t keep you in the rails. I’ve seen a couple of the things you’re talking about, and it’s really just mediocre devs in bad (but common) situations.

If someone gives you a paint-by my-numbers page, and you just scrawl all over it… is that the “fault” of the page?

Excellent point… and one I should know. I spent about 6mo as a data eng (only one at the startup) and long after, found out no one ever had a clue what I was talking about in standup. (To be fair, I was self-teaching, and no-one else knew anything so)

I have felt exactly this on regular full stack teams many, many times, so it’s also not just limited to data teams.

IMO a major factor here is that software engineering is both opaque and esoteric - at least with physical engineering, there’s something people can look at and think they understand.

Yep. I introduced Rubocop at a past gig… only to watch my colleague write worse code playing whackamole trying to adhere to the rules.

I kept telling him that the whackamole is a sign to rework things at a higher level - that the Rubocop rule catches symptoms, and that he needed to address the cause, but…

PS - to be clear, I love Rubocop and swear by it. In that circumstance, I needed to introduce it differently, is all.

I’m a lot younger but

I think maybe it’s not about not letting objects become totems, but about being deliberate and intentional about which, and why.

I have a lot of friends that keep “altars”; collection of objects sacred to them (and objects that are prayers). I think they’re probably right to do so.

Huh. I mean - how does that even work? How can the company “force” you to stay, aside from emotional/cultural pressure?

Like - If you hand in a resignation, they tear it up, and then you just no-show… what happens?

I disagree in a very specific and limited way: good tests show you how to use the code, which can be as simple as just “here’s some typical parameters for this function.”

In more complex situations, good tests also show you the environmental set up - for example, all the various odd database records the code needs or expects.

It’s not everything you’d want out of a doc, but it’s a chunk of it.

Colleagues: If the code works, it’s good!

Me: Hmmm.

Managers, a week later: We’re starting everyone on a 50% on-call rotation because there’s so many bugs that the business is on fire.

Anyway, now I get upset and ask them to define “works”, which… they haven’t been able to do yet.

Heh :) Enforcement would potentially look a lot like unemployment, but in reverse: you have to show you’ve been interviewing people, just like unemployment requires you to show you’ve been looking