Andy Molloy

Update: Wrote a bit about how this has been going for me now, almost a year later: 50 Down, 20 to Go.

As a 36 year old overweight person trying to get into shape, I have some advice for all the fit and trim fresh college graduates: Do not let yourself go. Sounds obvious, but the realities of having a full time job and growing older are going to conspire against you. If you haven’t already, you will soon stop growing taller. You will no longer walk from class to class, instead you will be stuck behind a desk. You may gain a spouse, have a kid or two, and lose a majority of the time you might otherwise spend keeping fit. It will be a very exciting time, and hopefully you will be enjoying yourself. But do not let yourself go. Always be vigilant. Being young, it will surprise you how little time you have to exercise, but find the time anyway. When you start your new job, request a standing desk. If you are lucky enough to work within walking distance of some good lunch choices, take advantage. If you aren’t, pack your own lunch. Take a daily constitutional. Unless your boss is a jerk, you should be able to fit that into your work schedule. Do not let yourself go.

Because, and you already know this but probably don’t truly understand: getting back into shape when you are 36 and overweight is really freaking hard¹. It truly does not matter how fit you were in high school and college. Your body forgets. Your mind forgets. Getting back to it is a fight, one that a lot of people never win. If you are fortunate enough to be in shape now, then do yourself a favor: Do not let yourself go².

If you are young and in shape, you are probably now thinking I’m just stating the obvious. You are no doubt thinking to yourself, of course I’m not going to let myself go! I know, because I thought the same thing. In high school, I was on the swim team and by my senior year was in great shape. I wasn’t one of those bulky swimmers³, but I was slim and mostly well toned. I lost some of that muscle tone in college, but kept slim for most of my college career. Admittedly, I started adding pounds towards the end, but was still fairly skinny and healthy (as college students go). I still fit the same sized pants as in high school. Even so, I remember having an argument with one of my closest friends, who predicted I would become overweight within a few years. I thought he was being a jerk, and I was absolutely certain that he was wrong.

Shortly after graduation, I moved across the country and got my first post-college job. The next few years I gained a small amount of weight. It was subtle to me. I continued to wear the same pant size, but my girlfriend (now wife) noticed. I lived in a very walkable area, and curbed the weight gain primarily by walking almost everywhere I went. I wasn’t gaining anymore, but I never did loose any weight, either.

Now, here comes my excuse: I took a job which ended up requiring me to work 60-80 hour weeks for months at a time. To keep our butts in our chairs as much as possible, my employer catered meals for the company. Free food, endless hours of being behind a desk. When possible, I took walks with one of my work buddies. For a time I was going to the nearby gym with some other work buddies. But ultimately, I gave in. I stopped being vigilant. I forgot not to let myself go. I had to go up a pant size. It surely didn’t help that I was already on that road, and I’m not blaming the job for my weight gain; I could have kept myself fit, as evidenced by a number of my coworkers. But it was the time in my adulthood that I gained the most weight.

A few years later, I no longer worked for the 80-hour-week-employer, but hadn’t recovered from it, either. My wife and I had our first child. Losing ever more of my free time to child rearing⁴ gave me the excuse to reduce my already meager exercise time. I added yet another pant size.

I had let myself go.

My wife has asked me a few times if there are things in my life I regret. My answer is generally “no.” I’ve certainly made mistakes, and plenty of them, but I accept them, own them, and put them behind me. But this, the fact that I let myself go, I do regret. It may be the single largest mistake I’ve yet made.

And now that I am trying to get back into shape, I am paying for it. Four weeks ago I started jogging, following the C25K program. It’s hard. Painful. My body doesn’t like it. I know some of it is just my muscles not being used to the motions of running, but I also know that an awful lot of it is the extra work required to move all of that excess mass I’m carrying. But, with any luck I’ll keep at it and that excess mass will slowly disappear. It’s started happening a little already. After two years of making life changes and a month of jogging, I’m now half way to my weight goal. But there’s still a long way to go. A long way that I wouldn’t have to travel had I not let myself go.

