glenjamin

> Logging events are the epitome of observability, and metrics and tracing events end up specializations of logging events which only cover very precise and specific usecase.

This is a common way of thinking about things, but having now worked with event-based tracing for the last few years I no longer believe traditional logs are necessary.

If you do “good” logging you likely have entirely structured data and no dynamic portions of the main log message. This is almost exactly equivalent to a span as represented by tracing implementations.

I have come to believe that these events are the core piece of telemetry, and from them you can derive metrics, spans, traces and even normal-looking logs.

The key difference is my experience is not about destination - backends are as flexible as you say

One key difference is having an event name + properties, rather than a human-readable description and maybe some fields if you’re lucky

Another key difference is wrapping units of work rather than just scattering log lines in places you think need them somewhat arbitrarily

I’m increasingly of the opinion that we should stop using “logging” libraries, and instead we should produce telemetry via events using something like OpenTelemetry’s trace API.

These traces can be rendered as strings for people who like their logs in files

I'm with the GP here, I'd much rather give them a few days and advise how much time they should spend on it than give them a strict timebox - it allows for a lot more flexibility with other responsibilities.

If I set a take-home test designed to take two hours, and then very clearly tell the candidate to take two hours, and then they clearly spent way longer than that, then I will consider that a signal that they don’t follow instructions well and don’t value their time appropriately.

I don't know if this is the case at Snowflake, but there are similar seemingly misaligned incentives with CircleCI's build-seconds-based pricing model.

However, the generally accepted wisdom there was that improving performance had always led to more builds being run - and so still come out as a net-positive. This had happened a bunch of times as we upgraded CPUs or storage drivers or the version - there'd be a short term drop in direct revenue, but then it would bounce back quickly as people took advantage of being able to do more stuff in the same amount of time.

I'm told the revenue and finance people were pretty concerned the first time it happened though!

Firebug was some truly excellent work - but I think it's worth also mentionining its precursor Venkman - which in turn built upon the js/jsd low-level debugging APIs inside the mozilla suite.

https://www-archive.mozilla.org/projects/venkman/

edit: there's a nice write-up of how firebug got started here https://flailingmonkey.com/the-history-of-firebug

I find it very disappointing that this article does not attempt to draw a distinction between state management for complex local states (imagine an image editor), or state management for fetching and updating data via APIs

I think the shape of solution needed for these two problems are quite different.

I think a hosted mulit-tenant CI platform appears fairly simple on the surface, but there's actually a lot of complexity under the hood when your product is arbitrary code execution as-a-service - and you want to offer a smoother user experience than something as general-purpose as a container runtime.

Especially when you throw in a large and generous free tier.

> at least you'll be working in an environment where the people using your software and the people paying you are the same.

Close, but not quite - because you end up selling to management or executives when it's the rank-and-file who actually use the software and don't get much purchasing power.

The graph in your link appears to show an operating profit of over $6 billion.

What has gone wrong with our world that making a 6 billion dollar a year profit is considered a problem?

Since it's being returned it doesn't really matter whether `.rewrite()` is returning a promise or not. `return await x` is mostly equivalent to `return x` within an async function.

Are you planning to add support for other languages in future, or are those two your main focus?

That's surprising to me, because the author of that book recently re-advertised his long post about a hard-line definition of a "unit" test

https://www.artima.com/weblogs/viewpost.jsp?thread=126923

I think the properties you list are good ones, but if you drop the word unit from your post the advice is just as good and you can't get mired in ontological discussions

Some time ago I stopped debating the definition of "unit" in testing, and instead started focusing on whether my tests were fast, reliable, and provided a useful signal about the health of the system when they failed. I've been much happier since then.

Something this articles glosses over is that some of these approaches, especially the way 'All builds are “locked”' is achieved with minimum version selection, and “A little copying is better than a little dependency” are tradeoffs against an alternative security model, where transitive dependencies are automatically updated to pick up security fixes.

Part of the churn and noise in the Node.js dependency ecosystem actually stems from security-related issues being noted in a low-level module, and the ripple effects caused by that when a bunch of maintainers have to go around bumping lockfiles and versions.

To do this requires some standard way of encoding an AST which includes comments and dividers.

That standard format is commonly known as source code - although it lacks a normal form.

Tools like prettier, gofmt and black can be thought of as a way to produce a normal form of source code.

This is (IMO) a reasonable incremental approach towards exactly what you describe - if a project checks in only source code that's formatted using a standardised format, then you're free to work on it using whatever equivalent representation you like - as long as it's converted back at commit-time.

And now with generics we have a way to make this decision/optimisation once, and have everyone else benefit from it without having to be aware of the details!

Because unknown headers are already passed through safely in existing implementations, whereas unknown methods are handled in a variety of different ways

You can use `-v` on the add to see what it’s doing instead of the extra status

I really like using tuple, but there’s a couple of things I’d really like to see:

- an idea of how much bandwidth it’s currently using or needs. I often find if I’m on a patchy connection it’s unclear how changing the settings will have an effect - make the video face stuff more prominent, especially for multiple monitors. I work 100% remote so when pairing I like to put my Co-workers full size on my second screen while I work on the primary screen, which helps us feel more connected.

This seems kinda neat - especially for ecosystems which don’t have standard ways to pin tool dependencies (looking at you, go).

The pricing makes me concerned though, I have to email about the enterprise plan to try this out on a private repo, and it’s extremely unclear what sort of ballpark this is going to cost me.

I am also concerned that it’s hard to see a path from “install a bunch of linters” to “VC gets their exit”, which doesn’t give me a lot of confidence to incorporate this into important projects

The fun thing about the docker rate limit is that the layer tarballs are stored on S3 in us-east-1.

If you do a docker pull inside us-east-1, you’ll get a direct S3 link instead of a proxied download, and thus neither you nor docker need to pay AWS anything for bandwidth!

actually.

I think it’s because the centre is computed using the X and Y axis, and the rotated shapes have a different bounding box on those axes.

If the containerized app you’re deploying follows 12 factor principles it’s very unlikely that you’ll be locked in due to specific functionality

The cost to move your operations expertise to another platform and learn all of its new quirks might be significant though.

Looking at those power numbers, I can't help but wonder how much you'd gain by doing this sort of modification on a bike that is more efficient and/or aerodynamic even without the motor attached.

A touring bike frame with 700c wheels and a more stretched out position would likely allow you to travel at the same speed for lower total power output - and make your battery go further (or not require such a large battery).

The reason for basically all of the problems you have described is over a decade of systematic under funding by the current government.

Continually forcing trusts to make cuts and costs savings result in them running with no slack at all - which leaves no room to make improvements, thus perpetuating the downward spiral.

Half an hour is 30 times longer than I want to wait for good quality feedback.

I’ll settle for under 5 minutes, but I always shoot for 1 minute.

30 minutes is not really compatible with continuous deployment approaches

> I noodled on this a while ago and figured it was easier to just restart the app on config changes than try to change things on the fly =D

I think this is generally the best approach, as it also applies some pressure for your application to be able to quickly shutdown and restart without affecting users - which is a desirable property to have for many other reasons too.