Lessons in home remodeling

Almost a year ago, we embarked on the journey to transform our house into a home. It has been an interesting journey, to say the least. I’ve learned a lot about myself and a lot about the process. While I love our house and I consider it down, the most important lesson I’ve learned is that I never want to do this again! Why would I say this? Remodeling a house requires you to make hundreds and hundreds of decisions ranging from what faucets to get to what color paint to put on the wall. We had a general contractor who handled all the sub contractors. Dealing with the general contractor was easy and he was quite responsive.

We had an architect do the design and my dad who was in construction inspection his entire career offered to act as the project manager, per se. Man dad was at the house a few times a week and paid attention to all the details along the way helping mitigate problems that arose and guiding us on what we should do. By getting up early every day and working from 5:45 am to 2:30 pm, I was able to goto the house everyday and see what was going on with the house. Inevitably there was some problem I had to deal with or some decision to make.

Just to give you an idea of the decisions we had to make:

  • What faucets to buy
  • What countertop to get in the bathroom
  • What countertop to get in the kitchen
  • What light fixtures to buy throughout the house
  • What outdoor light fixtures to get
  • What floor to get
  • What color paint for all the rooms
  • What color paint for the outside of the house
  • What kinds of toilets to get
  • What towel bars to get
  • What kinds of windows to get (I was very specific on the type of lock I wanted)
  • What sliding glass doors to get
  • What tile to get
  • What fireplace to get
  • What tile to go around the fireplace
  • What color stain for the cabinets
  • What ceiling fans to buy
  • What track lights to get
  • What thermostat to get
  • What furnace to get
  • What garage door to get
  • What garage door opener to get
  • What shelving units to get
  • What closet organizers to get
  • What sinks to get
  • What vanity to get
  • What doors to get
  • What door hardware to get
  • What speakers to get
  • What appliances to get (refrigerator, microwave, washer, dryer, range, dishwasher)


I tried to keep ahead of the contract and to make things as easy as possible for my wife, I tried to only present a few decisions to her at a time.

On top of the decisions, issues came up with just about every sub contractor. Some issues were easily resolved, some were a bit more complex. One of the most memorable problems was the day we moved in (the house wasn’t done, but enough so that we could move in), I smelled gas in the attic, so I shut off the valve to the furnace. The next morning, I went up again and still smelled gas. The shutoff valve wasn’t properly connected so I had to shutoff the gas to the house. The contractor got the sub contractor out to fix it right away, but that kind of workmanship is pretty unacceptable as it was a safety concern.

This really wore on me and caused me an immense amount of stress. Our house is now really a home and I’m very pleased with the outcome; the process, however, is one that I could have done without.

Another Stab at using OS X Server

I’ve had a few run-ins (as I like to call them) with OS X Server in the course of my career. I’ve been very comfortable with UNIX/Linux machines for a long time (I compiled my own Linux kernels when I was right out of college) and found them to be quite reliable and highly configurable. The lack of a GUI didn’t scare me and I thought it was a plus as there are tons of options for services like Apache and named (DNS) and a there was no way that a GUI could expose all of them.

In one of my contract positions, we were using a Linux box until a new IT person came in and bought an Xserve with OS X Server thinking that since he was comfortable with OS X, the server was the next logical step. While OS X Server runs on UNIX, the friendly GUI hides lots of options, some of which are necessary to running a successful server and some of which are needed when the server does something stupid. So now you have the GUI modifying settings and devs modifying settings via the command line in order to work around deficiencies in the GUI. It was just a recipe for disaster. After awhile, we resigned the Xserve to specific tasks and put the more important services on a Linux box.

My next run in with OS X Server came a few years later when the company I contracted for and then went to work for already had an investment in 4 or so Xserves. They were chosen because the lead IT guy was more comfortable with OS X than with UNIX/Linux (he was more of a desktop support guy and not a server guy). In this setup, we had to use Open Directory and I managed to unify the boxes and spread out the services. Open Directory was a nightmare because sometimes it just returned errors with no way to fix them. Again, the GUI hid things (including ways to fix problems) that would have been simple using a command line. We eventually put a few Linux boxes on the network and ran more core services on those; the Xserves still handled FileMaker Server (that’s another nightmare for another day) and Open Directory. The only saving grace for Open Directory was the GUI for user management as sending LDAP commands to populate it was probably worse than dealing with OS X Server.

