HN user
Kubernetes isn’t a great example of you can just read it like a document. The resource kind jargon is huge.
Most compose files are small and use familiar linux jargon.
I can give an non-dev IT person a compose file and they can understand every key. I can’t do that with K8s or Quadlet.
I like to think most seniors know to not blindly follow DRY. However, I can tell many of us are uncomfortable with the idea of needing to maintain multiple duplicated sources of code.
To help with that, I think the simple model of two callers depending on a common code needs to be scrutinized. If the common code needs to change because only one of the caller needs it, then it doesn’t belong in the common.
The wrong goal for DRY is attempting to do it with encapsulation. Encapsulation shifts the refactoring work from the caller to the common code. However this is not what you want because there’s a lot more consequence in updating the common code than the caller.
You can avoid encapsulation and still be DRY by having multiple thin abstractions that the caller needs to be aware about is better. In OOP you are taught SRP and IoC for this. In procedural programming, this just comes naturally as code calling series of helper functions.
This assumes the bug exists in both places which might not be true at all even if they both are dependent on the same duplicated code.
If you only spot the bug in path A and not path B, why fix the bug for B?
You could still have security bumps happening (like dependabot).
GTD has the addition that you must create a system of reminders/followups. GTD is great to practice being okay with forgetting stuff and trusting your tracking system.
I think your argument focuses a lot on the scenario where you already have cleaned data (i.e., data warehouse). I and many other data engineers agree, you're better off with hosting it on SQL RDBMS.
However, before that, you need a lot of code to clean the data and raw data does not fit well into a structured RDBMS. Here you choose to either map your raw data into row view or a table view. You're now left with the choice of either inventing your own domain object (row view) or use a dataframe (table view).
We need long running averages and 2023-2025 is still too early to determine it's not effective. The barriers of entry for 2023 and 2024, I'd argue is too high for inexperienced developers to start churning software. For seasoned developers, the skepticism and company adoption wasn't there yet (and still isn't).
The data is surprising. However, I do wish this article looked carefully into barriers of entry as it can explain the lack of increases in your data.
For example, in Steam, it costs $100 to release a game. You may extend your game with what's called a DLC and that costs $0 to release. If I were to build shovelware with especially with AI-generated content, I'd more keen to make a single game with a bunch of DLC.
For game development, integration of AI into engines is another barrier. There aren't that many choices of engines that gives AI an interface to work with. The obvious interface is games that can be entirely build with code (e.g., pygame; even Godot is a big stretch)
You could either delete the .venv and recreate it or run `uv pip install --upgrade .`
Much prefer not thinking about venvs.
The autocorrelation is important to show that it's transformation to D-K plot will always give you the D-K affect for independent variables.
However, the focus on autocorrelation is not very illuminating. We can explain the behaviors found quite easily:
- If everyone's self-assessment score are (uniformally) random guesses, then the average self-assessment score for any quantile is 50%. Then of course those of lower quantile (less skilled) are overestimating.
- If self-assessment score vs actual score are dependent proportionally, then the average of each quantile is always at least it's quantile value. This is the D-K effect, which is weaker as the correlation grows.
-The opposite is true for disproportional relation.
So, the D-K plot is extremely sensitive to correlations and can easily over-exaggerate the weakest of correlations.
The more common experience with autocorrelations are with time series, but what the author said is correct even in that context. A time series autocorrelation relates the same time series function at different times. At the simplest you plot the arrays X vs X where X[i] = f(t[i]). You then may complicate it further by some transformation g(X) vs X (e.g., moving average).
Did you guys considered existing standards when you chose what to use for representing workflow definitions before choosing OpenFlow? For example, Common Workflow Language
Hover your mouse over those and you should get the absolute date. Some if not many are using time tags.
It's not popular because you're mostly hearing from the science community who want more features in their array (vector/matrix/tensors).
Why would you want to use C-like arrays in Python anyways?
It is not deprecated. Calling setup.py directly is (i.e., `python setup.py sdist`)
Modern way of building a package is to use a build frontend. Most notably is the PyPA's build package.
python -m build .
In this particular case. OP had a lot of knowledge which served as a crutch in this journey. The less you are aware of how setuptools used to work, the better.
Here's a packaging guide that answers most of your questions.
https://learn.scientific-python.org/development/guides/packa...
As a TLDR, you have many options 3rd party build tool (aka build backends). Each build tool have different *static* ways to specify compile options that is native to the language or generic (e.g., CMakeList,s Cargo.toml, 3rd party YAML. When it comes to dynamically specifying your extensions, setuptools is still the only option.
In diataxis, a tutorial serves your education and a how-to guide serves your work.
Following this standard, a tutorial may contain a simpler or more contrived example; it may contain things you'd never do in production.
Why? What's your goal visiting the W3C homepage?
It should be to learn who they are and what else the website provides. You're not there to read it's entire homepage. You're there to navigate.
The pages that need to be dense, like the standards document, are.
It works on HN for at least the reason that HN post titles are often relatable. The same can't be said about paper titles even if you're in the field.
The design is horrible and a relic of skewmorphism.
Single tally memory is useful on small screens. I just wish they’d display the stored value somewhere.
I'm way off. I meant 15A. Now I've no clue what the journalist is calculating.
I think the journalist is calculating load capacity. A 1500A @120V kettle requires 0.18 MW. Rounding up, 60 kettles requires 12 MW. It's not how much water you can boil, it's how many kettles you can run at the same time.
Yes you're right, every superposition of quantum systems have a real valued probability distribution for some observable variable.
QM has very specific rules when it comes to how two random variables are dependent. That specific rule comes up when you have quantum interference and this is best described by the conjugate square of two complex functions A^2 + B^2 + A*B + B*A. This is just a special case of the union probability: P(A) + P(B) - P(AB).
Not to mention in terms of making money, you would be far better off in the industry than spending 6 years in hopes of getting a tenure.
That's true for most technical fields in academia. A physics degree can land you a well paid job as a data analyst/scientist or in quantitative finance.
Just don't forget, this does not mean you don't have deadlines. On top of deadlines, you have the cultural pressure of publishing.
What about credit card rewards that are high in certain types of store (e.g., 6% cash back on groceries)? I don't see how this is more than the consumer getting a product 6% less than what they would initially pay.
At no point do I want pretty visualisations made by wannbe PhD candidates
See Figure (5). Your argument doesn't really counter any part of the scientific notebook. A notebook will still have the abstract and conclusion (result & discussion). The tools mentioned in the article describes how to restructure the methods, data, and figures. You're note going to look at these anyways until the abstract and conclusion intrigues you.
Certain scientific software packages (e.g., Tensorflow, pymc3, etc) do have frameworks that you follow to return pipeline and result objects that follow some data model that others can learn quickly (e.g., an arviz::InferenceData result object). I wish there was a more extensive framework where this is applied end-to-end from data input, to library components in a pipeline processes, to the result, and then to plot.
Look into Dask if you are attempting to process an entire data table that's larger than memory.
For your last paragraph, you're conflating the need to share code with the need to build a robust scalable service. Most research code are only needed for the paper and rarely touched again.