I read some time ago (that was before the Twitter acquisition) a Fellon Muskolini apologist say that āHe is always the smartest person in any roomā. Itās clear now that this is absolutely true, as long as everybody else in the room is a rutabaga.
The Muskrat is the dumb manās idea of a smart person.
If he actually is the smartest man in a room, itās because the smart people got up and left because they got tired of his bullshit.
"Ladies and gentlemen, weāre sorry to announce that the JWST has smashed some of itās own mirrors due to unexpected behavior of something called a ātype systemā "
What was the state of Python in the early 'oughts? Theyāre using it basically the same way according to the article; an easy human-readable language to control basic procedures.
āYou have an issue in the sprint without any story points. Why doesnāt it have any story points?All sprint issues must be pointed.ā
Well fuck, Janice, I donāt know. All Iāve done so far is click āAssign to meā. Thereās no evaluation yet! I have no idea what the root cause is or how long it will take to fix.Let me cook goddammit.
As someone who works as a software engineer for a smaller company without any of that noise, that sounds like complete hell. I have no clue how devs are getting anything useful done while having to context switch constantly during the day for asinine meetings and corporate progress tracking bullshit.
I literally would not work for a company if they made me do story points.
We do have a scope rule which is intentionally ambiguous, but the idea is a ticket ought not take more than 3 days, and some can be quicker. We expect the average time to meet our velocity and prioritize accordingly. If an effort seems like it will take longer we try to divide it into smaller tickets.
There may be like 5 tickets a year where this doesnāt hold true and we are ok with it. Nothing to be religious about.
The other issue is the amount of points it is totally depends on who does the work! Itās a garbage system to estimate work. Makes people think they have some sort of idea that is more misleading and harmful than just saying āI donāt know exactly but you can expect it to get done promptly because weāve taken proper steps to analyze and break down the work to be bite sized and delivered consistently.ā
@CountVon@soloner In our company every person in the team (dev, qa, doc writer, po) is estimating the story points in secret, then we reveal them and mostly take the average. Our experience is that we all are mostly in the same range.
No offense but it sounds like you donāt actually understand nix flakes if you think theyāre 1:1 equivalent to Docker.
They simply are not containers. They allow the declarative BUILD of any derivation at any time in the future. They hermetically lock all dependencies and build instructions which allows you to archive and reproduce the EXACT content-addressed dependency graph of the software. You can rebuild using a flake while Docker doesnāt actually allow that same hermetic reproducible guarantee whatsoever.
See here for a much better explanation of the glaring differences between the two: youtu.be/0uixRE8xlbY
You could even build a container with a flake though Iād recommend OCI instead because theyāre an open standardā¦
This is programmerhumor so perhaps allow for a bit of hyperbole on my part. I wasnāt completely factual.
However the initial days of Docker were effectively promising to solve the exact same āit works on my laptopā problem. The idea was that developer builds docker image and pushes it to repository where it can pass through CI and eventually the same image gets to production.
As you can see, this effectively reproduces the EXACT content as well, because you transfer the files in a set of tar files.
It didnāt work for many reasons. One of which is the fact that itās often not so much about the exact files, but the rest of the environment like DBs, proxies, networking, etc that is the problem. Iāve seen image misbehaving in production due to different kernel version/configuration.
I know itās a strange place for this conversation but the facts remain: docker images donāt do this and nix flakes actually do. As the video I linked demonstrates and you allude to, Docker files arenāt 100% hermetic (which means theyāre not reproducible) while Nix flakes actually do achieve this. Watch the video I linked for more explanation which directly talks about how nix works with the goals of Docker that you mentioned in the head of your last comment. I hope my non-confrontational tone comes across somehow. This is all said with respect and in the spirit of science.
First of all. Thank you for civil discussion. As you say this is weird place to have such discussion, but itās also true that these jokes often have some kernel of truth to them that makes these discussions happen organically.
So with that out of the way and with no bad intentions on my side:
Iāve noticed you use Dockerfiles and Docker Images interchangeably. And this might be the core of misunderstanding here. What I was describing is that:
Developer builds an image (using Dockerfile or otherwise) on their laptop and then pushes that image to a Docker repository.
This exact same image is then used in CI to do integration tests, scanning, whateverā¦
If all is good, this image is then deployed to production.
So if you compare sha of the image in production and on developers laptop, they are the same checksums. Files are identical. Nix arrives to this destination kind of from the other side. Arguably in more elegant way, but in both cases files are the same.
This was the promise (or one possibility) in the early days of Docker. Obviously there are some problems with this approach. Like what if CPU architecture of the laptop differs from production server? Well that wasnāt a problem back in 2014, because ARM servers just didnāt exist. (Not in any meaningful way) Thereās also this disconnection between the code that generates the image and the image itself, that goes to production. How do you trust environment (laptop) where image is built. Etcā¦ So it just didnāt stick as a deployment pattern.
Many of these things Nix solves. But in terms of āit works on my laptopā what I wrote in previous comment applies. The environment differences themselves rather than slightly different build artefacts is whatās frequently the problem. Nix is not going to solve the problem of slightly different databases because developer is runing MariaDB locally to test, but in production we use DB managed by AWS. Developer is not going to catch this quirky behavior of how his app responds to proxy, because they do not run AWS ELB on their laptop, but production is behind it. You get the idea.
When developer says it works okay on their laptop, what it usually means is the they do not have 100% copy of production locally (because obviously they donāt) and that as a result they didnāt encounter this specific failure mode.
Which is not to say, that Nix is bad idea. Nix is great. Iām just saying that thereās more to the ālaptop problemā than just reproducible builds - we had those even before Docker Images.
Hope that makes sense. And again, thanks for civil discussion.
programmerhumor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.