So, no matter how obvious this sounds to you, remember it anyway: Do not let yourself go.

A few months ago, I released BabyGrow Lite, a free version of my app BabyGrow. In terms of downloads, it did relatively well, reaching the top charts in its category in many countries. In the few months it was available, it was downloaded nearly as many times as its pay counterpart has over its nearly four year lifespan (excluding a two week period where BabyGrow was featured by Apple in 2009). Unfortunately, those great numbers did not turn in to revenue for me. I attempted to monetize BabyGrow Lite via ads and a handful of in-app purchases, plus pointing users to the full version in hopes of some conversions. None of these were successful. Ad revenue is negligible and few users have felt compelled to buy any of the in-app purchases. As far as I can tell, fewer than 30 users of BabyGrow Lite has gone on to buy BabyGrow. As a result, I pulled BabyGrow Lite from the App Store a few weeks ago.

I still see potential in the free app market, though. For a few weeks I mulled over further restricting what can be done for free in BabyGrow Lite. But then there would be the development and support challenge of reducing functionality for people who have already downloaded the app. I considered a number of options for keeping existing users of the free app happy. I even implemented a key part of making that work in a recent update. In the end, I decided it wasn’t worth it, that any new attempt to use the free app market to expand my customer base would need to be a new app.

So, it is my pleasure to introduce BabyCalc, a simple app for calculating percentile rankings for the weight, length, and head circumference of babies up to three months old:

To anyone who has used BabyGrow, BabyCalc may look familiar. It is essentially the Instant Read feature of BabyGrow extracted and turned into its own app. Unlike BabyGrow, which supports kids up to 36 months out of the box and older kids with an in-app purchase, BabyCalc is restricted to three months. I considered expanding that via an in-app purchase, but decided to keep this app as simple as possible. It is designed to do exactly two things: calculate percentiles and direct users to BabyGrow.

Note the BabyGrow icon in the top left corner. Tapping this will bring up my simple pitch for BabyGrow, and a button that will take you to the App Store to (I hope!) buy it.

Like BabyGrow Lite, BabyCalc is an experiment. It required relatively little new effort and so is, I think, low risk. Even if it fails to bring the conversions to BabyGrow that I am hoping for, at least it won’t be giving away the bulk of BabyGrow’s functionality for free, like BabyGrow Lite did.

BabyCalc is available now — please go check it out! (BabyCalc is no longer available - yeah, it didn’t work out, either!)

Some time ago, Daniel Jalkut created a gist with a Jenkins job configuration to build the latest Clang (here). I decided it would be great to use this in conjunction with the Jenkins scan-build plugin to use the latest Clang to perform static analysis on all of my projects. It wasn’t completely straightforward (to me) and there are still some kinks, but here’s how I did it.

First, you’ll need to make sure a handful of Jenkins plugins are installed: Clang Scan-Build Plugin, Environmental Injector Plugin, Hudson Post build task.

Then, you’ll need the updated Clang build configuration, found here.

The updated Jenkins job adds a post build task which sets the archived clang’s executable bit (this is required due to a bug in Jenkins). It also creates a file in the Jenkins Home folder. This file is a Java properties file with a single property, STABLE_CLANG_PATH, which points to the just archived clang executable.

You’ll need to let Jenkins know where scan-build is. You’ll do this in Manage Jenkins -> Configure System. Find Clang Static Analyzer and, if needed, click Add Clang Static Analyzer. Unfortunately Jenkins environmental variables cannot be used here, so you will need to provide the full path into the Clang job. For me, this is

/Users/molloy/.jenkins/jobs/Clang/workspace/llvm/tools/clang/tools/scan-build

With Jenkin’s Clang Scan-Build Plugin, you could add static analysis to your normal build jobs. I decided not to do that, instead creating new jobs that get executed after Clang is built. This way even inactive projects get analyzed with the latest clang. You could start with a fresh job, but I made copies of the jobs I wanted to analyze then modified them for the static analyzer. You’ll want to remove the Xcode Build and any post build actions from the analysis jobs.

