The UK government has announced very little about the plan and in fact made it clear that the details are yet to be decided
https://www.gov.uk/government/publications/digital-id-scheme...
Yet plenty of people including in this thread have lept to criticising details of a non existent specification.
I find it perplexing. I agree with Tim. This could be done well. The UK Govs Digital Services Department have done fine work in recent years. I have faith in them to pull something like this off well.
Next though, we need an actual tech spec and public technical consultation. Then perhaps we can have a meaningful debate on it.
I would recommend doing more than gaussian blurring. Blurring makes it harder but not impossible to recover, especially if you know the exact font and font size in an image (which is easily recovered when the attacker can visit the website to work it out!).
https://youtu.be/acKYYwcxpGk here's a citation for that being possible, in case anyone's interested. Also has some of the methods posted on github from what I remember.
I'm not sure that's a particularly fair conclusion to make Mike.
1bn a day is order 10k/s. if you the creator of Sidekiq know "dozens" of people hitting that rates, if anything you're supporting arcticfox's point that these systems are quite rare.
No shade intended. I have been a very grateful Sidekiq Enterprise customer in past Ruby jobs.
It's a piece of mind thing. Everywhere I worked did a lot of stuff on the background. The db is already so full on a normal Rails application that adding more reads doesn't make sense to me when Sidekiq works so well. You never have to worry about Sidekiq throughput, or when you do is to be careful to not overload the db because Sidekiq is so fast.
Rails is already on a slow language, I don't understand why we want to overload even more with slow things.
Having both available is a huge win for the Rails ecosystem.
If you’re just starting or have a small project Solid Queue is invaluable and reduces costs and friction.
If and when you need more performance or power Sidekiq is still available. Both run in the context of your Rails app so moving jobs from one to the other shouldn’t be terribly hard.
Yes. But as with all things Rails I do wish the default performance could be pushed a bit. So say Solid Queue could work for 90% of project instead of 70 - 80%.
Exactly, it's not an either/or situation. I've worked on a codebase that did 3-4k/s jobs through sidekiq and in this case sidekiq is obviously the best option (although we also used a go sidekiq client for certain tasks that didn't need the rails app context) but using sidekiq from the beginning is premature optimization. You can easily start with Solid Queue and switch over to sidekiq when you actually have data that tells you that it'll potentially become a bottleneck. Premature optimization is a complexity cost.
Dozens is just the number I've talked to who have told me their scale. I'm sure there's a lot more.
And ultimately the precise number is not as important as the fact that it *is normal* for midsized Ruby apps to operate at this level of scale. The more you start to use the background job pattern, the more you tend to create. "A Job for every ProductVariant record" can easily create 10-20m jobs.
You want tools that scale to the size of "success". That would be a good marketing tagline for Sidekiq.
This was a really compelling article Dan, and I say that as a long time l advocate of "traditional" server side rendering like Rails of old.
I think your checklist of characteristics frames things well. it reminds me of Remix's introduction to the library
https://remix.run/docs/en/main/discussion/introduction
> Building a plain HTML form and server-side handler in a back-end heavy web framework is just as easy to do as it is in Remix. But as soon as you want to cross over into an experience with animated validation messages, focus management, and pending UI, it requires a fundamental change in the code. Typically, people build an API route and then bring in a splash of client-side JavaScript to connect the two. With Remix, you simply add some code around the existing "server side view" without changing how it works fundamentally
it was this argument (and a lot of playing around with challengers like htmx and JSX like syntax for Python / Go) that has brought me round to the idea that RSCs or something similar might well be the way to go.
Bit of a shame seeing how poor some of the engagement has been on here and Reddit though. I thought the structure and length of the article was justified and helpful. Concerning how many peoples' responses are quite clearly covered in TFA they didn't read...
its absolutely ridiculous and sad the level of responses failing basic comprehension and this is a topic i happen to know well... makes you wonder how much to trust the avg hn comment where i am NOT knowledgeable...
There are a couple of "red flag" quips that if I hear them coming out of my mouth (or feel the urge to do so), I have to do a quick double take and reconsider my stance. "Everything old is new again" is one of them — usually, that means I'm missing some of the progress that has happened in the meantime.
Sometimes I imagine "progress" as movement along a coil.
In 2D, it seems like you're just reinventing the wheel. But in 3D, you can see that some hack or innovation allowed you to take a new stab at the problem.
Other times I imagine trilemmas, as depicted in Scott McCloud's awesome book Understanding Comics.
There's a bounded design (solution) space, with concerns anchoring each corner. Like maybe fast, simple, and correct. Or functional, imperative, and declarative. Or weight, durability, and cost. Or...
Our job is to divine a solution that lands somewhere in that space, balancing those concerns, as best appropriate for the given context.
By extension, there's no one-size fits all perfect solution. (Though there are "good enough" general purpose solutions.)
The beauty of experiencing many, many different cuts at a problem, is that one can start to intuit things. Like quickly understand how a new product fits in the space. Like quickly narrowing the likely solution space for the current project. Comparing and contrasting stuff in an open-minded semi-informed way.
> This layout creates uniformly-sized columns, without any rows
I find it amusing that they've decided to refer to this as masonry layout. If you actually built a wall like this (as opposed to uniformly-sized rows, without any columns) it would be a structural engineering disaster.
Probably influenced by the most popular JavaScript library for achieving this type of layout, Masonry[0]. The author notes at the end of the article:
> But do expect the name of this value to change in the future. And perhaps prepare for a future where we call this “columnar grid” or “Grid Level 3” instead of “Masonry”.
I expect this is the case, if I had to describe that layout in iOS-land I'd also call it "masonry".
It's a pretty common descriptor in the Wordpress world - grids/scrapbooks will often have masonry as one of their layout styles. Maybe 100 years from now when people are browsing in their neurodisplay they'll be able to think "masonry" and have their photos tile the way they like, never having heard of Javascript or CSS in their lives. Language is neat like that.
It makes sense they'd pick this name, it refers to the jQuery plugin that was popular for doing this kind of layout back in the 2010s, so it's a convenient shorthand.
> Accidentally, seems harder. It kinda smells for people to intentionally make it not popular by actively working against fame, or something like that..
It's not harder; it's the only thing that works for tools. Tools cannot be good for long because of marketing. Marketing is the thin layer of paint over the Ferrari. Very nice paint, but if the car doesn't work or go very fast very quickly then that's that.
because every new construction requires a solid cornerstone? every archway a keystone? dont forget to put your boots in the trunk and your trunk in the boot. Nucular aluminum? I dunno
I've never had a case where I didn't know the reason or mechanism by which an element would be hidden. In my code, I use the `hidden` property. In that case it simplifies from
$(el).is(':hidden')
to
el.hidden
It's not quite as succint as your jquery, but you also could have written this.
jQuery has a fluent interface and often shorter/smaller/more convenient APIs on top of that.
DOM APIs are quite literally 90s era Java-style APIs.
While DOM APIs have pulled in a few niceties over the years, some of them are really anemic (e.g. querySelectorAll does not return a proper Array-like object). Worse is combining them. Almost every API is a single-shot tedious step-by-step chore.
From a structural engineering point of view, this is because of the extra 1G of force keeping the rows together, but nothing keeps the columns together.
Since bricks have some tensile strength, but mortar (the 'glue' between rows and columns) has ~none, that means that, if you must have lines of weakness, you would prefer they be horizontal than vertical.
Maybe there should be a grid-template-masonry-direction? Just quickly surveying a couple of sites, "masonry" and "horizontal masonry" seem to be about equally common.
On the other hand horizontal masonry is constructed very differently: Flickr fits thumbnails into a row until it reaches some predefined total length, then scales everything down slightly so the total row width matches exactly (resulting in rows of different height). Deviantart does something similar, but shuffles the images for better fit so that the different row heights are barely perceptible.
More seriously, what you describe is quite doable with flexbox (flex-direction: row, flex-wrap: wrap and flex-grow: 1).
Interestingly, even the Masonry layout was already doable using a simple multi-column layout, the "only" issue is that instead of having the items left-to-right, top-to-bottom (ordered by row) you have them top-to-bottom, left-to-right (ordered by column) which is not what you want most of the times
There's a CMS I use that has a photo search option. It loads in images in a column ordered masonry layout, which when you scroll down adds new images to the columns, so all the pictures move about and you've no idea where you are.
> amusing that they've decided to refer to this as masonry layout
They haven't decided this. Keep reading!
TL;DR:
Perhaps the best syntax could be grid-template-rows: none; to convey “please do not give me any rows”. Sadly, it’s too late to use this name, because none is the default value for grid-template-* and means “please give me only implicit rows, no explicit ones”.
Instead we could use the name off to convey “please turn off the grid in the row direction, and give me only columns”.
grid-template-rows: off;
But do expect the name of this value to change in the future. And perhaps prepare for a future where we call this “columnar grid” or “Grid Level 3” instead of “Masonry”.
This is creating a mode of grid where we say "it's not actually a grid" and is my biggest problem with this philosophically. It makes more sense to treat it as it's own display type, where the row/column targeting don't exist. It's not just that row targeting doesn't exist, it also makes no sense to target columns.
I think, in structural engineering terms, it refers to old natural stone wall [0] construction methods. Some bridges around me are made like this, and they're over a thousand years old.
But I agree that it's not a good adjective because I had the exact same first thought. Both "natural" and "stonewall" would be better, and they're not great names either.
I associate masonry with the old ages, since this is one of the technologies you research in Civ games and back then I think people did have stones in non-standardized shapes and were just trying to fit things together. I'm not native English speaker, so I first heard this term from the games.
There's no gravity here, so the comparison makes no sense. In walls masonry construction produces sheer lines horizontally, an axis gravity is not bearing upon. This feels like taking the metaphor just a tad too literally.
I didn't think so, of you look at old stone walls, there's an absence of continuous horizontal or vertical patterns. (However the discussion was a fork, about wall building, so it was quite literal)
"Dry stack" is another term for that, a stone wall without mortar.
In my opinion, thinking of this as a grid is misguided. It's barely different than flex columns. I would want to be able to have some objects take up more width than one column, or not have clean columns at all. Like "space filling" and "mosaic".
I think this is just transposed masonry, the wall looks ok if gravity is on the left. "Transposed" is redundant though, since I assume it will work in both grid-template-columns and grid-template-rows
Sounds plenty plant-based to me. Why conflate plant-based with healthy? Plenty of people, myself included, have turned to meat-alternatives to reduce our environmental impact. I am under no illusions that it is healthy for me!
You can fry potatoes in a vat of vegetable oil, or you can cook skinless chicken breast in boiling water. Using plant content as a proxy for health makes no sense.
