geoelectric

Mozilla has their issues, but please don't undermine the good they are managing to squeeze out between the head-scratchers.

Whatever else I might say about Mozilla as an organization, the people who are part of it have their hearts in the right place. The ethical messaging is sincere.

I actually passed on an offer from Palantir when I went to work for Mozilla in 2010 (I left in 2015) and I never once doubted I made the right choice. With those two options I'd absolutely do it again, Mozilla management issues notwithstanding.

Thanks for the correction, I do appreciate it.

MoCo doesn't get the goodies. It's a cash generator (in theory, probably not so much at the moment) for MoFo, and money has to flow only in that direction as I understand it.

It's not treated as a non-profit in any way, which is why it could do multi-million dollar partnerships and pay competitive tech salaries without the kind of scrutiny or restrictions a 501(c)-anything would have.

Besides the fact tech skews much higher, especially tech in SV, Mozilla doesn't have stock or equity to pass around, so has historically had relatively high cash compensation for its size instead.

I think that has become less true over the years, but it does tend to inflate salary or salary+bonus numbers unless you compare to total comp elsewhere (including parachutes and other bonuses that may not make these sheets).

I can see where it's an attractive example for cleanup behavior, for sure. But I do think the distinction between code-level cleanup and domain-level cleanup is important. You can see the fixture management as part of the test code and then they align much more closely. It's usually better to not couple that way, though, and to think of automation as something that fulfills a test instead of being the test.

I also know there's a lot of debate over xUnit patterns and, in particular, setup/teardown. My take is that the perceived value depends on a lot on background and how much experience one has actually maintaining automation strategies over time. One of the bigger dangers is losing track of what you're testing so thoroughly that any confidence you might have rests essentially in magical belief instead of periodic review. That especially hits unit tests since they're added from multiple sources, and makes things like standardized fixtures/setup/teardowns pretty useful for alignment.

I'll keep a look out for future blog posts. I'm interested in your take.

Sounds like we're really in full agreement, some semantics aside, and I think probably more people align with your semantics than mine. Thanks for the clarifications!

Depends on how derivative and how transformative and, since Fair Use is a affirmative defense for which merit is decided subjectively, doesn't really matter until you're in court. Fair Use isn't protected, per se, more that it's an exception to copyright being protected if you can convince the judge.

That said, I wouldn't even call what I was looking at derivative. I can barely match the transit lines up for most of it, and the styling is completely different. It goes beyond transformative to just being a unique artistic rendering of the same base system. That's the phone book scenario the article raises to a T.

It's weird to include a testing framework in it.

That just speaks to usage of any orchestration class with overridable hooks, and has everything to do with events pertaining to domain (xunit's domain being "run a series of isolated tests") and not clarifying lower-level code organization. It's sort of like the author treated onFocus and onBlur in JS DOM events as startup/cleanup. It's just entry/exit orchestration.

The editorial stuff about being unnecessary also ignores that unit tests must fully reset the fixture between every test to be isolated--one reason test doubles are nice, they can generally be reset instantly--and that one of the more popular ways to organize unit tests is around common fixture handlers, aka setup/teardown routines.

This usually makes sense if you're testing units of an otherwise cohesive module since related operations usually use related fixtures. If it doesn't make sense then, sure, you move the setup/cleanup into each test but it totally craps up being able to review them for validity, etc.

Ideally a test is a clean known fixture handed to the test, one state change, and a verification of post-state, nothing more. Anything else complicates the test to some extent or the other, and (though devs get this wrong constantly) readability is paramount in tests or you don't know you're testing the right thing six months from now. Tests have to be their own docs. That's why setup and teardown exists, to hold everything but that.

Most of the article was pretty good, though.

Just...ruby, python, C++, xunit...misguided testing advice...wtf? Felt like the author was swimming outside their lane and missed a pass in editing, frankly.

That means the transponder became non-viable at that point. Any sort of in-air catastrophe could have caused that, including onboard fire.

Redundant airplane systems protect against component failure, but they tend to still be near each other. For example, if an AA gun were to tag the plane in the right place it could easily take out power to both a primary and backup.

It really doesn't look like a mid-air explosion. It was either a massive spontaneous fire for some reason (assuming the burning thing in the social media post was the plane) or it got shot down.

I seem to remember one of the PopCap founders being active on comp.sys.ibm.pc.games, back when Brad Wardell and some of the other later-high-profile designers were in the conversation as well, mid 90s or so IIRC.

Would that have been one of you too? Those were gaming glory days for me, with limited forums for discussion and everyone gravitating to what there was. You got to rub shoulders with some pretty cool people, digitally speaking.

Also, how weird is it that the public net has been around long enough to ask things like if we met on the internet 25 years ago? My mind still reels.

Check the "highest paying companies" thread.

One of the top comments leads to a discussion of unlimited PTO. There's a long reply in there that lays out a bunch of "here's how" bullet points. Working at an unlimited PTO place, they were right on the money.

Thought PAMF was a part of Sutter Health?

Anyway, I agree with you. Kaiser is convenient, but the standard of care of HMO-nominal (i.e. poor).

I've used PPOs with PAMF for lots of years now, and it's been far better than Kaiser no matter who my actual insurance provider was.

I've been at Netflix a few years now as a SWE.

There's no forced PTO, though good managers will encourage you to take it. That's relatively common from what I gather.

I've never had any friction around taking time off, if I was responsible about clearing/delaying/delegating projects and getting my day-to-day work covered.

It's easy to fall in the psychological trap of thinking you never can, sure, but since Netflix pretty much starts at the Senior level for hires (biggest reason they aren't in the first two sections probably) I think it's less of an issue. The fact you see your coworkers taking time off without the world blowing up is also a powerful social cue.

