HackerLangs
TopNewTrendsCommentsPastAskShowJobs

switz

no profile record

Submissions

Cloudflare forked just-bash and they really, really should not have

twitter.com
10 points·by switz·4 bulan yang lalu·3 comments

Show HN: Gapless.js – gapless web audio playback

github.com
35 points·by switz·4 bulan yang lalu·11 comments

TLDraw plans to move their tests to a closed-source repo

github.com
6 points·by switz·5 bulan yang lalu·1 comments

Tests Are the New Moat

saewitz.com
7 points·by switz·5 bulan yang lalu·0 comments

Ukranian controls Home Assistant over LoRa radio when their power grid goes down

old.reddit.com
99 points·by switz·5 bulan yang lalu·10 comments

Turning Your Robot Vacuum into a Mesh VPN

saewitz.com
2 points·by switz·5 bulan yang lalu·0 comments

Show HN: Box of Rain - Auto-Layouted ASCII Diagrams

github.com
24 points·by switz·5 bulan yang lalu·14 comments

[untitled]

1 points·by switz·7 bulan yang lalu·0 comments

Parallel and Recursive Route Rendering

twofoldframework.com
3 points·by switz·10 bulan yang lalu·0 comments

comments

switz
·24 hari yang lalu·discuss
I do this. The awkward thing is when I am in person or on the phone and have to explain that my customer email address is [their_business_name]@my_weird_domain.tld

But the people usually just nod along.

The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).
switz
·bulan lalu·discuss
Can someone explain to me if EU card transactions are capped, why Stripe charges me (US) the full ride on my EU customer's cards? In fact, I get charged even more for EU cards – perhaps as much as 2.5% extra.

I just checked and I get charged ~8% in fees on a 10 euro transaction on Stripe. Of course some of that is the low transaction amount (flat 0.30), but it's brutal for a small business like myself.

    2.9% + 1.5% (intl card) + 1% (currency conversion) + 0.30

    Payment amount (€1.00 EUR = $1.15253 USD)
 
    €10.00 EUR -> $11.53 USD

    Fees

    Total:    - $0.93 USD

    Stripe currency conversion fee 
    - $0.12 USD

    Stripe processing fees
    - $0.81 USD

    Net amount
    $10.60 USD
I guess the NA interchange is charging the card, rather than the EU? Could using a MOR reduce the fee structure?
switz
·2 bulan yang lalu·discuss
I personally don't agree, and my experience is that RSCs embrace the inherent complexity of building websites. All websites span the server and the client to some extent. Giving you the tools to wield those boundaries is actually a bid for developer autonomy and flexible control over user experience.

It is complex because the domain is complex. Though it requires a deep understanding of the web as a platform, most high-level websites could net-benefit from the ideas behind RSCs. I don't find it to be quite as much of a footgun as most people would suggest, but if you don't understand both server and client in a deep manner it is, of course, confusing.

Happy to dig in deeper for anyone who wants to have an honest discussion about the benefits and drawbacks without dropping into FUD. Even if you decide it's not for you, all web developers could glean something from their model.

It's also always worth noting that RSCs don't require a server, and still bring value without one.
switz
·2 bulan yang lalu·discuss
It's a shame that VCs have corrupted a $200MM/year business into the perception as a failure. Who cares if the VCs didn't get a large return, or if the outsized impact of the software didn't quite fully capture the value created. $200MM/yr without aggressive R&D or operational costs could be an incredibly healthy business.

Maybe we should stop trying to build so many billion dollar/year businesses and work on more sustainable models.
switz
·2 bulan yang lalu·discuss
Please do not wash your authentic writing through an LLM.
switz
·3 bulan yang lalu·discuss
Workers runtime is open source and permissively licensed fwiw

https://github.com/cloudflare/workerd
switz
·3 bulan yang lalu·discuss
Though this would be mildly annoying for the earnest case (selling a ticket to a friend), it would be the actual solve to the problem.

The parent's suggestion still creates artificial scarcity, which is the real issue: people buying tickets they have no intention of using.

The problem is that the artists, venues, and ticketing companies benefit from this artificial scarcity. So we'll never see it change.
switz
·3 bulan yang lalu·discuss
It's really up to the artists. Many are surprisingly cool with it, though there are a few notable exceptions (i.e. Prince). Sounds like the artist in this particlar case gave their blessing.

Many bands (like GD and Phish) specifically note in their rider that venues must allow and provide space for tapers to bring their rigs in.

A sibling comment in this thread pointed out my project Relisten[0], which now has over 4,000 bands who have given explicit permission for people to tape, record, and share their concerts non-commercially. We've been operating our FOSS platform for 12 years, and most of the audio is hosted by Archive.org. I can't tell you how many bands have begged us to add them to our platform.

[0] https://relisten.net (https://github.com/RelistenNet)

