geoelectric

I actually use Karabiner now to do Ctrl if held, Esc if tapped. It’s a little tougher to walk people through though:

1) install karabiner elements

2) select complex modifications

3) add rule

4) import more from internet

5) import change caps lock key v4

6) add rule change caps_lock to control if pressed with other keys, to escape if pressed alone

...is my actual current setup, along with a bunch of other key mapping. But I started with what I posted above, which everyone with Mojave+ on a MBP has available already.

Mapping the Caps Lock key to Esc in the modifier remap interface is how I handled this situation (and others with essential ESC). Figured that probably wasn't coincidence that they added Esc to it when the new keyboard was introduced--was as much of a nod to mitigating a bad idea as we got.

But yeah, it was stupid, especially given that software developers are a very visible market for them in the Bay Area. As soon as the 16" came out with an Esc, I ordered one at work and bought one at home so I guess they won, but it's another step towards getting me on a Linux or Windows PC a generation or two down the line.

If he's shooting for self-destruction and eventual reclusiveness, he's doing a great job. Seems unlikely that's his intent, though, and that's pretty much what's happening.

At this point, I'm fairly sure he either has a cyclic mental illness causing him to be reckless in waves; is incredibly sleep-deprived to the point of executive function broadly going sideways; or has a serious problem with tweeting (and apparently earnings calls) while on stuff.

It's possibly all three.

Whatever the case, it resembles a lot what my ADHD did when it was completely unmanaged and at peak. But I didn't have a few billion dollars to make people have to put up with me. It definitely smells like impulse control/executive function in some way or the other.

There's no content to check out at all between here and the download link, primarily. Therefore it can't be for anything other than specifically to get downloads.

For what it's worth, I'd have been more positive about your post if the website weren't solely a meditation blog and a link to the app stores with very little info on the app itself.

I like checking out apps via Show HN -- via their websites or technical blog posts. I'm not generally going to up someone's download count from one of these posts by actually spending time with the app before I'm introduced to it.

I subscribe to Headspace and like it OK, but I definitely subscribe because I like that particular dude's voice and it's a positive trigger for me now. Otherwise there's nothing particularly special about them compared to Insight Timer or any other mature service.

This looks cool, but it's also the most direct advertisement I've seen on HN.

There would potentially be an age bias, though probably less in FB than a lot of other services you could cherrypick from. It'd also arguably bias older, since FB has been aging up in audience from what I can tell.

Without reading the study, though, possible they actually controlled that in the demographic profile for the ad.

Edit:

Going to the other thread confirmed this. From the paper,

"This study had several limitations. First, our sampling strategy selected for members of Santa Clara County with access to Facebook and a car to attend drive-through testing sites. This resulted in an over-representation of white women between the ages of 19 and 64, and an under-representation of Hispanic and Asian populations, relative to our community. Those imbalances were partly addressed by weighting our sample population by zip code, race, and sex to match the county. We did not account for age imbalance in our sample, and could not ascertain representativeness of SARS-CoV-2 antibodies in homeless populations. Other biases, such as bias favoring individuals in good health capable of attending our testing sites, or bias favoring those with prior COVID-like illnesses seeking antibody confirmation are also possible. The overall effect of such biases is hard to ascertain."

Definitely, if I were using rendered output primarily that'd make a ton of sense of course.

As you surmised, though, I use VS Code, vim, nvAlt, and iOS text editors as my primary tools (depending on setting) and actually create/read the journal in pure plaintext.

The markdown formatting is more so I can c/p rendered versions from a preview HTML page to Google Docs and other targets that understand rich text from clipboard but not markdown directly--I can create meeting minutes and whatnot from my notes very quickly that way.

You can't hide it in plaintext, which is the point.

I think your post got partially eaten by HN as formatting but I understand the []() format for MD--but you can see where that's at least 2 chars longer than just putting in the raw URL, and not super necessary in my editor that auto-linkifies. The markdown formatting is so I can share it with other people and paste into gdocs, but 50 char wide plaintext is the primary format.

