I tried using Bazel a while back but immediately ran into a few issues.
The existing codebase I was working with did not lay out its dependencies and files in the manner expected by Bazel so dealing with dependency/include hell was frustrating.
Then there was a large portion of the project that depended on generated code for its interfaces (ie. similar to protobuf but slightly different) and trying to dive into the Bazel rules and toolchain with no other Bazel experience was not fun. I attempted to build off of the protobuf implementation but kept finding additional layers to the onion that didn't exactly translate to the non protobuf tooling. The project documentation seemed out of date in this area (ie. major differences in the rules engine between 1.0 and subsequent versions) and I couldn't find many examples to look at other than overly simplified toy examples.
All in all a frustrating experience. I could not even get far enough along to compile the interfaces for the project.
Did you find genrule? It’s a generic escape hatch rule that can be used to just run any program. Of course it still needs the input and output dependencies declared and you are responsible for ensuring it is hermetic.
Yes, I started out by using genrule before going down the custom rule path. I was able to properly trigger bazel to generate the interface bindings but then lost the thread when trying to properly configure the output files to act as proper dependencies to other code (ie. generate C++ headers and libraries that could then be properly listed as dependencies by client code.)
I think part of the issue was that the generated code from the 3rd party tool did not align with the Bazel expectations about code layout (ie. paths relative to WORKSPACE). Likely solvable but not in the amount of time I had available to dedicate to the effort.
Extraordinary claims require extraordinary evidence. Not no evidence except the word of the person denying a story which paints them in a bad light.
If true, it is very surprising. Surely in most venues the people responsible for back stage hospitality are not the same people responsible for lighting, electrics, sound installation and stage safety? Isn't it quite likely that one of those teams would have met the requirements perfectly, and the other would have cut corners? How about the situation where extremely professional and scrupulous venues do all the important things right but resent having to sort M&Ms for overpaid stars? Wouldn't it have made more sense for Van Halen to have their own electrical inspectors who would check safety and reliability of the installation? How do other touring rock groups make sure everything is set up correctly? How did Van Halen come up with this particular canary test among all others?
Is it really that conspiratorial that an extremely famous 20 year old acted like a dick, and that at age thirty he made up a story to cover up his youthful dickishness?
Your assertion that they were dicks is funny. Even if they just didn't like brown M&Ms if they were paying for the venue then surely it was no different than expecting their personal luggage to be carried to the dressing room, or having banners hung. Why is this request so egregious that it's dickish but having the right brand of sparkling water is not?
> Surely in most venues the people responsible for back stage hospitality are not the same people
They all get paid from the same pool. It's the boss they're testing, not the stage hand.
Does the boss treat every requirement like a requirement and have it done seriously or do they pick and choose based on what they think is important and surprise the artist?
The original story has been told for around 50 years with the widely noted implication "this was dickish behavior - they didn't have any particular preference for non-brown M&Ms but just wanted to mess with the people waiting on them". Even the 'debunkings' invariably recognize this interpretation of the original story.
Obviously part of the reason this story gets told a lot is because a lot of people, many of them management consultants who charge by the day for nuggets of catchy wisdom like this one, love the idea that organizations have a homogenous culture and the same ones that skimp on the buffet preparation also skimp on the rigging safety. Actually, this is complete fantasy. It's perfectly believable to think that the same boss makes sure the artists have everything in their dressing room they want, no matter how demanding, but thinks that they won't check the bigger, critical but more expensive stuff.
> The original story has been told for around 50 years with the widely noted implication "this was dickish behavior
I didn't ask when people started making up the claim, I asked how the claim was reasonable. The person sorting M&Ms would have been paid just the same. How does a reasonable request become dickish?
> they didn't have any particular preference for non-brown M&Ms but just wanted to mess with the people waiting on them"
Mess with? There's that unsupported judgement again. Am I messing with the cook if I ask for less salt, or no onions on my burger? Or are those valid things for a customer to want? Do I have to prove a medical reason for not wanting onions? Or brown M&Ms?
> management consultants [...] love the idea that organizations have a homogenous culture and the same ones that skimp on the buffet preparation also skimp on the rigging safety.
That's generally true but it doesn't need to be. If it saved them one bad show ever it's worth it. Even if it didn't, if they thought it would it was still probably a safe investment.
I'd be happy if a performer went out of their way to make sure that a live event that I paid for and travelled to attend went off without a hitch. To do otherwise would be dickish.
Don't forget that generally e2e tests take longer to run and typically require more test assets.
For example, if e2e tests involve simulations running in real time, then by increasing the number of distinct e2e tests you also increase the requirement on test assets and/or overall CI duration.
My wife created a starter from scratch last year using only water, honey, flour, and raisins. I think the recipe was similar to this (http://www.bellarminemagazine.com/making-your-own-sourdough-...). It has since churned out a loaf or two on a weekly basis (and the discard turns into pizza dough.)
My ability to remain in ketosis is apparently indirectly proportional to the availability of delicious fresh sourdough bread.
I understand most people use "cocktail" to be roughly synonymous with "mixed drink". but technically, cocktails are supposed to have liquor, sugar, and bitters (or ingredients that fill those roles). a cosmo has no bitters or similar ingredient. it's a highball.
I was taught that the only "strong" rule about cocktails was that it had 3+ ingredients. Every other rule (like sweet + bitter) has notable exceptions, ie. drinks like the cosmo substitute a citrus for the bitters.
Plus, the whole sweet cocktail thing was a more modern invention of the prohibition era to cover up the taste of harsh spirits. Plenty of older cocktails around.
EDIT: It kinda feels like the rule about email address parsing. The only good rule is that it has an @ symbol.
> Business travelers are basically not going to voluntarily take a later flight at all.
This. As a business traveler, I don't know how I would justify this to my finance department and/or management. It would take too much effort to justify the change in travel plans for a shitty voucher that I'd probably never be able to redeem.
The test is a list of 23 true/false questions, so you can think of each question as a bit.
You've prearranged a list of 5400 unique 23-bit vectors, so he determines the bit vector with the most correct answers (ie. smallest Hamming distance) and leaves at whatever time offset corresponds to that bit pattern.
It's not a perfect scheme since you only have 5400 possible bit vectors, and 2^23 > 5400.
The existing codebase I was working with did not lay out its dependencies and files in the manner expected by Bazel so dealing with dependency/include hell was frustrating.
Then there was a large portion of the project that depended on generated code for its interfaces (ie. similar to protobuf but slightly different) and trying to dive into the Bazel rules and toolchain with no other Bazel experience was not fun. I attempted to build off of the protobuf implementation but kept finding additional layers to the onion that didn't exactly translate to the non protobuf tooling. The project documentation seemed out of date in this area (ie. major differences in the rules engine between 1.0 and subsequent versions) and I couldn't find many examples to look at other than overly simplified toy examples.
All in all a frustrating experience. I could not even get far enough along to compile the interfaces for the project.