msum's comments

For one of our Samsung TVs, we were able to put the update on a thumb drive (we're old, we still have some around) and then use that to install the update on the TV.

It's kind of funny, we bought these TVs because they were "smart" (when they first came out) but they were so clunky and unreliable we disconnected them and used either PS or Apple TV for other things. Now we wouldn't connect our TVs to the internet for anything, and only use PS5s for specific things. We mostly just use our Apple TV.

This is what we've been doing for a few years now. It works.

A friend told me about the Dropbox setting last night, so I logged in and turned it off. This morning, I went to look for the setting to take a screenshot but it's gone. The setting just...isn't there anymore.

Made me feel like I was going a bit crazy TBQH. Surely I didn't misremember?

Annoyed because it was a convenient file storage solution and now they have proven themselves untrustworthy so I have to set up my own thing. My fault for trusting to begin with, I suppose.

This article aligns with a lot of my person experience. I'd add a few of my own observations on design systems:

1. The team making the design system needs to be really passionate about making a design system specifically

2. Everyone on the design system (DS) team needs to be pretty far in their careers, and have a few failed or quasi-successful attempts in their past experience.

3. Everyone's skills should overlap but each individual should bring their own depth/area of expertise.

4. I've never seen a "contributing back" model work, really. There can be some collaboration, or specific asks, but when you have a really cohesive DS team, they took the time to become that cohesive and it shows.

5. No matter how good the docs are, there will always be people who don't read the docs. I'm tempted to go as far as to say that I think there should be an onboarding course on how to use the design system that teams have to take before they can use it. (I legit don't know how else to reasonably solve this issue).

6. Make it compliant with accessibility requirements (at least bare minimum WCAG Success Criteria). I've seen that alone drive adoption for design systems.

I've been creating for web for 25+ years now, and I've only seen 1 or 2 successful design systems. It's so easy to get it completely wrong, or get off track.

Sooo much this. I think we are going to see a rise of “wait that’s not cool” defensive measures _in general_.

FWIW, OWD writes open source technical content and is not responsible for the design of MDN nor the blog, ads, or login and membership features of the site. That is done by Mozilla.

The OWD team writes technical documentation on APIs, HTML, and JS. OWD also works on information architecture and browser compatibility data. They contribute mainly to https://github.com/mdn/content/ and https://github.com/mdn/browser-compat-data/.

Mozilla, not OWD, is responsible for Yari, the platform behind MDN Web Docs (https://github.com/mdn/yari). The MDN blog, ads, AI and design, the MDN infrastructure, are fully owned and controlled by Mozilla.

I know some folks who work on this content and TBH it’s the folks we’d want working on this content.

And a Pema Chodron book.

This is neat to read. The README for the Ember.js repo (github.com/emberjs/ember.js) was updated recently too, and I feel like there's a lot more specific clarity about what Ember really has to offer, especially for folks who might not have considered it an option yet.

Ember just got a facelift with Octane, and they’re open source & have a good community for support.

Things that are more useful to know:

- What's your mechanism for bias self-check?

- If someone gives you specs and you notice that something is off, what do you do?

- If you have to solve a problem you haven't solved before, how do you approach it?

- What's your take on accessibility on the web?

- What's your process like for deciding that you're at the point in your career where you can mentor others?

- What do you prefer to do when you see someone else getting nit-picked?

- You're just about to finish a feature and have a great idea for improving it. What do you do?

For all of these things, people will likely give different answers but those answers will tell me a lot about whether or not they would end up being really useful for the kinds of teams I build.

Ember used to require jQuery but recently moved to removing it by default; users can opt-in if they still need it. Once the project moves to a later version of Ember I suspect the jQuery bit will drop off. (Who knows, though...)

Going strong since 2011, although Ember is aimed a lot more toward quiet business productivity.

What some see as constraints, others see as consistency. It's more typically seen in "dashboard apps" but it's also great when you need to quickly spin up a new site and don't want to have to configure anything. I know movie studios in LA that use it for those kinds of promo websites, because of the fast turn around time.

Another thing that is cool about Ember is the community-driven process- if you have a good idea for Ember and the energy to make it happen, it typically will happen. Makes you feel like you can make a difference if that's your thing.

It's super easy to pick up for a weekend project, and the Discord community is active enough to find support when you have questions.

Also https://medium.com/ember-ish is incredibly useful.

I really enjoyed the EmberConf talk about movie studios using it for movie promo sites because they needed to be able to get them up quickly. I think if you took that concept and maybe a blog post about doing an Ember PWA (https://madhatted.com/2017/6/16/building-a-progressive-web-a... for example) then maybe the large part doesn't matter so much...

The thing that has most impressed me about Ember is the way the teams on a project at giant corp will not do things correctly (honestly, some days it feels like they are doing weird crap on purpose to try to get it to fail) and Ember still works.

For a tiny glimpse of context- we have globally distributed teams who all work on different (isolated) parts of the project using ember-engines. All of these parts can either be stood up as a standalone app or become part of one host app. And every single one of these is consuming a single UI Addon that has components, minimal services, and themes.

Think about all of the moving pieces there, all of the parts where teams can disagree or do weird stuff, and yet somehow when it all comes together, we have so many things that could colossally fail, yet nothing does. We have a few bugs that are hard to reproduce but that's because we do weird stuff, not because Ember does. It's really epic when I sit back and think through all of it.

If you haven't tried Ember in ages, or ever- this is definitely the time to try...and I mean really try. Some of it will be a paradigm shift, but a worthy one.