HN user

Tea418

125 karma
Posts0
Comments11
View on HN
No posts found.

The headline could also be “Google is deprecating older Widevine CDM versions”, which is a regular process.

Whether or not the playback error rate of your product significantly spikes depends on the number of older non-Chrome browsers that are using Widevine. Probably mostly Firefox installations that don’t receive regular updates by their users. Chrome itself is doing pretty well with pushing updates for plugins such as the mentioned CDM.

Analytics tools will certainly help to determine how many users will be affected after December 6. Perhaps something for Bitmovin to provide a smart metric for exactly this.

The public Go code I usually read are libraries and I admit I also noticed only a little adoption of generics.

My personal hypothesis is that many libraries follow the official Go release policy[1]. Due to the fact that generics were introduced with v1.18 and we now have v1.19, libraries would be bound to the features that were available with v1.17, unless they spend effort on working around this by implementing the respective build flags that make generics available exclusively for >=v1.18. However this is just an assumption.

According to the Go Developer Survey 2022 Q2[2], 1 in 4 respondents said they've already started using generics in their Go code and 14% have started using generics in production code.

[1] https://go.dev/doc/devel/release [2] https://go.dev/blog/survey2022-q2-results

For me, a language or tech stack is not more than a tool box to achieve a higher goal, namely solving specific problems. While I do enjoy building software, "writing code" or mastering a particular tech stack is only one component of several things that make software engineering enjoyable.

One of these other things is understanding the kind of problem I want to solve and its environment, by collaborating with stakeholders and domain experts. As soon as I understand their expectations, I decide on the tech stack.

That being said, if I want to make an estimation which tech stacks are likely to be relevant in the long run, I would start with understanding which business requirements will be relevant. Based on that (and maybe more), I can assess which stacks could be a promising fit.

And if I'm wrong, don't neglect the experience I make mastering or learning a tech steck.

Fully agree here: I don’t expect anything else but reliable and performant HTTP caching from a CDN like CloudFront.

Request manipulation is not the duty of a cache - even though other CDN providers mix request manipulation functionality with caching. In my opinion, they don’t need to be in the same product.

If you still need request manipulation, because you don’t control the origin or you don’t want to introduce another service between CloudFront and the origin, you would use CloudFront Functions, which is cheaper than Lambda@Edge and easy to set up.

I don’t expect software to fail generally, but I’m getting used to a recurring stimulus quickly, especially if I underestimate its importance. Perhaps it’s a kind of habituation.

I feel like it’s getting harder to estimate importance properly as the complexity of an abstract system grows. People tend to click the same error message they don’t understand away each day, because it hadn’t had any negative impact (so far).