Trials and Tribulations with My New iMac

I recently bought a new iMac, making my conversion to The Dark Side complete. I got it almost completely tricked out. I was especially glad to get the SSD/HD combination. It's a 240GB SSD for the system drive and then a 1TB HD for whatever. The problem is that the way the system comes configured from the factory you would end up just using the SSD for everything unless you do some wizardry first. So I had to go and teach myself the wizardry through a couple failed attempts before I landed on what I believe, now, to be the proper solution.

Form 1: Default Configuration
The default configuration from the factory makes the SSD the main drive where everything gets stored.  The system, all the applications, all the user folders, everything.  The problems with this configuration are that I have a 1TB drive that is now useless and the SSD is only 240GB.  This is big enough for a while and may even be big enough if I wanted to really watch my disk usage.  But the whole point is that I don't want to watch my disk usage!

Form 2: Move /Users to HD

This is more like it!  So now I have the operating system, applications and such on the super-fast (but small) SSD and all my big fat user files like pictures and music and videos on the HD.  This is how I did it:

1. Create a Users directory on the HD (named "Macintosh HD 2" by default).
2. Copy the contents of /Users to the new Users directory.
3. Open System Preferences.
4. Select Users & Groups.
5. In the lower-left corner, click the lock to unlock and make changes.  (Authenticating as an administrator also, if necessary.)
6. Right-click on a user and select "Advanced Options...".
7. Where it says "Home Directory" click the Choose button and select the new directory in the new Users folder.  (This would be /Volumes/Macintosh HD 2/Users/[username] if everything is still on its defaults.)
8. Click Ok and repeat for the other users.

The problem I ran into with this configuration is that some stuff I use at the command line chokes on a home directory path that has spaces in it.  This led me to ...

Form 3: Delete /Users and Create a Link

What the link does for you is that anything that looks for "/Users/Foo" gets sent to "/Volumes/Macintosh HD 2/Users/Foo" instead.  But it is all behind the scenes and isn't the wiser ... so it doesn't have a chance to choke on the spaces in the path.  This is how I did it:

1. Delete /Users.  (Not a big deal because everything was already pointing to the other drive.)
2. Open Terminal.
3. Type the command: sudo ln -s /Users /Volumes/Macintosh\ HD\ 2/Users

The nice thing about this is now /Users and /Volumes/Macintosh HD 2/Users were essentially indistinguishable.  But then I read this article from MacWorld and learned of a weakness in my plan ...

Form 4: Abandon the Link and Go Back to Form 2

The problem with this plan is exposed in the final paragraph of the article.  (Good thing I read the whole thing!)  What happens if at some point the HD dies?  The system could still boot because the SSD is working, but it can't because it doesn't have a way to log in as any valid user!  But how do I take the advice and still keep my command line stuff from choking on spaces?  Rename the drives!  I renamed "Macintosh HD" to "System" and "Macintosh HD 2" to "Data".  Then I had to delete the link and recreate the /Users directory.  Here's how I did that:

1. Open Terminal
2. Type the command: sudo rm /Users
3. Type the command: sudo mkdir /Users

Then I went in and created a new administrator user called "backupadmin" and left their home directory in the default /Users location.  Any other real users I create will have to be migrated to the HD by hand, but I think this will work best in the long run.

Some Thoughts on Application Stores and Openness

In writing down my thoughts on why I switched to Mac from PC, I ended up composing a big rant on the difference between the iOS App Store and the Android App Store from what I hope is a rational cost/benefit perspective.  I wanted to post these thoughts separately to protect the flow of that other article and also because I think it is deserving of its own post.

I want to divorce this analysis as much as possible from the iOS App Store and the Android App Store.  So I will generically refer to a few different things.  There is the application store.  This is the store, virtual or physical, from which applications are purchased in order to be installed upon a device.  There is the user.  This is the person or party who owns the device on which applications will be installed and used.  There is the operator.  This is the person or party who owns, operates and optionally curates the application store.  Curation is the action of managing what is contained and ultimately sold from the application store.  When I speak of curation, I'm thinking of the kind that we see in the Apple application stores.  I know that the Android application store does remove applications and perhaps even proactively prevents some applications from being listed, but these are rather rare exceptions.

Who benefits from keeping bad apps out of an application store?  The user does surely because they can purchase apps without fear.  Does the operator benefit?  They might sell a few more applications because of the benefit enjoyed by users, but they also might not.  Curation, on the other hand, is a huge cost.  Each application and every update must be scrutinized by, presumably, both automated and manual processes.  So the operator of a curated application store must spend a lot of resources for a benefit enjoyed mostly by the user.