I had completely put OS X Server behind me when Apple announced Xcode Server at the last WWDC. It intrigued me, but I ignored it until last week when I went ahead and created a Mavericks virtual machine and put Server on it. It was quite painless and actually looked like it had some useful features. Xcode Server, VPN, and Caching were the primary things that I couldn’t do from OS X out of the box. (I already had FTP, for my scanner, and Apache going on my media center.) After I ran the VM for a day or so, I decided to take a leap of faith and install server right on my media center and not in a VM. I was reassured in this decision after seeing some articles on how to remove it. In the olden days, OS X Server was as a separate install and couldn’t be removed. I’ve been running Mavericks Server for about a week now and it has been great, unlike my previous run-ins with the product. While it is still not perfect (Xcode Server needs some work), it is looking good. I had have to hack on a config file for the web server to do proxying as my security system runs a local service on port 8000 and in order to protect it with SSL, I had to setup SSL on the web server and proxy it, but that was just a matter of adding:

<IfModule mod_proxy_balancer.c>
     ProxyPass / balancer://balancer-group/
     ProxyPassReverse / balancer://balancer-group
     <Proxy "balancer://balancer-group">
          BalancerMember http://localhost:8000

to the config file for the site. The downside is that if I touch the site setup, my changes will get blown away.

While playing around with the Profile Manager today, I think I discovered the biggest problem with OS X Server in the past…Open Directory. In order to do MDM (Mobile Device Management) in Profile Manager, you have to turn on Open Directory. I quickly cancelled out of that and ended that experiment. I mentioned Open Directory to a co-worker who also used to do IT and he had the exact same feeling about Open Directory that I do; I hate it. I know that’s pretty strong, but that service has had many, many problems that I’m unwilling to risk my server to turn that on as I have no use for it. Maybe a company that has a dedicated IT guy has no problem with IT, but if you leave Open Directory out of OS X Server, I think Apple has a fine small business server product.

For developers, OS X Server is now free and if you’re like most geeks, you already have a machine running all the time, so might as well install OS X Server and take advantage of the caching and maybe play around with Xcode Server.

Code Signing Woes on Xcode Server

Following up on my post from yesterday, I’ve discovered that Xcode Server does something very strange in the build process. After the build, it creates a .ipa file that is suitable to install on an iOS device and a .xcarchive file that contains the .dSYM file as well as the .app file which is the .ipa file before it has been packaged up. The packaging process is basically putting the .app file in a Payload directory, zipping it up and changing the .zip extension to .ipa. Sounds simple enough and unzipping the .ipa should yield a file identical to the .app. Unfortunately this is not the case. If you run the following command:

codesign --display --entitlements - AppName.app

on the .app in the xcarchive and on the .app that is extracted from the .ipa file, you will get different results.

From the .ipa, I get:

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

from the .app, I get:

??qq?<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

It appears that the code signing entitlement, aps-environment is missing from the .ipa Xcode Server built. I can’t figure out why this is the case, but it does show that I’m not crazy and my setup works. The .ipa I create myself and upload to TestFlight works because my simple packaging script doesn’t re-codesign the .app.

So I have 2 choices when uploading to the app store:
1. Do what I described yesterday and that is resign the app on my desktop machine

  1. Take the .app file out of the xcarchive, zip it up and upload that.

Xcode Server does mangle the product and I’m not sure that is intentional. I should file a bug with Apple to see if they can fix it in the future.

I’d love to be proven wrong on this whole setup. If you have more information, please let me know.

Using Xcode Server for Builds

At last year’s WWDC, Apple introduced Xcode Server for doing continuous integration. Lots of people have tried to use it with mixed results. Recently after dealing with our build server for work (we use Jenkins), I decided to give Xcode server a try for one of my projects.

I was hesitant at first to use OS X Server (which includes Xcode Server) as I’ve had poor results with it in the past. It intrigued me often that I decided to install server and see where it went. OS X server install was a breeze and so was setting up Xcode Server.

I created a “Bot” from Xcode on my development machine and saw that it failed when the server tried to build it. No problem, I searched the Internet and all the results said to add the repository from the server instead of when creating the bot. Perfect, I did that and then the build succeeded. Yeah! I also added my Team to Xcode server so it could pull down provisioning profiles and create a certificate to build.

I checked the log and found 2 problems. First, I have a run script build phase that puts the version number in the Settings.bundle that failed and second, it was being signed using the wrong mobile provisioning profile.

I decided to tackle the second problem first. Through my searches, I found that I needed to put the mobile provisioning profile (an AdHoc one) in /Library/Server/Xcode/Data/ProvisioningProfiles. No problem. Next I also found that I needed to put the certificate and private key for the profile in the System keychain as the Xcode Server runs under _teamserver which doesn’t have its own keychain. I did that as well and found the problem didn’t go away. I started thinking about it and found that sometimes Xcode ignores the Automatic Distribution Code Signing Setting. So, I removed my Team and deleted all the other mobile provisioning profiles. Bingo, now my app was building and being signed correctly.

