Month: September 2014

Posted on

Google Testing a Password Generator

I saw that Google is testing a password generator for the Chrome browser. Hmm, I wonder if that means that they will stop storing passwords in clear text?

Password-generating tools like LastPass, 1Password, RoboForm, and others are a mainstay of browser accessories, and are often recommended by security experts because they can help create and manage “strong” passwords. “Strong” refers to passwords that are difficult for hackers and computers to guess. Google’s effort, if it makes it into the regular version of Chrome, could encourage other browser makers to build password generators and make the field more competitive.

1Password has the advantage that it is multi-platform and not tied to a single browser, which I consider to be a very good thing. Having each browser create its own incompatible password manager would be even worse that each browser having its own incompatible HTML interpreter.

Posted on

More On Design – API or Not

Another recent post, again focused on API design, but could/should apply to all tech efforts (The Four Principles of Successful APIs). This time the guidance takes a slightly different approach:

    1. Understand The Strategy
    2. Decide Who You Are Really Designing For
    3. Start Small and Iterate
    4. Architect for the Long Term with Abstraction

#2 sounds like a component of #1 – your target user base should be part of your strategy. #3 is a good opportunity to apply the consistency principle from the previous posting. #4 is interesting because abstraction seems to be a hard concept for developers who tend to think that API = CRUD overlay.

Posted on

“Put Design First” – Yes Always

I had to chuckle when I read through this post titled When crafting your API strategy, put design first. It is very high-level and could/should apply to anything. Here are the main points:

    Design for consistency
    Design for scale
    Design for people

Check. Yes to all of these. I suppose some folks need to be reminded of this. Especially the ‘sling code first and declare victory at some arbitrary point’ proponents. The ones with 60 hours of production downtime a month because design ‘just slows them down’. Apparently downtime doesn’t slow them down, but it sure slows down the consumers.

Another chuckle was this paragraph, which is nearly a direct quote from me (emphasis added):

Planning too little is dangerous. But so is planning too much. This isn’t a science experiment to find the ideal design. Perfection isn’t the goal: consistency is.