1 - based off of my experiences both using and maintaining various infra at the University of Washington the problem is not finding talent to write software, it's the part that comes after. Maintenance, updates, et al.
A common theme is limited or no budget for updating or expanding systems such that the go from "nice" to "acceptable" to "clunky" and then worse.
Politics also becomes an issue. That aged home rolled service might have a palpable price tag to fund a major update for, but once you do discovery and scope every specialized integration made for every department and reality sets in. Whatever path is chosen is going to burn a number of parties, and using a vendor provides a baseline for functionality and a convenient scapegoat
2 - see federated auth via shibboleth, or any number of incommon tech. Or even Kerberos
This stuff exists and often works well, but brings it's own operational maintenance challenges and required specialized skill sets.
3 - only a subset of these processes were handled on paper. expectations on both the timelines and breadth of services have gone up significantly since this was all on paper
Attrs would not replace your record array. IIRC you can supply slots so it might be useful for converting raw data into your numpy types, but I suspect you'd find the overhead in function calls problematic
If you want easier than recarray and almost as fast I think you're in pandas-ville
It's interesting to me that dataclasses seemed to be a slimmed down attrs but in practice I find it replaces namedtuple not attrs
For my use the key is how easily you can add simple conversion of values to attrs. IIRC this was intentionally omitted from dataclasses. For a 1-off using a factory with a dataclass is easy but repeated uses send me back to attrs
- R packages are much more likely to include compilation of C libraries, which can cause grief if you're not experienced enough to install specific libs that might be newer than eg what apt provides
- library(package) imports the full package into the global namespace (from package import *) which is fine for small projects but scales poorly
Anaconda largely handles the first problem if you can constrain you package use to its ecosystem though.
For my anecdata the worst R package wasn't any worse than a python package that needed gdal, but I had to deal with these problems easily 5 times more often
They're supposed to be tuned but often aren't, as many motorcyclists can attest to
Further the muni often lacks resources to fix this in a timely manner after reporting. In some cases you see states effectively throw up their hands and say "if it doesn't detect you can just run the red"
dhcp. Boring, simple, and insufficient for professional work imo. Not a problem for a largely static home network
At work "the ricoh guy" manages the printers. You can access them by name (wins) or ip. I think that's a good enough solution, but it focuses all the static ip work to one small team (possibly 1 person) and to everyone else it's some characters you effectively copy paste once per laptop refresh. No networking knowledge necessary
To be clear, it's not that I think these skills lack value or practical application in lots of professional settings, it's that I think their relative position to other things has gone down
My first job was as a sys admin, and I was explicitly told that they hired me because my eyes didn't glaze over when the interview covered their static ip network
The thing is, that was then. Now suggesting a static ip immediately begs the question of what wouldn't you use dns to solve the problem instead.
Dns doesn't solve all cases but it does now cover a significant number. The industry has changed enough that I no longer expect anyone who doesn't have some background with networking specific concerns to know this stuff
I couldn't tell you if this is a net positive, but it definitely feels less relevant to my day-to-day than being competent with whatever DSL your CI pipeline uses
Growing up in US public schools cursive was mandatory in ~5th grade in my district. Then shortly after (6th grade? 7th?) it became optional and the vast majority of my peers quit writing it
I persisted because I actually preferred it, only to be actively encouraged by teachers collecting longer written assignments to write _normally_ on account of my cursive being harder to read
It didn't end up mattering - computers and printed assignments were rapidly becoming the norm. I always thought teaching cursive was a strange choice
It may be worth noting that the legibility of my penmanship is generally poor. I wonder if perhaps emphasizing legibility has similar positive effects on developing brains...
For a long while I ran testing and had zero issues.
Warning: if you're used to PPA life in Ubuntu Debian doesn't offer an equivalent that I'm aware of. EDIT sibling comments indicate home brew might solve this.
The problem with Debian is you can't usually pick "a thing" from another channel, you mostly have to fully commit. Testing is great until it isn't and anecdotally sid/unstable never fixed that for me - I just had to learn to build the occasional package from source
Ultimately I'm a lot happier having gone on that journey but it can feel very arduous the first few times apt doesn't have a recent enough version of something available
A variety of workplaces have bureaucracy in place to require additional justification beyond manager and even manager + skip level approval.
Whatever your thoughts on the suitability of a workplace like this, know that the most time/effort efficient way to get a raise can legitimately be to show up with an offer which demonstrates a higher market value than current salary to justify an emergency retention pay adjustment
See "the high cost of free parking" for a complete answer
Heavily oversimplified, back when cars first became available to the middle class city politicians had a rude awakening when street parking became congested.
Minimum parking space requirements were decided on with an overly simplistic formula focusing on providing for peak demand.
Keep in mind there are a LOT of apps deployed on systems with SELinux with few, if any, tests
Further, the divide between ops and developers in many cases leaves this as an unsolvable problem - it's not the dev's job to do sysadmin, and ops lacks the expertise (or time) to comprehensively analyze the code base
You're right that this makes the app poorly behaved, but if that can't be addressed then... permissive mode it is
> “Instead of scratching only your own itches, why not scratch your girlfriend’s itch? How about your coworkers? And people who work at your favorite restaurant? And what about your doctor? Don’t you want him to spend his time doctoring, not worrying about apt get this and grep that?”
I'm guessing the line was born from an attempt to share Linux with his SO.
For me it was getting enough experience with the various tools and tooling to learn the right tool for each job.
I started around '08 on a Django-based stack with really only university courses and prior Python programming experience. I was very active reading about the tech stacks which helped substantially.
When building mostly static content, I relied heavily on templating. When it came time to add interactivity, jQuery was right there waiting for me. When more complex behaviors were needed, I had to figure out how to write actual javascript rather than string callbacks together. Then learning to manage dependencies and assets became necessary, ... and so on.
A mentor would have been an enormous benefit. I was very lucky in that I got a wide berth to work in, and much opportunity for greenfield work.
A common theme is limited or no budget for updating or expanding systems such that the go from "nice" to "acceptable" to "clunky" and then worse.
Politics also becomes an issue. That aged home rolled service might have a palpable price tag to fund a major update for, but once you do discovery and scope every specialized integration made for every department and reality sets in. Whatever path is chosen is going to burn a number of parties, and using a vendor provides a baseline for functionality and a convenient scapegoat
2 - see federated auth via shibboleth, or any number of incommon tech. Or even Kerberos
This stuff exists and often works well, but brings it's own operational maintenance challenges and required specialized skill sets.
3 - only a subset of these processes were handled on paper. expectations on both the timelines and breadth of services have gone up significantly since this was all on paper