Next step was to figure out my build phase. After dumping the environment variables, I found that in order to put files in the .app after the build, I had to set my script phase to be:

shortversionnumber=`/usr/libexec/PlistBuddy -c "print CFBundleShortVersionString" ${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH}`
bundleversionnumber=`/usr/libexec/PlistBuddy -c "print CFBundleVersion" ${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH}`
shortversionnumber=`echo $shortversionnumber '('$bundleversionnumber')'`

echo ${shortversionnumber}


echo $dest_file

/usr/libexec/PlistBuddy -c "delete :PreferenceSpecifiers" "$dest_file"
/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers array" "$dest_file"
/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:0:Title string About" "$dest_file"
/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:0:Type string PSGroupSpecifier" "$dest_file"

/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:1:Key string VersionKey" "$dest_file"
/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:1:DefaultValue string ${shortversionnumber}" "$dest_file"
/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:1:Title string Version" "$dest_file"
/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:1:Type string PSTitleValueSpecifier" "$dest_file"

/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:2:File string Acknowledgements" "$dest_file"
/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:2:Title string Acknowledgements" "$dest_file"
/usr/libexec/PlistBuddy -c "add :PreferenceSpecifiers:2:Type string PSChildPaneSpecifier" "$dest_file"

The key was the ${BUILT_PRODUCTS} variable.

So I was almost done with the build server. I setup 1 bot for the master branch that builds when code changes and another on the build branch that also builds when code changes; however, I only push to build when I’m ready for a build. The build branch also had to upload to TestFlight, so I researched that and came up with very convoluted solutions.

I created a second scheme for the TestFlight upload and set my build branch bot to use that scheme. Then I added a Post Action to the Archive phase that looks like this (make sure you select Provide Build Settings From “Your Target”):

rm -rf ${IPA}
/usr/bin/xcrun -sdk iphoneos PackageApplication -v ${ARCHIVE_PRODUCTS_PATH}${INSTALL_PATH}/${WRAPPER_NAME} -o ${IPA}

RELEASE_NOTES=`cat ${SRCROOT}/CurrentRelease.txt`
echo "*** Uploading ${IPA} to TestFlight ***"
/usr/bin/curl "http://testflightapp.com/api/builds.json" \
-F file=@"${IPA}" \
-F api_token="${API_TOKEN}" \
-F team_token="${TEAM_TOKEN}" \
-F distribution_lists="${DISTRIBUTION_LISTS}" \
-F notify=True \
-F notes="${RELEASE_NOTES}"

echo "TestFlight upload finished!"

I thought I was all done; builds worked and were uploaded to TestFlight. The moment of truth came when it was time to upload to the AppStore. I have push notifications enabled in this app and it is properly provisioning. After the upload, I got email saying that the ape-environment key wasn’t in the entitlements. Very strange, I checked and rechecked the build I got out of Xcode Server and it was correct. I tried a number of things and in the end sort of gave up. I took the archive that the build server created, put it on my main machine, imported into Xcode, exported for AdHoc distribution, resigned it using the same profile it was already signed with and submitted it. For some strange reason, this worked. I can live with that as I don’t submit to the app store all the time.

Things to note:
* You do NOT have to create an AppStore distribution profile. You can submit the AdHoc build to the AppStore without problems. This is key as it lets you test the exact version going to the AppStore without rebuilding or resigning.
* You have to manually move your mobile provisioning profiles for AdHoc builds to your build server.
* You have to manually add your private key and certificate to the System Keychain on your build machine.
* Be careful about your build scripts as the paths are different on Xcode Server.
* You have to add your repositories from Xcode Server and not from the bot you create.
* Read the logs carefully when there is a problem.
* Apple appears to have created Xcode Server for testing and not necessarily for release builds; I hope some of this changes in the future. I’m not a huge fan of unit tests, so I may just be abusing the server by doing what I’m doing.

Overall, I’m pretty plea with having my own continuous integration server. It will catch issues where I have something different from Debug builds to Release builds. In addition, it will upload to TestFlight along with the release notes saving me time. I am a little disappointed about having to resign for the app store, but it isn’t a huge deal. I could probably modify my script to do that during the archive, but I really don’t like having to hard code in the ID of a mobile provisioning profile. I could probably check the profile into source control and reference that, but I’m OK with this solution. As I already want to move the archives to my main machine, the extra signing process isn’t a big deal.

I know that there is a lot here, but hopefully it helps someone else in the future (that person may be me when I forget what I’ve done!).

The downside of parking meters

San Diego is in the process of replacing regular parking meters with ones that are called multi-space meters. These are ones that give you a ticket that you place on your dash. I thought that these were neat as I could just pay with a credit card as I usually don’t have change around. My wife, however, pointed out the problem with these is that the minimum is 1 hour on the meter which costs $1.25. I didn’t think much of it until I had to pick something up today and found a meter with some time left on it; I dropped a quarter in it (I do have some quarters in my car) and got another 12 minutes which was plenty of time for my errand.

