Yev from Backblaze here -> Thanks! We tried to act pretty quickly since it was causing deletions of data. As a backup company that's a thing we try to help people avoid :P
New standards take time to gain traction. Apple putting at least one USB-C on each "new" device would go a long way towards helping USB-C gain adoption.
I think they should have 'burned the boats' and gone all in with USB-C on everything they have updated so far (I.e. MBP 13/15, iMac). Throw a solitary adapter in the box, charge a nice Apple margin on additional ones.
It doesn't fail at UX - it's intended to be a presentation manually controlled by the presenter. Just because someone posted a link to Hacker News doesn't mean the author intended for it to be here.
Even if I had seen a message beforehand telling me "just use the arrows to navigate", I still wouldn't have found those arrows. Light gray on light green doesn't exactly stand out.
I put all my presentations on the web because Linux + projectors = sadness, and I often end up having to borrow someone else's laptop to give the talk.
SourceTree went downhill after the last major UI overhaul and never really recovered. I used to love it for more involved commits (picking apart lines and hunks, etc), but now it's slow and clunky, even on nice hardware.
The main thing I like about SourceTree is that it makes it easy to stage 'hunks', or select lines to stage. I also like that (as with UIs in general) it makes it a bit harder to make mistakes (by, for example, typing the wrong flag on the command line).
But it's become unbearably slow. I really wish they'd fix this.
Do you know about `git add -p`? That allows you to stage hunks or lines interactively in the terminal. Press `s` to split a hunk, `y`/`n` to stage or not stage.
I was aware there was something similar on the command line, but hadn't explored the details. This doesn't sounds as convenient as (a hypothetical responsive) SourceTree, but thanks for the pointers.
I use TortoiseGit on Windows because working with hundreds of repos via the file browser seems more natural to me. Standalone git clients cause too much friction when working with lots of repos in my opinion. They get cluttered with a huge list of repos that I have to organize separately from how they are already organized on my file-system.
With TortoiseGit, when I find a git repo in the file-system and want to start working with it, I don't have to start another program, I can just activate the file browser's context menu with a single keystroke and then I can instantly see all of the Git commands that I normally use. I hardly even have to look at the list of commands though because the next keystroke is usually to hit the letter of the command that I want: (M)erge, (C)ommit, S(w)itch/Checkout, (L)og, etc... because you can customize the context menu to show the most useful commands.
(Disabling overlay icons in TortoiseGit is also a good idea. I typically just delete their registry entries via SysInternals/Autoruns.)
Yes. Anything less than this becomes perceptible and starts to make the UX feel janky or sluggish. That is a huge turn-off for a lot of users, even if they can't pin down the exact cause being low framerate.
And framerate in UI is a different beast compared to video. A menu animation running at 24fps feels much choppier and sluggish than a video running at 24fps.
Same here. I was trying to point out that frames per second alone isn't a useful metric for "animation quality." Ideally, you'd want to compare the frames per second to how many pixel something moves per second (or something similar).
Having said that, shooting for your monitors refresh rate isn't a bad idea — it's just that you could use those cycles (and watts) for something else. And even worse, if your app is running at 60 fps most of the time but drops to 30 fps every now and then, then it's gonna look a lot worse than the one that runs at 30 fps consistently.