You will need to inject the contents of StableClangPath.txt into your build environment. If you are not already injecting anything into the build environment, this is pretty trivial. Check the “Prepare an environment for the run” in the Project’s settings. Set Properties File Path to
${JENKINS_HOME}/StableClangPath.txt.

If you are already injecting properties into your build environment, you’ll need to merge your properties with the contents of StableClangPath.txt. I leave this as an exercise for the reader.

Now, you’ll need to add a Clang Scan-Build build step and Public Clang Scan-Build Results post-build action. You’ll have to setup your target, workspace, and scheme depending on your project. Also, you’ll need to let scan-build know where to find the clang executable. Click the Advanced button to expose some more settings. Most of this should be configured properly already, but the Additional scan-build arguments setting should be set to

--use-analyzer=${STABLE_CLANG_PATH}

For my iOS projects, I had to set Build Active Architectures Only to NO for iOS Simulator or scan-build would complain about not being able to build the proper architecture. There is probably a better fix, but this works well enough for me.

Also, the Jenkins Clang Scan-Build Plugin does not currently know how to handle the directory layout of the current version of scan-build (See: JENKINS-17092). You will still get a report of the number of issues found and a brief summary of each one, but the links Jenkins provides for details about each issue are incorrect. Hopefully this issue is resolved soon, but in the meantime you can find the report in your filesystem and view it manually. The path to the report is listed at the end of the build console log, look for

scan-build: Run 'scan-view ...

to find the path.

That’s it, Jenkins is now set up to run scan-build using the latest clang on your project!

From time to time, you need to build a project with a specific version of Xcode. Sometimes, you need to do so with automated builds in Jenkins. Unfortunately, Jenkins doesn’t provide a clear cut way to do this. It turns out it’s not too difficult to do, but I searched around quite a bit and couldn’t find anywhere anyone had addressed it. So I am documenting the process here in hopes that it may help someone out there, including potential future versions of me who have forgotten it.

My first thought was to invoke xcode-select before running the build. I wasn’t very happy about the idea, and it turns out to be a nonstarter anyway as only root can run xcode-select. But if you take a look at the man page for xcode-select, you’ll discover that an alternative means of selecting which version of the xcode tools to use is to set the DEVELOPER_DIR environmental variable.

I believe you can set global environmental variables in Jenkins, but what if you need to set this one way for some projects, and another for others? To do this, you’ll need to use the Environment Injector Plugin. You can install it from the Jenkins Manage Plugins page.

After the Environment Injector Plugin is installed, a new section will appear in your project configuration called Build Environment. Check the “Inject environment variables to the build process” checkbox in that section. This will add a few more text boxes. In the box labeled “Properties Content”, add your environmental variable:

DEVELOPER_DIR=/Applications/Xcode 4.4.1.app/Contents/Developer

Note that the DEVELOPER_DIR variable must be more specific than what you might pass in to xcode-select. It must point to the actual Developer folder in the Xcode app bundle, rather than just the bundle itself.

I have added this step to every project I have set up in Jenkins, so that it doesn’t matter which version I may have set up with xcode-select. I always rename old versions of Xcode with their version number (as seen above) and leave the current version named Xcode.app. For projects which can always be built with the Latest & Greatest, this means I don’t have to do anything more. If I ever need to build them with an older version, I can go in and change it.

I feel that this is something that probably ought to be built into the Jenkins Xcode plugin, so I went to try to file a bug report/feature request about it. Unfortunately, this requires you to sign up for an account with their JIRA system, which I felt was too much friction for me to make this minor request. I think it should always be possible for users to report bugs and request features without having to sign in to any system. Otherwise, who knows how many issues you are missing because users find the process of reporting the issue too daunting? But, that’s a different story…

