quicksnap

I have been using Claude for 95% of the mechanical coding for months, and jj has proven to be more relevant than not for me. Because it is a better VCS tool than git, it allows to work with the firehose of commits much more seamlessly.

From practical experience from using jj daily and having (disposable) mega merges:

When I have discrete, separate units of work, but some may not merge soon (or ever), being able to use mega merges is so amazing.

For example, I have some branch that has an experimental mock-data-pipeline thingy. I have yet to devote the time to convince my colleagues to merge it. But I use it.

Meanwhile, I could be working on two distinct things that can merge separately, but I would like to use Thing A while also testing Thing B, but ALSO have my experimental things merged in.

Simply run `jj new A B C`. Now I have it all.

Because jj's conflict resolution is fundamentally better, and rebases are painless, this workflow is natural and simple to use as a tool

I'm not immediately aware. There's a certain amount of git-ness embedded in it with it being a DAG, having commits, and being compatible with git remotes. And, since the industry still runs on git, most people will need to learn it somewhat, anyway.

Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state.

And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged.

When I first tried to use jj, I wasn't entirely committed and switched between jj and git. Finally I hit a breaking point being fed up with stacks/merges and tried jj _for real_.

I recommend to give it a serious try for a few solid days and use it exclusively to really understand it. You won't go back.

The jj Discord is a very helpful place. Thanks to everyone there. Great article Isaac!

Comment · 1 year ago

also getting 503s from their api

Comment · 1 year ago

down detector is saying yes there is a problem

Here's a current-day horse carriage that costs as much as a cheap engine vehicle: https://www.carolinacarriagesuperstore.com/product-page/bran...

Same price, fewer applications.

Well said. If Matthias, a person who programs Python scripts for stress testing machines, and can navigate the hideous UI/UX of some digital oscilloscope, is not "computure-savvy"...

Give any of us a tired morning without coffee and a mis-click, and many of us could be in the same predicament.

It's awful that only a privileged subset of hacked users may get enough public attention to have Google give special treatment.

But I hope Matthias gets his channel back. I'm a long-time subscriber to both of his channels. Hopefully my comment adds into the pile and brings more notice to him :)

I used to be so pleased with CenturyLink myself. symmetric 1Gbps as well, and it was dreamy.

Then I began to exhibit packet loss. For gaming/discord, it's a death knell. I isolated the source of packet loss to be within the CenturyLink network, basically between me and the first traceroute hop. (Also retroactively verified by switching ISPs)

CenturyLink as an _offering_ is great, but their company operations and customer support is... kafkaesque and absurd. They are beyond incompetent and seem to have neither the capacity nor desire to fix any real problems.

When talking with some of the technicians and support people, the insight into their world was sad and disappointing. What a ramshackle company.

I really hope nothing ever goes wrong in your network segment :)

Heck, I'd pay $25/month if there were early access to videos and many an hour live q&a session!

As a software engineer fascinated by cars/engine work, I instantly purchased this for $25, even if the content is incomplete.

I'm sure there are many more people like me. Please keep making more videos and information. We'll happily pay more to support the effort.

After things were live, my migrations would be backward compatible. It's also possible to organize your tables where most of your data is in private schemas, and public views serve as your apis and versioning. Anything in a public view must be treated as a long-lived API until clients can be phased out.

My userbase was in the dozens at most, so pushing out a version OTA usually was effective to get things moving along.

Worst case, I had some code to check if the client version was too old and would shut it down until they updated.

As per models, what kind of details are you asking?