It's also an internal shortener service within an established company that maintains it well, but I appreciate your points for public ones.

This is pretty cool!

I might be able to learn from your outer loop, actually--this is close to a much simpler problem I've needed to solve.

I take my notes in markdown bulleted lists, and try to make them very narrow so they fit on the side of my monitor. I shorten all my links to keep the character count down. The shortener we use at work times out the links if they're not used, though, so in old notes I can go back and discover my alias is gone.

I've been meaning to write something that just sweeps my notes and hits the links through the shortener URL periodically as a keepalive. Since the notes are not always conveniently in one tree with nothing else around, I was thinking something a little richer than text extraction piped to curl.

If nothing else, maybe this'll inspire me to get off my ass and actually get it done.

Thanks for the tip! I've been looking for something up to date that wasn't part of a huge suite.

Well, there aren't that many things specific to them unless you're talking hardware specs. They're all part of the MacBook family, so it's valid to call them that.

I'd blame Apple who decided not to name the 12" and left it only with its family name. Sure, that's how it used to be, but post 2000s that's just not a model name anymore on its own, anymore than iPhone or iPad is.

Think "12 inch MacBook" probably would find the most hits, though. Probably even better than the "MacBook -pro -air" thing I suspect you were doing, since those two get mentioned in the same articles a lot.

At least they've mostly backed off the "The New <old name>" type crap they were doing with iPad 3, etc. You want to talk hard to search for...

At this point, I think anything you do is going to not be better than what the system could automatically do for itself. Their change will basically give you that 80% bit.

There's something to be said for occasionally running the battery down to zero and charging it all the way back up, of course, but I wouldn't think of it as an effective regimen with current battery tech.

