diurnalist
Joined 14 years ago
Karma
102
Submissions
37
Member since
Feb 7
Recent submissions
Comment · 23 days ago
I've used https://github.com/kenn-io/agentsview and found it to be quite sensible. Main friction point for me is I want it to be easier to extend.
Comment · 29 days ago
> The industry at the moment wants people who know how to use AI to further the business goals but here’s the thing nobody wants to admit: not one person knows how to use AI to actually do that. I use it to write a lot of my code and then I critically review that code before it reaches production.
Unfortunately I think the real sentiment here is "here's the thing I don't want to admit: I don't know how to use AI to actually do that." It's not at all clear to me that nobody knows how to utilize AI practically. It's more clear that you have to be working in an environment that values developing this capability enough to pay a lot for tokens and let employees be free to explore, within reason. Or, you have to be willing to spend a lot of free time and cash doing that yourself.
Comment · 2 months ago
I don't think we have to understand the natural world to care about it. But I will go further haha: I think we _already_ prioritize human health and advancement above preserving anything about the natural world (unless we have identified that the preservation is advantageous for our own purposes.) And I reject this anthropocentric view, which is I suppose where we might differ :)
Comment · 2 months ago
Despite the efforts of many of centuries, we are still so ignorant of the vast variety of life that surrounds and supports us on this planet. We should have more humility about this, but we (collectively, as a species) do not.
Some will say that AI can solve this, as is the fashion. But so far the things people are interested in doing with the new potential for synthesizing and translating animal sounds does not inspire any confidence[0].
[0]: https://www.bloomberg.com/news/articles/2026-09-04/ai-s-next...
Comment · 2 months ago
Hah! I was wondering if it was maybe something he started doing over time and should have looked more at the later seasons I guess. It's comforting that it's not just a fun story.
Comment · 2 months ago
I also saw that interview, then out of curiosity I tried to find any evidence of this. There are some fan sites with ostensibly original X-Files scripts out there[1]. Looking through some written by Carter[2], I wonder if this is apocryphal, or if he was messing with her a bit.
[1]: https://www.boggsfiles.com/x-files-scripts-by-season/season-... [2]: https://drive.google.com/file/d/1BQbfRmeq3FsajjYcEuqDHv0kf2B...
Comment · 4 months ago
Pi is one of the ways out of this problem (OpenCode another) so I took it as an intentional reference as it is highly relevant. I also use Pi as my daily driver and I think it's a wise choice to figure out how to decouple yourself from lab-specific harnesses that you have little control or observability over.
Comment · 1 year ago
> Also, thoughts on Vector vs otel agent?
IMO, with the current tech, it entirely depends on what data you're talking about.
For metrics and traces, I would use the OTel collector personally. You will have much more flexibility and it's pretty easy to write custom processors in Go. Support for traces is quite mature and metrics isn't far off. We've been running collectors for production scale of metric and trace ingest for the past couple of years, on the order of 1m events/sec (metric datapoints or spans). You mentioned low volume so that's less important, but I just wanted to mention in case others find this comment.
Logs are a bit different. We looked in to this in the past year. Vector has emerging support for OTLP but it's pretty early. Still, I bet it's pretty straightforward if your backend can ingest via OTLP. Our main concern with running the otel-collector as the log ingest agent was around throughput/performance. Vector is battle-tested, otel is still a bit early in this space. I imagine over time the gap will be closed but I would probably still reach for Vector for this use-case for higher scale. That said, YMMV and as with any technical decision, empirical data and benchmarking on your workloads will be the best way to determine the tradeoffs.
For your scale you could probably get away with an OTel collector daemonset and maybe a deployment with the Target Allocator (to allocate Prometheus scrapes) and call it a day :)
Comment · 1 year ago
This is very true! In practice I have seen that it is exceedingly difficult to write the GraphQL "sinks" (I don't recall the exact term) that can intelligently handle things like batching and understanding things like pre filtering, where one service in the composed call could and should be performed first to limit the result set. YMMV, in my experience it can be simpler to be more explicit about these things, especially when in "true" BFF the client team is also responsible for their immediate backend, which can give them that flexibility, at the cost, perhaps, of more boilerplate.
Comment · 1 year ago
The article imo misuses the term BFF a bit, but perhaps its meaning has evolved over time. I was at SoundCloud when BFF was being introduced as an important piece of the microservice architecture--this post explains the purpose well[0]. BFFs can enable you to build more general-purpose and domain-specific services with few assumptions as to how they are used and their callers. BFFs then provide a composition layer you can use to, e.g., call one service to get a list of tracks, then call an authorization service w/ the list of track IDs to get geo-specific distribution rules for them, and compose that together in one materialized presentation view for the clients of the BFF.
Eventually I think there was some work to move to GraphQL, which can solve some of the same problems. But GraphQL is a technology, and BFF is more of a pattern. There is a later reflection on that blog that makes this distinction, which I only read today.[1] It makes another observation that I kind of forgot about, because it was hiding right in front of my face as a worker there:
"The defining characteristic of a BFF is that the API used by a client application is part of said application, owned by the same team that owns it, and it is not meant to be used by any other applications or clients."
The ownership model is indeed a big deal. In practice, it helped in many ways to have a sort of intermediate layer between the client applications and the rest of the architecture. For example, in the SoundCloud web application, when you load a page of playlists, only the first 5 tracks in the playlist are visible to the end-user. So the web BFF application had special logic to only partially load all the track metadata past track 5, which had significant impact on scalability and latency, especially when rendering a lot of playlists that had lots of tracks!
[0]: https://philcalcado.com/2015/09/18/the_back_end_for_front_en... [1]: https://philcalcado.com/2019/07/12/some_thoughts_graphql_bff...
Comment · 2 years ago
just want to say, this is the most comprehensive, eloquent, and succinct description of the Staff role I have seen put to page.
Comment · 2 years ago
I don't believe this is a solved problem, and it's been around since OpenTracing days[0]. I do not think that the Span links, as they are currently defined, would be the best place to do this, but maybe Span links are extended to support this in the future. Right now Span links are mostly used to correlate spans causally _across different traces_ whereas as you point out there are cases where you want correlation _within a trace_.
[0]: https://github.com/opentracing/specification/issues/142
Comment · 2 years ago
Keycloak solves a complex problem.
It is built on a plugin architecture, so plugins are certainly a viable option and this is documented in more detail here[0]. In general I have found the Keycloak docs thorough and well-written. When I operated Keycloak I built a few plugins to solve specific needs/assumptions we had around IdP when migrating to Keycloak from a bespoke solution.
Re: your second point, the docs also describe this in detail[1]. Having the realm data exist in a simple form that can be exported/imported was very useful. However, I would have liked if they thought more about how to do live backup/restore; perhaps that is easier now than it was at the time.
[0]: https://www.keycloak.org/docs/latest/server_development/inde... [1]: https://www.keycloak.org/server/importExport#_importing_a_re...
Comment · 3 years ago
Good find :)
I find it interesting how this ties in to the "productivity paradox."[0] The idea the author seems to be getting at--that software accelerates the creation of ever more elaborate solutions (often to problems created by prior iterations of software), and in the process leaves a wake of complexity that frustrates and baffles the society it was supposed to serve--is something I'd like to read more about.