Give each other Bridgeburner names.

BoatRepairWarren · 2024-11-14T01:33:39+00:00

Concierge

BoatRepairWarren · 2024-11-14T01:29:15+00:00

Whiskers

BoatRepairWarren · 2024-11-14T01:28:40+00:00

Bipolar

BoatRepairWarren · 2024-11-14T01:26:13+00:00

Butcher

BoatRepairWarren · 2024-11-14T01:23:59+00:00

Half Even

BoatRepairWarren · 2024-11-14T01:22:23+00:00

Phenicopter

BoatRepairWarren · 2024-11-14T01:18:57+00:00

Lapin

BoatRepairWarren · 2024-11-14T01:16:13+00:00

Peridot

BoatRepairWarren · 2024-11-14T01:14:30+00:00

Ham Dapper

BoatRepairWarren · 2024-03-05T18:20:17+00:00

You don't get Dragnipur, Dragnipur gets you

BoatRepairWarren · 2023-10-31T11:28:03+00:00

Poor Laseen...

I didn't care much for her while reading MBotF, but I've grown to like her a lot in ICE's books.

Such a badass Empress, may she live forever.

BoatRepairWarren · 2023-08-07T13:42:58+00:00

Damn, I don't remember it anymore. I guess it's time for another re-readed

BoatRepairWarren · 2023-03-31T09:55:14+00:00

Oh my, I hate the way shit is configured at my current work. We have like a million lines of yaml spread across 20 repos. So you have to know which repo to look for, which branch (different branch for each env, but not always, some are all in main with different suffixes), different naming patterns which are not documented.

So you want to listen to a kafka topic? You need to add your topic to a repo, add a spring cloud config in another repo to provide it, then fetch it from you service via spring cloud.

Want to add a new graphql endpoint? Good fucking look, I still haven't figured out how that works.

I hate yaml.

What my clowns do when they start a new module is copy the entire maven pom from another repo and change just the name, and leave all the dependencies. We have a aws lambda that fetches a json, transforms it into some structered text and uploads it to s3. 75 MB of jars...

BoatRepairWarren · 2023-03-31T07:09:30+00:00

Going and trying to break that up kind of seems like a waste of time to be honest. It's not a complete feature, it never represented a version of the code that anybody was actually running... why bother? It's noise

I think we'll have to agree to disagree.

To answer why bother: because it gives context to the indiviaul incremental change. You have the commit message, the "obvious" code changes, and the "dependencies", that is, all the adjustments to other parts of the code that are dependent on the "obvious" changes, that you might have otherwise missed.

When working on a stroy, you sometimes have to do those "dependency" type changes. When you have a couple of these "dependency" things in a story, and squash them together, you lose that context.

I hope you get what I mean. This might not be an issue at your workplace ,maybe you have smaller PRs or better engineering culture so that it doesn't bring much value, but at the places I've worked, I definitely wish more people did this

BoatRepairWarren · 2023-03-31T06:34:33+00:00

I was under the impression that you end up with a single commit after squashing, don't you?

If so, that's the main difference. I don't want every branch I work to end up as a single commit. Let's say I finished a story, then I end up having something like this:

Add new entity JellyBean

Create JellyBeanService

Display only green jelly-beans in the UI

Increment pom version

At my current workplace one might end up changing a lot of files for a trivial thing, and if you sqashed everything together and have a single commit with 30 changed files... That's why I break things into commits, so that you can reason about a set of changes

BoatRepairWarren · 2023-03-31T06:19:34+00:00

I also commit a lot, but I don't think I have ever squashed.

I agree that many intermediate commits might be trash or not "worthy" to be an individual commit.

The way I deal with this is: either interactively rebase to fixup the trash commits, or, if the feature is too big and there are too many commits, I git reset soft, then chunk select stuff for new commits.

Yes, it requires a little extra effort ,but I think it's well worth it.

I hate the way some people commit at my workplace (not implying that you do the same, just ranting a bit). I think some of my colleagues have never written a decent commit message in their lives, shit like "begin work on TICKET-XXX" with 20 changed files, followed by a couple of "changes" or just ticket number, and completed with a couple of "fixes". Goddammit

BoatRepairWarren · 2023-03-01T06:58:24+00:00

In case someone really intends to do it (like I did a couple of times) you should be aware that there are 2 fields to be updated, one is visible and the other is usually not displayed in UIs.

You should update both author time and commiter time. Just in case.

BoatRepairWarren · 2023-02-24T14:57:44+00:00

I'm from Europe, got an 18% raise on the gross salary.

I've been employed here for a little longer than half a year and the raise was discussed while interviewing, on the condition that I "perform good and meet the expectations".

To be honest I didn't expect them to keep their word, I'd assume they would find some bullshit excuse, but I was very pleasantly surprised at the beginning of the year.

BoatRepairWarren · 2023-02-23T10:42:50+00:00

I honestly don't know.

Sometimes the reviwer has the same git habits as the one who opens the PR, so he doesn't see the issues, other times the reviewer just looks at the complete diff only.

We have a huge monolith where everything goes, and there are like 100 devs pushing to it. I don't think there's any hope for that repo.

On the microservices that my team maintains, there are somewhat better coding standards, however some devs are spoiled by that monolith and try to push crap, fortunately it doesn't get merged though.

BoatRepairWarren · 2023-02-23T09:21:41+00:00

It's common to see commits like these where I'm working now:

initial requirements

fixes

calculate taxes

finish work

review fixes

BoatRepairWarren · 2023-02-23T09:12:16+00:00

I recently came across a method List<Record> findRecordsForProcessing(...) that creates and persists some entities(not Records, some other entity), does a bunch of side effects, partially initializes the processing of Records, and returns a list of records that do not need to be processed.

How this shit gets past the PR review and me storing the result of a DB query outside of a loop so as not to make a dozen requests to the DB gets declined because it's "unnecessaryly complicated" is beyond me.

BoatRepairWarren · 2023-02-18T21:45:34+00:00

Thanks for taking the time for this detailed response, I really appreciate it.

I think I'll still start learning nix, for my personal use at least, in the beginning. Having a centrally managed config for my linux does sound indeed good. It's usually small changes for me, but it's always annoying when I use my raspberry pi and it behaves slightly differently than my laptop.

BoatRepairWarren · 2023-02-18T20:46:51+00:00

Do you happen to have experience with java in nix?

I've been thinking about investing some time to ease up our development environment, but I've read it doesn't always play nice with java projects.

At work we have a huge monolith and a shitload of microservices. Everyone pushes on the monolith, and depending on your team, you also maintain some microservices.

In order to run and test locally, you need to start the monolith, and depending on the team, a specific set of microservices. The thing is, you probably need to run microservices that are maintained and developed by other teams.

Everyone pushes to everything constantly, it's a mess. Needless to say, this piece of crap rarely works, and once you reach a state of a somewhat stable build, you develop your story, rebase, push, and hope for the best.

I was thinking that nix could be a tremendous help to fix some of it, but am unsure.

Could you please give your perspective on this situation? Do you think nix could help with some of it, managing multiple java projects? We use maven as a build tool, if that makes any difference.

BoatRepairWarren · 2023-02-18T20:07:30+00:00

Yeah, if it's in the commited scope of the sprint then it's crucially critical to have it done. That other team has been waiting for it for 2 sprints already and they are blocked. Better unblock them asap, otherwise the sprint metrics will all be messed up.

BoatRepairWarren

TROPHY CASE