I'm also not sure how quickly it's expected to drop in capacity. IIRC, batteries drop a notch when they start getting used, plateau there for a while where it mostly depends on environment (try not to charge them when it's 110deg ambient, for example, overheating will kill a battery fast); then eventually drop again and start heading on down.

And, of course, all of this scales by how cold it currently is ambient because lithium batteries have reduced charging capacities cold (though I don't think it damages them permanently like heat does).

For all I know, 95% (roughly where you're at) is the expected amount once all factors are concerned I wouldn't worry too much. Maybe just get some comparative specs on MacRumors or with one of the utilities (some benchmark against everyone else iirc)

Almost certainly, yes. I didn't note the capacity out of the box, so that 98% from spec is a bit handwavy for sure.

That said, Apple's usually pretty good about shipping things erring over spec, and publishing the low side of the real range. It was probably at least the spec amount when I got it.

If you check the power tab under System Information, you can find some battery health info that might be illuminating. For example, my newish MBP16:

  Charge Information:
  Charge Remaining (mAh): 8362
  Fully Charged: Yes
  Charging: No
  Full Charge Capacity (mAh): 8647
  Health Information:
  Cycle Count: 18
  Condition: Normal

Looking it up, specced full capacity is 8818 mAh, so I'm at 98% health right now--probably lost a point or two because I leave it constantly plugged in at work. Willing to bet yours is much lower.

There are a few apps out there that can do a better analysis too. CoconutBattery used to be a good one, no idea if it's still around, but they were common.

Any plans for dark mode? It's a dealbreaker not having it on Mac post-Mojave IMO.

In my experience, bitmap comparison testing is pretty hard to keep going unless you have a dedicated service for maintaining the bitmaps, updating them when needed, a nice reporting system that will shade the difference area, and people with enough time to review the results to figure out what the difference means and determine root cause. I'm sure some of that has become easier over time with off-the-shelf tooling, but since I'm still seeing bespoke systems out there doing it I doubt it's become turnkey easy yet.

It's also not something you want to do until the UI has solidified for that spot--which sometimes never happens, for some apps. It also has the issue that you can often only pixel-compare between two shots from the same rendering system--that is, same browser version if you're testing browser, same graphics drivers and rendering subsystem version if you're native, etc. Frequently that means testing against frozen reference environments that become increasingly less relevant to in-field behavior over time and are also a maintenance load to qualify and update.

When thinking of the "test pyramid" and why, for example, UI tests are at the point due to high fragility vs. low specificity vs. high effort to triage and maintain, I'd put bitmap testing at the very tippy-top on an antenna above the pyramid. They're useful, but have a large hump to set up, a long tail of rather heavy maintenance, a failure could mean almost anything under the hood, and they churn like a mofo during any flow or visual refactor whatsoever with no possible way to abstract them to mitigate that.

At that point, it's not really about the usefulness anymore, and more about the opportunity cost of not doing something different with the time. I think they're usually pretty questionable unless you're actually testing a rendering system where the bitmap is the primary output. A custom-rendered component ancillary to the application probably wouldn't meet that bar in most cases unless it were complex and central enough to merit the operational risk and stable enough to mitigate the same.

The article title is going to get people to summary judge without reading.

The actual article is a nice exploration of prioritizing unit tests based on context-driven testing principles: the decision-making around how to concentrate tests on your codebase in areas that need it, while not getting hung up on dogmatically creating them for areas that are already stable enough.

Without commenting on Mitchell's fitness as CEO, I think there are a few important points here that don't resonate unless you were at Mozilla.

The first is that Mitchell and Gerv probably were familiar enough with each other for her to speak to this. Gerv was very prominent inside the project, and Mitchell really did know everyone in the organization (at least in the triple digit or less days).

The second is that Gerv quite openly led with his religion, and this was incredibly controversial. It caused a lot of churn when Mozilla was working out community guidelines and that discussion was anything but private. I'm sure that led her to think that speaking to that publicly was essential.

The third is that Gerv was more or less impervious to criticism about his religion or his attitude of being open with it in all arenas, and probably wouldn't have blinked at any of her take. There was a lot of open conversation internally (and IIRC externally) about it. I suspect this led her to think that speaking as frankly as she might have to him or with the org internally was appropriate.

In total, I think she was wrong on a number of counts, the biggest being that the time after someone's death is about everyone else's reconciliation and they weren't coming from the same perspective Gerv would have. The optics were awful, and a combo of natural perception of position and her detached writing style makes it sound like a CEO crapping on the line from on high. The Mozilla "relationship" structure was much flatter than that, though, and with Gerv's community prominence and impact they were closer to peers than one might imagine.

Honestly, this shouldn't be the incident that colors her legacy. It was a pretty ill-advised blog post, but I don't think it's as malicious or even harmful as people make out, knowing the names involved. It's really hard to get across exactly how unshakably comfortable Gerv seemed to be with his faith and exactly how much that colored his relationship with the org.

I can't imagine how she could have acknowledged his impact without at least touching on some of that--even if I do think saying nothing at all would've been the winning move.

I have an anxiety disorder. Mine's co-morbid with ADHD, but even if it weren't ADHD-like symptoms are well-known secondaries of anxiety and depression. For people like me, gamification helps greatly with incentivizing participation until a habit is built. I have no idea if this particular app would be what'd do it for me, but you're down on the concept in general in a way that doesn't represent my own situation well.

I do hear what you're saying, and nothing replaces social interaction, but I think you're making an assumption about this being a be-all-end-all. Maybe it would be for some, but those are probably the people who wouldn't adequately find in-person on their own anyway. Maybe this gets them far enough to do so, since just being functional enough to get help in the first place is often one of the biggest problems.

On another note, everyone's different. It's one thing to say what works for you, but your social fulfillment will likely be higher if you don't tell everyone else what will and won't work for them.

I wouldn't put too much gloss on that. I was on AOL from its original GeoWorks-based release forward, and it always had considerably more mass appeal than icb/forumnet, IRC, Usenet, or any of the other Internet-based forums/chatrooms of the time. It was night-and-day.

You have to remember before there was AOL there was Prodigy, Quantum Link/PC-Link (which became AOL), CompuServe, GEnie, etc--all services that were mass-marketed to some extent and had healthy user bases that were mostly not very technical or academic. Modems were easy to use and ubiquitous at that point so if you had a computer at home, there was a decent chance you had one.

A lot of the early AOL folks consolidated from those services and the social BBS scenes, which were also not nearly as techie as you'd imagine.

So yeah, there were a lot less of us than when they started shipping out discs with hundreds of hours and later unlimited, but the audience wasn't necessarily more sophisticated. As soon as it was a standalone app and not GeoWorks-based, in particular, it seriously took off.

I hadn't actually realized Titor was a "real" person, and I'm playing/reading through Steins;Gate Elite now. This was a little surreal to see pop up.

The tiny all-in-one monitor didn't do it any favors. People wanted to play on their TV, but that obviously wasn't going to work with a vector-based system.

I don't think that's going to prevent confusion. I'd have assumed they were phases of the same project at a casual glance.

Weirdly, that page is listed as updated in 2019. Someone must have missed the SW one.

The Southwest page does mention the 2018 incident and fatality, and was updated the day of the incident in fact. However, the incident isn't "numbered" as a fatal event--instead it has a UL bullet instead of an OL number, which looks like a mistake.

On one hand, AFAIK the event wasn't SW's fault at all--they'd performed maintenance on the engine to standards. The fan blades failed due to a material fatigue issue, and happened to hit the engine cowl at its weakest spot and detached it.

But I thought Airsafe still would've counted that as related to the operation of the plane, though, and the FLE for that flight would be like 0.007 (1/143) and still round up to 0.01. Since only flights with a fatality at all count for their calculation that'd be an overall FLE of the same.

The other comment mentions it in passing, but the ability to uplevel (operate within the scope of your caller instead of your own) means the difference between statements and function calls is blurred.

That, along with the ability to pass code block literals, lets you redefine the language into your own DSL with new control flow statements. You can define a “while loop” function, for example.

Before heavy use of closures and callbacks in dynamic languages (Array.forEach, for example) became the thing this was pretty huge, and it’s still nicer syntax sugar than you get defining control structures with that route.

I used TCL with Squish for Qt-based UI test automation for a couple of years. For stuff like that where you really do want a set of domain-specific imperatives you can string together, it was really cool to work with. Biggest downside was you could get too fancy and find yourself alone off in the weeds of your own DSL.

It's actually more that an SDET has classically been the one who writes the tools and infrastructure that QA Automation Engineers would use to write scripts.

It implies an education/experience background equivalent to any other T&I Software Engineer, but usually with additional experience in QA. Alternately, it could be a QA engineer who would be genuinely qualified as a general SWE in a promotion path, but who chooses to stay in quality as a domain. But either way it implies equivalent qualifications as a SWE at the same level.

The "real" bit is because over the last half decade or so, SDET has been blurred by title inflation. Scripters have been getting the title without any real experience maintaining longer-term or larger software projects, and who aren't qualified enough to be hireable as a SWE generalist.

That's one reason you still get "lesser than SWE" status arguments about SDET, when IME you actually tend to demand a little more in the market because of the need for experience in two separate disciplines.

My response to the comment above you has a lot more detail expanding on that.

I've been in/around QA for about 20 years now, after 5 years as an app dev and doing a career semi-shift during the 2001 downturn. For the last ten years or so, I alternated between SWE and SDET titles depending on the job, and before that between QA and QA Automation Engineer. That history is where I'm coming from here.

In short, there's been a lot of title inflation in QA, in part to avoid the "black box tester" stigma for both the employees and the organizations alike.

One of those inflations has been calling what were QA Automation Engineers--generally people writing scripts--SDETs. I saw it start to rev up in the late 2000s, and saw it accelerate (maybe not coincidentally) in the early 2010s, shortly after a GTAC talk where they claimed SDET makes 30% more on the average than QA. I suspect a lot of people asked for title changes, or a lot of managers realized they'd also look 30% better managing SDETs than QA and advocated for them.

Thing is that SDET as originally conceived was/is supposed to be a Software Engineer who specializes in testing, with the same qualifications and training as any mainline SWE. The normal domain of SDET would not be scripts, per the other response, it'd be tools, infrastructure and harnesses, maybe seeding test frameworks for incremental development during test creation, usually along with some level of QA thought leadership.

The primary difference there would be the ability to scope, implement, and maintain longer-term software engineering projects. A QA Automation Engineer might be as skilled a coder, but test scripts tend to be short bursts of isolated code and don't require as much architectural or lifecycle experience.

But SDETs are also useful in cases where you want to blur SWE and test, since most SDETs have heavy experience in both and can talk shop and build rapport with both sides. That comes in very handy when pairing with a mainline SWE, hence mentioning it as a near-requirement for that process.

No offense to you and your journey, but I'd have never stepped back from an SDET role to a QA Automation Engineer. It really is objectively worth less in the market, for one thing, and there really is a stigma there with QA in the title. It shouldn't be that way, but it is, and inflation has been the natural response.

Re: advocating for quality from the beginning,

Testing is by nature quality control. You can do it early, you can do it late, but at the end of the day it's a screening process.

That's different than Quality Assurance, which is monitoring and influencing the process and decisions when they're made to promote and advocate for quality when determining the good/fast/cheap project management compromises.

That includes arguing for testability as a primary requirement, arguing against overly complex requirements likely to produce emergent bugs you can't easily catch with QC, pointing out gotchas (hey, everyone is on vacation in December, expect crap code rushed checkins in November), basically anything you can do to reduce risk.

So in that role you're not a tester, per se, but a Subject Matter Expert in quality, hopefully influencing a whole team towards testable products, intelligent context-driven processes and good use of test pyramid, use of static analysis and other code quality techniques (think SonarQube), etc.

All this is over and above just testing, because you simply can't test quality into a project, you can only delay it until it's good enough. That type of gatekeeping is an adversarial tension fraught with both process and organization risk, and it should be avoided.

When you're an obstacle, people will have the natural tendency to work around you and resent you when they can't, which makes it an unsustainable dynamic to rely on as your 80% case. Ideally, most testing should just confirm what you already know: you have a solid process that caught all major bugs before you ever did a final pass.

Even if your org is going to just go full QC instead of QA (which is pretty typical, unfortunately) being able to absorb the full architecture and use cases around what you'll be testing is vital for coming up with an efficient and sustainable test strategy.

If you've been in QA any length of time, you know that these qualities--efficient and sustainable--aren't exactly associated with that corner of the process. A lot of that is because QA/test is often relegated to reporting on how a bug repros and how severe the issue is. You could be doing so much more, but that requires cooperation from the people around you.

When I was doing my time as a QA Engineer before swinging back to SDET, I did this by leveraging my SWE experience to talk shop with devs in low level terms until they trusted me. But it's a hard road to climb, particularly if you didn't have a flipflop like I did.

I hope that answered your questions. It does reflect a degree of personal bias, of course, but it's pretty well-informed by a long time in this corner of the industry.

Excluding QA wasn't a plus. Quality works better when there's an advocate from the beginning.

Problem is a lot of companies only engage QA for post-build integration testing. They try to phase it as a mini-waterfall within the agile cycles, which doesn't play well with agile and drags the process. At that point, leaving them to their own horizontal meetings seems like a plus, but there's a ton of opportunity cost for not having them in the primary conversation.

Other companies try to leverage QA for unit tests, but those really should be written by whoever wrote the interface as part of ensuring their intended contracts are fulfilled. That makes unit test writing not really a good QA role, other than making sure they're there.

The exception would be if you're going to pull QA in and pair-program/test TDD style--which is its own potential boondoggle. But you need real SDETs at that point, as opposed to scripters. Real SDETs aren't terribly common, and are not terribly cheap as they're niche specialists.

The best solution I've seen is to split the advocacy/short-term roles and the test/architecture/long-term development roles (even if it's two hats on one person), have them in the meeting for the former and have the horizontal run their own projects with milestone syncs for the latter.

At that point you can treat the short-term role as a team member, and the long-term roles as an internal vendor or external dependency (i.e. no expectation of control). Any sort of one-size-fits-all approach won't work.