gurgeous (u/gurgeous)

gurgeous commented on Ultrasonic Chef's Knife seattleultrasonics.com/... · Posted by u/hemloc_io

tptacek · 3 months ago

Does that video show him doing actual prep? I 100% believe he made a knife that can make a paper-thin slice of a lemon. But that's not what a chef's knife is for. As someone who thinks the world would be a better place if this product worked and was successful: for god's sake record someone processing an onion. That's what matters.

gurgeous · 3 months ago

In Rand's video he does an "old" lime, mozzarella, and a shallot. It's just a quick vid he did in like five minutes but it shows some prep. Rand is a prolific amateur chef...

https://www.linkedin.com/feed/update/urn:li:activity:7374472...

Disclaimer: I've enjoyed many delicious meals at Rand's table

gurgeous commented on Ultrasonic Chef's Knife seattleultrasonics.com/... · Posted by u/hemloc_io

gurgeous · 3 months ago

I personally watched Scott spend years working on the project and obsessively iterating on the steel, the vibration pattern, the circuitry, the handle, and the form factor. Scott is a hacker, one of us for sure. I mean, the guy built a custom robot just to measure cutting efficiency...

The knife is amazing and exactly as shown in the video. Rand Fishkin has a nice short on LinkedIn trying out the knife too. I think he shows one his (sharp) kitchen knives slicing through a lemon, then the Ultrasonic. It's astounding.

Disclaimer: I am a (tiny) angel investor in Seattle Ultrasonics.

gurgeous commented on First Ultrasonic Chef's Knife Vibrates 40,000X/Second for Easy Cutting cnet.com/home/kitchen-and... · Posted by u/randfish

gurgeous · 3 months ago

I have used this knife, I am an angel investor in Scott's company. The thing is legit amazing. He labored for years to bring this to market and it shows.

gurgeous commented on Rv, a new kind of Ruby management tool andre.arko.net/2025/08/25... · Posted by u/steveklabnik

gurgeous · 4 months ago

I am so excited about this!! Ruby tooling is already pretty good, but we can do better. I will try to contribute. Now we just need types

gurgeous commented on Show HN: I built a Ruby gem that handles memoization with a ttl github.com/mishalzaman/me... · Posted by u/hp_hovercraft84

gurgeous · 8 months ago

This is neat, thanks for posting. I am using memo_wise in my current project (TableTennis) in part because it allows memoization of module functions. This is a requirement for my library.

Anyway, I ended up with a hack like this, which works fine but didn't feel great.

   def some_method(arg)
     @_memo_wise[__method__].tap { _1.clear if _1.length > 100 }
     ...
   end
   memo_wise :some_method

gurgeous commented on Show HN: TableTennis, a new rubygem for printing stylish tables in your terminal github.com/gurgeous/table... · Posted by u/gurgeous

gurgeous · 8 months ago

This got some attention in r/ruby so I figured I'd post it here too..

TableTennis is a new gem for printing stylish tables in your terminal. We've used ad-hoc versions of this in our data projects for years, and I decided to bite the bullet and release it as a proper gem.

- auto-theme to pick light or dark based on your terminal background - auto-layout to fit your terminal window - auto-format floats and dates - auto-color numeric columns - titles, row numbers, zebra stripes...

By far the hardest part is detecting the terminal background color so we can pick light vs dark theme for the table. This requires putting the console into raw mode and sending some magic queries. These queries are widely supported but not universal. There are some great libraries for doing this in Go & Rust, but as far as I know nothing like it exists for Ruby. Check out the long comment at the bottom of this helper if you are curious:

https://github.com/gurgeous/table_tennis/blob/main/lib/table...

As always, feedback, feature requests and contributions are welcome.

gurgeous commented on Implementing a Game Boy emulator in Ruby sacckey.dev/posts/impleme... · Posted by u/Kerrick

gurgeous · a year ago

Love the play by play.

gurgeous commented on Show HN: Interactive systemd – a better way to work with systemd units isd-project.github.io/isd... · Posted by u/kai-tub

ripley12 · a year ago

