I also want to add that I hate these "project generators" such as create-react-app when I'm just getting started. (It's just an example: I'm glad I learned React long before its existence.) They create an opinionated folder structure with template files and preconfigured tools. I don't function well in this model: if I don't immediately have a high-level overview of what the created files do, why they are created this way, I just become uneasy at all this magic that I do not understand. Each time a new thing is introduced, I need a high-level introduction covering its purpose that relates to the concepts I already know. I'm not comfortable dealing with magical black boxes unless I have at least a rudimentary understanding of the main interface of that black box.
To put this back into the concrete example, it means that hypothetically if I were to be learning create-react-app from scratch, I would immediately begin to investigate the purposes of the tools that have been configured by it, like Babel and ESLint.
I think this way too and I think it's because I'm autistic. I don't WANT to clone a project in one click. I want to understand every tool well enough to create my OWN project that serves MY use cases.
I spent a few minutes at an Apple Store holding an iPad Pro with tandem OLED, and I couldn't perceive any difference with the iPad Air right beside it.
(The even more expensive nano texture option was worse. It simply felt blurry.)
That would be a worse case scenario. The Apple stores are incredibly brightly lit, and you’ll be hard pressed to notice wining isn’t differences between any display type in such an environment.
These displays and their content are intended to impress in media viewing situations in which you’ll light control accordingly. They’ll still look good outside of that, but they offer so much more when you want to dim the lights and kick back with one on the couch with a movie or whatever.
Now if I could only get one in a size I cared about, I could be rid of LCD permanently. Alas, I doubt I’ll see this in a size suitable for what I want it for in less than 5 years or more.
I might be misunderstanding your needs but my home server uses just LVM. When I run out of disk space, I buy a new drive, use `pvcreate` followed by `vgextend` and `lvextend`.
If it only lets you select one, that's strictly less powerful. What if I want some parts of it into one commit and another parts into another? The `hg absorb` works for this case.
Yeah, it's definitely less powerful that what absorb is doing. I wasn't trying to argue that it was equivalent. I just wanted to share a bash one-liner that I've had success with in case others find it helpful.
> What if I want some parts of it into one commit and another parts into another?
Looks like absorb will automatically break out every hunk into a separate fixup commit. My one-liner will create 1 fixup commit for everything that's staged. That's typically what I need, but on the occasions it's not, I use `git add -p`, as kadoban mentioned, to stage exactly what I want for each commit.
Oh, hrm, looking at this description and the one liner, I rather like.
Once you mentioned `git add -p` I realised that this is pretty much what I do already, except with a far more efficient way of selecting the relevant commit to do it to.
Then you use `git gui`, which is part of the git distribution itself, or `tig` if TUIs are your thing. I have a key binding for `git commit --squash=%(commit)` in my tig config, so I can interactively select lines or hunks to stage and then the target commit for the squash.
That still requires you to manually select hunks. The point of `hg absorb` is to automatically select hunks even if these hunks are to be squashed into different commits.
No. How do you enable payment for such normal sockets? Even if you figure out a way to do that, the amount of payment for electric bikes is so tiny that just to cover credit card processing fees would require electric bike users to pay for exorbitantly expensive electricity.
So bike batteries are typically not more than 750 Wh. If you are trying to go on some long cross-country trip for fun, then maybe you pack three of them (2kWh of electricity). That gives you ~100 km of pedal assist.
That's still a dollar/day including CC fees. Seems reasonable.
0.75kWh per charge even at Electrify America prices ($0.64/kWh) is not enough for a single transaction. Maybe they will force you to preload the account and then deduct from your balance. But the fact is a normal outlet consumes so little electricity that it's not economically worthwhile to meter any reasonable duration of using that single outlet.
The connectors themselves aren't usually the cause for the perceived difficulty of plugging in. It's instead the weight and flexibility of the cable. Try this: plug in a CCS connector at Electrify America, and then plug in a CCS connector at ChargePoint. The latter feels much heavier than the former. Yet both are CCS connectors. Even though the former is rated for 350kW and the latter usually only 125kW.
The CCS connector itself doesn't dictate what kind of cables manufacturers use and what kind of cooling. Tesla designs cables with less cooling and they replace them more often; other brands want long-lasting cables with fewer field visits so they add more cooling. And some brands use liquid cooled cables, others simply opt for thicker copper without liquid cooling. All of these have nothing to do with the connector.
That's true, although connector quality does vary as well. And in his case, he was using an adapter, which adds some unique potential problems. Some connectors have electronic latches. I've had those engage before the connector and the adapter were fully seated, making it nearly impossible to push them the rest of the way together. Usually fiddling with the latch button is the easiest way at that point.
Also, some connectors have nasty white plastic, while others have really nice and usable handles.
> Code coverage has absolutely nothing to do with code quality
I'm going to disagree respectfully here. I don't think hard-and-fast rules on code coverage are useful (e.g. must achieve 90% coverage before merging), but just having code coverage run automatically and its results displayed is useful. When I add an "if" check and one of the branches isn't covered for example, I start to think what if some junior engineer didn't understand the reason behind this "if" check and decided to delete this check altogether? If no unit tests fail after deleting this check, that junior engineer might not have enough context to judge whether this check is needed in production.
You're really speaking about documentation quality, though. The most horribly written code ever written can still do a good job of documenting what the "if" does.
I think the real takeaway here is that code quality doesn't really matter. The most horribly written code is still quite fine to work with if well documented.
You actually brought to my attention a metric that I hadn't previously considered but now desperately want: branch coverage. I don't need 90% of lines covered, because one cannot measure coverage of missing lines
/* BadImpl.java */
if (theFile.exists()) {
doTheAwesome(theFile);
}
// uh, and else ... what?
/* BadImplTest.java */
@Test
public void looksGoodTestCoverage() {
theFile.create();
instance.runIt();
println("hurray, 100% coverage");
}
versus if the coverage tool was able to artificially rewrite the code to be this way, it would show up as not covered:
Yeah and the point is that there is more embedded knowledge about surface tension here. For example if I put a small drop of water onto my desk, it does not spread out into a thin film of one water molecule thick. It remains a droplet due to surface tension.
And if you put an oil drop into that little bead of water it will spread out because it destroys the surface tension. That's why Rayleigh was playing around with it to begin with, and the reason why a thin film of oil calms the surface of water.
I also want to add that I hate these "project generators" such as create-react-app when I'm just getting started. (It's just an example: I'm glad I learned React long before its existence.) They create an opinionated folder structure with template files and preconfigured tools. I don't function well in this model: if I don't immediately have a high-level overview of what the created files do, why they are created this way, I just become uneasy at all this magic that I do not understand. Each time a new thing is introduced, I need a high-level introduction covering its purpose that relates to the concepts I already know. I'm not comfortable dealing with magical black boxes unless I have at least a rudimentary understanding of the main interface of that black box.
To put this back into the concrete example, it means that hypothetically if I were to be learning create-react-app from scratch, I would immediately begin to investigate the purposes of the tools that have been configured by it, like Babel and ESLint.
reply