Same for me. Many times I would have an idea, but I would think ahead of all the mundane and tedious things I would need to complete to implement it and not even get started. Now I work with the LLM to do those more tedious and mechanical parts and frankly the LLM is generating pretty similar code to what I would have written anyway and if not I just rewrite it. A few times I've even been pleasantly surprised when the LLM took an approach I wouldn't have considered and I actually liked it better.
Personally I didn't care about shims or performance. I find the asdf commands to be difficult to remember because they are unintuitive. See the "UX" section of the link above.
you can't use latest:20 in a .tool-versions file or many other places
This has always bugged me in asdf where I just want to say something like python:3.11.* where I don't care about the patch version number just that some 3.11 version is used.
Obsidian Security | Principal Backend Engineer | Philadelphia, Newport Beach, Palo Alto | REMOTE | Full-Time
Obsidian Security is at the forefront of SaaS security, dedicated to detecting and mitigating threats effectively.
With our advanced threat detection solution, we visualize user activity, identify employee compromise, and mitigate insider threats, ensuring data security before a material breach occurs.
Skills:
- Python (specifically experience with asyncio)
- SQL
- Rust a plus
- SQLAlchemy
- Fastapi
- Scylla DB a plus
- Go
Obsidian Security | Threat Backend Engineer | Newport Beach, Palo Alto, Philadelphia | Onsite or Remote | Full-Time
Obsidian Security is at the forefront of SaaS security, dedicated to detecting and mitigating threats effectively.
We are hiring for multiple roles.
Threat Detection Team:
With our advanced threat detection solution, we visualize user activity, identify employee compromise, and mitigate insider threats, ensuring data security before a material breach occurs.
Skills:
- Python (specifically experience with asyncio)
- Rust a plus
- SqlAlchemy
- Fastapi
- Scylla DB a plus
- Go
The only time I've ever experienced a memorable amount of pain was when I was working on a project that used one of the newer options like Poetry. Using a virtualenv, a requirements.txt file, and pip I have not had serious issues in 15 years of using Python.
Obsidian Security | Threat Team Engineer | Newport Beach, Palo Alto, Philadelphia | Onsite or Remote | Full-Time
Obsidian Security is at the forefront of SaaS security, dedicated to detecting and mitigating threats effectively.
We are hiring for multiple roles.
Threat Detection Team:
With our advanced threat detection solution, we visualize user activity, identify employee compromise, and mitigate insider threats, ensuring data security before a material breach occurs.
Ensuring SaaS applications are robust and compliant with industry standards. You'll focus on real-time monitoring, proactive vulnerability mitigation, and managing sensitive data access for optimal security and continuous compliance.
Obsidian Security | Threat Backend Engineer | Newport Beach, Palo Alto, Philadelphia | Onsite or Remote | Full-Time
Obsidian Security is at the forefront of SaaS security, dedicated to detecting and mitigating threats effectively.
We are hiring for multiple roles.
Threat Detection Team:
With our advanced threat detection solution, we visualize user activity, identify employee compromise, and mitigate insider threats, ensuring data security before a material breach occurs.
Ensuring SaaS applications are robust and compliant with industry standards. You'll focus on real-time monitoring, proactive vulnerability mitigation, and managing sensitive data access for optimal security and continuous compliance.
Obsidian Security | Threat Backend Engineer | Newport Beach, Palo Alto, Philadelphia | Onsite or Remote | Full-Time
Obsidian Security is at the forefront of SaaS security, dedicated to detecting and mitigating threats effectively.
We are hiring for multiple roles.
Threat Detection Team:
With our advanced threat detection solution, we visualize user activity, identify employee compromise, and mitigate insider threats, ensuring data security before a material breach occurs.
Ensuring SaaS applications are robust and compliant with industry standards. You'll focus on real-time monitoring, proactive vulnerability mitigation, and managing sensitive data access for optimal security and continuous compliance.
What makes this particularly novel is the realization that traditional security measures, designed primarily for on-premises infrastructure, may not be enough to combat these SaaS-based attacks effectively.
There can definitely be some downsides to this approach. For example, let me see what the CI script does to deploy. "make deploy", ok let me checkout the Makefile. Ok, that calls some python module "deploy.py". I tend to get frustrated with all the indirection and would prefer to just see the deploy steps in the CI script itself.
I mean that example is frustrating because obviously `make deploy` and `python deploy.py` are both pretty simple so they are easy to remember.
One common pattern that I'll see though is deploy.py not being top level so `python deploy.py` becomes `python scripts/deployments/staging/deploy.py` so you still get the benefit of not wondering where `deploy.py` is.
Another is the configuration file also having a default version that is not obvious. Something like `configuration/deployments/staging.yaml`.
Now you might argue that I'm exaggerating (and I think it's fair to say that some refactoring could be valuable), but the simple `python deploy.py` now actually is.
`python scripts/deployments/staging/deploy.py -c configuration/deployments/staging.yaml` which is significantly harder to remember than `make deploy-staging` for example.
I am a big advocate for and user of this pattern with Make.
However there is one non-trivial downside with (GNU) Make, and that is the non-visibility of env vars set with `export` when running `make -n`. That is, if your Makefile looks like this:
Then `make -n do-it` will not show the exported FOOBAR variable. This makes it somewhat more difficult to audit or inspect with `make -n`.
The output from `make -np` is incredibly verbose and isn't easy to filter with standard CLI tools, which makes this doubly frustrating. You basically need to write an AWK/Perl/Python program to parse it. If there was one feature I'd pay good money to add to a new version of GNU Make, it's an option to emit more-easily machine-readable output from `make -p`, or to ship a script in the GNU Make package that parses it into something standard like JSON or XML.
It's nice to be able to run the same commands locally as you do in CI. Having the deployment logic outside of the pipeline specific format will allow you to do this.
Make is great because its usually installed everywhere. The downside is that it has a lot of edge cases. Breaking out right away into a better language for the more complex tasks can make sense.
I can certainly sympathize with not liking the extra layers, but if you put the steps directly in CI then you either duplicate local/CI steps (and they inevitably get out of sync), or CI becomes the only way to deploy (which, depending on your situation might be fine). It can be a reasonable thing to do, but it's a pretty sharp tradeoff.
I don't think that depending on CI for deployments is the worst thing you can do. You get two good signals; 1) this compiled on my machine, and it compiles on some other random machine, so it's looking likely that this binary will start up on the prod servers ok. 2) there is some proof that the test suite passed before you ship your thing to production.
I'm really pretty OK with "if CI is down, and there's a prod emergency, and the test suite is broken", not everyone on the team can fix that. Escalate to someone who can, the 0.5 times this happens a year; the rest of the time, everyone clicks "merge" on their pull request and the code filters out into production quickly and efficiently. They don't want to think about it, but the customer gets their features as soon as possible. Not the worst thing. Way better than "our release person is on vacation, we'll restore your outage next week".