This looks very good, thanks for sharing! I maintain a similar project and working with the systemd/dbus APIs has been pretty painful; eager to try this and see what I can learn from it.

https://github.com/rgwood/systemctl-tui

gurgeous · a year ago

This is incredible! I will use this a ton. Only thing missing is a deb package...

gurgeous commented on Just: Just a Command Runner just.systems/... · Posted by u/thunderbong

jdxcode · a year ago

(author of mise)

The biggest advantage just has is that it's been around longer, in mise tasks only came out of experimental like a month ago. mise tasks themselves are stable, but there are still experimental things and some portions that need to be used more—like windows. That said, most of the stuff that needs polish are features just doesn't even have.

I had a look at the top issues for just and pretty much all of them I've handled in mise: https://github.com/casey/just/issues?q=is%3Aissue+is%3Aopen+...

here's my unashamedly biased thoughts on why I like mise tasks compared to just:

* tool integration - this is the obvious benefit. If you run `mise run test` on CI or wherever it'll setup your toolchains and wire them up automatically

* parallel tasks - I saw this as table-stakes so it's been there since the very beginning

* flags+options - mise tasks are integrated with usage (https://usage.jdx.dev) which provides _very_ comprehensive CLI argument support. We're talking way more than things like flags and default options, as an example, you can even have mise tasks give you custom completion support so you can complete `mise run server --app=<tab><tab>`

* toml syntax - it's more verbose, but I think it's more obvious and easier to learn

* file sources/outputs - I suspect just doesn't want to implement this because it would make it more of a "build tool" and less of a "task runner". I chose to despite having the same position that mise tasks is also not a "build tool". Still, I think even in the world of running tasks you want to only run things if certain files changed often.

* `mise watch` - this is mostly just a simple wrapper around `watchexec -- mise run ...` for now, but it's an area of the codebase I plan to focus on sometime in the next few months. Still, even as a simple wrapper it's a nice convenience.

* "file tasks" - in mise you can define tasks just by being executable and in a directory like "./tasks". This is great for complex scripts since you don't also need to add them to mise.toml.

I have not used just very much, but I did go through the docs and there are a handful of things I like that it definitely does better:

* help customization - it looks like you can split tasks into separate sections which is nice, I don't have that

* invoking multiple recipes - I don't love how this is done in mise with `mise run task1 ::: task2` but I _also_ wanted to make it easy to pass arguments. At least for now, the ":::" won out in the design—but I don't like it. Probably too late to change it anyhow.

* [no-cd] flag - both just and mise run tasks in the directory they're defined, but I prefer how this is overridden in just vs mise.

* expression/substitutions - mise uses tera for templating, which is very flexible, but it requires a bit more verbosity. I like that in just you can just use backticks or reference vars with minimal syntax. Same thing with things like joining paths and coalescing. I have all of this, but the syntax is definitely more verbose in mise. Arguably though, mise's verbosity might be easier to read since it's more obvious what you're saying.

* confirmation - I love that in just you can just add `[confirm]` to get a confirmation dialog for the task. I'm sure we'll get around to this at some point, mise already has confirmation dialogs so it shouldn't be hard to add. The tricky part will be getting it to work right when running a bunch of stuff in parallel.

* task output - I haven't used just that much so I can't actually say that it's "better", but having more control over how tasks are output is definitely a weak part of mise right now and is in need of more functionality like in just how you can add/remove "@" to echo out the command that's running

I want to call out one very silly thing that from reading these github issues sounds crazy. It sounds like both just and taskfile have the same behavior with `.env` files. In just and taskfile, variables defined in .env are ignored if they're already defined. I don't think anyone would want that—nobody has asked for mise to behave that way—and it doesn't appear either tool even allows you to change it!

gurgeous · a year ago

Hi Jeff, thanks for creating mise! I am gearing up to migrate from asdf, very excited to check it out. Not totally sure we can adopt mise for tasks (we use just) but willing to give it a whirl. Putting run commands into toml sounds like it might be challenging, I wonder if there's syntactic sugar that would help.