tobestobestobes

Check out 3dep instead of Copernicus. 1 meter resolution elevation data vs 30 m. May need LOD and culling to support it though.

I think that things like Agile are not an accurate model of problem solving and that making good software requires 'extending yourself outside', especially w agile or other modern management systems like many of us are working within. That is my experience. The actual effort is much more to make decent software that works and 'ticketing' makes it easy for devs to disown their own bad or incomplete work when it's convenient and can be disguised as working within scope. This bad work is then passed onto other devs (and the users) and/or converted to technical debt (oh look at all these bug tickets!)... When arguably the real and complete problem at hand was ignored because it was 'out of scope'. There is a 'shadow world' of work that exists outside of ticketing but is required to actually build the software. If you're not involved in that shadow work, then you may be a part of the problem. Problem solving is fluid and technical requirements and matters of approach aren't always readily available at 'groom time'. Work as a group, get uncomfortable if required, and don't go disappear with your ticket for two weeks and half solve a problem and bake the e2e tests. Most development work truly comes to a conclusion in a war room after the ticket is closed and with none of the original devs -- too much of the time these days. Reward devs for taking on more and owning parts of the codebase. AI threatens dev jobs because devs and scrum masters water down work and the system encourages shoddy, transactional work. Not really a criticism of the above comment ... But something I see a lot in enterprise software development. And I also do realize going outside of scope is risky and doesn't pay in the current management zeitgeist.

woodworking ~= toy/side software projects

carpentry ~= software engineering (within an organization)

I think woodworking is attractive to software engineers because its akin to building side/toy software projects. Autonomy, building from scratch, requirements/AC's self-defined etc.

Software engineering professionally is more like carpentry/trades. Carpenters work in teams, work on one specific part of a house and may not touch other parts of the house, do not design but mainly implement. You might even liken SWEs to tradesmen generally in that there can be a high degree of specialization: plumbers, electricians, finish carpenters, tilers etc being the devOps, secOps, backend, frontend etc.

Woodworking != carpentry

Again, a big part of the draw to woodworking for SWE is the same as the draw for a software side/toy project: it's more fun and fulfilling to build something in it's entirety, from scratch, and by yourself (especially if you do the opposite in your day job).

Also, be wary of quitting your job to become a woodworker. Woodworking professionally does not necessarily resemble what is posted in this article or linked to. Many woodworkers start out as carpenters and learn on the job or as a side hustle to carpentry. Many woodworkers do not design the pieces they make/install. Many parts of the piece you are making could be prefab. The amount of time you'll be able to spend manually sharpening your hand tools will be limited. Grass is always greener: physical work is rewarding, but anyone who has done carpentry and/or woodworking their whole life will have infirmities, ailments, and maybe even disabilities caused by their career. There is woodworking fantasy and their is woodworking reality.

And also, tastes have changed and most don't care to pay for quality woodwork. Odds are the wealthy homeowner is going to take your beautiful mahogany built-ins and paint them purple because that's what the interior designer asked for. And that's if your lucky. Most folks don't buy custom built furniture, they buy IKEA. By all means take up woodworking and quit you SWE job, but assume that you will very quickly dip into the fortune you amassed as a SWE. I think there should be more craft in this world, so I wouldn't discourage it outright -- but make sure you have the material means to sustain this woodworking fantasy.

Looks like only recently opened tabs (or some variation on that) show up here. To test, reload all tabs In one window (I used an extension) and check out chrome://inspect again. It's all there. Maybe there's a good reason for not showing all pages in inspect. Who knows. Another problem is that my script grabs page subprocess urls also. I've mainly used this for grabbing my android tabs.

This is an adapted version that skips grabbing subprocesses

  collection = document.getElementById("pages").getElementsByClassName("subrow"); final_output_tsv = "title\turl\n"; for (let item of collection) {if(new RegExp("([a-zA-Z0-9]+://)?([a-zA-Z0-9_]+:[a-zA-Z0-9_]+@)?([a-zA-Z0-9.-]+\\.[A-Za-z]{2,4})(:[0-9]+)?(/.*)?").test(item.children[0].innerHTML) === false) final_output_tsv += `${item.children[0].innerHTML}\t${item.children[1] ? item.children[1].innerHTML : "N/A"}\n`}; copy(final_output_tsv)

edit: I used reload all tabs extension with reload all tabs in all windows option turned on. This could get messy.

It's a huge leap forward in browser management. Not exactly a replacement for headless browsing/scraping etc, but for personal use, nothing compares. A big contribution to the "personal data management" toolbox.

In the realm of tab management, I use this one liner in console of chrome://inspect every once in a while, then just close all of my tabs:

  collection = document.getElementById("pages").getElementsByClassName("subrow"); final_output_tsv = "title\turl\n"; for (let item of collection) {final_output_tsv += `${item.children[0].innerHTML}\t${item.children[1] ? item.children[1].innerHTML : "N/A"}\n`}; copy(final_output_tsv)

Substitute "devices" for "pages" to get android chrome tabs

This way I can backup all my tabs in simple, non-bookmark format and search them using python etc.

Just a shout out to this commenter. He's quite the expert on all things image. And from what I gather he's done quite a bit with image processing in Rust also.

I don't know what the context of the original post is, but I implemented this algo in Canvas/JS some time ago https://tgiachett.github.io/canvas-floyd-steinberg-dither/ It's a little rough around the edges, but I think the code is still readable.

Wonderful work. There is a similar project called Terra that someone at Mapbox did, but the raster tiles for that aren't working anymore (prob due to API change) so it's nice to see an alternative -- a whole library no less.

I don't find the Adobe Premiere SDK very intuitive or well documented, nor does it support Python. Looks like DaVinci Resolve does support Python and it seems well documented and intuitive. Thanks for the tip.

wrt why video editing needs automating: there are a host of repetitive tasks in video editing that are very tedious to do with GUI editors. For instance, labelling shots with shot number overlay text. At the moment you can get quick results for this specific task using other tools such as FFmpeg. Personally, the top item on my wishlist would be a video editing library (Python?) that outputs to Final Cut Pro XML so that I could do final tweaks in a GUI-based editor of my choice.

This article outlines how to run FFmpeg on AWS Lambda: https://intoli.com/blog/transcoding-on-aws-lambda/ With favorable cost comparisons to Elastic Transcoder. Not self-hosted, but looks like significant cost improvement. Also, one could set up a 'transcode farm' with virtual/real machines using FFmpeg running parallel with some light scripting for automation. Looking up 'render farm' might yield some ideas for distributed image computation. Just some ideas...