stevecrox

Maven has unit and integration test phases and there are a multitude of plugins designed to hook into those phases but there are constraints by design.

Trying to hook everything into the build management system is a source of technical debt, your using a tool for something it wasn't designed.

I would look at what makes sense within the build management system and what makes sense in a CI pipeline.

CI tools have different DSL and usually provide a means to manage environments. Certain integration and system level tests are best performed there.

For instance I keep system tests as a seperate managed project. The project can be executed from developer machines for local builds but I also create a small build pipeline to build the project, deploy it and run the system tests against it triggered by pull requests.

This is why I say the build management system doesn't really change, because you should treat everything as descrete standalone components.

The Parent POM gets updates once every six months, the basic build verification CI pipeline only changes to the latest language release, etc..

Projects which try to embed gitflow into a pom or integrate CD into the gradle file are the unbuildable messes I get asked to fix.

Maven has a high learning curve, but once learned it is incredibly simple to use.

That high bar is created by the tool configuration. You can change and hack everything, but you have to understand how Maven works to do so. This generally blocks people from doing really stupid things, because you have to learn how maven works to successfully modify it and in doing so you learn why you shouldn't.

This is the exact weakness of Gradle, the barrier for modification is far lower and the tool is far less rigid. So you get lots of people who are still learning implement all sorts of weird and terrible practice.

The end result is I can usually dust off someone elses old maven project and it will build immediately using "mvn clean install", about half the gradle projects I have been brought in on won't without reverse engineering effort because they have things hard coded all over them. A not small percentage are so mangled they can't be built without the dev who wrote it's machine.

Also you really shouldn't be tinkering with your build pipelines that much. Initial constraints determine the initial solution, then periodically you review them to improve. DevSecOps exists to speed development and ease support it isn't a goal in of itself

Doesn't the fact you have to use a separate mouse tell you the design is poor?

The better approach would be to detect clicks on the left and right of the trackpad as left/right buttons and support two finger right clicking.

I have had a vareity of HP, Dell, etc.. laptops. The trackpads will do gesture stuff but you can clearly feel a left and right button if you push down on the trackpad (e.g. push on left side for left button).

Tesla actually market it as a positive.

Car manufacturers have to setup different manufacturing lines to provide different feature levels. Tesla argue this makes them more expensive. Tesla cars have all features installed, just disabled and the optional extra packages are cheaper compared to their rivals as a result.

To be honest there is a certain logic, if you've ever been in a Ford Focus LX (bottom range) its pretty clear they had to spend quite a bit of money on more basic systems. I honestly thought each LX was sold at a loss

That kind of character conversation is exactly what you would see if escaping wasn't being done properly.

Definitely a bug in KBin there

I have a Mac book Pro for work.There is just a lot of random weirdness.

There is no right click, your supposed to do a light two finger touch for right click.If you click too hard it opens the dictionary.

If you plug in a mouse you can get right click, but it isn't consistent in working.

By default scroll is inverted (up is down, down is up), also windows can have scroll bars but they aren't clickable, you have to do a scroll gesture.

Almost every Left control + Button action is now Meta key + button. But not everything, its annoyingly inconsistent also new random shortcuts.

For example lock screen isn't Meta key + l like on Linux or Windows. Its Meta + Shift + Q, shut down is Meta +Left Control + Q.

The keyboard doesn't match the your countries layout, so keys move around and is missing traditional keys like print screen. To do that you press Meta + Shift + 4 to switch the mouse to a screen cut tool and select the area you cut.

I could go on and on, none of it is obvious and I wouldn't say any of it is an improvement at best its just different.

Mardown has several valid different ways to define itself, both ways listed are valid ways to indicate italics.

You would expect Lemmy and KBin to fix on one way but display both. That is a bug in the lemmy renderer.

For example asterisk Is a special character, when used in JSON you have to escape special characters with a backslash. A single backslash is also a special character. What your seeing is double escaping, (e.g. something is repeating it on code)

A quick look through the KBin code showed it using json_encode which is the JSON conversion library built into PHP. A quick google shows double calling the library on a string won't do that and I can't see KBin doing anything obviously wrong.

Lemmy has had some really weird bugs, an expectation that Lemmy hadn't escaped a block of code at a set point so they escape it and KBin is escaped would seem the most likely candidate.

The easiest test would be seeing how it renders on an alternate KBin instance, you would expect the extra characters to show up there, if they don't its probably Lemmy

The admins to perform upgrades, monitoring, fixes, etc.. will require root access to the database. That means they can alter all your posts to say *blah blah blah" if they wanted.

Similarly passwords will be encrypted within the database and encryption algorithms have to be able to go in both directions. Normally they need a seed value to start random generation. The admin defines the seed as a result an admin can decrypt everything in the database.

@ergoplato I didn't suggest that.

Personally I don't think its ego. I think you have two issues.

The first is people go through stages learning DevOps. Stage 1 has people deploy a CI because its cool, they build a few basic pipelines and then 90% of people get bored. The 2nd stage is people start extending those pipelines, it results in really complex pipelines requiring lots of unique changes based on the opinion of the writer. You move to the 3rd stage when your asked to recreate/extend for a new project and realise how specific your solutions are.

Learning how to make minor tweaks and hook in a few key points to get what you want takes years. Without that most packagers will want to make big changes upstream which won't go down well.

The second issue, I have met quite a few developers who become highly stressed when the build system is doing something they haven't needed to do or understand.

A really simple example I have a Jenkins function which I tend to slip into release pipelines, it captures the release version and creates a version in Jira.

I normally deploy it first as a test before a few other functions to automate various service management requirements.

Its surprising how many devs will suddenly decide every problem (test failed, code failed review, sharepoint breaks, bad os update, etc..) is due to that function.

For me this little function is a test, if the team don't care I will work to integrate various bits. If they freak out, I'll revert decide if it is worth walking them through the process or walk away.

One of the reasons for the #DevOps movement is developers see building and packaging as #notmyjob.

The task would historically fall on the most junior member of the team, who would make a pigs ear out of it due to complete lack of experience.

This is compounded by the issue that most C/C++ build systems don't really include dependency management.

Linux distributions have all tried to work out those dependency trees but they came up with slightly different solutions. This is why there are a few "root" distributions everything branches from.

That means developers have to learn about a few root distributions to design a deb/rpm/aur package systems to base their release around.

That is a considerable amount of learning in a subject most aren't interested in.

The real question is why don't package maintainers upstream a packaging solution?