Totally agree. And even the overhead of construction/destruction can be avoided in runtime for languages with inline types (e.g. https://kotlinlang.org/docs/inline-classes.html).
Readit NewsAn adjacent point is to use checked exceptions and to handle them appropriate to their type. I don't get why Java checked exceptions were so maligned. They saved me so many headaches on a project where I forced their use as I was the tech lead for it.
Everyone hated me for a while because it forced them to deal with more than just the happy path but they loved it once they got in the rhythm of thinking about all the exceptional cases in the code flow. And the project was extremely robustness even though we were not particularly disciplined about unit testing
That is why I am happy that rich errors (https://xuanlocle.medium.com/kotlin-2-4-introduces-rich-erro...) are coming to Kotlin. This expresses the possible error states very well, while programming for the happy path and with some syntactic sugar for destucturing the errors.
hiddew commented on Hurl: Run and test HTTP requests with plain text github.com/Orange-OpenSou... · Posted by u/flykespice
hiddew commented on How we decreased GitLab repo backup times from 48 hours to 41 minutes about.gitlab.com/blog/202... · Posted by u/nayak
"fixed it with an algorithmic change, reducing backup times exponentially"
If the backup times were O(n^2), are they now O(n^2 / 2^n)? I would guess not.
hiddew commented on A love letter to the CSV format github.com/medialab/xan/b... · Posted by u/Yomguithereal
I think for "untyped" files with records, using the ASCII file, (group) and record separators (hex 1C, 1D and 1E) work nicely. The only constraint is that the content cannot contain these characters, but I found that that is generally no problem in practice. Also the file is less human readable with a simple text editor.
For other use cases I would use newline separated JSON. Is has most of the benefits as written in the article, except the uncompressed file size.
hiddew commented on Baffled by generational garbage collection – wingolog wingolog.org/archives/202... · Posted by u/todsacerdoti
You are comparing very old Java if you had to touch anything else than heap size.
Especially that Java's GCs are by far the very very best, everything else is significantly behind (partially because other platforms may not be as reliant on object allocation, but it depends on your usecase)
You can use GC defaults, but tuning can provide valuable throughput or latency improvements for the application if you tune the GC parameters according to the workload. Especially latency sensitive applications may benefit from generational ZGC in modern JVMs.
hiddew commented on OpenStreetMap's New Vector Tiles tech.marksblogg.com/osm-m... · Posted by u/marklit
I'm a bit conflicted with vector tiles. I haven't found a good combination of style and tile generator (schema) that provides the same level of detail as the original raster tiles provide.
The article has screenshots that very much demonstrate this difference. The first screenshot has, for example, a lot of POIs (statues, shops, theaters, viewpoints), highways that are different when they are bridges, different colors for grass vs parks, different line widths for different highways, sports fields, building and neighbourhood names, arrows denoting one-way streets, building parts, stairs, trees, and a lot more.
The second screenshot has none of that, aside from a single trolly station and a single street name (which is also rendered incorrectly).
I've tried a lot of vector styles (all openmaptiles styles, the base protomaps styles, all mapbox styles) and generators (protomaps, openmaptiles, mapbox). None of them come close to the amount of detail as the raster OSM tiles while still being as readable.
I've never found anyone as bothered with this as I am. Vector styles are cool as they zoom and pan very smoothly, and their style is fairly easily editable. But, for any map where you actually want to see map data instead of using it as a base map for your own data, vector maps fall short.
Maybe it is just because of computational limits. I can imagine that displaying the same amount of detail as the OSM raster tiles would require too many resources: both on the client side and for tile generation.
It would be nice if OpenStreetMap would try to mimic their raster style closer, instead of providing just another low contrast, low detail base map. I hope this release of open vector tiles will facilitate more detailed vector maps!
I built a fork of OpenrailwayMap (original at https://www.openrailwaymap.org, vector styles at https://openrailwaymap.fly.dev).
The style was built to match the look of the original raster tiles closely, although I added many more interactivity features in the vector variant.
Is is interesting from a style/tile design perspective that the performance tradeoffs choices become very different how and where the tiles are rendered. This is obvious, but it has effects on what is possible on the server / clients visually as well.
Maintaining a fork by merging upstream into downstream branches would be a mess: upstream and downstream code would be totally entangled, there would no clean way to edit/remove/reorder downstream commits. You can't easily know what you actually changed (not the full diff, but each "atomic" clean change).
The way the author suggests is way cleaner IMO.
> there would no clean way to edit/remove/reorder downstream commits
Yes, but I consider commits immutable so reordering or editing commits is not a thing that would happen. New commits are appended (either upstream or downstream), and any conflicting changes then of course have to be merged from upstream into downstream.
The post considers rebasing the fork. It seems easier to do only merges. You can merge specific upstream commits, or the entire upstream branch. That way you only need to merge in the changes, and not resolve the same conflicts for each downstream commit, every time the upstream is changed.
For stuff like security keys you should typically add them as build --args-- secrets, not as content in the image.
Do not use build arguments for anything secret. The values are committed into the image layers.