aprdm

64 ms·

811.
by aprdm 6y ago
I work in a company with ~20 years old code. Huge code base as well (TBs of code). It is mostly team dependent... the company adopted a monorepo for the majority of its code and I think in the monorepo everything has a place and you know wh
812.
by aprdm 6y ago
AWS has 1000s of services (literally). I would bet the vast majority of them are written in Java, including the new ones. I do not work at Amazon but I do have a couple of friends there both in Seattle and Vancouver. Everybody wants to look
813.
by aprdm 6y ago
Saying AWS uses it a lot is very misleading. Same for Microsoft. I won’t dispute that there are some teams using it but the majority of new projects aren’t in rust and there’s no trend for it.
814.
by aprdm 6y ago
This trend of wanting to move fast and break old code is exactly the opposite of what I want from my dependencies. Look the story of AngularJS vs React. As a library you’re the less important part of my system, I use you to save me time so
815.
by aprdm 6y ago
The conclusion in google's page has nothing to do with bugs and failures. They mention how it would be better to use it but for practical reasons (read big legacy code base) it isn't feasible.
816.
by aprdm 6y ago
Gosh this gave me the chills. I am afraid some people are that creative to cause chaos!
817.
by aprdm 6y ago
Hm, not really. It has build scripts which you do whatever you want to build your package and put somewhere and then it adjusts PYTHONPATH dynamically at runtime. You don't need Pip if you're using rez. You also don't use a s
818.
by aprdm 6y ago
Yeah totally. Our use cases seem very similar. We still haven't transitioned to python3 at our HPC. Well.. we do have it available but only around ~10% of the workloads make use of python3 and their libraries. We have created the two d
819.
by aprdm 6y ago
Have you read about the problems Rez solves ? Our environments are too dynamic and need to always be available. Our hpc cluster runs millions of different combinations of software runtimes at any given day...
820.
by aprdm 6y ago
What would you suggest instead for HPC?
821.
by aprdm 6y ago
That works but doesn’t solve the problem mentioned by the other comment. We also have to support a matrix of Python runtimes and dependencies in all of our machines. We can’t pre-bake the environments. It’s a very unique problem for HPC I g
822.
by aprdm 6y ago
Yeah of course :) we have terabytes of Python code written over the past 20 years that support our business. Good luck justifying to the business to stop producing code that generates revenue to “modernize” all that stable code.
823.
by aprdm 6y ago
I would say 90% of our code base is still in 2.7 and 10% in 3.6. That’s for the desktop applications, we have a bunch of services in 3.8 already.
824.
by aprdm 6y ago
Hm not exactly what I tried to convey. I guess I would love if python stopped trying to add new syntax so often. Walrus operator, fstring, etc. should happen maybe once every two years ideally? Did we really need the walrus operator? The co
825.
by aprdm 6y ago
I believe the biggest issue is having non compatible additions to the language... for example, any code written in 3.8 with walrus operator will not work in python3.7. That is IMO not ideal. If it was security fixes / new features &#x2
826.
by aprdm 6y ago
Argh, Python is moving too fast. 3.8 has barely settled in with the walrus operator. For people doing docker based stuff with the latest and greatest always it might be OK, however, for enterprise environments where OS versions do not move
827.
by aprdm 6y ago
Usually my first instinct is to hate it but then as I spend more time on it I start understanding it better, sometimes takes a couple of months :) I have inherited a couple of 10 years+ codebases at my current place, I would say that usuall
828.
by aprdm 6y ago
Depends in the code base... a big C++ project can take a long time to compile and tests even in beefy machines. Some of our biggest projects are in the 3-6h mark using ccache.
829.
by aprdm 6y ago
even if 10% went to them.. this is 1998.. it is a lot of money back back then (more than 99% of people will make in their life time) and is a lot of money now.
830.
by aprdm 6y ago
I think for some people building software became about making the most amount of money they can possibly make, it became about grinding leetcode to get that sweet package at FAANG. Startups became about flipping crud apps that try to get us
831.
by aprdm 6y ago
It is not like you're sitting on morale high ground by squatting domains
832.
by aprdm 6y ago
It is really not that hard... I spent less time setting some nginx / letsencrypt than trying to configure google loadbalancer for static files with https and their blob storage... It likely will have a better uptime too and require les
833.
by aprdm 6y ago
This is truly great! Work in an organization with ~200 sw engineers and some of it is pretty accurate to my role as well.
834.
by aprdm 6y ago
At my team we "ticket" presentation prep just like dev work. So if you wanna do some sort of story point / ticket anlalysis per dev is no different.
835.
by aprdm 6y ago
That sounds great! Have done similar things and recommend.
836.
by aprdm 6y ago
I have done two big devops transformations so far in two different companies.. from manual deployments and no CI to CI/CD + infrastructure as code. For me it usually goes with: 1. Have people trust you by usually executing a big projec
837.
by aprdm 6y ago
What about something like sqlite?
838.
by aprdm 6y ago
I feel you probably speak of experiences in very big companies. If the software team is of a medium size, let's say, less than 50 people, then it surely isn't how you paint. The CTO / Manager(s) for sure know the impact of th
839.
by aprdm 6y ago
How's that a problem is the product works and there's less friction to develop? Let's say it produced buggy code and the cost of not enabling it was great than enabling, am sure projects would enable again..
840.
by aprdm 6y ago
I believe the right option would had been to delegate, mentor and trust. Is never too late. Have been in a similar position myself a couple of times...

More ›