A blog by Jacob
Springpad is kind of like a mix between Evernote and Pinterest. It was a very clean personal organization site that I thought was pretty decent. Sadly, they announced this week that they are shutting down.
It is always a little sad when I see such a good product and many hours of innovation just die.
I’ve been looking for ways to write code inside a web browser. There are a number of offerings, and I plan on giving a serious look to the free ones.
So far, I’ve come across runnable.com, It seems like a good site to share code snippets that can be executed right on the site. Kind of like a YouTube-like site for sharing code. It isn’t the sort of site that you would want to code a large project, but good for sharing just a chunk of code that might be useful by others or useful for programming instruction.
Some of the things I am looking for when writing code in the cloud is the ability to import, export, run, and write code easily. I am especially looking for the ability to work along side my existing development practices on my home computer.
I’m an adult leader for a patrol of 11 year old boy scouts. This weekend we are going camping, and I was thinking about the dialog that might occur between the boys and their parents after the trip. I thought up these questions which I might suggest to parents in order to facilitate such dialog.
Ask about the food. What did they eat? Who made it? What was their favorite thing to eat? How was the food compared to other camping trips? How long did it take to cook? What could they have done to eat sooner?
Ask not just about the weather, but how the scout prepared and reacted to the weather. What did you do to stay warm?
Ask about the accomplishments. What was the hardest thing on the campout? What was the most rewarding?
Ask about their interactions with other scouts. Who was in the tent with you? Who was responsible for putting up and taking down the tent? How did you help the other scouts have fun? What “good turns” did you do for others?
As parents ask these questions, they shouldn’t be judgemental. It isn’t a checkup to see if the scout behaved appropriately. The purpose of the dialog should be to help the scouts make the connection between their actions and the results of their actions. By talking vocally about the campout, the scouts can turn the things they have done into things they have learned.
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.