I have no intention of making this a political blog; however, with the Supreme Court’s recent ruling on portions of The Patient Protection and Affordable Care Act (AKA ObamaCare ¹) there’s been an awful lot of discussion about the Act. Much of this discussion is misinformed, or based on incorrect assumptions about what it does and how it works. For reasons that will soon become clear, I know more about ObamaCare than the average person should have to know (still, I admit I am not an expert). I could write a substantial post defending the Act, as well as criticizing its faults. I’m not going to do that. Instead, I’m just going to share how the Act has affected me and my family and why it was so important to me that the Supreme Court reached the decision it did.

On January 8, 2008 my first child, Sean, was born. He was three weeks early and had a low birth weight, but was otherwise perfectly healthy. Over the next 5 months, he nursed, slept, wiggled around, and did all of the normal things little babies do. Then, his weight gain began to slow. He didn’t have much interest in either nursing or drinking formula. When he was big enough to consume solid foods, he continued to lack interest in eating, and he remained in the lower percentile rankings for weight.

Over various trips to multiple doctors and one attempt at medicating him, it was decided there likely wasn’t anything physically wrong with him; he just didn’t like to eat. We did get his weight up by feeding him via an NG feeding tube from when he was about 14 months until 17 months ². After that, we stopped worrying so much and were happy that he was gaining weight at all, even if he did keep hovering just below the 5th percentile.

Fast forward to November of 2009. Like many companies then (and now), my employer was struggling to stay afloat. In the prior few months, the company had gone through two rounds of layoffs. Unfortunately, that November the company had to do a third round, and I got caught up in it. I was disappointed – it was a great place to work – but unsurprised. Fortunately, unlike many Americans in that situation, I was able to quickly find new work as a contractor.

Of course, being a contractor means providing your own health insurance. Continuing my coverage from my previous employer through COBRA was not an option, the premiums were ¾ of my paycheck. So I tried to buy individual coverage for my family. I don’t remember how many applications I filled out. I am certain that I tried every provider I could find. Each and every one of them refused to cover Sean due to his “preexisting condition” of being a slow weight gainer. None of them would even cover him with a higher premium. They simply would not cover him because he was underweight.

I eventually bought insurance for the rest of my family, and purchased accident insurance for Sean to cover injuries. It was far from ideal, but at least I wouldn’t have to try to find another job, one with benefits, during a down economy. Plus, by that time, ObamaCare had passed and I knew that starting September 23, 2010, the health insurance providers would no longer be allowed to exclude Sean for his preexisting condition. Our only real choice at the time was to cross our fingers and hope that Sean didn’t get sick before September 23, 2010.

Fortunately, we made it to that date without incident. I immediately purchased coverage for the whole family. Of course, the cost controls in ObamaCare had not come on line yet – they still haven’t – so our premium tripled. In the contract, we could clearly see that we were being charged nearly 10 times to cover Sean as our younger son, Zack. But, at least we were all finally covered (more or less ³).

A year and a half later, in another bit of good fortune, the company I had worked with before recovered and was doing better than ever. This past December I called them up and asked if they would be interested in hiring me again. They were, and they did. I once again have a great job and, importantly, employer-sponsored health insurance, which is a huge relief. That doesn’t mean I’ve stopped caring about ObamaCare.

The Supreme Court’s recent ruling covered a handful of areas of ObamaCare. The most important to most people, including myself, was their ruling on the constitutionality of the individual mandate. I have been told by some friends that I shouldn’t worry so much about the individual mandate, that if the court had struck it down there would have been no effect on my family. These friends are wrong. I don’t mean this as an insult, but their belief in this regard is based on ignorance. I am not a lawyer or constitutional scholar. My understanding of the individual mandate is admittedly incomplete. Even so, I am entirely confident that the people who feel the individual mandate doesn’t affect my family are wrong, for two reasons.

