Several things while I'm between full time gigs, working on learning rust for my own pleasure:
- Rust Lab Log (https://github.com/bryan-lott/rust-lab-log) a simple CLI to take down notes and timestamp them in a single markdown file. I was inspired by my dad's use of logbooks in chemistry labs growing up so that you can always look back and figure out what went right or what went wrong. Has come in very handy during a couple of incidents.
- LogProx (https://github.com/bryan-lott/logprox) a logging proxy with stupid-low added latency. We had an issue where we were accessing a deprecated version of an API and couldn't figure out where the calls were coming from. The API owner was threatening to turn off our access entirely (long story). The idea being LogProx is to send all traffic through it and create rules to log and/or block calls that match a ruleset. Added latency was so low that I had to drop down to measuring in tenths of a millisecond.
> you should probably take a step back and redefine what a PR is for your organization
I agree with this wholeheartedly if you are in a role that allows you to redefine what a PR is. In almost every organization that I've worked for, the PR is defined several levels above my pay grade and suggesting changes/updates/etc is usually seen as complaining.
May not be the most shiny/flashy thing, but I'm trying to figure out how to get out of burnout (adhd/autism/tech - all the varieties) without having to quit the world for six months.
Also, don't be afraid to revisit your favorite fiction and/or try young-adult fiction. IMO what you read matters less than building a habit or routine of reading.
Agreed. I have discovered at 53 that teenage fiction is my happy reading place. Impossible Creatures was my favourite read last year and currently reading the Eragon series. 30;years in IT has resulted in me scanning rather than reading.
I purchased the collection after reading this review. It was always a series that I wanted to read when I was younger but never did. Trying to get back into reading fiction again and this felt like a great place to start!
> Can I use jj inside a repo that was already initialized with git?
Yes.
> What does the workflow look like to use jj on an existing git repo that all of your coworkers use git for?
I struggle a little to answer this because on some level, the answer is "whatever you'd like it to be." That is, from your co-workers' perspective, nothing changes. You push some changes up to a git repo, they have no clue you used jj to do it. But I also feel like that maybe isn't answering your question.
I suppose what I'm looking for is maybe a translation from git to jj from the perspective of working in a repo with other users that are using git. Something along the lines of:
1. init jj in an existing git repo
2. instead of branching, do x, y, z
3. instead of committing after changes are done, do x, y, z
4. when pushing, do x, y, z
5. if someone else pushes to the same branch, here's how to handle it
6. if someone rebases and force pushes the branch, here's how to handle it
7. if you have merge conflicts, here's how to handle that
I think I'm having a hard time trying to grok the jj "mental model" while simultaneously understanding how it translates to an existing git repo.
I suspect for jj to get traction outside of single devs or companies that use jj exclusively, some extra focus in the docs giving guidance in the liminal space between would be super helpful.
I don't think these things are perfect yet, and I'm actually re-writing the whole thing, and it's going to focus on exactly these things, and there's interest in upstreaming the whole thing. That is partially why I asked, because I'm trying to make it so that these things are more easy for you in the future :) So I do really appreciate the answer.
Just wanted to say thank you for working on this, I'm going to take another read-through of those 2 links and see if it makes more sense given the extra context of this thread. Either way, I look forward to reading the updates and seeing if they click better in my brainpan ;)
Not trying to hijack, but in addition, I'd love to know how we can fight back beyond just archiving data. HN tends to lean heavily into tech skills. How can we leverage those skills collectively or individually to prevent needing to archive this data in the first place?
Agree - in my 10+ year career, I've run into exactly 2 PM's that have provided enough value to a team or project to justify their inclusion in the team or project. Both were technical enough to understand what the engineers were working on and talking about and were able to offer genuinely good suggestions.
The rest? At best they were glorified QA/QC with a large stick to hit the engineers with when the spec wasn't met exactly. And when it was, and things still failed, they still hit the engineers with the large stick and were usually promoted for it.
Just wanted to say you've built an amazing product. So much so that I got my team hooked on it and am working on getting it out to the rest of the company that needs it. Well done!!
- Rust Lab Log (https://github.com/bryan-lott/rust-lab-log) a simple CLI to take down notes and timestamp them in a single markdown file. I was inspired by my dad's use of logbooks in chemistry labs growing up so that you can always look back and figure out what went right or what went wrong. Has come in very handy during a couple of incidents.
- LogProx (https://github.com/bryan-lott/logprox) a logging proxy with stupid-low added latency. We had an issue where we were accessing a deprecated version of an API and couldn't figure out where the calls were coming from. The API owner was threatening to turn off our access entirely (long story). The idea being LogProx is to send all traffic through it and create rules to log and/or block calls that match a ruleset. Added latency was so low that I had to drop down to measuring in tenths of a millisecond.