I'd never trust a startup with unlimited PTO, but Netflix actually does mean it.

I've seen a reasonable amount of infrastructure work in node too, at this point.

My basic take right now is that service-based infrastructure is probably going to favor Go (or node).

Infrastructure that's not accessed directly as a server (kicked off from a separate CI tool or whatever) has a lot of Python representation.

Which side interests you more? Personally I wouldn't be thinking either/or for any popular language or stack, more like 80/20 and what should be my 80?

This looks pretty nice, and I like the idea of a universal help/getopts syntax that can work over different execution engines (python, bash, etc.)

I just did a new install at home, and may try reimplementing some of my utility scripts in terms of this just to see how it plays.

As a US citizen, I'm jealous they take any malfeasance seriously.

Dumb question, of course, but you're logged in as aaaaaaa, right? That's what whoami returns?

I use Bitbar to display my current Apple Music song in the menu bar.

Works pretty well, and it was easy to customize the iTunes script I downloaded from their user scripts page. Was nice when I went to Catalina and the only changed I needed to make was %s/iTunes/Music for the AppleScript target name change and the plugin just worked.

If you want to feel better about those websites, Provident CU makes you pick a username with the same rules, including capitals and numbers when you register for online banking.

Someone in their IT department is the Grand High Idiot of Cargo Cult Security.

Possible these laws have a specific line about not being waiveable via contract, a la our renter protection laws. I seem to remember that might be the case for the non-compete, and I'd be surprised if the non-solicit voiding law wasn't the same.

However, I think the explicit codification also prevents that. AFAIK, once something is in state code as a requirement/prohibited/void action you can't personally waive that.

...except for everyone in CA who reads the news.

https://www.law.com/therecorder/2019/06/11/employee-nonsolic...

Edit: above was paywalled, and I didn't realize I was trial-viewing it. Think this is free for all:

https://www.lexology.com/library/detail.aspx?g=5993e280-c03b...

They were only questionably enforceable before too, since they still amounted to a contract restriction limiting someone's employment opportunities (in this case, the person being recruited).

While CA does codify non-competes (and now non-solicits) are void, general interpretation was that any restrictive contract clause wasn't going to fly in court except under very specific circumstances. CA takes a very dim view of restricting job mobility.

Ethically, totally slack if he recruited while still employed, of course, and if he literally did it at work I suspect he'll run into a "using company resources (time, building, hipchat channel, etc)" issue, which is one of the things that severely weakens a defense that whatever you do yourself, you still own.

No idea how or if that applies at a high-level action like starting a company, but if he had any technical contribution I could definitely see it coming up.

If you anticipate that their argument is that you were actually calling them one, then yes, it's the sensible thing to do to prepare yourself.