(The 4,000 number will be coming to web soon - it's available today on our mobile apps)
switz
·3 bulan yang lalu·discuss
Oh hey, it's me! Happy to answer any questions

We landed an update on mobile last week that brought all 4,000 artists with a "collection" onto Relisten. That'll be coming to the web and sonos shortly as well.

We've been discussing the Aadam Jacob's collection with the archivists for some time. It comes with its own unique UX[0] and data constraints so we've been iterating on that and waiting for a critical mass of uploads before tackling it. We're getting closer though.

I agree with most of the sentiment in these comments. Archive and share non-comercially all the things!

[0] it's not "one" artist so it requires some custom UI, it should be unified through a single Aadam Jacob's collection, and it has a unique data path/structure on Archive.org relative to other collections
switz
·3 bulan yang lalu·discuss
4 1's == 4/1

could just be a coincidence
switz
·4 bulan yang lalu·discuss
really appreciate you building and maintaining it! state machines are the truth!
switz
·4 bulan yang lalu·discuss
I run Firefox latest so it should work. There's always a risk when going from HTML5->Web Audio. There's an occasional blip that's impossible to avoid (or at least, I have never found a solution). It doesn't happen every time though. Try going from track 2 to track 3 in the second tab of the demo (if both are "READY" as web audio).

The problem with exclusively using the web audio API is that the entire track must be loaded into memory before playing it, whereas HTML5 loads progressively. So we use both to balance the techniques.

In prior versions of the library, we'd load the track in parallel to HTML5 and make the switch mid-track so it's actually far less noticeable even if it does blip. I'm considering adding that to the new version.

Another alternative is building a custom buffer using RANGE requests to exclusively drive it via the web audio API. But obviously that is a far more complex undertaking (and requires the server to support RANGE requests). I'm open to implementing it, though.
switz
·4 bulan yang lalu·discuss
Thanks! Please do share if you choose to implement it (you can open a Github issue). I'd be glad to add any projects using it to the README.
switz
·4 bulan yang lalu·discuss
Gapless 5 was actually the precursor to this library over a decade ago, so Rego deserves full credit. They built the first example of gapless playback on the web and I took inspiration from their techniques.

Gapless 5 has a built in UI and style. Our library is headless: you bring your own UI and controls. It just depends on what your use-case is.
switz
·5 bulan yang lalu·discuss
RSC by design does not ship everything to the client. That's one of its basic premises. It ships markup, composed in client interactivity, but you can shed a lot of the code required curate that markup.
switz
·5 bulan yang lalu·discuss
This is pretty fascinating and comes with some complicated AI-world incentives that I've been ruminating on lately. The better you document your work, the stronger contracts you define, the easier it is for someone to clone your work. I wouldn't be surprised if we end up seeing open source commercial work bend towards the SQLite model (open core, private tests). There's no way Cloudflare could have pulled this off without next's very own tests.

Speaking more about the framework itself, the only real conclusion I have here is that I feel server components are a misunderstood and under-utilized pattern and anyone attempting to simplify their DX is a win in my book.

Next is very complex, largely because it has incrementally grown and kept somewhat backwards compatible. A framework that starts from the current API surface and grows can be more malleable and make some tough decisions here at the outset.

Crazy to see it's already being run on a .gov domain[0]. TTFGOV as a new adoption metric?

[0] https://www.cio.gov/
switz
·5 bulan yang lalu·discuss
Yup! We’re just one link in the chain (bands, tapers, archivists, & the listeners), but I appreciate the sentiment. Alec and I have been running Relisten for over a decade and we’ve put a lot of work into it these past few years.

Had to give the Dead a little nod here
switz
·5 bulan yang lalu·discuss
TIL about ambiguous width unicode characters. Turns out some locales render these chars as double width. I'm attempting to work out a solution.

Seems like maybe there are some universal half-width characters that can be used.

https://www.unicode.org/reports/tr11/
switz
·5 bulan yang lalu·discuss
Fair point. I added basic mermaid parsing to the library so you can do that here too.

    $ echo 'flowchart LR
        web([Frontend])
        subgraph platform [Cloud Platform]
          api([API Server])
          db[(Database)]
          api --> db
        end
        web -->|HTTPS| api' | npx box-of-rain --mermaid

                           ╔══ Cloud Platform ════════════════════╗
                           ║                                      ║
    ╭──────────╮           ║  ╭────────────╮      ╔════════════╗  ║
    │          │           ║  │            │      ║            ║  ║
    │ Frontend │ ─── HTTPS ──▶│ API Server │ ────▶║  Database  ║  ║
    │          │           ║  │            │      ║            ║  ║
    ╰──────────╯           ║  ╰────────────╯      ╚════════════╝  ║
                           ╚══════════════════════════════════════╝
switz
·5 bulan yang lalu·discuss
I agree with you that we should care more about resource usage, but it's a false comparison. Backend devs control where their code runs, frontend devs don't.

You can make more precise decisions when you have complete control over the environment. When you don't, you have to make trade-offs. In this case, universality (electron and javascript) for higher RAM usage. It doesn't seem to have slowed Discord's adoption rate.

Even if they built their desktops apps in native code and UI, they'd have to build a JS website in parallel.