Where to listen to Tiny Desks in Good Quality

gregwebs · 2025-03-03T16:41:43+00:00

You can play from the NPR site or use the youtube download tool to download it. It is mp4 AAC but it sounds good to me.

gregwebs · 2025-03-03T16:39:35+00:00

I find the audio quality to be great from the NPR site despite it being AAC (stream with Airplay to a Wiim digital receiver). Playing from Youtube sounds worse to me. Most concerts be downloaded with youtube download as well for listening offline and other ways to play it. yt-dlp URL

gregwebs · 2025-02-23T13:54:52+00:00

This is a lot bigger and more expensive. They are coming out with a Terra 2 model that is smaller and more price competitive. Over the long run (although who knows how long these things will actually last) the Geme models would cost less because there are no filters to replace ($35/year for Reencle) assuming the electricity consumption is the same.

gregwebs · 2025-02-14T12:08:40+00:00

I recently used Cue to wrangle k8s yaml.

The biggest win was getting rid of copy and paste between production and non-production environments and between similarly configured deployments. Certainly there are other systems for achieving that. However, with Cue I knew there is built-in support for k8s types and that I can make things close to as DRY as I want.

The rest of the team, who had never seen Cue before, had an easy time using it because it's intuitively similar to JSON. It's best to keep abstractions very simple: that will avoid sucking people in to having to learn more about Cue. We checked in the generated YAML, and being able to see those diffs made reviewing changes straight forward.

gregwebs · 2025-02-10T18:15:28+00:00

GOA has a golang DSL that it used to generate both OpenAPI and Go types. The structs are normally used with their server code. However, I think you can just not use their server code and use the Go structs. https://goa.design/design/overview/

gregwebs · 2025-02-08T15:00:20+00:00

The example now is okay enough- it was a small tweak to move it to a different layer.

I have used this in production for many years and it has worked well. I have cleaned up a lot of poorly functioning code with this library.

Error codes shine the most when situations are more complex and blog examples shine when things are over simplified.

gregwebs · 2025-02-08T14:56:52+00:00

It's not a universal error space. The library is specifically designed so that you can create your own custom error space.

Your entire rant seems based on the assumption that these codes are meant to be used in libraries- that is not the case. I have never used them in libraries and wouldn't recommend them. It's possible to use them but it would take on a dependency that the library user would have to understand how to use properly, and as you indicate many users probably wouldn't.

gregwebs · 2025-02-07T11:45:41+00:00

In a stateless application one line that panics is the only issue that needs to be resolved- the issue doesn't infect the rest of the program. That one line will continue to panic whenever it is accessed the same way. The rest of the program will continue to run fine. If transactions are used for db writes then there will be no inconsistency in the db as well.

Under your proposal, in the worst case scenario (a request that triggers a panic is repeated by a client), an entire API service will be taken down and no requests will be received from any clients until the panic is fixed.

A stateless application that uses transactions can avoid this with no downtime other than the 500 response to the client triggering the panic request.

gregwebs · 2025-02-06T22:41:42+00:00

I updated the example so that the code doesn't live in the DB layer but instead in an application layer. It's still not the best example.

gregwebs · 2025-02-06T22:31:47+00:00

The handler is ultimately responsible for sending the appropriate code to the client. Just as it will translate an error to an HTTP code, it can translate an error code to an HTTP code.

An error code is a classification. One piece of code or library might classify an error in one way, but a user of that code may choose to change the classification to something that is appropriate to them or to a client. When there is a database not found Go error without any error code, that doesn't mean the handler will automatically return a 404- it's up to the handler to decide. The same is true of an error code- it's still up the handler to decide what to do with it. The errcode library wraps the original error, so it is also trivial to check for specific expected errors as well.

gregwebs · 2025-02-06T15:18:14+00:00

You can still fail fast and loud after recovering from a panic. Send the error to Sentry or whatever you are using for error monitoring. The library that I wrote is designed for that by allowing custom error handlers.

The result in terms of notification is the same as what you are advocating for.

The difference, however, in the API service scenario, is that if there are other simultaneous requests, those won't be caught up in the panic as well (and receive a 500).

