glckr | 2 years ago | on: The most prolific packager for Alpine Linux is stepping away
It's a reference to Hamilton. Definitely reads like nonsense without the context, though...
glckr's comments
glckr | 4 years ago | on: Updated Okta Statement on Lapsus$
Typically services will have you confirm your current password before allowing you to change it (for exactly this reason).
glckr | 4 years ago | on: API versioning has no “right way” (2017)
Why is that wrong?
glckr | 5 years ago | on: Irish teen invents magnetic liquid trap to remove microplastics in water (2019)
Craig Ferguson is not Irish.
glckr | 5 years ago | on: You might not need jQuery (2014)
> If your code can execute 10x faster without jQuery then the optimization is not premature.
One could argue that it is premature if the code doesn't _need_ to run 10x faster.
glckr | 5 years ago | on: .gay Generic Top Level Domain(gTLD.) is now open for public
Why?
glckr | 5 years ago | on: New ‘Meow’ attack has deleted almost 4k unsecured databases
No other bad actors can get it, but we don't know if it's already been found, and now that it's gone we have no idea what data is out in the wild. And as you note, we can't trust the companies to accurately report it themselves.
glckr | 6 years ago | on: TLDR pages: Simplified, community-driven man pages
man is universally known in the industry, and supported (to some extent, at least) by project authors/maintainers; this project will be forgotten by almost everyone (and start decaying) as soon as this post is off the front page here.
glckr | 6 years ago | on: Family turned a former Freemason temple in Indiana into a home
They're publicly well known, and as far as I'm aware they don't have any rules against telling people you're a member. Many of their temples/lodges/whatever you want to call them are identified somewhere on the facade (Freemasons' Hall in Edinburgh for example is available for hire as an event space).
However, what they do and talk about within the lodge is secret.
glckr | 6 years ago | on: Developers mentoring other developers: practices I've seen work well
In what way is it stated as gospel truth? It literally starts with "In my personal experience".
glckr | 6 years ago | on: Nuclear fusion is 'a question of when, not if'
Putting a limit on population would imply a dystopia to most.
glckr | 6 years ago | on: Intro Guide to Dockerfile Best Practices
Tip #6 (Use official images when possible) is certainly convenient when you're just spinning up something (I use them in local docker-composes all the time), but it's surely opening yet another security hole when it comes to prod. We're not lacking examples where packages are hijacked (feels like it happens constantly on npm, rubygems had it just the other day...), and docker hub has already had one security breach.
Perhaps worth a mention in this blogpost?
glckr | 6 years ago | on: Amazon rolls out machines that pack orders and replace jobs
Amazon already (for some items, in the UK at least) makes you explicitly choose to have them re-box it in their own packaging, otherwise they just ship it in whatever box it's in. I imagine they'll do the same here, just not feed these items into the box machine in the first place.
glckr | 6 years ago | on: Python at Netflix
Interesting. I had it in my head that Netflix was a pure Java shop. Was I wrong in the first place, or has something changed?
glckr | 7 years ago | on: Serverless Best Practices
Conceptually I would say I'm a fan of these sorts of ideas (serverless, and queues in particular). Forcing you to look at the system as a chain of processes operating on data can really bring architectural problems into line.
However, 99% of the work that I've done involves users hitting buttons and us responding to them synchronously. In these scenarios, I simply can't figure out how queues (and chains of serverless functions as advocated by this blog) are supposed to work (if they are at all). There seem to be many ways to solve this when the queues are all flowing freely, but as soon as there's any sort of pressure on the system these things all look to fall down.
Looking at the amazon booking flow as an example -- it appears that they always show a "your order has been placed" page with a big green banner synchronously at the end of the cart flow. Some time later the user may then receive an email saying their payment method was declined. This certainly works, but a) it's horrible UX and b) it only works at the final stage of the process.
I see queues (and serverless) advocated as good architectural decisions, but every time they come up in a lecture/blog they're given in toy or data-sciency sort of examples. Is it possible to use these patterns in a sensible way where users are actually involved? (the blog mentions CQRS, but that seems... not a perfect solution)
page 1