stevecrox
- 2 Posts
- 16 Comments
- •
- 5M
- •
Do not mix tabs and spaces.
Its impossible to automate checking that tabs were only used for indentation and spacing for precise alignment. So you then take on a burden of manually checking
You end up with the issue where someone didn’t realise and space idented or anouther person used tabs for precise alignment and people forget to check the whitespace characters in review and it ends up going inconsistent and becoming a huge pile of technical debt to fix.
Use only one, you can automate enforcement and ensure the code renders consistency.
Years ago there was no way to share IDE settings between developers.
You ended up with some developers choosing a tab width of 2 spaces, some choosing 4 spaces and as there was no linting enforcement some people using 2-4 spaces depending on their IDE settings.
This resulted in an unreadable mess as stuff was idented to all sorts of random levels.
It doesn’t matter if you use tabs or spaces as long as only one type is consistently used within a project.
Spaces tends to win because inevitably there are times you need to use spaces and so its difficult to ensure a project only uses tabs for identation.
IDE’s support converting tabs into spaces based on tab width and code formatting will ensure correct indentation. You can now have centralised IDE settings so everyone gets the same setup.
Honestly 99% of people don’t care about formatting (they only care when consistency isn’t enforced and code is hard to read), there is always one person who wants a 60 charracter line width or only tabs or double new lined parathensis. Who then sucks up huge amounts of the team time arguing their thing is a must while they code in emacs, unlike the rest of the team using an actual ide.
I am actually arguing for a stable ABI.
The few times I have had to compile out of tree drivers for the linux kernel its usually failed because the ABI has changed.
Each time I have looked into it, I found code churn, e.g. changing an enum to a char (or the other way) or messing with the parameter order.
If I was empire of the world, the linux kernel would be built using conan.io, with device trees pulling down drivers as dependencies.
The Linux ABI Headers would move out into their own seperately managed project. Which is released and managed at its own rate. Subsystem maintainers would have to raise pull requests to change the ABI and changing a parameter from enum to char because you prefer chars wouldn’t be good enough.
Each subsystem would be its own “project” and with a logical repository structure (e.g. intel and amd gpu drivers don’t share code so why would they be in the same repo?) And built against the appropriate ABI version with each repository released at its own rate.
Unsupported drivers would then be forked into their own repositories. This simplifies depreciation since its external to the supported drivers and doesn’t need to be refactored or maintained. If distributions can build them and want to include the driver they can.
Linus job would be to maintain the core kernel, device trees and ABI projects and provide a bill of materials for a selection of linux kernel/abi/drivers version which are supported.
Lastly since every driver is a descrete buildable component, it would make it far easier for distributions to check if the driver is compatible (e.g. change a dependency version and build) with the kernel ABI they are using and provide new drivers with the build.
None of this will ever happen. C/C++ developers loath dependency management and people can ve stringly attached to mono repos for some reason.
The linux kernel is very old school in how it is run and originally a big part of the DevSecOps movement was removing a lot of manual overhead.
Moving on to something like Gitea (codeberg) would give you a better diff view and is quicker/easier than posting a patch to a mailing list.
The branching model of the kernel is something people write up on paper that looks great (much like Gitflow) but is really time consuming to manage. Moving to feature branch workflow and creating a release branches as part of the release process allows a ton of things to be automated and simplified.
Similarly file systems aren’t really device specific, so you could build system tests for them for benchmarking and standard use cases.
Setting up a CI to perform smoke testing and linting, is fairly standard.
Its really easy to setup a CI to trigger when a new branch/pr is created/updated, this means review becomes reduced to checking business logic which makes reviews really quick and easy.
Similarly moving on to a decent issue tracker, Jira’s support for Epic’s/stories/tasks/capabilities and its linking ability is a huge simplifier for long term planning.
You can do things like define OKR’s and then attach Epics to them and Stories/tasks to epics which lets you track progress to goals.
You can use issues the way the linux community currently uses mailing lists.
Combined with a Kanban board for tracking, progress of tickets. You remove a ton of pain.
Although open source issue trackers are missing the key productivity enablers of Jira, which makes these improvements hard to realise.
The issue is people, the linux kernel maintainers have been working one way for decades. Getting them to adopt new tools will be heavily resisted, same with changing how they work.
Its like everyone outside, knows a breaking the ABI definition from the sub system implementation would create a far more stable ABI which would solve a bunch of issues and allow change when needed, except no one in the kernel will entertain the idea.
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
@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?
I want a build job to be triggered when a merge request is raised/changed to verify merge requests. Primarily I want it to comment/annotate changes so peer review focusses on logic and warnings are clear.
I can do this with Concourse, Circle, Jenkins and Github Actions on Azure Devops, Bitbucket Cloud, Bitbucket Server & Github. All Gitlab can tell you is pass/fail, which was good in 2003 but seriously lacking in 2023.
Similarly I want the ability to trigger a release and supply a desired version for the release (or someway to achieve that since our projects follow semantic versioning).
The release DSL is incomplete and could not work on server/cloud last time I used it. The page claims it can do alot but there is a hole in it and even the writer clearly knew.
I want the ability to specify multiple reusable pipelines, in a central place. This is not possible in cloud.
Lastly I would like to have multiple potential pipelines in a repository (e.g. smoke test and release). You can hack this in via variables. This will/won’t work depending specifically on the runner for your job. if self hosted or cloud you’ll notice different parsing behaviour depending on what host it runs on. This is shocking.
I have an email somewhere where I went through every GitLab CI DSL and documented which didn’t consistently work, which only worked consistently on cloud and which only worked on server. Also things like release that are broken on both.
The only way to make it work is to use multi stage docker builds and if your doing that build bot and a bash script would be better.
Gitlab marketing docs heavily mislead you on its capabilities. Technically they are correct, but the way something works is reality isn’t often useful (epic boards are a great example).
This would be ok, but It’s really tightly integrated and doesn’t provide means for external tools to hook into it usefully.
For example I think GitLabs CI is the worst on the market but if you integrate another CI you don’t have a means to feedback information into Gitlab.
Just to add.
Look at any hobby in your life and break out the money spent vs the enjoyment you got out of it.
For example the Cinema costs me £10 and a film is 2 hours long, meaning my fun time costs £5 per hour.
A £100 console would have to provide me 20 hours entertainment for it to be comparable to going to the cinema.
These days any PS4 game will have 10-40 hours content, but buying them costs money. Popping on CEX website the most expensive PS4 games are £12. Assuning you only get 10 hours of fun from a game…
The question you should ask yourself is are there 3 games on the PS4 you are interested in playing?
So reading twitter…
It seems much of the “Ammunition shortage” Prigozhin was loudly complaining about was stock pilling. Similarly much of Wagnar was pulled out of Ukraine to rebuild.
There have been suggestions Prigozhin was planning to launch an attack on Sunday but the Russian MoD attacked a Wagner site forcing him to launch a day early.
One tweet suggested Wagner soliders had been calling family all day (e.g. before a big operation).
Seizing Rostok Von Don was a clever initial play, since its a major logistics hub. This allowed him to arm his troops and provides a base if the coup fails.
It seems the South Military District gave up without a fight, with soliders surrendering.
Prigozhin has sent a shock force to Moscow, its bypassing major cities and trying to get there ASAP. There is a belief senior Kremlin officials will abandon ship.
Various helicopters are attacking the shock force but it seems Wagner are using air defence. Various MI-8, KA-52 and a ll-s2 have been shown destroyed.
The Tik Tok bigrade are trying to attack Rostok, considering they aren’t “true Russians” and were used as barrier troops, this doesn’t seem to be going down well. They are also stripping Donetsk of defenders to do this.
Its a really immature and niave response from Kev. Information is power, he’s chosen to operate without knowledge for internet points.
Meta think there is potential to enlarge their market and make money, Kev’s response won’t impact their business making decisions.
Kev should have gone to the meeting to understand what Meta are planning. That would help him figure out how to deal with Meta entering the space.
I don’t expect he could shape their approach but knowing they want to do X, Y or Z might make certain features/fixes a priority so it doesn’t impact everyone else
I think there is a focus on C/C++ to justify Pythons performance.
There have been times when the performance of Node js/Python were part of the reasoning for choosing Java/Scala.
Each time you are regaled with how Python is C/C++ underneath and so faster. Each time you have to ask if they will write C/C++ libraries to ensure the application performance meets our needs.
Similarly any time you go near lambas you get a comment on how python lambdas are faster because its C running, where as Java has to start a virtual machine, etc…
3 different companies samething
I avoid any company that requires a software test before the interview.
I worked for a company that introduced them after I joined, I collected evidence all of the companies top performers wouldn’t have joined since we all had multiple offers and having to do the test would put people off applying. The scores from it didn’t correlate with interview results so it was being ignored by everyone. Still took 2 years to get rid of it.
The best place used STAR (Situation Task Action Result) based interviews. The goal was to ask questions until you got 2 stars.
I thought these were great because it was more varied and conversational but there was a comparable consistency accross interviewers.
You would inevitably get references to past work and you switch to asking a few questions about that. Since it was around a situation you would get more complete technical explanations (e.g. on that project I wrote an X and Y was really challenging because of Z).
I loved asking “Tell me about something your really proud off”. Even a nervous junior would start opening up after that question.
After an hour interview you would end up with enough information you could compare them against the company gradings (junior, senior, etc…).
This was important because it changed the attitude of the interview. It wasn’t a case of if the candidate would be a good senior dev for project X, but an assessment of the candidate. If they came out as a lead and we had a lead role, lets offer them that.