Sorry for the dumb question, is the second version actually better than the first? Because I prefer the first. But perhaps you chose this as a particularly annoying/unuseful comment
I personally don't give a shit either way but I've worked in dev shops with a clear preference for the second one. I can see their point because the code as natural language parses better but I don't think its strong enough to care about.
Sort of place that is fussy about test naming so where I would do smth like:
TestSearchCriteriaWhere
they'd want
Test_That_Where_Clauses_In_Search_Criteria_Work
I think its a waste of typing but idk, I'm willing to let it slide because I think its a pointless hill to die on.
depends on what `items` is, no? Is the `.Count` O(1)? Do you really need a variable or is it fine for the (JIT) compiler to take care of it? Is it O(n) and n is significant enough? Maybe you need a variable and spend time arguing about that name. Yes I chose this because almost everyone I know at least would argue you always have to create the variable (and then argue about the name) ;)
fussy about test naming
I get fussiness about test naming. I believe that a good test "name" should tell you enough for you to be able to "double check" the test setup as well as the assertions against the test name with some sort of "reasonable" knowledge of the code/problem domain.
As such both of those test names are really bad, because they can't tell anything at all about whether you're testing for the correct thing. How do I know that your assertions are actually asserting that it "works"?
Instead, I'd want a test named something like this (assuming that that's what this particular test is actually about - i.e. imagine this particular test in the context of a user defined search, where one of the options is that they can specify a project to search by and this particular test is about verifying that we check the permissions the user has for said project. There would be different tests for each of the relevant where clauses that specifying a project in the search params would entail and different tests again for each of the other user specifiable parameters that result in one or more where clauses to be generated):
Every single test case gives you the ability to specify both a good name and clear, concise test assertions. If I see anything but a bunch of assertions related to project permissions for the logged in user in this test, I will fight you tooth and nail on that test ;) I couldn't care less tho if you use camelCase or snake_case or whatever. I just had to choose something to post. I also couldn't care less if you had 17 different assertions in the test (we all know that "rule", right? I think the "test one thing" and "one assertion" is not about the actual number of "assert statements". People that think that, got the rule wrong. It's all about the "thing" the assertions test. If you have 17 assertions that are all relevant to testing the project permission in question then they're great and required to be there. If 1 is for asserting the project permissions and the other 16 are repeating all the other "generic assertions" we copy and pasted from previous tests, then they're not supposed to be there. I will reject such a PR every time.
It matters if there's a lot of churn or the test fails a lot but if its a test that I write and for whatever reason it never fails I think we've just wasted our time on being fussy.
I appreciate neither of those test names are great but it was just a strawman example to show the fussiness.
If I was going to nitpick it I would point out that `itemsCount` could easily be confused with `items.Count`, or vice versa, depending on syntax highlighting. That kind of bug can have a negative impact if one or the other is mutated while the function is running.
So clearly distinguishing the local `numberOfItems` from `items.Count` _could_ be helpful. But I wouldn't ping it in a review.
That’s why it’s `itemCount` and not `itemsCount`. ;)
(Because the correct English term is “item count”, not “items count”.)
Personally, I tend to only name it “count” if it’s a variable that is used to keep a count, i.e. it is continually incremented as new items are processed.
Otherwise I tend to prefer `numItems`.
Yes, this is very close to bike-shedding. There is, however, an argument to be made for consistency in a code base.
I think in this case itemCount had application in a couple of conditions later in the function, so there was value in extracting the count. In my recollection I might be missing some nuance, lets say for the sake of argument it was:
var relevantCount = items.Where(x => x.SomeValue > 5);
vs
var numberOfRelevantItems = items.Where(x => x.SomeValue > 5);
so it wasn't necessarily cheap enough to want to repeat.
Almost. I think you're reflexively doing the same thing GP was questioning (which I agree with; in the original example the new variable was just straight duplication of knowledge and is as likely to be the source of bugs as anything else (like if items were added or removed, it's now out of date)).
Here though you're missing the ".Count", so
var relevantItems = items.Where(x => x.SomeValue > 5);
relevantItems.Count
As long as it's not a property that's calculated every time it's accessed, this still seems better than pulling the count into its own variable to me.
Took me a month to learn jujutsu. Was initially a skeptic but pulled through. Git was always easy to me. Its model somehow just clicks in my brain. So when I first switched to jj, it made a lot of easy things hard due to the lack of staging (which is often part of my workflow). But now I see the value & it really does make hard things easy. My commit history is much cleaner for one.
I was scared to learn but then a coworker taught me the 4 commands I care about (jj new, jj undo, jj edit, jj log) and now I can't imagine going back to plain git.
Obviously the working tree should be a commit like any other! It just makes sense!
Well, Graphite solves the problem of how to keep your stack of GitHub pull requests in sync while you squash merge the lowest pull request in the stack; which as far as I know jujutsu does not help with.
Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow.
I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration.
Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over.
jj is actually perfectly fit for this and many other problems. In fact, this is actually the default behavior for jj -- if you squash a bunch of jj commits, the bookmarks on top automatically point to the updated rev tree. Then when syncing the dependent branches to git they all rebase automatically.
The problem however lies in who or what does this rebasing in a multi-tenant environment. You sort of need a system that can do it automatically, or one that gives you control over the process. For example, jj can often get tripped up with branch rules in git since you might accidentally move a bookmark that isn't yours to move, so to speak.
Correct (Graphite eng here for context) - we've thought about extending our CLI to allow it to sync jj with GH pull requests to do exactly this. Essentially - similar workflow but use `jj` as the frontend instead of `gt`
Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.
Rail networks are no longer a government priority in Canada because of planes and cars. We've kept some of the rail tracks, but theyre mostly just used for freight transport, not for people.
I'm curious what the missing features are in Figma from a designers perspective. You've mentioned the paywalled variables, what else? (I haven't been a product engineer in years, and have barely touched Figma in the last ~5 years)
- Clunky component and variable system; inadequate for more complex stuff with lots of parameters.
- Can't set connectors on Design files (used for documenting the navigation flow between different pages of an app).
- You can set connectors on FigJam files, but if you want to bring your components from Design files then you can't keep the instances synchronised to the component definition. And you can't attach the connector endpoint to some element inside the Design component. It's essentially just an image export of the Design component.
- Prototyping is very clunky and trying to build a flow that has elements reacting to interactions on other distinct elements is either variable hell or downright impossible.
Those are just off the top of my mind. I'm always finding threads from 5 years ago on their community forums with loads of people on the same boat and no activity from Figma side.
Look at their code, from projects or any open source contributions. Ask how they intend to write secure code, rather than asking a bunch of useless algorithmic problems
There are actually export statistics (obviously errors, possibly fraud) for these islands. Someone probably stuck the numbers in a formula without digging a little deeper.
There are people who asked several AI engines (ChatGPT, Grok etc.) “what should the tariff policy be to bring the trade balance to zero?” (quoting from memory) an the answer was the formula used by the Trump administration. If I find the references I will post them as a follow-up.
Russia, North Korea and handful of other countries were spared, likely because they sided with the US and Russia at the UN General Assembly on Feb 24 of this year, in voting against “Advancing a comprehensive, just and lasting peace in Ukraine.” https://digitallibrary.un.org/record/4076672
The theory was first floated by Destiny, a popular political commentator. He accused the administration of using ChatGPT to calculate the tariffs the U.S. is charged by other countries, "which is why the tariffs make absolutely no fucking sense."
"They're simply dividing the trade deficit we have with a country with our imports from that country, or using 10%, whichever is greater," Destiny, who goes by @TheOmniLiberal on X, shared in a post on Wednesday.
> I think they asked ChatGPT to calculate the tariffs from other countries, which is why the tariffs make absolutely no fucking sense.
> They're simply dividing the trade deficit we have with a country with our imports from that country, or using 10%, whichever is greater. https://t.co/Rc45V7qxHl pic.twitter.com/SUu2syKbHS
> — Destiny | Steven Bonnell II (@TheOmniLiberal) April 2, 2025
He attached a screenshot of his exchange with the AI bot. He started by asking ChatGPT, "What would be an easy way to calculate the tariffs that should be imposed on other countries so that the US is on even-playing fields when it comes to trade deficit? Set minimum at 10%."
"To calculate tariffs that help level the playing field in terms of trade deficits (with a minimum tariff of 10%), you can use a proportional tariff formula based on the trade deficit with each country. The idea is to impose higher tariffs on countries with which the U.S. has larger trade deficits, thus incentivizing more balanced trade," the bot responded, along with a formula to use.
John Aravosis, an influencer with a background in law and journalism, shared a TikTok video that then outlined how each tariff was calculated; by essentially taking the U.S. trade deficit with the country divided by the total imports from that country to the U.S.
"Guys, they're setting U.S. trade policy based on a bad ChatGPT question that got it totally wrong. That's how we're doing trade war with the world," Aravosis proclaimed before adding the stock market is "totally crashing."