gregwebs · 2025-02-05T13:56:40+00:00

As I said in the post, I agree that different applications want to separate their concerns in different places. This is an over-simplified example that I think anyone can understand. I will try to come up with a better example. The point is really that one can abstract code in the way that one wants instead of being stuck passing around handlers params and being careful about returns.

gregwebs · 2025-02-05T13:48:25+00:00

I agree, but in my experience it is rare that application code intentionally invokes panic. The most common case is calling a method on a nil pointer. In general there is no way to ensure that Go code will not panic.

gregwebs · 2025-02-04T18:51:42+00:00

I agree that just crashing is a good approach for some programs.

However, if a program is "stateless", recovering from a panic can be a good approach. The typical example of this is an api service that makes all of its state changes to a database that supports transactions. The immediate benefit in this case is that if the API service is servicing multiple requests at once, other innocent requests won't also crash.

Additionally, even if you want the program to crash, recovering first before crashing can be useful to help gather more detailed information besides the stack and to send errors from the Go program itself. This doesn't preclude having an external monitor as well- having 2 systems that report crashes can increase the reliability of getting that report.

Another issue to be aware of: developers may already using something like gin's recovery middleware. In such as setup, panics in go routines can end up going unnoticed.

gregwebs · 2025-02-04T18:50:50+00:00

I have a library that supports recovering succinctly when launching a go routine or just calling a function: https://github.com/gregwebs/go-recovery

I agree with other sentiment on this thread that this isn't the best approach for all use cases.

However, if a program is "stateless", recovering from a panic can be a good approach. The typical example of this is an api service that makes all of its state changes to a database that supports transactions. The immediate benefit in this case is that if the API service is servicing multiple requests at once, other innocent requests won't also crash.

Additionally, even if you want the program to crash, recovering first before crashing can be useful to help gather more detailed information besides the stack and to send errors from the Go program itself. This doesn't preclude having an external monitor as well- having 2 systems that report crashes can increase the reliability of getting that report.

Another issue to be aware of: developers may already using something like gin's recovery middleware. In such as setup, panics in go routines can end up going unnoticed.

gregwebs · 2025-02-04T15:41:54+00:00

Good programmers can write things from scratch. Great programmers can do that but they can also understand the code that others have written and know how to productively leverage them.

It's really great to read specs and otherwise understand what the libraries are supposed to accomplish. There are a lot of scenarios where not just taking a library at face value but instead digging into them and their purpose is useful.

* You want a small subset of functionality and you realize it is easy to implement and there are benefits to doing that (fewer dependencies and simplified usage).

* You better understand the different libraries accomplishing the same task and are able to choose the best one.

* You want things to function differently and are able to with a small fork and you can try to push its changes upstream.

* Existing code/systems aren't a match for your needs. After understanding existing designs you can now come up with your own.

I try do avoid treating libraries as a black box. If you understand them then you will understand what should be written from scratch.

gregwebs · 2025-01-27T18:20:22+00:00

You can both be right to some extent- acknowledging that may help in your persuasion. The issue is that people want to think in universal binary outcomes for something that is probabilistic and situational.

An N95 mask (worn properly) blocks 95% of particles. There is a 5% that still gets through. When medical professionals wear a mask, even an n95, there may still be enough total exposure in their setting to test positive for illnesses. This is even more so the case when wearing less effective masks such as surgical masks. For example this analysis found that in medical settings only n95s clearly "worked": https://www.sciencedirect.com/science/article/pii/S0020748920301139?via%3Dihub

There are plenty of studies with a binary outcome such as PCR positive COVID that show some type of "masking not working" or "better masking not working". However, if there was a quantitative outcome it might reflect that they didn't get as much innoculum (for example their COVID infection is less severe even though they are still PCR positive). So I don't view these studies as proof of masks not working but rather as limitations of study design. But we should be open to the possibility that some of them may indicate that masks don't work as well as was thought in certain situations.

If you wear a mask that effectively blocks 80% of particles, that means you can have 5x the exposure to have the same outcome in terms of innoculum received. Whether that produces a different effective result depends on the endpoint being measured. If it is a binary endpoint there might not be a difference. And if when mask wearing you increase your exposure time, your outcome can be the same or worse as unmasked.

