[-] firelizzard@programming.dev 3 points 5 months ago

“How easy is it to onboard?” is functionally equivalent to “How easy is it to understand?”. The biggest factor in maintainability almost always boils down to how easy it is to understand. So, difficult to onboard almost certainly means difficult to maintain, and thus is tech debt.

[-] firelizzard@programming.dev 3 points 5 months ago

Are you saying you don’t support FOSS projects that aren’t willing to engage in activism? A lot of us are morally aligned with you but aren’t willing to die on that hill. I think this age verification stuff is utter bullshit but if I were a maintainer of a project that was likely to be the target of one of these laws I would not be willing to put my livelihood on the line. Shaming people who are volunteering their time for being unwilling to endanger their livelihoods is pretty entitled IMO.

[-] firelizzard@programming.dev 3 points 5 months ago

That doesn’t make it not suck. I’d much rather not hate my job.

[-] firelizzard@programming.dev 3 points 5 months ago

Your coworkers are not your oppressors. The people who own the company are. And maybe management if they’re assholes, but most people in management are just doing their jobs so they can get paid.

[-] firelizzard@programming.dev 3 points 6 months ago* (last edited 6 months ago)

Using YAML as an intermediate format between steps of a process is a mistake. I love YAML for configuration but I’d never use it for machine-to-machine anything. If the tool you’re feeding data to requires YAML as input, just give it JSON. All JSON is valid YAML.

Edit: I realize you weren’t the one who made that decision. I’m saying the problem isn’t YAML, the problem is someone using YAML inappropriately.

[-] firelizzard@programming.dev 3 points 6 months ago

Depends on what you mean by “basically a class”. If you mean inheritance, overriding, and more generally class/inheritance based polymorphism, no, it does not. Those require dynamic dispatch, which Go does not have (for concrete types, which is what we’re talking about here).

[-] firelizzard@programming.dev 3 points 7 months ago

They’re different signals. The default handling is the same - terminate - but they’re triggered by different things and (if the process handles them) handled by separate handlers.

[-] firelizzard@programming.dev 3 points 2 years ago

Objective-C does not enforce method access (e.g. private methods) at the runtime level. If you are sufficiently determined, there are no restrictions on what methods you can call, unlike Java or C# (AFAIK).

[-] firelizzard@programming.dev 3 points 2 years ago

Fuck that, I don't trust executables unless they're signed, downloaded securely (e.g. HTTPS), and I trust the source I downloaded them from. Anything else might as well be a virus. If I can't find a signed binary from a trustworthy source, I'm either not using it or I'm going to build it myself (after skimming through the code).

[-] firelizzard@programming.dev 3 points 2 years ago

As my first job out of college (when I didn't know what I didn't know) I was hired to build a bespoke inventory system for a manufacturing company. My prototype became a production system the second I showed it to one of the engineers. The next three months of my life were a living hell as I frantically fixed bugs on a live system. Lesson learned.

[-] firelizzard@programming.dev 3 points 3 years ago

There are certainly situations where it would be valuable to be able to place limits on what can be imported, but I can't imagine trying to work with a language that was completely devoid of imports. Because that would mean 100% of your source would have to be in a single file, which sounds absolutely awful for anything but the most trivial applications.

[-] firelizzard@programming.dev 3 points 3 years ago

But evidently git rev-parse - will not print out the previous branch 😔 that would have been useful for scripts

view more: ‹ prev next ›

firelizzard

0 post score
0 comment score
joined 3 years ago