HN user

vogtb

171 karma

benjvogt at g mail dot com

https://vogt.world/

Posts6
Comments26
View on HN

I lived in Chicago for about a decade, and around 2017 to 2023 I set a goal of biking to every one of the 76(?) neighborhoods. I made it to about 63. There are definitely neighborhoods rougher than others. But tbh every neighborhood has good food, and, you know, normal people living there. Like, in Garfield park I remember buying ribs from a guy that was just sorta cooking them outa the back of his truck. They were terrific. Pilsen has great Mexican food, and Devon has nuts Indian food (Ghareeb Narwaz is by far my favorite). Yeah, in some neighborhoods, on a couple of blocks there are guys out on the corner selling. But no one's bothering anyone. There's nowhere you can't go on a Saturday at 1PM. Basically, what I'm saying is, the Chicago you see on the news isn't the one I live in. So, you know, keep your wits about you, take care, but I think everyone in Chicago should go to a random neighborhood and get some food.

Neat! Having literally everything backed by object storage is The Dream, so this makes a lot of sense. So to compare this to the options that are available (that aren't Kafka or Redis streams) I can imagine you could take these items that you're writing to a stream, batch them and write them into some sort of S3-backed data lake. Something like Delta Lake. And then query them using I don't know DuckDB or whatever your OLAP SQL thing is. Or you could what develop your own S3 schema that that's just saving these items to batched objects as they come in. So then part what S2 is saving you from is having to write your own acknowledgement system/protocol for batching these items, and the corresponding read ("consume") queries? Cool!

Exe.dev 7 months ago

Val.town seems to be serverless, where as this is explicitly a server. One is really a subset of the other though, so I suppose if you're deploying ts functions to a service/server, and your execution costs match up with the tiers here, exe.dev could be cheaper.

Exe.dev 7 months ago

Oh, we're doing Fly again? Cool! I don't mean that sarcastically -- making it dead simple to get a VM at a domain or IP in a few seconds is good and useful. We should keep trying this idea, because every time it gets easier.

On a side note, a lot of people in this thread are doing a sort of "I don't get it, your website sucks" but it's like, come on dude! Just read the site! It takes less time to read the pricing, docs, and FAQ than it does to post about how you don't get it.

This is super true. Whenever I find myself struggling w/ flexbox it helps to take a step back and solve it one step at a time. Working my way out-to-in, parent-to-child element, and it becomes so much easier. There's a skill to it, but it's basically just elastic algebra.

This is rock solid. I keep a plaintext file with all my daily notes in it, but still find myself formatting code before/after dropping it in. The formatting feature alone is a draw here. The math part is great as well - I use a REPL all the time just to do napkin math.

+1 for pgtap. Surprised it's not been mentioned more in this thread.

I'm using it w/ supabase, and it works really well.

They have a small doc on it that's a better primer than the pgtap docs: <https://supabase.com/docs/guides/database/extensions/pgtap>.

Pretty easy to get started, I'm doing something like this in a Makefile.

  supabase_tests := $(call rfind, supabase/tests/*_tests.sql)
  DB_URL := "postgresql://postgres:postgres@localhost:54322/postgres"
  test-supabase: $(supabase_tests)
    @echo "Testing supabase..." && \
        echo "${supabase_tests}" && \
        psql -f supabase/tests/setup.sql ${DB_URL} && \
        $(foreach t,$(supabase_tests),\
            echo "Test: $(t)..." && psql -f $(t) ${DB_URL} $(__EXEC)) && \
        psql -f supabase/tests/teardown.sql ${DB_URL}

I think that no-code and low-code a real movements, and are going to be popular. But the terms are too broad to have a productive discussion about what their power really is.

Are all tools with programmatic capabilities low-code? Where do we draw the line? Or is this just a new paradigm, and eventually all platforms/tools/products/SaaS-companies are low/no-code? It seems like there's room for distinction here.

Having looked into a couple of these, it seems like they each have their own sort of focus, which makes sense. From my own experience, and talking to other engineers, companies use kafka for: an http replacement that lets subscribers have down time, a way to record and replay time series data, a tool for buffering to some async path, or general pub-sub event bus. Sometimes all of these at once! Each one has it's only operational patterns, so having UIs that focus on these patterns sorta clicks with me.

That said, it's been a while since kafka gained popularity, so it's surprising we've not seen any coalesce into a main contender.

A company I used to work for a few years ago did it pretty well.

To begin with, we agreed on who is asking questions if there were multiple rounds for the interview. If I recall correctly, it was just a straight up spreadsheet with the people interviewing, questions to ask, goal of questions, and possible follow ups. These are questions tailored to the engineer using things on their resume. Instead of being like "tell me about a time you showed leadership" questions (which suck) the questions were about specific things on their resume. Eg: "Susan will ask about how they built a replacement for their payment processing platform, with the goal of seeing if they can describe the challenges of leading a team end-to-end on a project."

For the white-board interviews, we did mock white-board interviews with my current coworkers. These were white-board questions that were less about a "right" answer, and more about how the candidate thinks about problems. By doing mock interviews with these problems, we achieved two things: we made sure we're asking questions that are useful (our current coworkers should be able to answer them) and we made sure that had answers to compare against the candidate. For example, if the candidate had an answer that sounded a lot like someone that we already worked with, then no one can say they "didn't pass" the question.

On the whole I think we spent about a 1:1 ratio of hours of preparation to hours of interviewing.

David Reich's "Who We Are And How We Got Here: ancient DNA and the new science of human past" covers it a bit, but only for the first couple of chapters. It's focused on genetics as well, and is a little technical but he looks at migration patterns of ancient human beings as a way to figure out where they lived and how they interacted with other human sub-species. Still a good read though!

A History of Visa 7 years ago

It's interesting (and great!) to see this level of research and attention to detail in a blog. Do you mind if I ask why? Are you gathering potential users for a product, service, or startup in this space?

I have a habit of taking notes on these types of talks when I stumble upon them, so for anyone interested, here's a quick write up of the video. Some of it is paraphrased,.

* "[Microsoft estimates that 750M users of Excel. (%7 of the world population).]"

* Spreadsheet errors basically ruined the economy of Greece.

* "State of the art" is manually double checking your formulas. This is what the experts suggest…

* There's apparently an article out there from Forbes titled "Sorry, Your Spreadsheet Has Errors (Almost 90% Do)".

* Thomas Herndon is the guy that did manual spreadsheet verification to prove that there were errors.

* Talks about CheckCell, ExceLint.

* Input errors are a huge problem: "Roughly 1% of characters people mistype."

* "[1 out of 20 cells manually typed probably has an error.]" (Woah.)

* "[Users often add a digit or remove a digit, changing the order of magnitude]"

* 1) Manual data entry is hard to do correctly, 2) Writing formulas/code/Excel that uses that data is also hard to do correctly.

* One take away: Like code, if you're not testing it manually, and no one is testing it for you manually, and you're not writing tests, and the results aren't "gut-checked" or the results aren't used, why would it be correct? If a tree falls…

* "[A lot of public posted Excel sheets are filled with errors, or fudging.]" Look at the grades one that he shows around 19:36 to see what I mean.

* "The Bootstrap" - stats analysis using simulations. "[Resample samples]... random sample with replacement, repeatedly, to get distribution of output of calculation." Requires a homogenous range. Allows you to find "outliers" that drastically change the output. "What is the likelihood of observing one of the simulations under the null hypothesis, and if it's below [X] then we say it's unusual." Dude in audience at 30:29 describes it well.

* Formulas are easier to audit because they're usually named w/ column, etc. Data is hard.

* Goes through a long process of describing how they gather data, etc. Good stuff, but the short and the long of it is CheckCell is good.

* Loops back around to the global finance sheet that had a lot of errors: CheckCell worked on it.

* ExceLint - static analysis, ranks errors and their fixes. Can find off-by-one-like errors. Formulas using off-by-one ranges, etc.Excel has its own error finder, but it gives a lot of false positives and false negatives."Most errors are reference errors" - wrong row, wrong column, too short a range, too long a range, etc. "Looks for disruptions in rectangular regions." Not just outliers. Looking for irregularity, where regularity is basically low entropy. "[Capture the relationship of cells/ranges and their relationship to one another.]" Looking for relationships that minimize entropy ("[Because users aren't insane and they're putting things in a rectangular grid.]" Looks for every rectangle (i.e. range) that when merged with a neighbor, would remain rectangular. That is considered a potential fix. Then you can simulate the fix as if you already did it, and check the entropy on that.

* A lot of the errors, and their origins have to do with basic Excel features. Some of these features were outlined as best practices in Joel's "You suck at Excel" talk, which is kinda funny. Great power, Uncle Ben, etc.

* Dropped this one: "SUM is [something like 45% of formulas]".

(edit: spacing out list)

This is really cool! Back in college I used the Kinect dev kit to build proof-of-concept special effects for live theatre as an independent study project. I used the Kinect pointed at the face of an actor off stage, ran the resulting 3D data points to some cool algorithms, and then projected the result onto a screen on stage. The idea was that, for example, in Hamlet instead of having an actor in make up play the ghost of King Hamlet, you could have this larger-than-life projection on stage.

This camera is way better quality, so it'l be neat to see the sort of projects can be done now.

Nice, that sounds ideal! I've always found it frustrating to use the AWS console for anything other than dashboards and one-off trouble shooting.

You don't ever have issues with teams not applying resource changes? I.e. contributor A adds a resource, but doesn't apply it, and then contributor B goes to apply their changes and sees unexpected resource changes that they potentially don't have the permission to create? I guess that would be as much of a cross-team problem as a technical one.

S2 Geometry 8 years ago

I was playing around with s2 a year or two ago, and it was surprisingly difficult to find information on it, so FWIW here are some links I was able to find at the time if you're looking for some historical reading on s2:

Google Presentation on S2: https://docs.google.com/presentation/d/1Hl4KapfAENAOf4gv-pSn...

Christian Perone's blog post on it: http://blog.christianperone.com/2015/08/googles-s2-geometry-...

Google Code Archive: https://code.google.com/archive/p/s2-geometry-library/

Java Implementation: https://github.com/rschreijer/s2-geometry-library-java

A couple of days late, but you can solve this by recording changes rather than objects themselves.

So you log the timestamp of the status changes with the "id" of element you're changing. Then you when an object goes from one status to another, you can record a concat of the id and old timestamp to the "remove" hyperloglog for the previous status, and then record the concat of the id and the new timestamp to the "add" hyperloglog for the current state.

Say you object A at time=1 is being recorded as "At=1" for status R. If it moves to status Q at time=2, you record "At=1" to the hyperloglog for your status R "removes", and then "At=2" for the status R hyperloglog. This works with objects changing status NOT more than once for however you're measuring time. If you're using milliseconds and the status changes infrequently, you're probably good.

The down side is this requires you to track changes rather than just iterate through your objects, so it might not be compatible with your architecture. You also would have to iterate through all objects to capture their initial status. It also is susceptible to errors increasing over time, as your "add" and "remove" hyperloglogs will record more and more elements (re: changes) over time.

This is terrific! I listened to it for about a half hour last night, and it was far more useful than I thought! One of the articles I had read earlier in the day, and your parser did a great job of using different voices for different people quoted in the article, which made the article flow in a way that's pretty close to real speech.

One of the articles, however, seemed to switch from voice to voice for no discerning reason. It might have been a medium article, where authors are more likely to stylize the text with bold, underline, italics, etc. That made it a bit confusing and difficult to follow.

For me, listening to any spoken word requires a little mental effort. For example, listening to an NPR podcast takes about 10%. Your app maybe took 20%. That's within a margin that, if you're able to smooth out your speech algorithms and tune the voice-choice algorithm, I could imagine this being as easy to listen to as a podcast.

So, on the whole, the voice-choice algorithm needs a little work, but other than that, I really like this!