I'd add that turning a one-time install followed by running a build command n-times into running a build command n-times is practically irrelevant and saves no time at all.
This reads like a solution desperately looking for a problem.
934 karma · joined November 14, 2021
This reads like a solution desperately looking for a problem.
Keep in mind that even though vscode's vim extension is not bad, it has significant differences to the point it degrades the user experience and gets in the way.
To start off, if you intend to run the same container image for 10 days straight, you have far more pressing problems than reproducibility.
Personally I know of zero professional projects whose production CICD pipeline don't deploy multiple times per day, or in the very worst case weekly in very rare cases where there is zero commit.
> OP's suggestion is to build a separate image with required packages, tag it with something like "mybaseimage:25032022" and use it as my base image in the Dockerfile.
Again, that adds absolutely nothing to just pulling the latest base image, running apt-get upgrade, and tagging/adding metadata.
But that's completely irrelevant, isn't it? Cherry-picking aside, don't you understand how loss leaders work, and how companies use that strategy to push the sale of their cash cows?
The same baseless assertion can be made regarding Eclipse, and it would be less doubtful given Eclipse's FLOSS nature.
Again, can we spend a minute discussing how idiotic is this fad-drive development belief? It's weird how, unlike in any engineering field, there's this cargo cult faith that new and untested is automatically better than old and reliable,and anyone who hasn't mindlessly jumped into a bandwagon is somehow the fool in the story.
I don't understand what Borland's history has to do with JetBrains' decision to invest their resources on adding support for a programming language to a third-party text editor.
Sounds like a non-sequitur of an unwarranted cheap shot that adds nothing to the discussion besides noise.
Perhaps because people do their homework and just by reading the sales brochure they understand that lambdas are only cost-effective as handlers of low-frequency events, and they drag in extra costs by requiring support services to handle basic features like logging, tracing, and even handling basic http requests.
I use both vscose and intellij, and I must say that even though vscode can sometimes feel snappier without any plugin running, it's missing a whole lot of features even with dedicated Microsoft plugins running, to the point it feels half-baked. I'm talking about things like basic refactoring support and even symbol recognition.
IDEs like intellij and Clion may have slightly longer startup times, but that doesn't really matter as you're only going to start the app a few times throughout the day.
Ultimately vscode is nice if all you want to do is open text files and Run regex searches, but the minute you want to run the most basic refactoring steps then it's faster and less frustrating to just start intellij, refactor, save files, and quit the app.
So your circle of acquaintances doesn't include anyone who used an IDE in the past year, and you extrapolate your personal anecdote how far?
> Don't you think that supporting Eclipse might be a viable marketing strategy to get people who are stuck in the past (...)
Can we spend a minute discussing how idiotic is this fad-drive development belief? I mean, why is anyone expected to be perceived as smart if they drop something that works in favour of an unproven tool just because it's new?
It also looks like you're forgetting that Java has been for years (decades) owned by Oracle, which is renowned for taking very public legal fights to milk Java to the extreme.
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
How exactly does that a) assure reproducibility if you use a custom unreproducible base image, b) improve your security over daily builds with container images built by running apt get upgrade?
In the end that just needlessly adds complexity for the sake of it, to arrive at a system that's neither reproducible nor equally secure.
Also known as going through an end-to-end user flow?
The point of a "hello world" is also not to greet people.
> At what point we stop pretending that the king is in fact naked and doesn't have new clothes?
No one is pretending anything. There are only those who understand onboarding is about onboarding, and those who fail to understand it and fill in that blank with outlandish interpretations.
That solves nothing, as it just moves the unreproducibility to a base image at the cost of extra complexity. Arguably that can even make the problem worse as you just add a delta between updates where there is none if you just run apt get upgrade.
> Freshly generated image can be tested in a pipeline to avoid issues and you won't hit issues like inability to scale due to misbehaving new containers.
You already get that from container images you build after running apt get upgrade.
It's a tradeoff between making container images reproducible, and not shipping security vulnerabilities.
People tend to prefer the latter.
Furthermore, you can exec your way into a container and check exactly which package version you installed.
I've been using Dockerfiles extensively for years and I'm yet to find anything that fits the definition of a OS quirk.
The quirkiest thing I've noticed in Dockerfiles is the ADD vs COPY thing.
> I've run into so many strange things just converting a simple predictable shell script into a Dockerfile.
What exactly are you trying to do setting up a Dockerfile that requires a full blown shell script?
A Dockerfile should have little more beyond updating/installing system packages with a package manager, and copying files into the container image. First you run a build to get your artifacts ready for packaging, and afterwards you package those artifacts by running your Dockerfile.
I don't understand your point. If all you want to do is set a container image by running a shell script, why don't you just run the shell script in your Dockerfile?
Or better yet, prepare your artifacts before, and then build the Docker image by just copying your files.
It sounds like you decided to take the scenic route of Docker instead of just taking the happy path.
This has zero to do micromanagement. Either your new hire onboards with dedicated staff in dedicated sessions, or that task falls upon the new arrival's team members. The need is always there, and forcing each team to allocate one or two members to do the job that a onboarding meeting does is hard or impossible to justify.
Keep in mind that the blog author talked about SSO and installing software.
It really isn't. It's a statement of fact. The whole point of getting everyone in the same room and showing them how to go through a SSO userflow and install basic software is precisely to not force everyone on your team to endure that each and every single time there's a new hire.
The majority of questions are always the same predictable set of questions, the struggles are the same, the process is the same, the goals are the same. Thus instead of bringing down each and every team's productivity to go through exactly the same thing over and over again, you just get everyone on the same room, get a pair of dedicated employees to do the handholding, and you're done.
Onboarding processes are done to get most/all those questions answered immediately out of the bat, and in the process spare your team members from time sinks of being repeatedly pestered with having to answer the same question over and over again.
Onboarding is really not about you. It's for everyone which will have to be around you. More importantly, it's to avoid everyone around you wasting their time and energy with unnecessary hand-holding.
If you make onboarding about yourself, you're missing the whole point.
It's also highly unprofessional and demonstrates a high level of disdain for everyone around the author, which is particularly worrying given the author started expressing that at a moment in time when had barely got through the door.
To me it's particularly cringeworthy how the author decided to skip onboarding to afterwards force team members to waste their time onboarding her, and that's depicted as a win. No, it isn't. Onboarding processes are there to avoid wasting everyone's time getting yourself up to speed, and the author forced everyone around to waste their time with an unnecessary do-over. and even that was slammed.
The blog post mentions that the author decided to skip steps of the onboarding process and decided to occupy a desk in a moment in time new arrivals were expected to occupy none.
Also, it seems the onboarding process the author decided to skip was a multi-day event, so it seems the need for a desk popped up a few days before schedule.
How many teams have free desks around waiting for unexpected developers to show up?
Because the accusation has absolutely nothing to do with doublespeak, and given the fundamental difference between the meaning of doublespeak and the case discussed then it's so far-fetched that just reads as a desperate attempt to gratuitously pin the fascist label.
> They are literally making contradictory statements while refusing to make any logical association between them.
If you knew the definition of doublespeak and read the article and the comments you'd quickly understand the absurdity of your accusation.
Correct me if I'm wrong, but a quick search for Clion's support for xmake only returns a dead plugin from intellij which was last updated 4 years ago.
https://plugins.jetbrains.com/plugin/10156-xmake
Meanwhile, Clion is built around cmake. Why would any Clion customer want to drop first-class support for cmake to fall back to an unmaintained plugin that seems to be abandonware?
This was the only substantiated claim you made in your whole post, but it refers to stuff that most standard build systems already do, specially cmake.
In fact, it's even trivial to hack together a plain old Makefile to add a target that invokes vcpkg or conan to fill in dependencies.
What exactly do you believe makes xmake worth the trouble?
That's quite the odd statement. CMake is extremely easy to use, just works, and handles everything at all that everyone needs, from building cross-platform projects comprised of multiple programming languages, tests, dependencies, and even packaging.
In your opinion, what makes xmake worth the trouble?
Let's even put up a concrete example. Say I have a cmake project. It handles dependencies with a mix of ExternalProject_Add(), Conan, and even a stashed folder of vended third-party binaries. Also, it handles tests, and packaging, and it runs in a CICD pipeline that does it all on a couple of target platforms. Why would anyone switch that project to xmake?
Keep in mind that in CMake, that is done by listing the language in program(some program LANGUAGES CXX OBJC ETC) and afterwards you pass the source file list to add-library or add_executable, and CMake takes it from there.
And in CMake support for Conan is literally a single line of code: conan_basic_setup()
https://docs.conan.io/en/latest/getting_started.html
On top of all this, it's really mind-boggling how a build system's main selling point is doing something a build system has no business doing.
It really isn't, and trying to force absurd 1984 references makes absolutely no sense at all.
Think about it for a second: if you already feel you have the absolute best candidate for a spot already working at your side, or you create a position specifically to get that person to work for you, does that mean you are racist or sexist or, as you chose to imply with your absurd comparison, fascist?
...or it really can't and it's quite clearly breaking the law?
The "without salary basis" looks pretty clear to me, and I'm sure someone holding a PhD could spot that as well.