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.
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.
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.
cool this seems handy, but when I try my chrome://inspect/#pages only contains a small subset of tabs out of the few dozen windows I have open. Any tips?
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
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.
thanks for the link :)
I will check that. I certainly will try this using processing. There is already a video on youtube which details how to do this.
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.
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.
I've used moviepy (https://github.com/Zulko/moviepy) with some success. Doesn't do Final Cut export but it uses ffmpeg under the hood, so it could be used to create raw clips in some lossless format.
Soory for necro.
Editors should know how to code. Lots of editing tools are extensible in Python pretty easily. Sadly, those parts of my career didn't intersect.
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.
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...
I ended up building a transcoder within the past few months using Lambda that is handling, as of today, 500k+ videos per month and growing. This was replacing a set of EC2 instances similar to what you described.
A few caveats I ran into:
1) You are limited in how much /tmp on a Lambda instance can hold (512MB total). For the transcode I'm doing on these boxes, some of the videos are that size just to download. It will fail. I have a backup using the older method to handle these very large instances.
2) These, obviously, need a pretty decent amount of RAM to run.
But the benefits are really worth it for us. Elastic Transcoder, for our needs, was going to be >$15k/mo). Our current transcoder cost is around $400/mo. The previous, EC2-based iteration, was a step up for us, but it sometimes took a while to start. Doing it with Lambda has actually been less expensive, provided a faster experience for our customers, and was significantly easier to build than the EC2-based option.
Not bad for a project to see if I could write something in Go.
Couldn’t you attach an EBS or EFS volume and use that for temporary storage?
Sure, even if it’s on SSD, it’s still likely to be more expensive than local storage on the lambda instance, but that might still be better than using ec2.
