jidiculous

It's good that your team is empowered to tailor its rituals to its needs. It seems that a lot of people forget that the Agile manifesto[1] is loose enough to allow for team-specific customization: "Individuals and interactions over processes and tools".

1: https://agilemanifesto.org

I can't imagine (haven't tried it so I'm just speculating here) that Magit functions very comfortably on something like a deep clone of the Linux repo, but I think there would be very few monolithic projects most of us would encounter with that kind of lengthy history in our day-to-day work. Maybe some Googlers could weigh in on how their large repos are handled by Magit?

> but the performance profiles & characteristics that we must know about in order to make a choice on which tool to use. And it shouldn't be that each user has to figure it out on their own, dig into PR's or whatever.

That's an interesting take – I like the idea of a catalog of standard tasks with implementations in several languages as well as their performance characteristics. I suppose Rosetta Code gets the ball rolling with this, but it's missing some performance metrics. It reminds me of Ben Hoyt's piece[1] on counting unique words in the KJV Bible in different languages.

1: https://benhoyt.com/writings/count-words/

Yeah, as I understand it (I currently work in another department), anything sub-10k has much less red tape for fed government procurement in Canada.

Somewhat related: part of the Government of Canada (ESDC) has started their own pilot for making micro-acquisition opportunities much easier to both set up on the government side, and bid for on the contractor side. https://twitter.com/MicroBuysGC

I tend to use my commit messages for things like this.

there's an effort to replicate Magit in VS Code: https://marketplace.visualstudio.com/items?itemName=kahole.m...

Yeah, that default ruleset is quite sparse. It would be nice to see Go's Code Review Comments (https://github.com/golang/go/wiki/CodeReviewComments) added as a basic ruleset.

Are you still maintaining the project? It looks like it's been a while since the last commit or release.

Staticcheck for Go kind of does something similar in that it outputs Googleable error codes, but doesn't actually print a link to the pages. It's also included as part of golangci-lint.

https://staticcheck.io/docs/checks

It is 100% a Google language. Step 0 of their contributor guidelines is to use a Google product (ie a Google account) for authorship of your commits[1]. It's insane to me that this is required for contribution to the language's development.

[1]: https://golang.org/doc/contribute#google_account

There's a bit of a reporting bias when it comes to BTC's (or even crypto itself) environmental impact. We're only able to say "it uses as much electricity as X country" because there's a well-defined ledger of every BTC transaction.

The question is how much non-crypto "conventional" currencies cost the planet.

That being said, BTC probably isn't the "best" cryptocurrency. I'm not sure about the details because I don't know much about this space now, but other commenters have pointed out that it's more efficient for ledgers to record proof of stake rather than proof of work.

I don't think it's an antipattern if you're working by yourself. As you said, it's a safety net that helps your confidence in case something does go wrong. The only thing I'd recommend changing might be to make your commit messages a tiny bit more detailed, even for the interim commits - that way you know what's going on at each commit if you do have to eventually do a `git bisect` to hunt down a regression.

Going a step further and rebasing interactively to tidy up your logs would also accomplish the same goal, but if it's just for your own eyes, it's probably not worth the time.

The software isn't Citi-built though - it's Flexcube, which is an Oracle product. Still Citi's mistake (among multiple other mistakes along the way) for not a) throwing their weight around and demanding new features or b) building something in-house.

Yep, I didn't see why the author decided to snipe at Emacs and Vim at the end of the piece. Maybe 4 or 5 years ago, that criticism of Emacs would have been valid, but packages like flycheck and lsp-mode have brought Emacs at least to parity with many IDEs. In terms of Git alone, Magit has catapulted Emacs past any other editor, IDE, or Git GUI client.

imo the strength of Magit (and its author has certainly said so) is that while the Git CLI provides a slightly different interface that you have to learn for each different operation, Magit provides a consistent UI for every single Git operation it supports (around 90% of Git features).

The prize for being good at firefighting is being assigned more firefighting.

This is a very cool plugin! I'm the sole Emacs user on my team, who mostly use VS Code, and I'm always extolling the virtues of Magit. I can't wait to share this with them tomorrow!

I'm still not sure if I have my Tide/Typescript set up properly in Emacs either - I think currently I have web-mode and a couple of other packages for formatting and linting, but I'm also rarely in that world these days.

Are/were you using one of the lsp-mode packages for Typescript?

I just wish it had a feature to nest folders :(

> I don’t know if Chris Espinosa still works for Apple but I think he might have been around a couple of years before Gassé. He started as a teenager.

He's still at Apple, and was actually employee #8, making him its longest-serving employee according to his Wikipedia page: https://en.wikipedia.org/wiki/Chris_Espinosa

The coolest feature is kind of hidden away in its support article[1]:

> A Screen share slide is also a great way to show the screen of your iPhone or iPad to quickly demo an app, for example. To use your device in a Screen share, first plug it into your computer, then select it with “Add Screen Share”.

This potentially provides an easy way to use your far better iPhone camera as an external webcam for your Mac.

[1] https://help.mmhmm.app/hc/en-us/articles/360056971194

Yeah I heavily recommend magit to anyone who can tolerate Emacs (which is unfortunately a barrier). It's allowed me to discover so many powerful Git features I would otherwise never have used, and provides a very intuitive interface that does exactly what you expect it to do. This is especially true of its wrappers for rebasing and history editing.

I'm seeing this weird keyboard behaviour on wakeup with my 2012 MBP running Catalina too

Yeah this is somewhat related to the spoon metaphor[1], right? Basically another term for bandwidth, and acknowledging and accepting that your bandwidth will be at a different place from someone who is healthy.

1: https://en.wikipedia.org/wiki/Spoon_theory

> Their newer MacBooks are going to be ARM based, which, I think, is mostly so that they have more people to develop apps for their phones and iPads.

I think it's oversimplifying the situation to say "Apple wants ARM just for mobile", though. While that's certainly a benefit of having a single architecture to support in their product ecosystem, there have been plenty of threads on HN about how Intel's rate of chip improvements have been stagnating. The much-touted scaleup of their 10-nm chips ended up being delayed by 2 years, and their 7-nm chips aren't arriving until 2023, by their own (likely optimistic) estimate[1]. The more likely narrative is that relying on Intel became untenable both cost- and performance-wise.

1: https://www.theverge.com/circuitbreaker/2020/7/23/21336356/i...

I use web-mode, tide, react-snippets combined with yasnippets, and prettier. You can see my config [here](https://github.com/jidicula/dotfiles/blob/master/init.el#L61...) (or search for "react-snippets" if that line number is outdated).

lsp-mode recommends the same on its guide for improving performance: https://emacs-lsp.github.io/lsp-mode/page/performance/

Sure thing, I've just emailed you.

I'm pretty new to HN so I'd really find that post interesting – having them listed in one place would be useful.