The first is perhaps the simplest. Had the Supreme Court ruled that the individual mandate was unconstitutional, they would have then had the option to strike down the law in its entirety. Many Supreme Court observers were certain that this is exactly what the Court would have done, for reasons I will outline below. In the likely case that the Supreme Court struck down the whole law, health insurance providers would no longer be forced to provide coverage to Sean. Some people have argued that, even if the law was struck down, the insurance providers would continue to cover children with preexisting conditions. I am certain those making that argument are right, in the short term. It would be a PR nightmare for the insurance providers not to do so. But gradually, over months or years, as health care news fades out of the national consciousness, they would return to their previous behavior. They have to; they are for-profit corporations ⁴.

How about the unlikely case where the Supreme Court knocked out the individual mandate, but left the rest of the bill standing? Things would fall apart. Many people fail to understand that the individual mandate is key to making this whole thing work. Here’s basically how it goes:

• Starting on September 23, 2010, ObamaCare forbids health insurance providers from denying coverage to children with preexisting conditions.
• Starting on January 1, 2014, ObamaCare forbids health insurance providers from denying coverage to anyone, regardless of age, due to preexisting conditions.
• Also starting in 2014, ObamaCare forbids health insurance providers from raising premiums due to preexisting conditions, as well as in a few other cases.

That means that, starting on January 1, 2014, the health insurance providers will no longer be protected from a healthy person waiting until they get sick to buy insurance. This is incredibly important. Insurance is a risk pool. Policy owners put their money into that pool, and if they get sick, they get to take some of the money out. If someone who is already sick joins the pool without having added any money to it, they get the benefit of the pool without having to contribute to it first. Sure, these people will now be contributing to the pool, but because the insurance providers cannot charge them more for their preexisting condition, their contribution is far less than the people who have been paying in while healthy. And, once they get well, they could simply jump back out of the pool until the next time they get sick. The result is the pool, and the insurance provider who manages that pool, loses money. Potentially lots and lots of money.

The individual mandate is an attempt to keep that from happening. Everyone who can afford to ⁵ must pay into a pool. If they refuse to buy insurance, they are paying into the government’s pool. The government’s pool, in turn, leaks into the insurance providers’ pools.

The result is that it doesn’t matter whether the Supreme Court struck down the whole law or just the individual mandate. Had they struck down the individual mandate, but left the rest of the Act standing, the whole thing would have eventually fallen apart due to the insurance providers’ inability to remain in business.

Again you might be asking why this is important to me now; I have a full time job with benefits. Sean will now be covered regardless of the state of ObamaCare. That may be true, but without ObamaCare my ability to direct my own future becomes far more limited. I quite like my job and plan to stick with it. But what if I ever did decide I wanted to strike out on my own, start my own small business? I wouldn’t be able to, because I wouldn’t be able to buy insurance for my son. Critics of ObamaCare claim that the Act hurts small business, but without the Act I would never be able to start my own small business, and I am certain I am not alone.

It gets worse. Sean is four years old. It would be a tragic thing indeed if by the time he is of working age this country hasn’t worked out a way to provide health care for all of its citizens. But, if ObamaCare had been struck down, and nothing else is done in the next 20 or so years, Sean will also not have the ability to start his own business, because he will not be able to purchase insurance for himself. Like his father, his choices will be constricted because of this country’s inability to provide for one of its citizens’ most basic needs. That is another potential small business prevented from entering the marketplace, not because of ObamaCare, but for lack of ObamaCare.

So please don’t tell me the Supreme Court’s ruling on the individual mandate doesn’t affect me. And please, please read more about what the Act actually does and try to understand the whys and hows of it. ObamaCare isn’t perfect – far from it. But it is a major step in the right direction – the first real step this country has made in a very long time.

This isn’t a game, this is the future of our country, and of my family, and almost certainly of someone in yours.

TL;DR: ObamaCare allowed me to purchase insurance for my son Sean from September 23, 2010 until I lucked out and got my old job back in January 2012. Without ObamaCare, I would have to make sure I keep a full-time-with-benefits job, and neither Sean nor I will ever have the choice of starting our own small businesses.

Edited mostly for grammar, June 29, 2010 3:30pm

