I opened this on a mobile device, and it only shows the top and bottom topic buttons. I was pretty confused until I tried turning on "desktop site" in Chrome and saw the left/right buttons.
Having only a linear track of topics kind of undermines the overall idea!
If you don't mind a baking soda toothpaste, then another option is Trader Joe's. They made a baking soda & fluoride toothpaste that is SLS free. Been using it for a number of years now... Though it's been briefly discontinued and is slated to be back later this year.
> here are the empirical distribution functions (ECDFs) with 30ms added to each response time
> The added constant seems artificial, but it's just viewing the results from the point of view of a client with 30ms ping time. Otherwise the log scaled x-axis would overemphasize the importance of a few milliseconds at the low end.
I thought this was interesting - maybe it's a standard practice I was just unaware of but it seems like a smart trick.
Yes and no. When trying to show quantitative data in terms of areas or angles, then you are spot-on: same issues. But these plots, or chord diagrams more generally, are often used to show relationships (like translocations, inversions or duplications in genomes) in context of other landmarks. This use is common and less troublesome. A real problem with Circos plots is that it's so tempting to keep adding additional tracks of "information" that plots get ridiculous. It becomes like staring at the Voynich manuscript: uninterpretable but so compellingly pretty it must mean something.
They aren’t good at measuring small quantities. But it is easy to see 1/4 or 1/2 of a circle. And it is easy to see if something is a straight line, 90 degree, or a little more or less than either of those.
Compared to a bar graph, it seems a little easier to spot that one quantity is, like, half of another. And it is easier to visually sum of a collection of quantities, on a bar graph this is a major pain (unless it is stacked of course but that’s another type of graph).
The tone is entertaining, but some of the snarkiness around the code is bit frustrating at times. e.g.
> # do i really need to say I'm not serious about this?
Can you just come out and say what you mean here? Like, presumably it's bad, insecure code, but can't you just spell it out for the benefit of your audience?
I'm probably being really picky here - just find this kind of developer in-crowd signalling to be really irritating and counterproductive.
The Python code here is essentially just pseudocode. In reality, if you build a Python Macaroon implementation, you'd pull in pyca/cryptography and use an actual AEAD, rather than rolling your own authenticated cipher out of pure HMAC. But the point is that this isn't real code, just enough to make the concepts concrete.
Yes, you articulated what I think often when I read a tpt post. Enjoy the casual writing but feel like I’m frequently left out of the joke.
I understand all these concepts in general but looking at a block of code… I’m supposed to 1) know if it’s serious/not and 2) he’s being sarcastic about it not.
I even know Python well but the whole post is so “inside baseball” am not sure what to think. Guessing the bulk of the audience is not grizzled security engineers.
(I’d recommend another summary/details tag to put the grandparent explanation directly into the fly post.)
I read your related piece a few years ago but apparently didn’t retain much, due to not using it every day. Knowledge went out to backup tape.
So, come to yesterday’s piece. I remember the abbev. HMAC but have to look it up. Didn’t get the use case. No idea what attenuation meant in this context… thought of sound and plowed ahead. Gave up by the middle of the piece, lost.
But, then saw the link to the old piece, and read it top to bottom. Ok, now I get it! Reread and got the second piece. Understand finally but still not entirely clear why you were dissing your work.
Read another related piece on why json and xml are discredited for this kind of work.
Often upfront in a piece the author will say read this first, define some jargon, and “why’s”. (The why is often what I care about most.) These go well with the details/summary tags. Well, looks like you used a button for that but same idea.
Experienced dev here but haven’t just spent two years building an iam system. Slightly more acknowledgment of that upfront would work wonders.
The only unserious code in this post, for what it's worth, is a couple functions that make an authenticated stream cipher out of HMAC, because the Python standard library doesn't have an encryption function that I could find.
Ok, don’t believe there’s full encryption because it changes often and better to let the community experts handle. (Besides the ancient crypt module.)
But the recent secrets module might have some building blocks you could use.
This whole thread reminds me of a Hollywood sequel—need to spend ten minutes regurgitating the backstory to an audience who maybe saw the movie two years ago.
I can always appreciate that these types of stripped-down examples are merely for illustrative, conceptual purposes...but the ignoramus in me would also appreciate links to fleshed-out examples that take into account the shortcomings of the simpler example.
I studied that code and the comment for a good 10 minutes. As far as I can tell it just obfuscates, and is not actually implementing authenticated encryption. It would help to just come out and say that part out loud.
I once inherited a codebase that did this, and it was a nightmare to learn. All the classes were named after types of alcohol for some reason.
Naming things clearly is really hard, but this approach is just giving up completely.
It needs the right balance. 95%+ of classes absolutely should not do this, but it's great for the handful of times when a class is complex, nuanced, and used prolifically.
Assuming good documentation, it just means a few extra minutes learning what some terms mean, and that's worth it in the long run in my experience.
> the handful of times when a class is complex, nuanced, and used prolifically
Is there a way to describe an example of such a class? That sounds like it could have a proper descriptive name, it'd just be a bit harder to come up with.
Here is an unoptimized example, built on an M1 Mac:
$ cat <<EOF > Dockerfile
FROM python:3.12-slim-bookworm
RUN apt-get update && apt-get install -y python3-pip
RUN pip install pandas
LABEL "name"="python-pandas"
ENTRYPOINT ["python3"]
EOF
$ docker image ls -f 'label'='name'='python-pandas'
REPOSITORY TAG IMAGE ID CREATED SIZE
sgarland/python-pandas latest 89e31f6eb83d 9 minutes ago 764MB
A more optimized version:
$ cat <<EOF > Dockerfile
FROM python:3.12-slim-bookworm
RUN apt-get update && \
apt-get install -y --no-install-recommends python3-pip && \
pip install pandas && \
apt-get purge -y --autoremove python3-pip && \
rm -rf /var/lib/apt/lists/*
LABEL "name"="python-pandas"
ENTRYPOINT ["python3"]
$ docker image ls -f 'label'='name'='python-pandas'
REPOSITORY TAG IMAGE ID CREATED SIZE
sgarland/python-pandas smaller 102308842b88 4 seconds ago 342MB
sgarland/python-pandas latest 89e31f6eb83d 27 minutes ago 764MB
Even adding in scipy didn't crack 500 MB:
$ docker image ls -f 'label'='name'='python-pandas'
REPOSITORY TAG IMAGE ID CREATED SIZE
sgarland/python-pandas scipy 808535284f03 3 minutes ago 497MB
sgarland/python-pandas smaller 102308842b88 9 minutes ago 342MB
sgarland/python-pandas latest 89e31f6eb83d 36 minutes ago 764MB
I'm not sure how they managed 10 GB. Here's the non-slim version, with no optimizations (this is much larger because `python3-pip` has the system default Python interpreter as as dependency, so this installs Python3.11 into the image):
$ cat <<EOF > Dockerfile
FROM python:3.12-bookworm
RUN apt-get update
RUN apt-get install -y python3-pip
RUN pip install pandas scipy
LABEL "name"="python-pandas"
ENTRYPOINT ["python3"]
EOF
$ docker image ls -f 'label'='name'='python-pandas'
REPOSITORY TAG IMAGE ID CREATED SIZE
sgarland/python-pandas bigger f8f98e9a241c 8 seconds ago 1.44GB
sgarland/python-pandas scipy 808535284f03 3 minutes ago 497MB
sgarland/python-pandas smaller 102308842b88 9 minutes ago 342MB
sgarland/python-pandas latest 89e31f6eb83d 36 minutes ago 764MB
Interesting that most of the top comments here seem to be about the day to day process of estimation itself, when the linked article is about how poorly the research on estimation has been done to date. Did any of you actually read the article?
Glad I am not the only one who noticed this, thought I was reading the wrong thread. Software engineering research is something I was interested in a long time ago, so hoped for a better, more on-topic discussion.
