Tag: Mirrored: Tech Tips

These posts can also be found in my collection of tech tips.

Posted on
by

Over the years I’ve written a lot of troubleshooting posts on my blog, describing problems I’ve run into and how I solved them in hopes that other people with the same problems might find it helpful.

I’m starting to collect them on a mini-site that’s not a blog: Hyperborea Tech Tips.

Several things came together to inspire me to reorganize those posts:

  • Tinkering with IndieWeb.
  • Building a Gemini capsule.
  • Opening the developer tools on one of my WordPress-powered blog pages. There’s no reason a 500-word article should need 400KB and a dozen connections!
  • Keeping multiple WordPress blogs up to date with security fixes.
  • Reading about the garden and stream metaphor. (via)

The essence of the garden and stream is that we’ve gotten used to a constant, time-based stream of information, but some things are better handled as an idea-based, organically-growing and cultivated collection. Sometimes you want to post a status update to social media (into the stream), but sometimes you want to update a Wiki page (taking care of the garden).

A lot of stuff isn’t here because it belongs in a stream. It’s here because it became more convenient than copying a template, writing the page, adding links and uploading everything over FTP.

I’d already mirrored some of these troubleshooting posts on my Gemini capsule, so I figured they’d be a good place to start.

My goals with the sub-site:

  • Deeper dive into Eleventy, the static site generator I’d used to archive my Les Misérables commentary.
  • Dig into IndieWeb.
  • Light as possible. One CSS file, images only for content, system fonts, no JavaScript unless I have a specific thing that needs it. (And if I do have to add JavaScript, only include the parts I need, not half a megabyte of some framework or another.)
  • Look somewhat decent (and legible!) on screens from cell phone up to widescreen desktops.
  • Create a reusable template, both for my own projects and for other people.
  • Be at least as useful as the original blog posts, if not more!

Posted on
by

To keep myself from getting distracted by too many notifications on my phone, I ask myself the following questions whenever a new category pops up:

  • Will I need to act on it? (Likes/favorites are nice, but I don’t need to respond.)
  • How time-sensitive is it? (“Your ride is here” is more time sensitive than planning a get together for next weekend.)
  • How important? (“Server down” is more important than a project update. A conversation is more important than a newsletter.)
  • Is it actually for me, or is it an ad for the app service?

Then I turn off what I don’t need, turn off sound on the less urgent ones, and customize sounds for the most important ones.

So I hear when a text or instant message comes in, but not email or social media. When I pick up my phone I see emails, mentions & replies, but not favorites or boosts, etc.

It helps me a lot with alert overload. YMMV.

Posted on
by

From time to time the idea is put forth that Opera (and Firefox, for that matter) needs to start dealing with bad code. There are two problems with that view:

  1. Opera already deals with quite a bit of “bad code” (but there’s always room for improvement)
  2. Just dealing with bad code isn’t enough: you have to deal with it the same way someone else does.

#2 is the tough part.

The rules for dealing with good code are, for the most part, specific. If you encounter well-formed HTML, you can be reasonably sure you know what the author meant. But there are very few rules for dealing with bad code. Trying to "deal with it" means trying to guess what the author meant, and sometimes different assumptions are equally as likely.

Example:


<p><b>Here's some text</i> and here's some more.</p>

Did the author close the non-existent italics by mistake, meaning to close the bold? Or did he open bold by mistake, intending to open italics? Or is the closing italics tag left over from copy-and-paste? Depending on what assumptions the browser makes, it should display it as:

Here’s some text and here’s some more.

Here’s some text and here’s some more.

Here’s some text and here’s some more.

And that’s just a simple example. It gets wilder when you throw in issues like inline vs. block elements. A paragraph should never appear inside a tag for text formatting, like bold or italic. By all rights, starting a new paragraph (or more precisely, ending the previous one) should also revert to plain formatting. But a lot of old pages expect the formatting to continue into the next paragraph, because way back when, a P tag was a double-line break, not a container.

Now, suppose that Browser A always makes the first assumption, and Browser B always makes the second. If someone tests their code in Browser A, and it happens to be what they want it to do, they won’t necessarily notice that their code is broken. The result: the site looks wrong in Browser B, and the page author — who thinks the page is fine, since he tested it in Browser A — blames Browser B.

Multiply that scenario by millions of pages and you have a large chunk of the web as we know it today.

So the solution isn’t just to “handle bad code.” It’s to handle that bad code in the same way that the dominant browser handles it. And since there’s no document you can look to for guidance, that means taking every possible chunk of bad code, running it through the other browser, and seeing what it does to it.

And there are a lot of ways to break code!

Even Microsoft did this back when IE was new. At the time, lots of people were writing broken code and testing it by seeing whether it looked right in Netscape. So IE had to make the same assumptions Netscape did on certain things. Once IE became established, they diverged.

Some relevant articles:

This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community. Minor updates are on my Tech Tips site.