It turns out that the pay and display meters do take change and apparently you can put less than $1.25 in them. So the lesson is that I still need to have quarters in my car for times that I think I’ll be at a meter less than an hour; otherwise, paying by credit card is quite convenient. Now if the city could just get with the game and figure out some micropayment strategy with lower transaction fees, maybe they could reduce the minimum amount to go cashless.

Simple fix to “This accessory is not compatible with the iPhone” with mophie cases

I’ve been using mophie battery cases for a few years now when I travel as the iPhone doesn’t seem to last all day when I use it extensively. Granted the iPhone 5 has gotten better, but I typically use GPS to track my run/walk if I’m in San Francisco for WWDC or somewhere else. Every now and again when I’d charge my case, I’d get the message “This accessory is not compatible with the iPhone”. mophie’s FAQ gives some lame answer on how to fix this problem.

Recently I bought the charging dock for my juice pack and was getting this message every time my phone got to 100% charge and then overnight my phone would start to drain. After a bit of searching, I found a reference to charging cables on Apple’s support site. While this wasn’t my problem as the dock has an integrated cable, it got me thinking. My dock was plugged into a USB hub instead of directly into the wall or my Thunderbolt display. I switch the dock to plug into the Thunderbolt display and bingo, the problem went away. This tells me that the current supplied by the hub (it’s an unpowered hub as I don’t want to plug in the power supply) isn’t enough to keep the iPhone/mophie case happy.

Such a simple fix for a problem. Maybe mophie can update their FAQ with this information and save others from returning their products or contacting support.

Review: Dyson DC44 – An expensive vacuum that really sucks

When we were picking what to put in our house, we decided to go with an engineered hardwood floor as it would look nice and wouldn’t trap allergens like the carpets we had in the past did. We had a Shark vacuum that we brought to our new house and found that we were using it a few times a week because one thing that you don’t realize with a dog is just how much it can shed! Our dark hardwood was constantly covered with dog hair (he’s a light colored dog), so it started driving me crazy. The corded Shark sucked up a lot of hair, but the cord didn’t make it convenient to use.

One day when I went to Costco (it is now my job to goto Costco as we’re literally 2 minutes away from one and my wife hates going), I was browsing the aisles and saw the Dyson DC44. It was quite expensive, but I was willing to give it a try. When I got home, I told my wife that if we didn’t like it or thought it wasn’t worth the cost, it would go back. The Dyson’s main selling point for me was that it was cordless; while there was another cordless on display at Costco, the Dyson looked more powerful.

I hung up the charger in the garage (this is absolutely key to using it as it makes it very convenient to grab). My son loved it and wanted to vacuum. We started vacuuming about every other day as there was tons of dog hair. Was the amount we were vacuumming just because it was a novelty to use a cordless vacuum or would we keep it up? Our house isn’t that big (just over 1600 square feet), so vacuuming the entire house can basically be done on one charge (it gets about 20 minutes on a charge). About a month after I bought it, I knew it was a keeper as my wife offered our Shark to her parents. Yeah!

Now that we’re 4 months into having it, I still vacuum a few times a week and sometimes just grab it when I see a large clump of hair around (we can never completely eliminate the hair). It’s easy to use, but a little on the heavy side for my son. The canister is far too small for having a dog as I have to empty it 3-4 times when I do the entire house; it is adequate for quick cleanups, but a pain for the full cleaning.

* It is easy to use.
* Cordless makes it very convenient.
* Charging base is well designed and makes it easy to grab the vacuum out of it.
* Has enough power to pick up dog hair.
* Lots of attachments; we tend to use the attachment that spins like a vacuum and a pointed one.
* Battery is big enough for our use; using it on carpets or a bigger house, it would be too small.

* Charger cord is too short. The base has to be mounted very close to the outlet which won’t work for everyone and barely works for us.
* The canister for the debris is too small for a family with a pet.
* Very expensive.

So far, this is proving to be a good investment. We are vacuuming regularly and don’t just put it off to a bi-weekly task like we’ve done in the past. I believe that this will help us live in a cleaner house (not sure how clean a house can be with a dog in it). I would like to see it have a larger canister to hold debris and a larger battery wouldn’t be bad, either.

Overall, I have no regrets about buying this. Without this vacuum, I imagine that we’d have dog hair around all the time and make our house look dirty. Cordless vacuums have come a long way and I’m not sure I’d go back to a corded one even if it offered me more power. The cost is the biggest hurdle in me recommending this product to others, but if you have some spare change, this is well worth a look.