Blog

A blog from Brandon Moser, a Senior Web Developer. Mostly code, sometimes I post about drumming, UX and/or loyalty.

What I've learned about many of the Healthcare websites

After reading a few articles (like this one and these ones) about the implementation issues many of the Healthcare websites, MNSure & the Federal Healthcare.gov sites for example, is that many people are learning how difficult it is to build these systems. Software engineers, project managers, infrastructure engineers and the like are required to build systems in ways that many are unfamiliar with. For example, how many companies actually build interworking sites between 4-5 parties? How many companies build sites that can handle unknown amounts of traffic on these SOA-style (service oriented architecure) sites?

The public (and politicians for that matter) just assume that all websites should work 100% of the time and be able to handle unlimited traffic. Inclusive of this fact, if these systems fail to meet the requirements, the head of the group will be held to a standard no one could achieve. If we held politicians to a similar, yet stringent, standard, not one if them would have made it past the shutdown, or at least the head of each party would even fired.

I see this level of expectation often (without the firings) and it does not bode well for many. Having built a few sites that handle a bit of traffic and continue to build SOA-style sites, it is increasingly important for us to discuss the users' experience over many of the common first discussions, like architecture and platform.

Anyway, I think the most important thing that is coming out of this is that our governments are spending an enormous amount of money on these sites and are not receiving the best return on investment. Instead if they had asked ~10 large-scale website developers to build this, the site would have probably had a much larger success.

There are 2 things that I think ultimately failed:

  1. Government contracts are absurd by having too many restrictions on how to implement
  2. Govenments need to stop throwning large sums of many at projects, it looks worse when it fails

Tracking Page Views in CFWheels w/Google Analytics

Today I was tasked with tracking page views and email campaigns in Google Analytics (GA) within our CFWheels application. I found a great option in GA to track events. Thinking about how the framework is designed, we essentially are using Events (like most frameworks) to control the application. Within Event Tracking in GA, you define a Category (controller) for the Event. Then,  define the Action (action). The _trackEvent() method also accepts 2 other parameters, opt_label, which is an option descriptor for the event and opt_value, which is a number (positive integer).

To add this to your GA script snippet, just add the following line:

_gaq.push(['_trackEvent', '<cfoutput>#params.controller#</cfoutput>', '<cfoutput>#params.action#</cfoutput>']);

Once you have added this snippet to your GA script you will find the report under Content >> Event Tracking. From here you will be able to determine the usage of your app without having to create Custom Reports.

Local Web Dev Platform

In an effort to remember how I setup my systems on both my Mac and my PC at work, I have decided to post my setup here. Hopefully it helps others, not just myself.

Since I like to control my web server separate from my application server (PHP, ColdFusion, Railo, Java, etc.), I use Apache HTTP, as it allows me to setup multiple virtual hosts (websites) vs. IIS on Windows XP or 7. I don't do much PHP development these days, but the other nice thing to using Apache is that most installs include PHP4/5 already. I have found that XAMPP for Mac and Wamp Server on Windows are the easiest to work with and allow you to customize the web server as needed. I tried MAMP for Mac and because I didn't want to pay for the ability to create vhosts (virtual hosts), I switched to XAMPP and have found no issues in its setup.

Setting up my CFML engine was easy, since Adobe ColdFusion has a built-in script for attaching itself to Apache's http.conf configuration file. I also run Railo on my VPS, but because I also run Tomcat on the VPS, configuration there was a bit more complicated (an honestly, I'm still working out the kinks). If you install the Apache server first, installing the ColdFusion connector script is a breeze. When it asks for the server to use, point it to the http.conf directory location and it will add the following code to your config file.

# JRun Settings LoadModule jrun_module /Applications/ColdFusion8/runtime/lib/wsconfig/1/mod_jrun22.so JRunConfig Verbose false JRunConfig Apialloc false JRunConfig Ignoresuffixmap false JRunConfig Serverstore /Applications/ColdFusion8/runtime/lib/wsconfig/1/jrunserver.store JRunConfig Bootstrap 127.0.0.1:51800 #JRunConfig Errorurl url #JRunConfig ProxyRetryInterval 600 #JRunConfig ConnectTimeout 15 #JRunConfig RecvTimeout 300 #JRunConfig SendTimeout 15 AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf

Adobe's ColdFusion also has an option to install the above script on an existing Apache install if you have both ColdFusion installed and Apache HTTP and you didn't connect them during install. You can find option in the Mac ColdFusion Launcher application, under Serivce menu >> Webserver Connection Utility.

Also important to a local development setup is using local web addresses to mimic the production/staging setup. For example, I have setup http://brandonmoser.dev in my home workspace to mimic this blog. Obviously, the .dev domain does not exist, but adding them to my hosts file, makes using these domains very easy. It also allows me to quick know which site I am developing. To find your hosts file on Windows it is found in "%system_root%\system32\drivers\etc\hosts". On Mac it is hidden a little more and requires Admin/root access so tools like TextWrangler or TextMate make things much easier. The hosts file location on Mac OS X is located in "/etc/hosts". While that doesn't seem very hidden Mac OSX keeps directories like /etc, /var & /opt hidden from user view, especially in the Finder. I usually add both the www and root domains to my hosts file, (e.g. www.brandonmoser.dev & brandonmoser.dev), just in case I decide to manually type in the URL.

Add virtual hosts to Apache is a breeze once you have a good template. I like to keep them in a separate file for cleanliness and ease of find them. There is a line in most Apache http.conf that allow for this. If not you can add it anywhere.

# Virtual hosts Include etc/extra/httpd-vhosts.conf

Running virtual hosts, also allows to you keep your development directories organized and located as you please. I like to keep my work projects separate from my personal projects. I keep all of them in my user's Sites directory, but within that directory is a director for Denali (my current employer) and Personal. Below is a sample vhost code sample.

DocumentRoot "/Users/brandonmoser/Sites/mango/" ServerName mango.dev ServerAlias www.mango.dev ErrorLog "logs/dev.mango-error_log" CustomLog "logs/dev.mango-access_log" common

Keeping separate error and access logs allows me to quickly parse the log, when something goes wrong. Obviously in development you don't have multiple sites being accessed at once, so you can comment out the log config to use the default logs which are setup in the http.conf file.