Am I crazy or is it still the case that, in the year fucking 2022, there's no way to have a downstream CI/CD job in Gitlab depend on an upstream one?
Like...this is an obvious feature right? I've got job X which builds a docker image, and anytime it does that I'd like everything which declares a dependency on that to rebuild?
Gitlab seem to think this bullshit is this feature? But like, not even slightly right? It requires having access to the upstream pipeline? I don't, ever want that. I want to just subscribe to updates?
Is the whole industry fucking useless?
At that point you're not looking for pipelines that fire jobs between them, but a build/dependency manager like Bazel and whatnot.
You could maybe do it with downstream pipelines if you were to make a downstream pipeline that is always fired from your upstream after successful build. Make it so that this downstream pipeline is open to anyone who wants to depend on it and just let them add their own pipeline to this list that will fire it off afterwards.
We use Terraform for AWS stuff at work, which is still fairly new to me.
And here at home, I have my IoT junk running on a Raspberry, but it's an unholy mix of things running on bare metal and in Docker containers, and in addition to that my CC2531 Zigbee stick is kind of crappy, so I ordered a new one.
So I figured, why not go overkill and use Terraform to set up my next generation of IoT junk.
Couple of hours of experimenting later I have it mostly ready to deply to a fresh Raspberry Pi, after developing and applying the infra on my Mac Mini for testing.
+1
gavindelThe reason all your softwareis brokenRegistered Userregular
Watching the cluster that is Twitter now...jeez. The loss of institutional knowledge is such a blow. It can take weeks to figure out seemingly simple things when you have no context on a service and nothing to start from. I've been with my current position for nearly two years now, and its only recently that I felt confident to explain why something was setup like X or Y. To see past the code and into the meaning.
It is literally impossible to succeed in a Twitter situation. "I'm on call for teams I only knew the names of" - good luck. Gonna be reading through the five year old half-finished docs posted to a ghost-town slack channel at 3AM? Ain't no amount of smart or driven that can fix that.
Yeah, my first thought was about all the knowledge they lost because of senior people tending to write less code and do more planning stuff. It's just utterly moronic and betrays either ignorance or malice, thus confirming ye olde saying.
Apparently Elon's telling the devs themselves that they have to make sure the features they're implementing meet those "privacy review" requirements. Which is just hilarious(ly sad). The amount of liability he's opening them up to is just nutso.
As a developer who has our compliance dept sign off on any change we make that isn't a bug fix there is absolutely no way I would "self certify". But maybe that's why I'm not thr one in a position to make a bonfire out of 44 billion dollars.
im about to send an email to my users declaring "i dont think there's any report you could run in this system now that would cause the server to crash" and then go rock back and forth in a corner for the rest of the day
im about to send an email to my users declaring "i dont think there's any report you could run in this system now that would cause the server to crash" and then go rock back and forth in a corner for the rest of the day
In my analyst days, I'd respond with "challenge accepted"
0
gavindelThe reason all your softwareis brokenRegistered Userregular
Does self-certification have a legal meaning? It sounded like "here, put your name on this doc, you're liable when this inevitably turns out to violate GDRP in 37 separate ways".
Does self-certification have a legal meaning? It sounded like "here, put your name on this doc, you're liable when this inevitably turns out to violate GDRP in 37 separate ways".
It's either that or they just stopped submitting docs entirely in exchange for a "beg forgiveness" policy.
Okay C++ coroutines are really nice, even if they picked a middle ground that makes nobody happy (no yield across frames but also mandatory heap allocations)
But this is super clean and allows fully asynchronous execution whereas before it would be a nightmare of chaining callbacks and worrying about managing references to the file handle and buffers. It's even relatively straightforward to start the read of the next buffer ahead of time and the helper structs can just check for completion and immediately complete the await, but you can prevent any data races easier than the chained callback formulation.
i know there's not a lot of xcode users around here but if anyone knows how to make the documentation app autocomplete function that would be really nifty. the offline documentation is nearly worthless since I can't directly look up any methods
i know there's not a lot of xcode users around here but if anyone knows how to make the documentation app autocomplete function that would be really nifty. the offline documentation is nearly worthless since I can't directly look up any methods
this is basic stuff, apple, come on!
If in doubt, wipe derived data, clean, restart.
Then get some rum, cigars, and a black chicken. (Mostly the rum and cigars, Xcode likes its vices.)
Edit: Also, it likes to be left alone while indexing; if I have to do the above I try not to... Bother it for a few minutes while it thinks. Coffee break, like.
Edit: Also if you just want Apple's docs (as in iOS/tvOS core stuff) then popping open the docs window manually should let you search in there; web's also really good/up to date. If you mean the lovely "why the fuck isn't it indexing all the methods in my project come the fuck on" problem then yeah, try the other steps and pour it a small glass of rum. (You can drink the rum later, it's not like it drinks the PHYSICAL rum; it's just the offering that matters. Bit like the old gods used to eat the smell/spirit/etc of the sacrifice, then everyone else ate the other bits.)
I'm still trying to think of how you could even create DB tables through Grafana.
Easy: you constantly have selenium watching your graphs, and if at any point it detects a color (say: red for not enough tables) it fires a script to create a new one.
i know there's not a lot of xcode users around here but if anyone knows how to make the documentation app autocomplete function that would be really nifty. the offline documentation is nearly worthless since I can't directly look up any methods
this is basic stuff, apple, come on!
If in doubt, wipe derived data, clean, restart.
Then get some rum, cigars, and a black chicken. (Mostly the rum and cigars, Xcode likes its vices.)
Edit: Also, it likes to be left alone while indexing; if I have to do the above I try not to... Bother it for a few minutes while it thinks. Coffee break, like.
Edit: Also if you just want Apple's docs (as in iOS/tvOS core stuff) then popping open the docs window manually should let you search in there; web's also really good/up to date. If you mean the lovely "why the fuck isn't it indexing all the methods in my project come the fuck on" problem then yeah, try the other steps and pour it a small glass of rum. (You can drink the rum later, it's not like it drinks the PHYSICAL rum; it's just the offering that matters. Bit like the old gods used to eat the smell/spirit/etc of the sacrifice, then everyone else ate the other bits.)
yup... i cleared the derived data and then I went back in and I had to specifically press the enter key in the search field to make it start autocompleting again... only after I do that will it follow my typing... remarkable stuff
Terraform continues to be very interesting. I'm looking at what kinds of providers there are, and there's tons of stuff. There's one from 1Password, so you can have items as code. Started wondering what kinds of interesting stuff you could do for onboarding new people with these kinds of things.
Ditto for Grafana for setting up users and dashboards and stuff.
0
gavindelThe reason all your softwareis brokenRegistered Userregular
Been doing this job for 7.5 years now, and I am still amazed at how it is such a mix of the complex and the stupid.
"Yeah, how are we going to solve parallelized caching in this distributed system given our communication restrictions?" and then "How do I turn an enum into a string again?"
I just discovered a pattern in my project's codebase that I don't know how to feel about:
foreach (var item in itemList ?? new List<Item>())
It's certainly a textually compact way of handling a possible null reference, but going out of the way to create an empty list just so that you can not iterate through it feels wrong.
I just discovered a pattern in my project's codebase that I don't know how to feel about:
foreach (var item in itemList ?? new List<Item>())
It's certainly a textually compact way of handling a possible null reference, but going out of the way to create an empty list just so that you can not iterate through it feels wrong.
The new empty list only gets created if itemList is nullish, right? I would hope that happens rarely enough that it isn't a performance consideration, but I don't know why the pattern would be doing that instead of just making sure you're not throwing nulls around by accident.
I just discovered a pattern in my project's codebase that I don't know how to feel about:
foreach (var item in itemList ?? new List<Item>())
It's certainly a textually compact way of handling a possible null reference, but going out of the way to create an empty list just so that you can not iterate through it feels wrong.
The new empty list only gets created if itemList is nullish, right? I would hope that happens rarely enough that it isn't a performance consideration, but I don't know why the pattern would be doing that instead of just making sure you're not throwing nulls around by accident.
If itemList is referenced anywhere else following that code then it's null check once and done. If you've got an empty list then iterating over it doesn't do anything, as opposed to trying to iterate over null, or getting an item from the empty list returns nothing, as opposed to trying to perform operations on null.
It's something I prefer to do - instead of checking for null values everywhere you just do it once and then you know everything further down just works.
Performance wise the compiler is way smarter than you and an empty struct takes up a negligible amount of space so it's not even worth considering and produces nicley readable code.
The one about the fucking space hairdresser and the cowboy. He's got a tinfoil pal and a pedal bin
I just discovered a pattern in my project's codebase that I don't know how to feel about:
foreach (var item in itemList ?? new List<Item>())
It's certainly a textually compact way of handling a possible null reference, but going out of the way to create an empty list just so that you can not iterate through it feels wrong.
The new empty list only gets created if itemList is nullish, right? I would hope that happens rarely enough that it isn't a performance consideration, but I don't know why the pattern would be doing that instead of just making sure you're not throwing nulls around by accident.
If itemList is referenced anywhere else following that code then it's null check once and done. If you've got an empty list then iterating over it doesn't do anything, as opposed to trying to iterate over null, or getting an item from the empty list returns nothing, as opposed to trying to perform operations on null.
It's something I prefer to do - instead of checking for null values everywhere you just do it once and then you know everything further down just works.
Performance wise the compiler is way smarter than you and an empty struct takes up a negligible amount of space so it's not even worth considering and produces nicley readable code.
In this case, I think the performance concern is less about the iterator itself and more about the allocation of a new list instance. That puts collection pressure on the garbage collector, which might slow you down if you're doing it on a tight loop.
A better way to do the same thing would be (I'm assuming this is C#, since it looks like it):
foreach (var item in itemList ?? Enumerable.Empty<Item>())
... since that's written to use a static instance, so every time you ask for an empty set of type T, you get the same empty set to enumerate over.
My favorite musical instrument is the air-raid siren.
I just discovered a pattern in my project's codebase that I don't know how to feel about:
foreach (var item in itemList ?? new List<Item>())
It's certainly a textually compact way of handling a possible null reference, but going out of the way to create an empty list just so that you can not iterate through it feels wrong.
The new empty list only gets created if itemList is nullish, right? I would hope that happens rarely enough that it isn't a performance consideration, but I don't know why the pattern would be doing that instead of just making sure you're not throwing nulls around by accident.
If itemList is referenced anywhere else following that code then it's null check once and done. If you've got an empty list then iterating over it doesn't do anything, as opposed to trying to iterate over null, or getting an item from the empty list returns nothing, as opposed to trying to perform operations on null.
It's something I prefer to do - instead of checking for null values everywhere you just do it once and then you know everything further down just works.
Performance wise the compiler is way smarter than you and an empty struct takes up a negligible amount of space so it's not even worth considering and produces nicley readable code.
In this case, I think the performance concern is less about the iterator itself and more about the allocation of a new list instance. That puts collection pressure on the garbage collector, which might slow you down if you're doing it on a tight loop.
A better way to do the same thing would be (I'm assuming this is C#, since it looks like it):
foreach (var item in itemList ?? Enumerable.Empty<Item>())
... since that's written to use a static instance, so every time you ask for an empty set of type T, you get the same empty set to enumerate over.
Java also has Collections.emptyList() for similar functionality.
In some languages, you could also extend nil to respond to your iterator but do nothing...
class NilClass
def each
return nil
end
end
I still think it's better to guard against null explicitly; if you are getting a null passed around your code I think it's an indicator that something has gone wrong.
If it was me, I'd want more brackets around the `(itemList ?? makeMeAnEmptyList())` stuff, because I have no instincts for if `in` binds more or less tightly than `??`, so that would make it more obvious what was going on.
Posts
Absolute boss
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
At that point you're not looking for pipelines that fire jobs between them, but a build/dependency manager like Bazel and whatnot.
You could maybe do it with downstream pipelines if you were to make a downstream pipeline that is always fired from your upstream after successful build. Make it so that this downstream pipeline is open to anyone who wants to depend on it and just let them add their own pipeline to this list that will fire it off afterwards.
Sounds a bit hacky but ¯\_(ツ)_/¯
And here at home, I have my IoT junk running on a Raspberry, but it's an unholy mix of things running on bare metal and in Docker containers, and in addition to that my CC2531 Zigbee stick is kind of crappy, so I ordered a new one.
So I figured, why not go overkill and use Terraform to set up my next generation of IoT junk.
Couple of hours of experimenting later I have it mostly ready to deply to a fresh Raspberry Pi, after developing and applying the infra on my Mac Mini for testing.
It is literally impossible to succeed in a Twitter situation. "I'm on call for teams I only knew the names of" - good luck. Gonna be reading through the five year old half-finished docs posted to a ghost-town slack channel at 3AM? Ain't no amount of smart or driven that can fix that.
Apparently Elon's telling the devs themselves that they have to make sure the features they're implementing meet those "privacy review" requirements. Which is just hilarious(ly sad). The amount of liability he's opening them up to is just nutso.
we also talk about other random shit and clown upon each other
In my analyst days, I'd respond with "challenge accepted"
It's either that or they just stopped submitting docs entirely in exchange for a "beg forgiveness" policy.
Either way that is, how you say, very very bad.
we also talk about other random shit and clown upon each other
But this is super clean and allows fully asynchronous execution whereas before it would be a nightmare of chaining callbacks and worrying about managing references to the file handle and buffers. It's even relatively straightforward to start the read of the next buffer ahead of time and the helper structs can just check for completion and immediately complete the await, but you can prevent any data races easier than the chained callback formulation.
task read_file(std::string_view path) { aio io; char buf[8192]; auto f = (co_await fs.co_open(path, io::open_mode::read_only)).value(); size_t offset = 0; for(;;) { size_t n = (co_await f->co_read(&io, offset, buf, sizeof(buf))).value(); offset += n; if(n < sizeof(buf)) break; } }this is basic stuff, apple, come on!
we also talk about other random shit and clown upon each other
when can we get more of those sequels, everybody loves SQLs
If in doubt, wipe derived data, clean, restart.
Then get some rum, cigars, and a black chicken. (Mostly the rum and cigars, Xcode likes its vices.)
Edit: Also, it likes to be left alone while indexing; if I have to do the above I try not to... Bother it for a few minutes while it thinks. Coffee break, like.
Edit: Also if you just want Apple's docs (as in iOS/tvOS core stuff) then popping open the docs window manually should let you search in there; web's also really good/up to date. If you mean the lovely "why the fuck isn't it indexing all the methods in my project come the fuck on" problem then yeah, try the other steps and pour it a small glass of rum. (You can drink the rum later, it's not like it drinks the PHYSICAL rum; it's just the offering that matters. Bit like the old gods used to eat the smell/spirit/etc of the sacrifice, then everyone else ate the other bits.)
[XY Problem intensifies]
On the plus side, this has cured whatever imposter syndrome you might have had.
Easy: you constantly have selenium watching your graphs, and if at any point it detects a color (say: red for not enough tables) it fires a script to create a new one.
yup... i cleared the derived data and then I went back in and I had to specifically press the enter key in the search field to make it start autocompleting again... only after I do that will it follow my typing... remarkable stuff
we also talk about other random shit and clown upon each other
Ditto for Grafana for setting up users and dashboards and stuff.
"Yeah, how are we going to solve parallelized caching in this distributed system given our communication restrictions?" and then "How do I turn an enum into a string again?"
Ah yes, I always have to review the Ruby docs for programming 101 stuff like that during Advent of Code.
Thank god for ruby-doc.org.
It's certainly a textually compact way of handling a possible null reference, but going out of the way to create an empty list just so that you can not iterate through it feels wrong.
The new empty list only gets created if itemList is nullish, right? I would hope that happens rarely enough that it isn't a performance consideration, but I don't know why the pattern would be doing that instead of just making sure you're not throwing nulls around by accident.
If itemList is referenced anywhere else following that code then it's null check once and done. If you've got an empty list then iterating over it doesn't do anything, as opposed to trying to iterate over null, or getting an item from the empty list returns nothing, as opposed to trying to perform operations on null.
It's something I prefer to do - instead of checking for null values everywhere you just do it once and then you know everything further down just works.
Performance wise the compiler is way smarter than you and an empty struct takes up a negligible amount of space so it's not even worth considering and produces nicley readable code.
In this case, I think the performance concern is less about the iterator itself and more about the allocation of a new list instance. That puts collection pressure on the garbage collector, which might slow you down if you're doing it on a tight loop.
A better way to do the same thing would be (I'm assuming this is C#, since it looks like it):
... since that's written to use a static instance, so every time you ask for an empty set of type T, you get the same empty set to enumerate over.
I'm "kupiyupaekio" on Discord.
Java also has Collections.emptyList() for similar functionality.
class NilClass def each return nil end endI still think it's better to guard against null explicitly; if you are getting a null passed around your code I think it's an indicator that something has gone wrong.