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)

etc.

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:

     ProxyPass / balancer://balancer-group/
     ProxyPassReverse / 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:

    application-identifier
    123324243AS.com.something.something
    keychain-access-groups
    
        123324243AS.com.something.something
    

from the .app, I get:

??qq?



    application-identifier
    123324243AS.com.something.something
    aps-environment
    production
    get-task-allow
    
    keychain-access-groups
    
        123324243AS.com.something.something
    

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')'`