Software engineers often work on teams. The team writes software that has value. In order to plan when that value will be realized, it is useful to know when the software will be ready to ship. Failing that, it is useful to measure how the team is doing so that management can take action if the plan isn't going to work out. Both of these endeavors involve estimating the complexity, time, or risk of various software features. This is harder than it sounds.
I first learned about Emacs Hydra in early 2015, and I didn't really understand why it would be useful, but it seemed neat, so I dug in. In short, Hydra provides a transient form of modal editing in which keys are rebound to various actions. It turns out this is a very cool abstraction, even if it can take a few moments to wrap your head around the utility. Examples are helpful.
The Ruby community is filled with attempts to use complex solutions to simple problems, often in the interest of making code smaller, tighter, or more convenient, but this is frequently a poor trade. Compactness in exchange for simplicity results in dense, complex code.
In 2008, Jeff Atwood wrote of magpie developers: those who always are attracted by the latest programming framework or tool. He concludes:
Be selective in your pursuit of the shiny and new, and you may find yourself a better developer for it.
Unfortunately, nowhere in the blog post does Jeff offer any advice as to what criteria to use when being 'selective'. In fact, the final sentence is the first time he actually advocates being selective; the rest of the post is dedicated to detailing the costs of picking up new tools:
Eventually, you grow weary of the endless procession of shiny new things.
and the value of simply sticking to whatever you know:
Who cares what technology you use, as long as it works, and both you and your users are happy with it?
Rendering a modern web page is a hugely complex task, and users expect it to be accomplished in milliseconds. It requires comprehensive support for encryption, parallel network connections, rendering each of text, images, videos in accordance with CSS, as well as just-in-time compilation and execution of JavaScript. With all this complexity comes the enormous security concerns of downloading and processing assets from remote, often untrusted, servers.
Ideally, the web would be an ecosystem built on standards, allowing anyone to build their own browser and read content on the web. In practice, the task of building (and maintaining!) a web browser is so difficult that only a few organizations can manage it: Microsoft, Mozilla, and a consortium of other companies and browsers that rally around WebKit/Blink (Opera, Vivaldi, Chrome/Chromium, Safari). This means that compared with other standards (calendars, text editors, image editors, and even spreadsheets), there are relatively few choices in the market for browsers, simply due to the overwhelming cost of building and maintaining such a hugely complex piece of software.
Programs often handle numbers that are measurements. Measurements for the same dimension (time, distance, volume, pressure, etc.) can have many different units. There are two main drivers of this diversity:
- Granularity
- Fragmentation
Time has seconds, minutes, hours, days, weeks, months, and y...
Observers are a useful mechanism to set up event flows. They are designed for 'fan out' communication, in which multiple objects are notified when a single object changes. Their power lies in their use of composition, allowing observers to be added and removed at runtime as necessary, based on the current state of the application.
Many languages have implementations of the observer pattern. Ruby, for example, has a module Observable that implements the pattern. The documentation is straightforward enough:
include Observable- Have observers implement an
updatemethod - Have observers register with the source via
add_observer - Have the source call
changedand thennotify_observers
restclient
is a major mode for Emacs that provides a simple, clear DSL for making REST API client requests and viewing the responses. I've found it very useful both when developing and testing API code, as well as when building clients that consume other APIs. It has numerous advantages over products like Postman since it uses clear syntax, can be operated entirely without a mouse, and is based purely on text, so it can be version controlled along with a project to document API call formats. I'm going to share a couple of tricks with restclient that make it even more useful as you make greater use of it.
The title of this post is borrowed from Dustin Kirkland's blog, in which he discusses in some detail the issues with biometrics being used as a method of authentication.
When Apple launched Touch ID on the iPhone and iPad, I was skeptical. Fingerprints are not equivalent to a password or PIN in three major ways:
- You leave fingerprints everywhere, including the device that uses them to authenticate you
- You can't change fingerprints; if they're compromised, there's no recourse
- Fingerprints are something you are, rather than something you know
When you move from a PIN to fingerprints for authentication, it's important to understand these differences.
Background
Today, Let's Encrypt opened up a public beta test of their service that provides a highly automated mechanism for obtaining an SSL certificate. This is very exciting because it has the potential to usher in a new era of free, ubiquitous encrypted internet connections. Unfortunately, t...