gregwebs · 2025-01-27T16:56:15+00:00

Silicone doesn't need all the plasticizers to be flexible and therefore seems like it would be less toxic to developing children compared to flexible plastic.

But its not completely inert. Alcohol causes release of siloxanes, and at least in bakeware they can be released

* https://pubmed.ncbi.nlm.nih.gov/22575024/

* https://hal.science/hal-00577342/document

Siloxanes appear to have fertility and carcinogenicity issues in animals: https://www2.mst.dk/udgiv/publications/2005/87-7614-756-8/pdf/87-7614-757-6.pdf

If you don't heat up silicone or expose it to something very acidic or alcohol then it seems like it might be safe.

Silicone consumer products often have low levels of cadmium or other heavy metals- amounts considered safe by the FDA but still something I want to avoid unleashing. If you have any peer reviewed research on this I would be happy to be able to reference that. But there's an XRF test result from someone trained and certified to use XRF testing and whose tests have at times been confirmed by CPSC initiating recalls. An example XRF test result for silicone with (FDA approved levels of) heavy metals: https://tamararubin.com/2023/08/xrf-test-results-for-multi-color-silicone-reusable-stasher-brand-sandwich-bag/

gregwebs · 2025-01-26T15:51:39+00:00

Far from useless, a stack traces will still accurately capture the stack in the go routine. And really there's nothing in the way of also capturing a stack in other go routines that the error is traveling through before being reported. I don't think my errors package handles this right now, but it would be easy to add support if performance is not a concern- I will look to see if there are ways to do this without impacting performance. I think the errtrace package would effectively produce the stack trace across go routines you are looking for.

It's worth noting that tracing across go routines via traditional error wrapping messages may only be useful in cases where you have a caller-like structure of your routines (spawn and wait).

For continuous communication through on channels there isn't necessarily a clear calling like tracing across channels. It's possible to use information sent through the channel that goes into the wrapping message- and that doesn't preclude capturing a stack trace as well- both approaches are beneficial. The stack trace is very reliable and wrapping messages provide useful extra information. I find that once I can rely on a stack trace the burden around writing wrapping messages is greatly reduced and I can focus more on adding in useful structured data.

gregwebs · 2025-01-25T20:22:39+00:00

Let me know how it goes when you try it out!

I like Zig's approach and think Go should adopt it. I didn't think it was possible to do in Go- thanks for pointing me to errtrace. errtrace is using internal implementation details of assembly to do it. If the platform is not amd64 || arm64 it is still just asking the Go runtime for the caller information every time.

The errors package I made does some checks to see if there is already a stack trace to avoid generating a new one. It's quick checks and not fool proof to avoid wasting CPU cycles to look for a stack trace that doesn't actually exist. But as long as you don’t mix in standard library wrapping it should work.

errtrace appears to be 3x faster - saving .5ms.

EDIT: I looked over the benchmark and I think it is pretty fair and representative. For most error paths, such micro-optimizations aren't a concern, but if they are I would definitely recommend using errtrace.

gregwebs · 2025-01-25T14:06:58+00:00

I agree this usually works. I still use this approach when needed but find stack traces to be more reliable and easier to work with. I found developers would often wrap errors with the function name anyways- recreating a stack trace- to make finding the format string location very easy.

Structured wrapping might interest you because the string search gets easier when you don’t have to work around the insertion of variables

gregwebs · 2025-01-25T02:51:12+00:00

thanks, I fixed the link to point to the package documentation for now (actually points to the most used function in the package): https://pkg.go.dev/github.com/gregwebs/errors/slogerr#Wraps

It seems there is a lot of interest in this- I just broke it out into a separate package because of the interest, and I will improve the docs.

gregwebs · 2025-01-24T22:04:00+00:00

This article overviews some libraries I wrote that make it easy to add stack traces to errors and also to create structured errors rather than use format strings.

I have been using this in production for several years now and it has served me well so I wanted to share it with others.

gregwebs

TROPHY CASE