Tags: web-review, nvidia, e-ink, craftsmanship, mypy, technical-debt, tech, display, business, xp, tests, systemd, security, pyright, python, rust, postgresql, arm, interoperability, performance, linux, wordpress, zoom, api, supply-chain, maintenance, complexity, imap, foss, type-systems, databases, services, programming, scrum
Let’s go for my web review for the week 2022-04.
Tags: tech, business, arm, nvidia
This is likely for the best.
Tags: tech, display, e-ink
Very interesting story (even though it feels a bit like advertisements at times) about the quest to get color into e-ink displays. Goes on to explain a bit of the technology behind those.
https://spectrum.ieee.org/how-e-ink-developed-full-color-epaper
Tags: tech, security, foss
This is… whoa… such a level of incompetency is incredible.
https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquiry-response-required/
Tags: tech, security, supply-chain, wordpress
Now this is a really bad supply-chain attack for the WordPress ecosystem.
Tags: tech, zoom, security
Also a good reminder of why the fact that it’s proprietary makes things harder security wise.
https://thehackernews.com/2022/01/google-details-two-zero-day-bugs.html
Tags: tech, interoperability, api
That looks like an interesting way to share data between applications. Reminds a bit of the semantic web movement back in early 2000s (talking entities and aggregates), maybe less heavy on the schema side though. I’d need to look at the specification more.
Tags: tech, scrum, xp, craftsmanship
Or why I’m actually glad I’m not certified even though I could be. This is a good way to stay balanced about all this. At least I’m trying to do my part trying to help people also on the technical areas which are mostly ignored by the “Scrum Industrial Complex” (as Ron Jeffries puts it). Clearly the scrum organizations are not interested in taking up that mantle so it falls onto us.
https://ronjeffries.com/articles/-z022/01121/scrum-rant/
Tags: tech, programming, python
Good explanation of the Python object model and how parameters are passed to functions. This can look rather surprising or confusing if you come from another language. Always keep in mind: mutability and the fact that variable name are just labels play a big role in this. That means you might need to copy explicitly in the case of mutable objects… which makes the performance burden explicit as well (and this means you need to pick between shallow or deep copying).
PS: I really mean “label” here (like in the post), it’s a bit different from “pointer” since you don’t get the pointer geometry (you can only reassign). From the C++ perspective I’d say it behaves as if all variables were “reassignable non-const references” only, something like that.
https://mathspp.com/blog/pydonts/pass-by-value-reference-and-assignment
Tags: tech, programming, python
Interesting caveat on how lru_cache is used in Python.
Tags: tech, linux, systemd
Nice way to learn systemd uses.
https://systemd-by-example.com/
Tags: tech, databases, performance, postgresql
Interesting tips for potential bottlenecks in your queries.
https://pawelurbanek.com/postgresql-query-bottleneck
Tags: tech, tests
Good guidelines to improve end to end tests. I especially relate to the first one, the test API is very important for those, otherwise they become a chore to maintain and understand.
Tags: tech, services, api
A bit on the fence with this still… but that sounds like an interesting path to explore in dealing with service APIs. A DSL with a code generator allows to neatly separate concerns if done properly. I wonder where the catches are (apart from the obvious strong coupling to Golang in that particular case).
https://blog.lawrencejones.dev/goa/
Tags: tech, type-systems, rust, imap
Interesting example of using a strong type system to avoid mistakes in code using a parsing and serialization library. The fact that it’s about IMAP and I’m still traumatized by it has nothing to do with my interest in that article, really.
https://duesee.dev/p/type-driven-development/
Tags: tech, programming, python, type-systems, mypy, pyright
Type annotations become quickly complex with Python. This is in part because it’s rolled out incrementally on top or existing practices. Here it collides a bit with decorators. Nice to see this hole is getting plugged though. Also nice to discover an alternative to mypy which seems a bit more precise (at least for the time being).
https://rednafi.github.io/reflections/static-typing-python-decorators.html
Tags: tech, programming, type-systems
Lots of food for thought in that article. Shows very well some of the trade offs in complexity languages have to deal with when they bring a strong type system to the table. Hence some limitations being in place… and that’s why it can get into nasty metaprogramming territory quickly. This show a couple of interesting examples on how this can be mitigated although we don’t have any perfect solution yet.
https://hirrolot.github.io/posts/why-static-languages-suffer-from-complexity
Tags: tech, technical-debt, maintenance, complexity
Good reminder of why “tech debt” is not a so bright metaphor. I find it useful sometimes but clearly it became overused in the industry (often a sign of something loosing its meaning whatever it was). That’s why lately I’m talking about complexity, some of it being legitimate so you need to keep the illegitimate one at bay. I like the focus on maintenance in that post. Also there are a couple of good ideas on how to schedule the maintenance tasks in your project.
https://blog.testdouble.com/posts/2022-01-20-stop-paying-debts-start-maintaining-code/
Bye for now!