I’ll come right out and say it: BabyGrow doesn’t make me a whole lot of money. People sometimes ask me why I bother. Wouldn’t it make more sense to try something new, perhaps aiming for a more substantial market? The simple answer is I bother because I love BabyGrow. I always have at least two or three new features on my mind, things I know I, as an actual user of the product, would love. And when I can, I work on those things.

Unfortunately, “when I can” typically isn’t often enough. BabyGrow 2 is perhaps not the best example, since in between it and BabyGrow 1.7 I moved (thrice), changed day jobs (twice) and otherwise was unable to spend many of my nights and weekends working on it. When things finally settled down I picked up where I had left off. For the purpose of this post, I will be referring to the time period between when I found I had time to work on BabyGrow again, around November of 2011, and now.

I have a day job. I also have two young boys. This basically means that the only time I am really able to focus on my (tiny little) business is for an hour two each evening between when the boys go to bed and when I conk out. I do this as often as I can. There are days that either my job or the boys have me so weary that I can’t think straight. Sometimes I just need an actual break, or often I just want to spend some time with my wife. The net result is that I typically have perhaps two to five hours a week to work on my business.

Due to this extreme time limitation, I have a choice. I can work on BabyGrow, or I can work on something new. Not both.

Intellectually, I know I should work on something new. BabyGrow targets a relatively small market. True, if every single member of that market were to purchase BabyGrow I’d be sitting pretty for a little while. But that’s not going to happen, no matter how many attempts at marketing I try (while staying within my very meager budget). It should be a no-brainer – put BabyGrow on the back burner and try to hit a bigger, more lucrative market.

Someday, I’m sure I’ll do that. Maybe even soon. But starting a new software project is hard. Building a new product from the ground up takes massive amounts of time. Not to mention, I apparently don’t have The Vision. I consistently fail to come up with interesting ideas for new apps. A few years ago my wife made some suggestions that I dismissed. Looking back, I wish I hadn’t – several of her ideas have turned up and been best sellers. Recently she’s made a few more suggestions… We’ll see.

But most of all, it’s because I’m not done with BabyGrow. I don’t know if I ever will be. I keep a list of the features that, if I finish them all, I would be comfortable leaving BabyGrow alone for a little while. But the list grows faster than I can keep up with it. Some of it may be feature creep, but it’s also that Apple keeps improving the iOS platform. Each new version of iOS has brought features BabyGrow can benefit from. Printing, iCloud synchronization, the iPad, etc. If only Apple would stop innovating, perhaps I could catch up. But who wants that?

Update 8/14/2016: I just hit this problem again and, what do you know, this blog post was the first result on a Google search for the problem. Unfortunately, the solution I landed on four years ago isn't the correct one (though it does work). Instead of going through the steps below, you simply need to be sure you are specifying the workspace when invoking xcodebuild. For example:

/usr/bin/xcodebuild -scheme "Entangler MAS" -workspace Antenna.xcworkspace -configuration Release_MAS clean build archive

Leaving this here because it is not at all obvious. If you have an Xcode workspace containing multiple projects, and a scheme in that workspace depends on targets in more than one of those projects, Xcode’s own automatic dependency detection may well work, but xcodebuild will fail. The solution:

1. In Xcode, go to Product -> Edit Scheme.
2. Click on Build
3. Add each of the dependencies in the Targets box, making sure the dependent targets are listed lower than the dependencies.

I also had to uncheck the Parallelize Targets box.

Related – you will also need to make sure the Scheme you wish to build is marked Shared in the Manage Schemes UI.

New review of BabyGrow over at Indonesian review site The iPhone Shack (now defunct). Google’s translation isn’t that great — but it sounds like they liked it!

By the way, if you’re wondering how I found out about the review, I have a Google Alert set up for “BabyGrow iPhone.” If you have an iPhone app (or any product or service, for that matter), I heartily recommend using Google Alerts to keep track of what people are saying about you. It comes in quite handy.