There are only a few defenses to that as an element: "No I didn't," "So what, nobody would actually believe an obvious insult," (that's the one that won) and "It's true." The latter automatically wins the suit if proven, so it makes sense to probe for it among the others.

If I recall from reading a memo/recap of the session yesterday, that exact argument came up.

I'm still shocked he won, mind you. My understanding was that he googled the Thai area in question and read its reputation before making the statement, which sure makes it look like he meant it at face value.

My astigmatism gives me doubles in any high contrast situation, whether light on dark or dark on light. Solarized/Zenburn type low-contrast palettes are the only thing that really addresses it.

And that's assuming that the 99% accurate really means 99% sensitive, 99% specific.

To amplify your point,

99% sensitive from 100000 people with an incidence of 60 means 1 false negative, assuming you can't detect .4 of a person and floor to integer.

99% specific from the same pool means 999 false positives, same assumption.

You mentioned that re: 1000 total, but the kicker:

Total population, 59 true positives + 999 false positives.

So, if I test positive, absent any more knowledge that means it's a 59/(999 + 59) chance of being true, or around a 6% chance of being true.

Probably enough for followup testing, but an interesting demo of why the statistical accuracy is meaningless unless you also know the actual incidence. 99% becomes not many % right quick.

Digitally, I use a variation on BuJo rapid logging, implemented in Markdown with plaintext. BuJo itself has become essentially scrapbooking for task management, but the basic idea of logging in bullet lists makes a lot of sense.

Markdown has three legal bullets for UL lists, which along with some sigils after the bullet/space is plenty for complex logging one line at a time. Here's the "key" at the top of each of my journals:

    #### Entry Key
    
    *   Event
    *   Project
    *   Planned Task
    +   New Task
    -   Note
    
    #### Event Status
    
    * ! Key
    * ? Maybe
    * % Cancelled
    
    #### Task/Project Status

    + ! Key
    + ? Watch
    + ^ Tracked
    + ~ Carried 
    + $ Completed
    + @ Delegated
    + % Dropped

Sample log for a day looks like:

    ### Friday :: November 8, 2019
    
    #### Highlights

    -   This cool thing that happened!

    #### Planned

    *   Some event
        -   Meeting notes
        +   Action Item

    *   Some planned task I copied from OmniFocus

    #### Journal
    
    + ^ Follow up on so and so issue
    + ^ Make sure stakeholders aligned
    
    -   Reached out to Coworker
        + $ Wait for followup
        + $ Schedule lunch for Tuesday
      
    - ! Some great idea
    -   DJSON awesome for nested JSON
    -   To extract from logs, wrap with [""]

I use Keyboard Maestro macros to quickly create the header skeletons from templates as needed and I fill in "Planned" during my daily prep. From there it's just appending to the bottom. I also have Alfred workflows and other scripts that know how to append a bullet line to the journal file, which helps a lot for logging notes from anywhere.

Periodically, I search for "+<tab>" in the text file, and it finds all the new tasks I haven't marked with sigils in the gutter row. That lets me quickly move them into OmniFocus for longer-term tracking. Someday I'll script it.

For you, if you really only want notes, even simpler. It's just a day header and appending a bunch of - bullets!

But there'll always be times when it comes down to paper. When all that fails, I have a nice-looking aged-brass Fisher space pen in my front pocket and a Moleskine Cahier (the cheap cardboard ones) in my back pocket. If there's something important to catch unexpectedly the last thing I want to do is fumble with my phone. The notebook is by far the quickest option.

There are some really nice leather wallets for Cahier/Field Guide-sized notebooks, and it actually helps balance my sitting posture by having wallets in both sides. Here's an example of one wallet I bought--I bought both a Horween and Chromexcel version from this seller and they're both high quality.

https://www.amazon.com/Journal-Horween-Leather-Moleskine-ref...

If you make it nice enough to carry around, it quits feeling like a chore to do so.

I keep a pseudo-bullet journal in markdown. Unfortunately, I rely on two things this (and a lot of other) Markdown editors won't do:

First, "-", "+" and "*" are all legal bullet characters for creating unordered lists.

This allows you to put further semantic meaning into your plaintext (for me that's notes, new tasks, events respectively) though it does get lost in render. This editor loses that distinction.

Second, and this one drives me nuts with MD editors not supporting it, "+<TAB>text" is just as legal as "+<SPACE>text" for Markdown--the spec, such that it exists, is just whitespace after the bullet.

I personally use that to create a bujo-style gutter column between the <UL> bullets and the text where I can insert a space and a resolution symbol without disturbing plaintext alignment.

So, "+<TAB>New Task" eventually becomes "+<SPACE>^<TAB>New Task" to indicate it's been tracked, for a final render of "o ^ New Task"

nvAlt is one of the few that does this right, and will actually copy the "+<TAB>" to the next line as a leader instead of only copying "+<SPACE>" or not treating the "+" as a bullet at all if a tab follows.

This editor won't even let you input a tab character. Tab always indents, whether it's opt-Tab, ctrl-Tab, or what.

I think Markdown is great, but the value I've seen is more in the semi-formatted plaintext representation than just being a text-based way to WYSIWYG. If I want WYSIWYG there are significantly more direct ways to get that. I wish more of the MD editors concentrated on optimizing the plaintext experience, as nvAlt is getting a bit long in the tooth.

Interesting bet. I like writing Bash functions, but have never wanted to put in energy to package and distribute them. I can see contributing to something like this where everything is set up and ready to go.

It will take some degree of critical mass before it really gets used, though. Here’s hoping people are patient.

Hopefully it was plain my comment is highly favorable to your tool!

Record/replay gets a bad rap, basically, but for anything short-lived it's often the superior choice.

I expected a ton of comments regarding record/replay automation being worse than programmatic, but--speaking from one of my past hats as UI Automation lead--this kind of tool can be really useful. It's super-quick to get something going that works today. Just don't expect the tests to live a long time.

That makes it really great for popping up some end-to-end "scaffolding" tests during incubation or primary development that you delete or reimplement later with "real" programmatic tests for stabilizing ongoing or incremental development. You don't really want to design the longer-lasting tests until UI flows have gelled, but this sort of quick-and-dirty you can do anytime.

There was also a really intriguing talk a number of GTACs ago that asserted that often the cost of just having to scrap and re-record a replay-based test when it breaks is lower than maintaining an equivalent programmatic one.

I'm not sure I believe that will frequently be true with proper UI automation design (page objects or some other kind of UI map, driving development of test hooks, etc). But I do suspect there's truth there vs. improper UI automation design.

If UI Auto isn't anyone's field on the team or a company doesn't want to sink significant resources into it, it's probably more likely you get the improper than proper designs by scripting, then they turn into maintenance sinkholes over time. At that point maybe record/replay is actually better.