My 8yo discovered my Playdate about 6 months ago and she loves it. She did crack the handle off of the crank though, so fragility might be a consideration...
We love our Playdate. Admittedly, when I first got the Playdate, it was a bit of a flash in the pan for me, possibly due in part to not having many games to try while Season 1 was trickling out. But since then, my daughter has reached the age (8) where she can really enjoy it, and that has pulled me back into it as another thing we can share together.
The achilles heel of the Playdate is screen brightness. There's an awkward sweet spot where you need to pour light onto the screen for it to be viewable but simultaneously avoid reflection from the light source. I guess for younger eyes that's less of a problem. But for me, I've had plenty of scenarios where I considered playing and then realized it was going to be impossible to comfortably set up a lighting environment.
I have clip-on lights for books. Maybe I should get one for the Playdate. Has anyone had success with that?
Thumbs up for Wispr Flow. Their iOS app was just released last week, and is an interesting addition to the product.
I needed to do an inventory of stuff in our house over the weekend, and I used Wispr Flow on iOS to take a very very long and rambly note in their app. Then the transcription text appeared on their Mac app, ready to be pasted into ChatGPT for parsing.
Wispr Flow handles languages switches quite well in my experience using it in both English and Japanese.
You mention it being scriptable, which makes sense as a CLI. Do you have any personal examples of using Lexy in a script? I'm curious about use cases outside of reading.
Excited to try this! I just started zone training a couple of weeks ago as a way to target VO2 Max increases. I’ve indeed found it hard to track time in zone across a week.
Also... this put PostHog in front of me right as I'm looking for a few things they seem to offer. The marketing-gimmick-to-thing-you-need flow was so on point it's kind of suspect.
What's the general consensus on them? Any PostHog users here that can share their impressions?
===
"Congrats - you've made it into Forbes 30 under 30. You scored 5 / 8."
As is evidenced by my score, you can't just select the tech bro each time and win.
Mermaid is fantastic as a portable I/O format for LLM context. I spent some time discussing entity relationships with an LLM recently, and had it produce a Mermaid diagram to wrap up the conversation.
Once you have the diagram code, you can use that as an artifact for new LLM chats related to databases, APIs, etc.
I'm not sure what the history of mermaidchart.com specifically is, but I'm guessing it's new since the ER diagram docs are marked as "coming soon":
I've been organizing a weekly morning coffee session in Astoria, Queens for the last 2 (or 3?) years. The morning coffees are connected to our local tech community's series of meetups, but they aren't hyper-focused on tech and they don't have an agenda. Just a chance to meet neighbors.
It's really been beneficial for me and my family, who aren't from here, to get to know more people in the neighborhood. These days I feel like it's a rarity to go outside without bumping into someone we know.
It's also been awesome to see friendships and even collaborations form among people in the group.
I recommend people give it a shot wherever they live. And if you're in NYC, come visit!
I'm going through the process of unpacking a prototype into a product roadmap. We just came out of a meeting to kick off architecture discussions/decisions when I saw your post.
A couple of questions:
- Do you have anything online that shows what Accord ADRs look and feel like?
- How are you thinking that Accord will plug into tools and workflows a team might already be using in the PDLC/SDLC?
Love all of these RSS resources. Thanks for sharing!
Last week, I spent a couple of hours at a local hack event putting an RSS aggregator[1] together for our community. Just something fun to do.
One thing I realized when I deployed is that Substack gives a 403 if you try to read their RSS feeds from a GitHub Action. The only obvious workaround to me is to pull the content on local periodically, commit it, and then deploy. But I'd much rather have this site updating itself via GitHub Action and cron.
It's really going to depend on what you want to host and how you want to interact with it as an admin.
For Node app hosting, I've been enjoying Render over the past year or so. But it seems like opinions on them are mixed among the HN audience:
https://news.ycombinator.com/item?id=42832696
If you look at that thread, you'll see comparable services mentioned as well, like Fly.io, Vercel, etc.
But if what you want to host is a WordPress site or just a Linux server, the options to consider are going to be different.
Bookmarked. I came here to see if DSL was on the list. :)
> There are always exceptions, if building this software has some competitive advantage, go ahead.
Good callout. There are no hard rules but it's nice to have this sort of sanity check to anchor the conversation in "why", which should tie closely to:
> Generally, developers at small to midsize SaaS companies shouldn’t build any software that doesn’t directly help them deliver a service to their customers.
My understanding is that these aren't really intended for much more beyond prototyping/MVP'ing.
I can't speak on the others, but I've used v0 a fair amount over the last year and have been happy with it as a prototyping tool. But the delta between the kind of UI it seems designed to generate and what, say, a designer working from user-centric first principles might come up with is huge.
I actually went through such an exercise where I prototyped something with v0 as part of an internal pitch. The prototype was super helpful in getting stakeholders engaged. Once I got a UX designer on board, they designed the concept from the ground up, and we tossed the v0 design and code completely.
This was the process working as intended. The prototype played an important role in getting something good shipped; it was not itself the end product.
At least today, I imagine v0 could be great for internal tools that would otherwise not get any UX love at all. But as far as shipping an app to external customers, I haven't been in a situation where I saw that as a viable path.
1. Work outside of the browser altogether (i.e., be built as an app for the OS), or
2. Integrate directly into the service it is targeting (i.e., G Suite add-ons, etc.)
npm download numbers are always exceptionally inflated. I'm sure that number serves some purpose, but I've never found them to be a useful metric when I've worked on public packages.
An ancient post [1] for the defunct npm blog offers some details:
> So the count of “downloads” is much larger than the number of people who typed “npm install yourpackage” on any given day.
I'm sure the particulars have changed over time, but directionally, npm download numbers aren't a proxy for "# of developers using my package".