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!

also getting 503s from their api

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?

About a year ago I took off maybe 5 months to create a ephemeral voice messaging mobile app (Android + iOS)

Stack:

- React Native + Expo - Typescript - Supabase - Vercel - Some Vercel/nextJS-ish lamda functions so I could avoid AWS (Supabase didn't have that kind of offering yet)

For me, it was _very_ pleasant to work in. I was able to ship features via OTA updates from idea to live in literally minutes.. sometimes even under a minute.

Loved working with Supabase.

Author here. I am sure there are many articles about this already. I just wrote this nugget to be as quick and to the point on the issue, since it's a peeve of mine.

Hope it helps someone!

While waiting for tests to run, I was directed to https://en.wikipedia.org/wiki/List_of_common_misconceptions

It's not about people not handling being wrong, but about introspecting on how we deliver feedback. If people cannot take feedback or accept flaws in their work, that certainly is a problem. But this article is just asking us to think about the human relationships in our work, and to hold back on knee-jerk feedback.

I must say... this is an interesting headline to see on HN...

Just going to toss out some unsolicited love at Supabase. Working with it has been extremely pleasant, and the team is amazing and helpful.

Keep up the good work!

I've been working with Next for a couple of weeks, here's my take:

- Next.js aims for "pit of success" in building sites with React that are optimized for CDNs and small builds

- Deploying said sites to Vercel takes advantage of the CDNs, so most of the users are getting cached data.

So, for this site, I would assume:

- There is no backend - All the HTML is cached and contains a static generation of the page(s)

- The javascript is also cached

- Vercel CDN is fast.

That's it!

Strange.. I went to check this out in an incognito tab and it trashed my tab to holy hell!

Edit: Having hardware acceleration disabled doesn't help. :facepalm:

I have and love my UHK! It has a few VERY minor superficial issues but it is overall incredible, particularly for me who is not obsessed with mechanical keyboards.

The thing that draws me to woodworking, as a software engineer, is that it resembles many aspects of software, but has a wonderful imperfection inherent to it.

The more skilled at woodworking I become, the more I learn that every piece of wood is unique, and does not care about systems and methods. The grain will happily explode in your face if you try to work with it the wrong way. =)

It all makes me appreciate the physical aspects of things much more.

I love your channel so much, and am so glad to see you here commenting!

It's great that you continue to post videos. Thanks so much for combining two of my favorite things: woodworking and engineering!

The React bindings for TS are quite good--I used them every day, and they're solid.

As for a ground-up approach, the bindings for ReasonML-react show how much effort it takes to have strong functional typing for React: https://github.com/reasonml/reason-react

I believe that there will be an effort to rewrite React in ReasonML in the future by core members. The goal is the leverage the power of Reason to obviate some of the weird parts of the current React internals. /shrug

Author here.. happy to discuss anything! It's been a really great pattern to use so far. Hope someone else can benefit from this!

Objects as a higher-order abstraction, as an encapsulation of data and methods, are all fine and dandy. When I think of OOP, however, I think of deep inheritance. I'm not a great fan of the latter.

This quote made me smile.. Thanks OP! Happy holidays!

Just in case all that wasn’t enough to convince you about the superiority of the functional gospel, take this threat: FP will displace OOP, so start thinking along our lines our you will eventually lose your job

The short answer is that Reason's syntax is simpler and more enjoyable to use. I simultaneously learned both OCaml and ReasonML syntaxes and find Reason to be much easier to work with.

Perhaps people in Reason core will chime in with a more detailed answer. Here's some official information: https://reasonml.github.io/guide/ocaml/

I've been developing front-end apps for so long I was out of the loop when a friend asked me, "How can I upload a website folder to a domain".

Turns out, the easiest path is Netlify. It provides you with a CDN and storage for free, and has a nice drag-and-drop deploy interface for basic static sites.