Who benefits from fewer apps in an application store?  The user benefits if the apps that are allowed in are of the same variety, similar cost and of generally higher quality.  The operator benefits if the apps that are allowed in somehow bring in more revenue than all apps would.  Again, curation is not free.  So, once again, the operator of a curated application store is spending a lot of resources for a benefit enjoyed mostly if not solely by the user.

Who benefits from an application store that will allow any application with as few restrictions as possible?  The user is taking the risk of downloading malicious applications.  The user has to judge quality for themselves using their own time and money.  The user has to be their own curator.  The operator of the application store benefits from allowing in all applications because they have an application store without the cost of curation.  The operator benefits because users and volunteers like security researchers will find the bad apps and notify the operator who can then take corrective action reactively.  In this scenario, the operator benefits from the users' and volunteers' efforts, does not incur the overhead of curation and possibly brings in more revenue because all apps has a chance of making more money than most apps.

One of the costs of curation is that good apps can be thought bad and not allowed in to an application store.  Or the operator can use curation as an excuse for barring good applications from the application store that might cost the operator something.  These can cost the user the enjoyment or benefit of the good app.  Mistakes and maliciousness, from the perspective of the user, are the costs of curation.  These can be minimized, if the operator is interested, but perhaps not eliminated.  (Maliciousness doesn't have to be systemic, it could be that an app reviewer sees that their old college nemesis submitted an app and rejects it to "get back at them.")

Overall, it looks to me like the majority of the costs of the curated approach are borne by the operator and the majority of the benefits are enjoyed by the user.  The reverse seems to be true of the uncurated application store.  Looking at it from this perspective, I'm beginning to have a new respect for the Apple approach to the application store.

Words to Live By

A story I heard somewhere ...

A vegetarian friend of mine told me that I'm not "evolved" because I eat meat.  He said people only started eating cows thousands of years ago because they were savages, they were barbarians and they didn't know any better.  People who eat cows now are not evolved.  What a bunch of bullshit.  People ate cows thousands of years ago for the same reason we eat cows today.  Because they are easy to catch.  We're not savages, we're just lazy.  A cheetah could taste like chocolate heroin, we'll never know.  Those little bastards are fast!

I love the idea of "tasting like chocolate heroin" and look for ways to work the phrase into casual conversation.

 

We Don't Need No Steenkin' Cable!

Back in March, I wrote a post about The Ultimate Set-Top Box.  I've been thinking a lot about it lately and the fact that I just don't watch much cable TV anymore.  Sure, when I'm bored I occasionally flip through the things on my TiVo, but it wouldn't be any huge hardship to choose something else like reading a book, playing a video game or working on a programming hobby project.  So the question is ... how much extra am I spending on a cable subscription that I don't need?

I did some research.  Actually, I did some digging because Frontier Communications made it very hard to find out this information.  I tried going through their website via my account to see if I could change my plan.  They would not allow me to deselect TV from my current plan.  I could add or upgrade services, but I could not remove anything.  I finally had to resort to logging into their website as a new customer and look up the currently available plans that way.  Still, they didn't make it easy because of the dizzying array of choices available.  But I was able to finally select just FIOS Internet without TV, without Home Phone, at my current speed rating.  Making this change would save me $30 per month.  It also turns out that the next higher speed rating might save me an additional $10 per month.

As Marco Arment recently pointed out in a podcast, $40 per month can buy a lot of TV or movies on iTunes (or Amazon or Hulu or [insert your favorite video service here]).  Approximately thirty dollars will buy you a full thirteen-episode season of Doctor Who in HD from Amazon Video-on-Demand.  A full season of House in HD will run you about $56.  iTunes runs slightly more at $37 and $60, respectively.  Remember, these are HD videos that are yours to keep (so long as the DRM continues to be supported) with no commercials or other claptrap getting in the way.  $40 per month is $480 per year or eight full American-style seasons in HD.  So I could still have the shows that I really do want to watch, in a format that may allow me more freedom to watch when, how and on which device I want to watch it, and possibly still save me money.

Now I just need to figure out how to break the news to my daughter ...

Making Your Own Tools

I remember reading somewhere that you aren't a real carpenter until you've made your own tools.  Not being a carpenter of any sort, I'm not sure if its true or not, but I've started to feel like it might be true for programmers.

More and more I've noticed that IDEs are becoming required to work with code.  And more and more, these IDEs have very similar, but not the same, features.  They all offer customization of one form or another, but what's more custom than something that works exactly the way you want it to, because you wrote it that way?

So I've set out on a quest to take the journey of my programming forefathers and write, to begin with, an editor and a language with its own compiler/interpreter.  Perhaps the two will be related, perhaps not.  Perhaps the language will be generally useful or maybe it'll only be the extension language for the editor ... or perhaps it will be nothing more than an experiment in language design and have no practical purpose whatsoever.  But I expect that once I get to a certain basic level of usefulness with the editor, it will become my sole text editor since I do believe in eating my own dogfood.

Since my platform of choice nowadays is the Mac, I have already started writing my editor as an Objective-C OS X application.  I started out with the code from the article: Building a Text Editor in 15 Minutes.  It has given me a huge appreciation for the underpinnings of OS X and gotten my editor almost all the way to that basic usability level I mentioned before.

As I move forward, I'll be sharing thoughts and discoveries from my journey here.  I hope you find them useful ... or at least entertaining.

Pet Peeve - Silicon vs. Silicone

Silicon is an element used in construction of semiconductors, most notoriously computer chips.  Silicone is a type of plastic used for all manner of things, most notoriously breast implants.  Silicon is a component of silicone, but they are not synonymous.  Please stop using them as if they were.

Taxes Kill Developer Passion

I read Process Kills Developer Passion earlier today and could not wait to get home and write up my thoughts.  The essay posits that "Over the past few years, the software industry has become increasingly focused on process and metrics as a way to ensure 'quality' code."  I think the software industry as a whole has been tilting at that particular windmill for almost as long as there has been code.  I think the shift in focus is that now it is developers themselves that are trying to build systems to ensure quality code, not just managers.

It lists a bunch of ways that one would be spending time on process rather than not-process, presumably getting real work done.  He also lists a few horror stories like "... the test cases took two- or three-times as much time to code as the actual code ...".  My only question there was, "Were they good test cases?"

I agree that spending more time than is necessary on process can be seen as a tax, resources that are spent on things that do not benefit the end result of the project.  But in the cases of things that are objected to, they are not necessarily a tax.  Perhaps they were on the projects he has worked on.  But I have also seen counterexamples of the things that are listed:

• Doing full TDD, enabling the developers to write less actual code because the tests proved that it wasn't necessary.
• Requiring a high percentage of code coverage, ensuring that the tests that were written don't just test the same code over and over again.
• Having full code-reviews on all checkins, giving newer developers a chance to learn from their more experienced colleagues ... and even their more experienced colleagues being exposed to new techniques.
• Using tools to measure code complexity, so that there isn't a bunch of time wasted in code reviews saying, "I think this is too complex" and "I don't think it is".

So the processes that the article decries can be useful (or at least some of them).  It is only when there is a bunch of wasted effort through mindless devotion to "the process" that something quickly becomes a tax.  And taxes kill developer passion because a developer gets their pleasure out of creating something.  The more taxes that are heaped on top of creating something, the less pleasure they feel.  The less pleasure, the less passion.

But let us not forget the biggest tax of all, bad code.  Bad code forces one to do battle with it in order to make changes.  Bad code drags on a project so that it is moving slower and slower and slower until any change is moving the project backward because fixing one bug leads to the introduction of at least one new bug.  Bad code is a tax because the time spent fixing bad code could be spent moving the project forward.

As a wise man once said, "The only things certain in life are death and taxes."  You are going to pay taxes on your project, whether it is in the form of process to prevent bad code from entering your code base or in the form of fixing the bad code once it was in there.  Does that mean we should just suck it up and accept the drudgery of process?  Hell no!  But there's no reason process should be drudgery.  For example:

• There are many code review tools out there that significantly speed up the code review process as well as make it a searchable system that can be mined for information and learnings.  (Malevich and Mondrian are two that spring to mind.)
• Keeping track of time doesn't have to be a chore.  The Evidence-Based Scheduling in FogBugz uses a very simple system.  When you start working on a work item, you click a little dropdown and say which one you're working on.  When you stop, you set it to Nothing.  It even auto-stops for you at lunch and quitting time if you configure it so.
• Planning Poker and other practices have been developed to make planning easy, accurate and fast.

The article points out that there is a spread of skill levels amongst developers and that it isn't fair to force the best developers submit to process that is designed to prevent the worst developers from making mistakes.  Checklists and following process have shown time and again that they reduce defects even amongst the most talented.  Because all developers make mistakes.

So just as we shouldn't perceive mindless process as a magic bullet, neither should we perceive all process as evil.  Let's just strive for more and more ways to keep the taxes down.