This is a major reason why `let` was introduced.
Variable declarations with `var` should be avoided, linters commonly reject such code.
1,834 karma · joined March 22, 2012
https://zxcv.art
Variable declarations with `var` should be avoided, linters commonly reject such code.
It does affect your conclusions though.
The choice of null hypothesis in "The DK Effect is Autocorrelation" determined how the random data was generated. The hypothesis is: "nobody has any clue whatsoever how competent they are". The random data was specifically crafted for that hypothesis.
The choice of null hypothesis in this article is: "everyone roughly knows how competent they are". This random data, too, is specifically crafted for the null hypothesis.
So what does this mean? If you pick the a particular null hypothesis then you can try to argue that the DK is a statistical artefact. But it's not, it is an artefact of choosing a particular null hypothesis.
There are valid criticisms of the DK study, though. See this comment for example: https://news.ycombinator.com/item?id=31119196
* It encourages JSX-specific idioms. Outside of JSX, using `&&` instead of `if` for control flow would raise eyebrows from most people, I think.
* I find it easier and faster to refactor `if` statements to `if/else` and vice versa (only requires addition or deletion of code) than to refactor `&&` to a ternary operator and vice versa (also requires modifying existing code).
* Multiple nested ternary operators almost immediately become a mess, while a series of `else if` expressions (if such a thing existed) seem perfectly readable.
{if (gallery.length) {
<Gallery slides={gallery}>
}}
In particular, do not rely on news media that aim to be _the first_ to report. Being first comes at the cost of being thorough and balanced.
A small number of global breakpoints can be a better trade-off when it means the website works better (for most people).
2) It is at least an order of magnitude slower than not using a database at all.
Combined this makes for very slow tests. Certainly for larger applications with thousands of tests.
Having said that, I don't think there is a single right answer to the problem of testing applications that use a database and your suggestion still can be a valid solution.
Also, they probably copied the design from Netlify [1] to improve compatibility and therefore make it easier for people to migrate from Netlify.
[1] https://docs.netlify.com/routing/redirects/#syntax-for-the-r...
I have found Cloudflare Pages to be really, really fast. Much faster than Netlify, although they still win based on UI polish & features.
It's not mentioned at all in the article though, which I found surprising. My first reaction was that I don't think storage is the only problem, maybe not even the most difficult problem.
Who is going to be able to view a JPEG file 500 years from now? It requires not only the data, but also all the software infrastructure to be able to interpret this data. To me it seems a stretch that all software required to view it is still usable in a century, let alone 5 centuries.
So even if you keep these home pages around "forever", it seems unlikely to me that anyone wants to invest time in transcoding everything when the world moves on to different storage formats. So what you end up might be little more than a bag of bytes? Though I guess the textual content within the HTML still has some chance of still being readable.
It will be fun times for Internet Historians in 2496 when they try to compile the historical copies of gcc, cmake, nasm and libjpeg.
The problem is that many things a developer considers tools (as in: "the best tool for the job") are actually components.
The equivalent of a woodworker's tool for a software developer would be an editor. Only you or your team might care about which particular brand of sawing machine or editor you use. And they are not an integral part of the end result.
A component for a woodworker would be a hinge or drawer rails. You would probably not appreciate it if your woodworker uses hinges that they made themselves. They are not worth the time to build. They're probably not very reliable. And if they fail they might not be easily replaced or repaired except by the person that made them. So you would only use custom components if the part you need is otherwise unavailable or does not meet specific needs.
Are you a woodworker and making a cabinet for yourself? Go ahead and make your own hinges, but for paid projects you probably should rely on standard components as much as possible; only doing custom woodwork or software engineering where it adds value.
Setting up a monitor socket allows you to observe pretty much any event you could care about, like peer connect/disconnect/errors, etc.
There is also a draft feature to access the number of queued incoming/outgoing messages (see https://github.com/zeromq/libzmq/blob/master/doc/zmq_socket_... for details).
You seem to implying only applications with huge numbers of users can be profitable. This statement ignores a tremendous amount of (typically B2B) applications that provide enormous value for their users but don't see a lot of traffic.
I have worked on applications that are at the core of profitable businesses yet they can go days, in some cases weeks without any usage. Serverless architecture will be a real benefit there once it matures.
There are no alternate versions of the dashcam available. However, there are comparisons of the same location made by other drivers that make it pretty clear this is a fairly well-lit stretch of road. [1] It looks nothing like the released Uber footage.
[1]: https://arstechnica.com/cars/2018/03/police-chief-said-uber-...
Yes, "returning" is problematic, because that has a very specific meaning in the context of a function call. But even if we forgive the author the inaccurate terminology, it is also an incorrect statement. You can evaluate an expression. But in C in particular, an expression does not necessarily evaluate to a value.
A somewhat better statement might be:
"Expressions can be evaluated. Some expressions produce a result value."
This statement can probably further improved upon; it definitely still does not capture everything that expressions are in C: such as being able to cause side-effects! That might not be evident, but can certainly be important. But then again, I am not writing a book about C.
> “A pointer is a special variable that returns the address of a memory location.”
Indeed "returning" is problematic here. A pointer does not return anything, it points to something.
> Somehow I feel this was written with an air of superiority, the author doesn't expand on anything. I get that feeling a lot with articles about c
If you're going to write a book about C in order to teach programmers how to work with pointers, better explain things with the correct terminology.
If this were a journal, then of course you can forgive the inaccuracies. But it's a published book that supposedly teaches certain concepts to readers. The author of the blog post says as much in their notes:
"This provides some insight into the mind of the author: he's just picking up concepts and terms as he learns about them and tossing them in without any regard for the reader. This book is pretty much his journal — that somehow became a book with two editions."
> the author doesn't expand on anything
The author expands on a lot more than I would have the patience for; see the notes [0]. Why certain things are incorrect, misleading or dangerous does require some C knowledge. The article + notes won't be a place to learn more about C; but neither is the book that's being reviewed.
An ad hominem attack surely isn't needed.
1) incorrect if UTF-8-strings are supposed to be valid input, or
2) very inefficient if only ASCII-strings are supposed to be valid input.
I am confused by the implementations, although I have not spent any time testing them. Both versions contain a mix of code that counts bytes (`.len()` and `len(...)`) and Unicode code points (`chars()` and `[]rune(...)`). My guess is that the implementation might not work correctly for certain non-ASCII strings, but I have not verified this.
Of course, if only ASCII strings are valid as input for this implementation then both versions will be a lot faster if they exclusively operate on bytes instead.
Resist the temptation to use commas or dots as thousand-separators. Seeing a number with a dot as a decimal separator instead of a comma will be fine for most people (even if proper localisation would mean using a comma), but if you throw in commas that mean something else you WILL confuse people. And I imagine the inverse is also true.
The only way to make that happen is to stop using Chrome and tell others to do the same.