I’ve relapsed. I swore I’d never do it again, but I have. I’ve accepted a full time job.
I’m not in it for the money
I’ve been running happtic for just over 2 years now, and it’s been quite lucrative. I’ve managed to get a small, but reliable base of repeat/ongoing direct clients, and developed some applications that have done very well. I’ve only taken on 2 non-direct contracts in that period, so am happy with how that’s worked out. Overall, I’d say the business has been successful in terms of providing my family with a relatively good income. Sure, having a stable income, holidays, superannuation etc will be great, but that’s not why I’ve taken the job.
It’s a growth and opportunity thing
The main issue I’ve been struggling with in running happtic is growth. I wanted to turn happtic into a larger business, providing technical consulting and development service with a team of 10 or so. I haven’t been able to get enough volume of projects/clients to warrant taking on any extra staff (apart from that time I hired a graduate/entry level developer, and he called in sick on his first day and never got in touch with me again).
I’ve learnt that there are things I’m good at, and things I’m not good at. I’m great at systems architecture, technical strategy, software design, and development. What I’m not good at is cold business development. Once someone is at the door, the conversion rate is high, but getting them to the door is hard for me to orchestrate.
Joining a larger organisation, with a pre-existing client base and sales team helps me meet my goals of leading a technology team, in a position of influence in an organisation. One key thing that I remember from a corporate management training course many years ago is that in companies (and in real life), the path to achieving a desired outcome may not be the path you expect. If you can recognize that the outcome is what you are after, there are many paths that can take you there, so you shouldn’t be precious about how you get the outcome, as long as you get that outcome. The outcome I’m after is to lead a technology focussed team of people, providing development, consulting, and technical strategy services, and that’s what this job is.
What’s the new job?
I’ll be working as “Director of Mobile” for Simple Machines. The job will involve setting up and leading a mobile development team, as well as an office, here in Melbourne.
One particularly exciting thing about the job is the split between client and product work. Simple Machines have clients, as well as their (our!) own products and investments in startups, so there will be varied work which is great. I find working on a single product can feel a bit stale after a while, so having a mix of client and product work will definitely help with that, but also provide the satisifaction you get from growing and evolving a system over time.
If you’re looking for any mobile app development (iOS, Android, WP, any platform) or development of complex, high performance, scalable applications, get in touch firstname.lastname@example.org
Progress has been a bit slower this month. Short month, very hot here, and new baby all contributed to slowing progress down. Oh, in other news, we now have a baby! Exciting.
190km complete at end of Feb, which leaves me with a 30km buffer. The last graph was a little incorrect too - Numbers only puts dates correctly (in relative terms) on the x-axis if the graph type is a scatterplot. Dumb. The new graph below is correct.
Progress on the 1000km is good so far. 109km run in Jan, and I’m sticking to the 10km distance per run. Weight is also starting to fall, which is great because I’m about 9kg heavier than I should be.
Because I’m also a nerd (and if you’re reading my blog, you probably are too), here’s a graph marking progress. Grey line is what I need to run to get to 1000km this year. Any blue higher than the grey line is kms in the bank for a rainy day.
A couple of days ago I received an email from meetup.com about meetups that I might be interested in. Usually this is full of crap I don’t care about, like mothers groups or salsa dancing, but this most recent mail featured an intriguing group called “Meteor Melbourne - a better way to build apps”. So, I looked into it.
Amazeballs. Meteor is MAGIC. Don’t believe me? Watch this screencast.
I think the magic for me comes from the real-time (well, super fast at least -> sub second synchronization) nature of the system, and the automate shuffling of data between the server and client to synchronize/update pages with no specific actions on the developers part. The built in support for packages is also really tidy, although having to use a 3rd party packages system (Meteorite and Atmosphere) for more modern versions of some of the core packages (eg, bootstrap-3 vs bootstrap-2) seems a little undesirable.
It’s super fast to get set up (1 line install, 1 line to start), and this includes server, database, sync between client and server. Want user authentication? Two more command line hits (1 for a UI, 1 for a login provider package), and 1 line to get the UI template built in. Amazingly productive.
Where I see huge potential for Meteor is in the mobile space. Having a web app, which automatically pushes changes to a mobile device is super powerful. With the current state of mobile apps you typically need to poll for changes to data, unless you build your own data sync solution or rely on something like iCloud to push changes around for you (haha, yeah right). When I’ve done this sort of thing in the past with Parse, I’ve actually gone as far as abusing the Apple Push Notification Service to actually trigger a mobile device to re-query a web service to retrieve new data as APNS is the only push mechanism available. Having a service that reliably notifies a client when data changes server side, with sub-second speed, solves a whole bunch of problems for app developers.
This is the tech stack that I’m now looking at using for my small business productivity tool, and I’m hoping that mobile sync works just as well (and fast) as the client-server sync does. Next up is a small proof of concept to test this out.
I haven’t been this excited about web development since I saw DHH’s web app in 15 mins rails screencast in 2006.
Oh yeah, I went to the meetup too. Nice job meetup.com
I’m not one for new years resolutions, but there are a couple of things I’d like to achieve this year.
Design, Develop, and Release a productivity tool for small and medium businesses
1000km is something I attempted to achieve last year, but by the time February rolled around, it was obvious that that just was not going to happen. This year is going much better. I’ve established a running routine already, and have (as of today) extended my run distance to about 10km. I’m sure this will be much tougher when winter rolls around, but I’m up for the challenge.
The SME productivity tool is something I’ve been toying with the idea of for a while. The idea actually came from my sister and her husband (they run a construction company), and it solves a problem that they spend a few hours a week on. I’ve already got my minimum functionality defined, and business model. It works well as a SaaS/subscription style product so fits with the revenue stream style I like. I’ll hopefully have a splash/info/signup page soon. I’m also looking at a new (new for me) technology stack to power this thing, so I’ve also got a lot of learning to be able to create it. Fingers crossed it gets off the ground.
I guess there’s a third thing, but it’s more of an inevitability, rather than a goal as such. We’ll be having a baby soon (hopefully in 3 weeks), so life will be getting much more time-scarce. We’ll see how all this holds up under parenthood.
Yesterday I read an article in Venture Beat covering part of a series of hearings US Congress is holding on regulation of health and medical apps on smartphone and tablet devices. My significantly paraphrased version of the article is that the FDA are unsure if and how health apps should be regulated, and that representatives from the “app” industry are pushing for no regulation for consumer facing apps.
I have a slightly different take on this. To me, the question is simple (and what is driving health authorities globally to address this issue): can health apps be considered to be medical devices?
Medical devices are subject to legislation worldwide. In fact, often requiring prior market approval through mechanisms similar to which pharmaceutical companies must obtain approval for medicines. Clear guidance exists on the regulation which surrounds medical devices, and this includes the legislative definition of what constitutes a medical device. As a snapshot (and these definitions can be considered consistent with legislation in many other countries too), the definition of a medical device in Australia, the EU, and US clearly includes apps which diagnose, prevent, monitor, treat, alleviate disease.
41BD A medical device is:
a. any instrument, apparatus, appliance, material or other article (whether used alone or in combination, and including the software necessary for its proper application) intended, by the person under whose name it is or is to be supplied, to be used for human beings for the purpose of one or more of the following:
i. diagnosis, prevention, monitoring, treatment or alleviation of disease;
ii. diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap;
iii. investigation, replacement or modification of the anatomy or of a physiological process;
iv. control of conception;
and that does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but that may be assisted in its function by such means; or
b. an accessory to such an instrument, apparatus, appliance, material or other article.
EU Directive 2007/47/ec (paraphrased)
Any instrument, apparatus, appliance, software, material or other article that is used alone or in combination, including software specifically for diagnostic or therapeutic purposes, that the manufacturer intends for use in human beings. Such devices are used for:
- Diagnosis, prevention, monitoring, treatment, or alleviation of disease
- Diagnosis, monitoring, treatment, alleviation of, or compensation for an injury or handicap
- Investigation, replacement, or modification of the anatomy or of a physiological process
- Control of conception
US Food, Drug and Cosmetic Act Section 201(h)
Medical machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory that is:
- Recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them
- Intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment or prevention of disease, in man or other animals
- Intended to affect the structure or any function of the body of man or other animals, and does not achieve any of its primary intended purposes through chemical action within or on the body of man or other animals and does not depend on metabolic action to achieve its primary intended purposes.
The key, and common, part to all of these is the use of the device in diagnosis, monitoring, and treatment of a disease.
Regardless of the user of the device, regulation exists. Medical devices such as syringes, contact lenses, condoms, and bandages are all available to the public, and regulated (at least in Australia). If the same rule that is being proposed for apps was applied for these devices, anyone could make devices such as bandages, and the public would have no guarantee as to the quality, safety, and efficacy of these devices.
Devices and medicines are regulated to protect patients (and the general public) from faulty or harmful devices and drugs, and misdiagnosis or mistreatment from inaccurate information being provided to medical professionals who need to make decisions on the basis of that information. The consequences for patients from medical misdiagnosis from a medical app can be a lot more severe than (lets say) the physics calculations not accurately representing gravity in Angry Birds. Death or permanent disability is a real possibility with inaccurate (or just plain wrong) information being captured by medical apps and used for diagnosis.
Getting a medical device approved can be a very costly exercise. Typically, trials with verifiable data are required to show accuracy and stability in the product. There is also the paperwork required to submit the device to the health regulator in a country, and this submission process needs to be repeated for each health regulator in each country you want to sell your device in.1 However, due to the high cost (and high barrier to entry2 in the marketplace), if you can jump through the regulatory hurdles, you may find a relatively competition-free market. That’s the reward for navigating the processes.
There is also a comment in that article that “Developers are mystified by the rules in this highly regulated industry”. If this is the case, maybe developers need to do the same as other players in the health industry and either employ, or contract in, medical regulatory professionals. Mystification is no excuse for not playing by the rules.
Ignorantia juris non excusat.
happtic (my company) provides consulting services related to health regulations for medical apps. If you’re looking for help determining if an app would be considered a medical device, help with understanding regulatory processes, or help with regulatory submissions please get in touch.
Unless you’re in the EU. There is a single health agency for Europe.
Regulatory requirements are only one significant barrier to entry in certain industries. Other industries (such as telecommunications and energy suppliers) also have a large infrastructure requirement requiring both capital investment and significant time. Medical Apps don’t typically have this barrier.
I have a large objective-c codebase I’ve been working on with a client for over a year now. The application started off as a prototype, and transitioned into a demo client, and is currently undergoing modifications for security/penetration testing and commercialization. Initially for the protoype and demo, the objective was to get a working application as quickly as possible - speed of initial development was the key. With the current change in focus to a more productized codebase, and improving maintainability as part of that, I decided I’d actively go hunting for areas in the application that can be tidied up, and particularly, looking for duplicate segments of code and eliminating them where feasible.
DRY - or Don’t Repeat Yourself - is (according to Wikipedia) a principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” … When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.
One big problem with a larger code base that has been developed over a long period of time is that you may not know where the duplicate code actually is. You know it’s there, you’re just not sure where.
Finding Duplicate Code
What I wanted for DRYing up the code base was for duplicate chunks of code to be identified for me.
Searching out there I stumbled across a project called Simian - it’s a java based tool for identifing duplicate code in a set of different programming languages - one being Objective-C. Simian supports output in a number of different formats - plain text being the default, but also supports an XML based output. The project is available on a 15 day evaluation period, and then should be paid for commercial or enterprise use. A Build Server license costs $499 US.
Simian can be run against a codebase just by feeding it include/exclude directory and file patterns.
I’ve previously written here about setting up and using Jenkins as a build/CI system with Objective-C/iOS projects, and I really wanted to integrate this duplicate code reporting as part of my standard build process, along with my unit and application test reports.
To get Simian reports integrated with Jenkins there is a Jenkins extension available called the DRY Plugin. Just navigate to your Jenkins instance and click… Manage Jenkins -> Manage Plugins -> Available and type Duplicate in the filter box. The plugin is called “Duplicate Code Scanner Plug-in”. Install it.
To get the Simian process running is really simple. I added a new project that I could trigger after my unit tests have run, called “Code Analysis”. This project has a very small number of steps.
Pull the source from your code repo
Set a Build Trigger for the project to start after your unit test project has completed. This step isn’t necessary, but you need some sort of build trigger. I like mine to work after unit tests as then I know the codebase is in a good state.
Add an Execute Shell task. The task should look something like below
cd "<Path to your Jenkins project>/workspace"
git submodule update --recursive --init
echo "#!/bin/bash" > simian.sh
echo "java -jar <Path to your simiar jar>/simian-2.3.33.jar -balanceSquareBrackets=true -formatter=xml:simian.xml -excludes=\"External Libraries\" **/*.m **/*.h" >> simian.sh
echo "exit 0" >> simian.sh
chmod u+x simian.sh
What the above task does is change directory to the correct jenkins workspace, ensure all submodules are updated (if you don’t use submodules, you probably won’t want this), then create a shell script that runs Simian and exits with a 0 return code, sets the script to be executable, runs the script, then cleans up after itself. The reason why the build task needs to create a shell script to run Simian is because the return code from Java/Simian seems to be interpreted by Jenkins as non-0 i.e. a build failure. You don’t want that.
The -balanceSquareBrackets=true flag to Simian ensures that code that is split across multiple lines inside square brackets is treated as a single unit. It might be a good idea to use the -balanceParentheses=true flag as well to help matching on things like if statements.
Then it’s just a matter of configuring the reporting. If you’ve installed the DRY plugin correctly, you should be able to add a Post Build Action of “Publish duplicate code analysis results”. In the “Duplicate code results” field, type in the path and filename you gave the output XML from simian - in the example above I called mine simian.xml.
Save and “Build Now” your new project, and after this is complete, click on the project. There should be a fancy trend graph showing Duplicate Code in the upper right of the screen, and a “Duplicate Code” item on the left navigation menu. That will show you all the files with duplicate code chunks, and the other files they are repeated in.
Very unexpectedly, for the past few weeks I’ve been working with a Digital Agency here in Melbourne on a sports-themed iPhone app for a very large client of theirs (a worldwide media brand). I was called in at the 11th hour to work with two other developers (both experienced iOS and ruby contractors), and I knew within the first hour there that the project was going to be a significant challenge. The project had unrealistically tight timelines and a lack of testing and testing platforms/data sets available.
Needless to say, it was an interesting experience. In my previous full time jobs I’ve never worked as a developer, and with my current company all projects to date have been single developer projects. But I definitely found the whole experience really rewarding. It reminded me of the time I was a manager in a large digital agency myself, only there it was me cracking the whip to get development in on time, rather than having the whip cracked on me. :-)
(It also meant I had to get dressed and leave the house to work!)
In all seriousness though, the key thing that made the whole thing worthwhile was seeing a “production” codebase from other experienced mobile app developers. My Objective-C design and style is self-taught. It was great to have what I do and the way I do it validated by others, as well as picking up hints and tips for more modular app implementations. This is something that you really miss out on as an indie developer with a one person development team. The shared learning and ability to bounce ideas off people to come up with great solutions is something that is really missing from the indie way of working.
I’ll definitely consider doing more contracting work in the future - both for meeting other developers and for picking up new skills. Highly recommended.
Back in the late 90’s I took COSC 122 at the University of Canterbury. We had to learn functional programming as part of that course - HUGS (it’s based on Haskell 98). It never really clicked with me - for some reason my brain would just not understand functional programming.
I’ve always regretted that I never “got it”. It’s time to fix that regret.