For e-mail addresses as an authentication tool, you don't really need to be able to send emails at all, just receive them, and I think that is pretty feasible to not run afoul of the usual shenanigans.
My favourite feature of this video is that he uses the "Network Block Device Kit" to make a kit of 3 drives, each using one of those words as the main point:
"Network" storage, "Block" storage, and "Device" storage.
It is a popular design convention, there are even generators to convert regular screenshots into this angled and depth-of-field style. There are 2 important properties this convention has:
First, it makes it obvious that the UI being presented is not part of the website, but a screenshot, so people don't trying to mess with it like it's an interactive widget.
Second, it showcases a general feature without inviting scrutinising the details of the UI, which a general product page isn't the best place to do so anyways.
---
(Personally I do love a good software Screenshots page, but that can be a separate thing IMO)
Canvas would still be faster even if you used a full-screen box. Just the string concatenation overhead of doing this with box-shadows is insanely wasteful.
Which isn't to demerit the hackish creativity of taking one thing and running with it! But if you wanted to do a ball painting effect like that outside this "what if" context, it would be technically irresponsible to do it with box-shadows.
Sure it is, it's the first thing to be said just after the title and widgets
> This article is about aliasing in signal processing, including computer graphics.
In computer graphics, the relevant aliasing is spatial aliasing, in fact mentioned in the article: the signal is the fundamental shape (such as a font glyph or a triangle mesh or whatever), and the samples are the pixels.
In the specific application of a waveform, a typical "CD quality" audio file has 44.1 thousand samples per second, and say, 16 bits per sample. If we want to display the waveform of one second of audio horizontally on an entire standard low-density full HD computer screen, we have 1920 samples to fit our 1 second of audio data, and 1080 samples of amplitude with which to paint the amplitude.
Putting it into signal processing terms, The signal frequency here is 44.1Khz, and the sampling frequency is 1.92Khz. Do you see how aliasing applies now? We want to represent f_Signal / f_Sample = 22.96875 samples of audio with 1 sample.
In practice you get an even worse ratio, because we usually want more than 1 second of waveform to be visible on a region that isn't the entire screen.
These are the same thing. A shape with a solid boundary is a a signal with a discontinuous step: If you Fourier it, it has infinite nonzero terms, therefore you can't represent it exactly with any finite amount of frequencies, and therefore a finite amount of samples.
In the case of Moiré patterns in pictures, we have lines in the real world that need to fit into pixels that fit a larger area than the Nyquist rate of those lines. The Moiré effect in pictures is just the interference pattern caused by this aliasing.
If you look at just a column of the image, and imagine the signal as being the brightness varying over the Y coordinates, you can imagine the mortar being an occasional regular pulse, and when your sampling rate (the pixel density) isn't enough, you get aliasing: you skip over, or overrepresent, the mortar to brick ratio, variably along the signal.
Now if you look at the graph in that picture, doesn't that look awfully similar to what happens if you try to sample an audio file at an inferior rate for display purposes?
In fact, try it right now, download Audacity, go to Generate>Tone, click OK with whatever settings it's fine, press Shift+Z to go down to sample level zoom, then start zooming out. Eventually, you'll see some interesting patterns, which are exactly the sort of aliasing caused by resampling I'm talking about:
How do we add more colours (besides just picking a random colour, which wouldn't be helpful)?
By sampling the signal more often ("multi-sample anti aliasing"), also known as increasing the resampling rate, then representing that with a wider bit depth (not just 1 bit "yes/no", but multiple bits forming a color/opacity), since we do have more than 1 bit per pixel that can be used already.
I'll give it to you that this is "anti aliasing", not "not having aliasing in the first place", but the Fourier argument above is the reason why in computer graphics we practically always have to "settle for" AA instead.
Not really at all, the type checker understands it is a field reference (it's just an alternative syntax after all, it is absolutely 0% difference in behaviour.
However, it's a common typed-javascript idiom to use string-indexing when you're probing a value of unknown type. Even Typescript has settings to accept this.
I get it it's a nice idiom. But neither version is an error and the "correct" version is more verbose. Less verbose is better in my preference when it is just as clear or even clearer (because it is less verbose). And this is not TypeScript but JavaScript.
I guess my question is, how can I make the
ob.something
NOT be (listed as) an error? When is it not an error (according to WebStorm linter)?
I don't think "unresolved variable" is listed as an actual error in plain JS in WebStorm? At least by default.
In any case, like any inspection, you can adjust its severity to whatever you find appropriate, including "don't show it at all".
File > Settings > Editor > Inspections > Javascript and Typescript > General > Unresolved reference.
Or directly from the "Show Context Actions" action (Alt+enter or whatever you have it set to, the same combination that shows refactoring actions), you can navigate the inspection like a submenu and select "Edit inspection profile setting".
It is not an error true but it shows in the list with a yellow icon. But that means my list of "problems" is huge (because I prefer the shorter version of the expression). I would like the problems-list to be empty.
The problem is the long list often hides real errors in it. I would like to spot those more easily.
But I'll try your suggestions, maybe there's a way to make this warning disappear altogether from the list.
I still don't think, and don't understand, why it is a "problem" since the equivalent longer expression is not. It feels like WebStorm is mandating its own JavaScript-rules on me and my programming style.
For (the vast majority of) games the player can be looking at anything on screen, not just a specific point.
In real life, eyes track objects in order to minimise blur.
But realtime motion-blur implementations just blur everything that moves relative to the camera, which is not correct, and makes the human looking at the screen lose track of the objects they were looking at.
If we had pervasive perfect low latency eye tracking then a game could pull off something that actually looks plausible, but that is not the case, so the only games that can get away with it are the ones that are largely a movie and can take advantage of the motion blur cinematographically.
