HN user

rtuin

117 karma
Posts7
Comments48
View on HN

Most definitely. Although I haven’t found an (F)OSS project that lets one easily ship [favorite harness SDK] to self-hosted platform yet.

Which projects are standing out in this space right now?

Quick tip when working with Claude Code and Git: When you're happy with an intermediate result, stage the changes by running `git add` (no commit). That makes it possible to always go back to the staged changes when Claude messes up. You can then just discard the unstaged changes and don't have to roll back to the latest commit.

Cursor CLI 12 months ago

It seems they haven’t implemented MCP client features in Cursor CLI yet

This type of service is becoming increasingly prevalent among European energy suppliers for their residential customers. Beyond providing a revenue stream for consumers this model aggregates distributed energy resources (home batteries, EV's, PV systems) into a one virtual power plant. This enables the storage of surplus energy generated during solar peaks and dispatch back to the grid during periods of high demand. I find it a fascinating domain to work in!

Otel seems complicated because different observability vendors make implementing observability super easy with their proprietary SDK’s, agents and API’s. This is what Otel wants to solve and I think the people behind it are doing a great job. Also kudos to grafana for adopting OpenTelemetry as a first class citizen of their ecosystem.

I’ve been pushing the use of Datadog for years but their pricing is out of control for anyone between mid size company and large enterprises. So as years passed and OpenTelemetry API’s and SDK’s stabilized it became our standard for application observability.

To be honest the documentation could be better overall and the onboarding docs differ per programming language, which is not ideal.

My current team is on a NodeJS/Typescript stack and we’ve created a set of packages and an example Grafana stack to get started with OpenTelemetry real quick. Maybe it’s useful to anyone here: https://github.com/zonneplan/open-telemetry-js

I see your point. Some of our measurements are counters and interpolate missing data via certain rules. We store these interpolations in a separate table with exactly the same format and join the two tables directly when querying the data. Since the real value always takes precedence over the interpolated value this is just a COALESCE(realmeasure0000, interpolation0000) statement.

This is super fast when taking advantage of postgres' partition-wise joins.

The schema is organized by how we need to query it which is mostly by fetching all measurements for an entire day or month. Querying statistics on those metrics is not often needed, maybe a few times per week or day, so we do that in Snowflake if necessary. Or create a specialized streaming data flow when it the stats are queried more often.

Good observation. The updates are as much HOT-updates as possible. I wasn't familiar with BRIN-indexes before, so I have to look into that.

At first glance our solution follows a similar approach, let me elaborate:

- no index columns are updated ever, only inserted

- all tables are partitioned based on date (partition range is 1 month)

- for some tables there is another layer of partitioning (3 sub-partitions, based on one specific column)

- finding an appropriate fillfactor is important to improve the speed of UPDATE statements (HOT-updates)

- standard vacuum / auto vacuum settings work great for us so far.

- to improve ANALYZE performance, set column statistics of value-only columns to 0.

Glad you asked!

This system contains measurements and state of physical devices (time series). It’s designed for both heavy write and read, with slight emphasis on write. Each table is one type of device and contains 1 to 5 different measurements/states. But here’s the trick: because data is queried with minimum bucket size of 15minutes I figured we could just create a column for each measurement + quarter of the day (i.e. measure0000, measure0015), so that’s 100 columns for each measurement (96 quarter + 4 for DST), include the date in the key, et voila: excellent write performance (because it’s mainly UPDATE queries) and good read performance.

Okay, the queries to make sense of the data aren’t pretty, but can be generated.

I find it really cool how effective this is for time-series data without Postgres extensions (we’re on RDS).

It’s really something you don’t know how this applies to your Postgres DB, until you run into a situation where you do.

The author explains this very well, it’s a good read! I’ve learned about this padding little over a year ago, while I was designing a data intensive application with a colleague. I was skeptical about the advantage at first, but for our specific design, where we have 100 to 480+ columns in one table it makes a huge difference on table store size. Not so much on the indexes, though.

Where I work we’ve set up OpenTelemetry SDK in the applications to expose traces, logs and metrics.

Grafana agent as OTEL collector on the application hosts, Grafana Tempo as backend for traces, Loki for logs and Prometheus for Metrics.

The cool thing about Tempo it generates metrics for ingested spans and their labels (spanmetrics) so this allows us to explore “unknown unknowns” as the author calls it in a very cost efficient way.

This is awesome, can’t wait to play TH again. Totally forgot about this game, but i remember playing a demo version of the original game. The game was good fun. What impressed me most back then was the quality and “realism” of the videos (mind you, it was 1997)

My setup extends on this: the pulumi stack creates ECR repo, IAM user+access token, adds credentials and ECR details to GitHub actions secrets, and GitHub actions builds tags and pushes the images to ECR when a release is (automatically) tagged.

Pulumi is (mostly) a bliss!

I've been using mail in a box since 2016 for a handful of personal domains. It's easy to setup and very low maintenance. Backups are solid too.

Just make sure your hosting package/provider allows and supports self-hosted mail. PTR dns records specifically as without your mail might work but much ends up in spam boxes. The mail in a box setup guide covers this too.

Maybe sharing my experience helps in some way:

I’ve been using a handful of these accounts nearly 10 years ago. Not much if any mails received on them for at least a few years, and received the inactive notification for all of them last month. Note the nuance that these account didn’t have mail to forward for several years.

The article does not exactly state what is measured, but suggests it measured web traffic (browser, I assume).

It’s very bold to state “ChatGPT user sessions went down by X” when not taking into account:

- iOS app launch (May ‘23)

- Android app launch (July ‘23)

- GPT3.5 turbo and GPT4 API general availability (July ‘23)

- the explosion of apps that users shift to after 3.5-turbo/4 API GA

I worked with ChatGPT’s web interface daily before the mobile app was launched, and my usage is now at say 70% web / 30% app. And countless extra “sessions” integrated directly in code editor (Cursor)