scoates

Hello. Agreed that we need comprehensive privacy reform.

You should probably read the article, though. (-;

I have access to everything (on the tech side) at Matter, and if you put your social security number into the app, I wouldn't be able to access it to write it on a sticky note. That's the whole point.

PS I'm also old and jaded. (-;

Hello. Thanks! This old blog design is showing its age, certainly, but I appreciate the nod to URL Sentences: https://shiflett.org/blog/2010/url-sentences

It's because builds are completely reproducible, and therefore they have to be built in the same place (in `/nix`), and you can't create directories off of `/` on modern Mac setups.

(I should have marked this Show HN; my mistake)

Thanks. Probably useful to remember that this isn't a production run of thousands of units, and I already had the WROOM board on hand…

The reasonably-priced response to this is the CAMEO from Silhouette.

The disturbing part is the domain name not the status code.

The PR I submitted to the backend (that was not needed after a bit of discussion) was Go.

https://github.com/cds-snc/covid-alert-server/pull/241

(I don't know Go (-: )

🇨🇦

Yeah, my interactions with them were all great. Really refreshing.

This is the link you want: https://github.com/Miserlou/Zappa yeah. The other thing is probably dead.

Indeed. (Zappa contributor here.) It especially aligns with the (below) concern of "why should I write code twice?".

For the most part, your code will work in both places the same, if you have a Python WSGI app.

apple.com: PasswordGenerationDisallowed

Hmmmm.

FWIW, I have this in my userChrome.css to fix that horizontal tabs annoyance: `#TabsToolbar{ visibility: collapse !important;}`. Not ideal, but a workaround I can forget about most of the time.

Thanks. Yeah; that's the idea for bootstrapping. At some point, I'd love it if sites themselves published APIs or at least manifests (similar to /robots.txt or favicon or a URL in a HTTP header, etc.) of how to programmatically change passwords.

A real problem I ran into is that a full browser is required for many operations, now. Instagram.com, for example, is completely opaque to non-DOM+JS browsers. Right down to the shamefully empty `<noscript>` block.

I have been working on-and-(mostly-)off on something like this for a while: https://github.com/scoates/celobox

Wish I had more time to spend on it.

Can help avoid that with the even-newer t2.unlimited [1] instances, it seems.

[1] https://aws.amazon.com/blogs/aws/new-t2-unlimited-going-beyo...

…not if they're moving faster.

I had the pleasure of tasting a Tonka Bean IPA I brought back from Brazil a couple years ago. Immediately ordered some of the beans (thanks to my freedom as a Canadian (-: ). They're really great in crème brûlée.

The HTML of the page doesn't contain "888". This makes it impossible for some disabled people to get the number at all.

This makes it a practical concern in addition to bad taste.

That's also age.

In case you haven't seen it (didn't notice it linked in the replies): http://codepen.io/gunderson/full/GJJPpV/

FWIW, I recently wrote up my Vermont hit list: https://seancoates.com/blogs/vermont/

Need to make a trip down there as soon as possible. I'm getting thirsty.

I see. Good point.

I love this visual, but elevators have way more safety mechanisms than poorly-designed web sites. Check out the source HTML of instagram.com for a great example. /-:

Searching the page for "14" misses this.

The jading goes much deeper than 12 hour days and "culture", in my opinion.

It's "easy" to get stuff done if you have no strong feeling of responsibility for the longevity of the things you're working on, or if you've never experienced the pain that comes with this lack of planning/implementation. The first 90% is easy, but the last 10% is what makes things stable, performant, maintainable, deployable and secure (not advocating for doing this last; just saying it's easy to ignore).

It's also easy to be excited about things when you['re naïve enough to] expect them to work "properly". People who've been doing this for a long time recognize that it's really rare that software Just Works™, and for that reason, things need to be architected to make room for failure. Building things without an acceptable failure mode is super fun until it fails, and then it's even worse than not doing it in the first place.

Doing stuff right takes a long time and is hard. It's truly satisfying to nail it, but it's certainly not always fun/exciting.

Very short sighted of parent post. One of the main reasons I don't consider (very hard) switching away from iPhone is the integration with my Mac (which I do still think is worth using, at least unless they ruin this platform).

If I had a Linux laptop………

> modifying something directly in production

That's a good way to lose access to production forever.