The premise of the article has some weight, but the final conclusion with the suggestion to change the icons seems completely crazy.
Green meaning "to the best of our knowledge, everything is good with the software" is well understood.
Using green to mean "we know that this doesn't work at all" is incredibly poor UI (EDITED from "beyond idiotic" due to feedback, my bad).
And whilst flaky tests are the most problematic for a CI system, it's because they often work (and usually, from my experience most flaky tests are because they are modelling situations that don't usually happen in production) and so are often potentially viable builds for deployment with a caveat. If anything, they should be marked orange if they are tests that are known to be problematic.
Hey, author here: I completely agree, that's why I also haven't used those strange colours for https://nix-ci.com.
I just thought they would make for a cool visual representation of the point of the blog post.
The GDPR applies worldwide to any data held about EU or UK citizens, regardless of where they reside. It does apply in the US, it's just potentially harder for the EU to enforce meaningful penalties for infractions.
Correct. It does not apply to US citizens residing anywhere in the world. It does, however, as I said, apply to EU citizens regardless of where in the world they reside.
If a company holds data about EU citizens, the GDPR applies to them, regardless of where that company is based. Including the US. Hence the statement "It (GDPR) does apply in the US" is completely correct.
When I was a kid, the first "special" Lego kit I remember was the Star Wars sets in 1983 (and especially that everybody wanted a Millenium Falcon but I didn't know anybody who had parents that could afford one!)
Apart from those Star Wars kits, everything I had were generic blocks and strips (not sure what they're called, the ones that are 1/3 the height of a block) and some different designs of people. The closest I had to previous special sets was a town thing that my brother and sister had before me (they were 10 years older), which was a bunch of large floor tiles with roads and grassy areas with studs, some flowers pieces (single stud) and a handful of special buildings. But they were designed to be relatively generic, and the fun was using those building blocks to make a new city each time, not trying to recreate exactly someone's model. Apart from the flowers and the men, basically everything was a standard part, except perhaps a different colour.
When I was a teenager, the trend had become sets with lots of specialised parts for one specific model, such that they didn't really make sense as generic pieces. I enjoyed the technics kits because the early ones were just generic building blocks (apart from the wheels and rack and pinion, but again they could be re-used in lots of subsequent designs), but more and more the kits in the shops were for specialised models with unique pieces that were never designed to fit aesthetically with anything other than the model they came with. I'm sure _some_ people built other things with them, but equally I'd bet than probably 90% of those kits were built exactly once following the instructions and then never disassembled again.
The elements that are 1/3 the height of a brick is a plate if it has studs, and a tile if it does not.
Lego did not have Star Wars sets until 1998. The original Lego Millenium Falcon set 4504 would have retailed for right around $100. Which was high, but just as high as the bigger Castle sets at the time.
They definitely had lunar/space themed sets in the '80s, but they were generic (at least the ones I had). I don't recall when the Star Wars sets came out, they might have been one of the first cross-promotional tie-ins that Lego did?
Star Wars sets started coming out in 1998. They weren't the first licensed sets, but the first fictional license.
Prior to Star Wars, they had Shell, Exxon, and Esso branded sets. I think sometimes they licensed the Ferrari brand as well.
And yes, Lego has had a Space theme since the late 70s. But it was a general "Space" theme. They would later make Space Police, Blacktron, Magnetron, etc.
But actual Star Wars was 1998. I have some of those sets. It was a big deal to get an actual lightsaber hilt and blade.
Very interesting. Googling shows some generic space themed things from the 80s like you say, but no Star Wars. I guess my old age is finally catching up on me and my memories have all blurred into one. I did find a Millennium Falcon from 1983, but it's definitely not Lego.
Same with me, I'll still instinctively go for ~. when a connection has hung / dropped (usually because of a NAT via a rebooted firewall), but never even considered how ~ doesn't normally cause an issue. Never knew it had to be immediately following a newline. Also never knew about the other options, ~^Z in particular looks useful.
I wonder if anyone still remembers the ctrl-[ sequence in telnet. I think I only ever used the quit command in that though.
In the UK, all the used oil from MacDonalds is converted into biodiesel. I often walk past the plan where they do this and there's usually a lorry waiting to be allowed in through the gates.
A few years back there was some eco-warrior protest outside trying to stop the lorries going in. Not really sure what they were trying to achieve with that as it seemed counter to their aims.
Many eco-warrior types, not every single one but many, have... how to put this gently... not thought things all the way through. To name just one example I can think of: protesting an oil pipeline being constructed and/or extended. Well, what will happen if the pipeline doesn't go in? People will still want gasoline — protesting the pipeline isn't going to do anything about people's desire to drive their cars around — so that oil is going to get transported to the refinery somehow. If not in a pipeline, then it'll get transported by train or truck. Which will 1) burn a lot more fuel than transporting the same amount of oil through a pipeline, and 2) be more prone to accidents and oil spills (a tiny chance per truck, but that adds up fast when there are thousands of trucks per month), therefore very likely to spill more oil than the pipeline would have. In other words, blocking that pipeline is very likely to cause more ecological damage than having it built would have caused.
The eco-warrior types protesting the pipeline probably think that they're reducing the use of oil. But they haven't thought it all the way through.
While we're at it, let's think the rest of the way through, and consider the marginal effect that additional transportation cost has on price and therefore both the supply and demand side, shall we?
To prove or disprove your hypothesis, we can look at historical gas prices.
In today's dollars (adjusted for inflation) the US average gas price stayed below $2.75/gal from roughly 1986-2002. Then they broke through that barrier, only ever going below it again for two brief moments in 2016 and in 2020. Most of the time since, they've been well above $3.50, and above $4 sometimes. [1]
If you're right that demand for gasoline is highly elastic, meaning people adjust their demand in response to price, then since gas prices got much more expensive, we should expect that gas usage decreased. Have we seen this? (No. [2]) Of course we haven't, because somewhere between 63-67% of people in the US and Canada live in car-dependent suburbs.[3] These cities and towns, in addition to most rural areas, are fundamentally car-dependent and cannot function without daily car use by a majority of residents. The only way for our society to consume less gasoline would be mass electrification of private transport.
And notably, even the recent increased popularity of EVs in the post-Model-3 era isn't manifesting in the data [2] in the form of decreased consumption to my eyes. Perhaps for every new BEV out there not using gas, five people traded the cars they used to drive for inefficient, huge SUVs.
You may not have learned much about them, or thought through the potential costs of a pipeline being built through your property. Some of those 'eco-warrior types' are not protesting a pipeline, they are protesting the potential irreversable damages to their communities if a neglected or mismanaged pipeline springs a leak (and many, many have), or catches fire, or explodes. Many of them have already seen more than one result of cavalier energy company facilities that have ruined community water and food supplies. What will happen to their community if the pipeline doesn't go in? NOTHING.
Are you sure this isn't a strawman? The recent Dakota pipeline protests for example were very clearly about water safety and building through native burial grounds and other historic native sites. Pretty much every pipeline protest I can think of is more concerned with environmental danger of spills, not reducing oil. And a catastrophic pipeline spill can be much worse than isolated truck spills, though I'd love to know more about research on that front.
There is a clear difference between "I don't want to look at the pipeline" and "pipelines have an established track record of cutting corners and avoiding regulation wherever possible which leads to leaks and spills, leaks and spills cause irreparable damage to the environment including the environment in the middle of our community, and the company is attempting to exploit our already historically exploited community"
The term eco warrior, in the UK at least, long predates social justice warrior. As the peer reply says, it's long been applied to members of Greenpeace and I think I first heard the term in the late 80s or 90s. As they said, maybe it was because of their ship Rainbow Warrior which was sunk by the French government in 1985 and prompted Greenpeace to continue the name with future boats.
I don't think it particularly had a negative connotation until recently though, to me at least it was always just someone who had strong opinions about protecting the environment, and Greenpeace always had quite a lot of support from the general population and they weren't actively disrupting the lives of ordinary citizens in the way Just Stop Oil do for instance.
I think you have the wrong end of this stick. See the Greenpeace vessel Rainbow Warrior for an example. There have been several iterations of this ship name since the first was bombed by the French secret service in 1985.
The problem that the Dakota Access Pipeline protests were protesting was not the pipelines in and of themselves, it was the running them through their reservation, and that many pipelines have had leaks, 23 from the Keystone pipeline alone.
They didn't want an ecological disaster in their back yard, they didn't want their religious sites disturbed, and they didn't want there to be a risk that their water ends up contaminated with oil, and the pipeline company didn't want to pay the cost to navigate around the reservation.
So of course the government stepped in and forced the protesters to accept the pipeline and now idiots that don't understand the reasoning behind the protest mock them after the fact.
Occasionally people in the UK get caught putting cooking oil in their (diesel ) cars, which is not illegal per se - but technically if you do it, you should pay fuel tax, which they generally don't. McDonald's are large enough that they will be, knowing that they would inevitably be caught.
It's not really hinted at in the article, which doesn't actually mention whether the rewrite was a net gain - I presume it was or they wouldn't have written the article, and the lead-in picture paints a rosy picture, but the tone at the end suggests he's not happy with how things turned out.
But one thing that used to be a common design anti-pattern was the "version 2 problem". I think I first heard about it when Netscape were talking about how NN2 was a disaster, and they were finally happy with NN3 or NN4.
Often version 1 is a hastily thrown together mess of stuff, but it works and people like it. But there's lots of bad design decisions and you reach a limit with how far you can continue pushing that bad design before it gets too brittle to change. So you start on version 2, a complete rewrite to fix all the problems and you end up with something that's "technically perfect" but so overengineered, it's slow and everybody hates it, plus there are probably lots of workflow hoops to jump through to get things approved that you end up not making any progress, and possibly version 2 kills the product and/or the company.
The idea is that the "version 3" is a pragmatic compromise - the worse design problems from version 1 are gone, but you forego all the unnecessary stuff that you added in version 2, and finally have a product that customers like again (assuming you can convince them to come back and try v3 out) and you can build into future versions.
To a large degree I think this "version 2 problem" was a by product of waterfall design, it's certainly been less common since agile development became popular in the early 2000s and tooling made large scale refactoring easier, but even so I remember working somewhere with a v1 that the customers were using and a v2 that was a 3-year rewrite going on in parallel. None of the developers wanted to work on v1 even though that's what brought in the revenue, and v2 didn't have any of the benefit of the bug fixes accumulated over the years to fix very specific issues that were never captured in any of the scope documents.
"The general tendency is to over-design the second system,
using all the ideas and frills that were cautiously sidetracked on
the first one. The result, as Ovid says, is a "big pile."
That and Brooks’ underrated “The Design of Design” are notable for having an almost impossible density of quotable aphorisms on every page. They’re all so relevant today that it’s hard to believe that he’s talking about problems he faced half a century ago.
Never heard of "The Design of Design" but I bought it off this comment chain.
I think our industry would do a lot to take a moment and breath to understand what we have collectively done since inception. Wonder often if we will look at the highly corporatized influence our industry has had during our time as the dark ages 1000s of years into the future. The idea that private enterprise should shape the direction of our industry is deeply problematic, there needs to be public option and I doubt many devs would disagree.
I definitely encountered this second-system effect recently. I have an app that works well because it was written to target a specific use case. User (and I) wanted some additional features, but the original architecture just couldn't handle these new features, so I had to do a rewrite from the ground up.
As I rewrote it, I started pulling in more "nice to haves" or else opening up the design for the potential to support more and more future features. I eventually got to a point where it became unwieldy as it had too many open-ended architectural decisions and a lot of bloat.
I ended up scrapping this v2 before releasing it and worked on a v3 but with a more focused architecture, having some things open-ended but choosing not to pursue them yet as I knew that would just introduce unneeded bloat.
I was quite aware of the second-system effect when doing all this, but I still succumbed to it. Thankfully, the v3 rewrite didn't take as long since I was able to incorporate a lot of the v2 design decisions but scaled some of them back.
My adaptation of the Version 2 Problem is “any idiot can ship version 1 of a product, but it takes skill to ship version 2”.
Usually levied at people who are so hyper focused on shipping a so-called MVP that is really demoware that they are driving us at a brick wall and commenting the entire way about what good time we are making.
This has been my experience exactly. V1 was custom built for a single client and they loved it. As we tried to expand to multiple clients the v1 was too narrowly scoped (both in UX and code architecture) so we did a full rewrite attempting to generalize the app across more workflows. V2 definitely expanded our client pool, but all our large v1 customers absolutely hated it.
We never did a full v3 rewrite, but it took about 4 years and many v3 redesigns of various features to get our legacy customers on board.
True | False | FileNotFound was a meme about 2 decades ago, and even that was a reference to MSDOS from another 2 decades earlier. I guess things never change, only the language.
Even now, I still find myself using true/false/null on occasions, but I'm usually smart enough to replace it with an enum at that point. The only time I don't is when it's an optional parameter to a function to override some default/existing value, at which point it then makes sense to keep it as an optional bool.
I'm surprised that trinary logic has not become a standard part of standard libraries yet. Almost every project I have worked on ends up with some form of a yes/no/maybe abstraction.
Yes/No/Maybe is a good fit for an enum because “Maybe” carries some specific information.
For more common situations where the yes/no bool is not available yet or should not be considered, constructs like Rust’s Option<bool> are a very good fit. Layering the bool inside of an Option creates intentional handling about the presence or lack of value first before you can work with it.
This just means that the problem requires more than a Boolean, but rather something like boolean | error. In many languages from the OOP heyday that alternative part was expressed via throwing an exception.
"I can recompile the entire thing from scratch in ~4.3s. That’s around ~900 TUs, including external dependencies, tests, and examples"
In 30 years of using C++ this is the first time I've ever come across "translation unit" being abbreviated to TU and it took a bit of effort to figure out what the author was trying to say. Not sure why they felt the need to abbreviate this when they explain PCH for instance, which is a far more commonly used term.
Thought I'd add the context here to help anyone else out.
I've updated the article to say "translation unit" the first time "TU" is introduced. The data was also incorrect due to an oversight on my part, and it's now much more accurate and ~50% faster across the board.
The problem is that even if the code is clear and easy to understand AND it fixes a problem, it still might not be suitable as a pull request. Perhaps it changes the code in a way that would complicate other work in progress or planned and wouldn't just be a simple merge. Perhaps it creates a vulnerability somewhere else or additional cognitive load to understand the change. Perhaps it adds a feature the project maintainer specifically doesn't want to add. Perhaps it just simply takes up too much of their time to look at.
There are plenty of good reasons why somebody might not want your PR, independent of how good or useful to you your change is.
Lemmings seems as fun as ever. I sped it up on one level and then the next level started at crazy fast speed and I couldn't figure out how to slow it down again. But otherwise looks nice.
Thanks :) The hardest part of making this was not spending all of my time playing.
F1 or ? will show the shortcut keys.
There are little +/- buttons you can click on (bottom of "Paws" button) to do this, right clicking will reset the speed.
There's also a benchmark mode, lots of other flags. This URL will run the game endlessly, spawning 10 lemmings at a time, automatically adjusting the speed to run as fast as it can, reducing speed when frames take too long. I chose a level that ensures they splat so that anyone who clicks on this and forgets about it only crashes the tab and not their browser https://doublemover.github.io/LemmingsJS-MIDI/?version=1&dif...
Green meaning "to the best of our knowledge, everything is good with the software" is well understood.
Using green to mean "we know that this doesn't work at all" is incredibly poor UI (EDITED from "beyond idiotic" due to feedback, my bad).
And whilst flaky tests are the most problematic for a CI system, it's because they often work (and usually, from my experience most flaky tests are because they are modelling situations that don't usually happen in production) and so are often potentially viable builds for deployment with a caveat. If anything, they should be marked orange if they are tests that are known to be problematic.
reply