> It doesn't take much to convince them that Google et al don't have their best interests in mind. They already know it and have experienced it.
I think with Apple in particular, this is the issue. Apple have largely demonstrated that they _do_ often have the users best interests in mind (or at least at some point have had) on the basis that the users are Apple’s primary customers. Yes, Apple lock down iOS functionality but this has often been to deliver innovative features. Users don’t mind that they’re in a walled garden because, they like the walled garden.
This is where Google is a different case. Google’s interests are aligned with mass data collection rather than products people love. Most Google users have experienced how this impacts them negatively at some point, usually with the degradation of their products, and constant advert spam.
Google is an example of a company that the mass majority assumes to be in the wrong. Apple often isn’t.
In most circumstances, I’d absolutely agree. For Art Galleries and museums, I’m far more inclined to be lenient.
It’s art. It’s okay for the api to be characteristically vibes based. Especially because the downstream use-cases probably only really care if it’s something that’s been accessed “much”.
I love this. I’ve always considered doing something similar with a traditional recsys model.
The only feature I’d love to see, is there are many posts where I’m more interested in the HN comments, rather than the articles themselves. It would be great to see this incorporated somehow.
Not as exciting or big as some of the projects on here, but just a small personal one I’ve been wanting to do for a while.
I recently impulse bought an Epson receipt printer, and I’ve started putting together a server in Go to print a morning update every day. Getting it to print the weather, my calendar and todos, news headlines, HN front page. Basically everything I pick up my phone for in the morning, to be on paper rather than looking at a screen first thing. Very early days but hacking away and learning escpos/go! (Vibecoding a lot of it)
Seconding that Zen has been an amazing Arc replacement for those happy with Firefox based browser.
The only challenge is daily driving both Zen and Zed as a code editor is a pain when it comes to macOS spotlight (/raycast).
Using dbt at $JOB, and building a custom dbt adapter for our legacy data repos, I've slowly developed a difficult relationship dbt's internals and externals. Struggling with the way it (python) handles concurrency, threading, timeouts with long running (4hr+ jobs), and the like. Not to mention inconsistencies with the way it handles Jinja in config files vs SQL files. Also it's lack of ingestion handling and VSCode/editor support, which it seems like Bruin considers very well!
Since starting poking around on the inside of dbt I've felt like Go or Rust would be a far more suitable platform for a pipeline building tool, and this looks to be going in a great direction, so congrats on the launch and best of luck with your cloud offering.
That being said, I tried starting the example bruin pipeline with duckdb on a current data project, and I'm having no luck getting the connection to appear with `bruin connections list` so nothing will run. So looks like I'm going to have to stick with dbt for now. Might be worth adding some more documentation around the .bruin.yml file; dbt has great documentation listing the purpose and layout of each file in the folder which is very helpful when trying to set things up.
Been working with sqlite and Typescript, needing random rows sampled reproducibly with a seed. Found this handy little trick [0]. Not the cleanest, but it works!
`SELECT * FROM sales ORDER BY substr(${seedValue} * sales.id, length(sales.id) + 2) LIMIT 10;`
Noticed the demo won't let me add spaces in table cells however.