A blog by Jacob
REI recently announced that their 100% satisfaction guarentee only lasts for one year, whereas their guarentee used to be time unlimited.
With REI’s transition to a clothing store, its not unreasonable to have a full year to decide if you are satisfied with a pair of socks.
But when it comes to camping and other outdoor equipment, its not like I use it day in and day out. In fact, I only go camping about three times a year. If I were to buy a tent (the cheapest tents that REI sells are about $100), I would expect it to last more than three camping trips.
Paying a premium price for outdoor equipment, I expect it to last for more than just a handful of adventures. Under the old REI return policy, if I found on my fifth camping trip that the tent really didn’t stand up to the wind like I expected it to, I could return it. Under the new policy, I better go camping many times in many conditions in the first year to make sure I bought a satisfactory tent.
In fact, it was only under the really exceptional old return policy that I even considered buying expensive camping equipment at REI, because I knew that REI guarenteed my investment.
It is the year 2018….
Facebook stops working….
No one notices
I’ve seen many software products have a version numbers in the form of:
Where X, Y, and Z are integers. For example, I’m using Linux 3.8.0.
Communicating a software version number is important because it communicates the fact that the same software title can be different between versions.
Unfortunately, when using X.Y.Z numbering, too many software publishers leaves the meaning out of the components of the version number. Often changes in X mean “big change”, changes in Y mean “medium change” and changes in Z mean “small change”. So software of version 3.2.1 is much better than version 1.2.3, but version 1.0.2 is only minimally better than version 1.0.1.
The problem with this is that it it is subjective. What a publisher considers a big change might not be important to a particular customer. What a publisher considers a small change might fix a show-stopping bug for another customer. When it takes someone’s judgement to decide the version number of the next release, your version numbering scheme is messed up.
When choosing a version numbering scheme it is important to remember how the version number will be used. Sometimes, a customer wants to know how old a software release is, in which case a date-based scheme might be appropariate. In many situations, a customer only wants to know if one version is newer than another version. In this case, I might suggest a simple numbering scheme where version 20 is newer than version 19 is newer than 18.
Firefox uses an X.Y scheme where X is the release number and Y indicates how many bugfix re-releases have been made. For example, Firefox 21.2 would indicate the second bugfix release for the 21st new feature release of Firefox.
When developing a software library, I like to use an X.Y.Z numbering scheme. If the API to the library is backwards incompatible, then X increments (and Y and Z reset to zero). If I add a new feature, then I increment Y (and Z is reset to zero), and I increment Z if I fix a bug. Consumers of my library can look at the version numbering to help them quickly decide whether or not they should update. If they see only Z change, then they should be able to get the only the bug fixes and improve stability. If they need to use a new feature, they should use a version with an incremented Y component. If the X component of the version changes, the library should not be updated until the developer has an opportunity to review the changes and adapt the consumer of the library.
If you are generating QR codes, you should try for a QR code that uses only uppercase characters, numbers, and some basic symbols. This way, the code only uses 5.5 bits per character. If you were to include lowercase characters, then you use 8 bits per character.
For example, encoding HTTP://SQUAREGALAXY.COM results in this image:
But encoding http://squaregalaxy.com (lowercase) results in this more complicated (harder to scan) image:
As I stated previously, I am evaluating different note taking systems. Here are my conclusions.
Google Keep really wasn’t impressive. Evernote and Springpad both did much better.
Alexis De Tocqueville 1805-1859
Recently Google released Google Keep, which is suppose to be some sort of note-taking system. I think I might need a note-taking system, but since I’m a little wary about using Google after they shut down Google Reader, I want to evaluate several note taking systems. But before I start looking at any of them, I wanted to define my judgement criteria:
There may be other things as well. Since I’ve never looked at any before, I’m not sure what I should be looking at.
Among the systems I’ll be reviewing: Google Keep, Evernote, Springpad, I’ll be looking at alternatives like keeping text documents in Dropbox.
As I make discoveries, I’ll note them in the comments.