Linked: Fast Software, the Best Software by Craig Mod

28 July 2019

Speed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk.

But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools.

Lots of great points in this post from Craig Mod. It can be contrasted with the point that I don’t believe teams should prematurely optimize or prioritize application speed over meeting user needs.

However — if an application is noticeably slow, especially for common tasks, I will feel annoyed every time I use it. It feels as though a shortcut has been taken for the development team’s benefit (and not mine), or maybe they just don’t know what they’re doing.

Mazda removes touchscreens from its cars

17 June 2019

“Doing our research, when a driver would reach towards a touch-screen interface in any vehicle, they would unintentionally apply torque to the steering wheel, and the vehicle would drift out of its lane position,” said Matthew Valbuena, Mazda North America’s lead engineer for HMI and infotainment.

“And of course with a touchscreen you have to be looking at the screen while you’re touching…so for that reason we were comfortable removing the touch-screen functionality,” he added.

The head-up display that top trims of the Mazda 3 get is now projected onto the windshield. The amount of time it takes the eyes to focus on the head-up display is greatly reduced because it’s now focused on a point 7.5 feet ahead of the driver.

I think this shows that just because a technology seems better (touchscreens are in all our phones!) or is newer (everything analogue should become more digital over time!) does not mean it will be a better user experience.

Read the article here

Programming language ⚡️ energy efficiency compared

30 March 2019

A team of Portuguese researchers have compared 27 programming languages by their energy use. They compared both CPU and DRAM energy usage with total time of execution and memory usage to build a fuller picture of efficiency.

The aggregated figures for energy, time, and memory across 27 programming languages.

Unsurprisingly compiled languages such as C and C++ perform best or near the top. Their modern successor Rust also does well.

Golang uses more CPU, but is still relatively lean. It’s especially impressive with memory usage, using even less than C or C++.

Swift and C# are not standouts, but both do very well both with energy and memory use. This contrasts with Java, which is faster and uses less energy, but has over twice the memory usage of these two.

JavaScript is one of the fastest interpreted language, having had over a decade of focused performance improvements. I have to assume they tested with NodeJS — I think server-side JavaScript has many interesting futures outside of this one particular tool.

Ruby and Erlang are both at the high end for energy use and CPU time. This could be because many of what were benchmarked were computationally intensive algorithms, which if you are building web applications you may not be writing many of yourself. However, many of the underlying libraries may still exhibit this sort of performance and energy profile.

All in all, I think it’s an interesting comparison, and I think it’s great to be putting a focus on energy usage as an important metric — it is something to be mindful of for both code running on servers in the cloud, and code on users devices.

You can read the full paper here, and there’s also more analysis to read.

Categorizing the elements of the modern web

1 March 2019

In the world of the web, what is a web app and what is a website is now often blended. It’s not as simple as written content is a website, and an interactive tool is a web app. Blogs can be interactive, they can provide tools, live searching, etc.

This is a high level overview of what fits where, of which rules apply to what elements. It’s mainly for myself to help me develop tools.

Content vs its Vehicle

Content

  • Navigation (Primary, Sidebar, etc)
  • Markdown
  • Images
  • Video

Site or App itself

  • CSS
  • JavaScript
  • Components
  • Icons

Mutable vs Immutable

Mutable Entities

  • Blog posts
  • Page content
  • Tag assignments
  • Editable Markdown
  • Editable components
  • Sessions
  • Git Repositories
  • Figma documents
  • Trello boards
  • Google docs / spreadsheets

Immutable Values

  • Images
  • Text snippets
  • Tags
  • Timestamps
  • Git Commits
  • Git Trees

Derivable Values

  • Resized and encoded images
  • Minified CSS or JavaScript
  • Rendered Markdown
  • Published components’ code
  • Rendered components
  • Cryptographic hashes