Can Google Find You?

Recruiters use Google.  Whether you’re actively seeking a new job or not, it’s important to use this fact to your advantage.  My friend Sandro gave me this advice years ago, when he told me to put my resume online and make it “googleable”.  For me, the result was contacts from recruiters and companies I might never have heard of otherwise.  In addition to putting your resume online, I would recommend blogging about your job–within reason.  Definitely do not write about company secrets or co-workers.  Putting such things in your blog doesn’t help you.  Instead, write about what you do, problems you’ve solved, even your process of problem-solving.  At the very least, when you encounter similar challenges in the future, you’ll have a reference for how you solved them in the past.  Your blog post about how you fixed a particular issue might be helpful to someone else as well.

There are many options available for putting a resume and/or blog online.  Sandro hosts his, mine, and a few others on a server at his house.  But for those of you who don’t have a buddy to host theirs, here are a couple of readily-accessible free options:

There’s a ton of advice out there on what makes a great resume, so I won’t try to repeat it all here.  You can simply put a version of your 1 or 2-page Microsoft Word resume on the web, or you can put your entire career up there.  Having your own blog or website means you aren’t subject to any restrictions on length that a site like Monster or CareerBuilder might impose.  Consider linking your resume to the websites of previous employers, technologies you’ve worked with, schools you’ve attended, and work you’ve done that showcases your skills (especially if it’s web-related).  I don’t know if that makes it easier for Google to find you, but it does give recruiters easy access to details about you they might have to dig for otherwise.  Doing what you can to make this process easier for them certainly can’t hurt.

Transforming Healthcare through Information Technology

Back on November 20, I attended a seminar at the Reagan Building on how healthcare in the U.S. could be improved through information technology.  As an alumnus of the business school, and someone who’d worked in healthcare IT before, I wanted to learn about a part of the healthcare debate that I hadn’t seen much coverage lately.  Dr. Ritu Agarwal gave the talk and answered questions during and after her presentation.

The main problem with healthcare in the U.S. could probably be summed up this way:

Despite spending more on healthcare than any other country in the world, our clinical outcomes are no better than in countries that spend far less.

Even more disturbing, of the 30 countries in the OECD, the U.S. has the highest infant mortality rate.

In the past 10 years, premiums for employer-based health insurance have risen 120%.  Over the same period, inflation grew 44%, while salaries grew only 29%.  So healthcare costs are increasing far faster than inflation (and our ability to pay for it with our salaries).

As far as healthcare IT goes, Dr. Agarwal gave the following reasons for the slow pace of adoption by healthcare providers:

  • inertia
  • it’s a public good–patients get the benefits–not the healthcare providers
  • lack of common standards

Adding to the inertia point is the fact that healthcare in the U.S. has many stakeholders–patients, medical professionals, hospitals, pharmaceutical companies, insurance companies, and more.

Dr. Agarwal pointed to a number of countries with successful implementations of healthcare IT.  They included Canada, Australia, and the United Kingdom.  Australia in particular was singled out as being 5-10 years ahead of the U.S.

One thing I didn’t expect was that the Veterans Administration and the Department of Defense would be held up as native models of successful healthcare IT implementations.  One key factor noted by one of the other seminar participants was that the VA and DOD systems were closed.  Providers, specialists, hospitals, etc were all part of the government.  This enables them to enforce standards, in patient records and other areas.  Another point I considered later (which didn’t come up in the Q & A) was that the government model is non-profit as well.

Dr. Agarwal’s proposed solution to improving the current state of IT use in healthcare (as I recall it) was an regional exchange model.  Healthcare providers in a particular region of the U.S. would choose a standard for electronic health records (EHR) and other protocols.  Connections between these regional exchanges would ultimately form a national health information exchange.  Building on existing protocols and technologies (instead of attempting to build a national exchange from scratch) would be the most practical choice.

For more information, check out the slides from the presentation.

Unit testing strong-named assemblies in .NET

It’s been a couple of years since I first learned about the InternalsVisibleTo attribute.  It took until this afternoon to discover a problem with it.  This issue only occurs when you attempt to unit test internal classes of signed assemblies with an unsigned test assembly.  If you attempt to compile a Visual Studio solution in this case, the compiler will return the following complaint (among others):

Strong-name signed assemblies must specify a public key intheir InternalsVisibleTo declarations.

Thankfully, this blog post gives a great walk-through of how to get this working.  The instructions in brief:

  1. Sign your test assembly.
  2. Extract the public key.
  3. Update your InternalsVisibleTo argument to include the public key.

Figuring Out Google Wave

I recently received an invite to Google Wave (thanks Rory).  From the few minutes I’ve played with it so far, it seems to be Google’s next offering in collaboration (Google Docs is probably their first).  I’ve still got some spare invites, so send me an e-mail if you’re interested in trying it out.

One of my bosses from a previous company came across a couple of links that explain Google Wave:

http://lifehacker.com/5272048/google-wave-is-what-email-would-look-like-if-it-were-invented-today

http://lifehacker.com/5395376/the-complete-guide-to-google-wave-is-a-comprehensive-book-on-wave

I’ll probably be checking these out when I have time (if I’m not distracted by other “oooo shiny” toys, or life in general).

A visit to Iowa City

Last weekend, I visited my cousin Kevin at the University of Iowa to sit on his Ph. D defense.  For the past five years, he’s been working in pharmaceutical chemistry figuring out how to create vaccines that can be delivered directly to human genes.  I’m no chemist, so the bulk of his talk was way over my head, but it was very cool to see his command of the material and how well he presented.  When he came back from the private portion of his defense, we knew he’d succeeded.

After a celebratory lunch, Kevin took his brother Richard, sister Michelle, and me to a firing range to shoot.  By firing range, I don’t mean some shiny building with paper targets on motorized tracks.  We drove about an hour from Iowa City to a fenced-in area outdoors with some metal stands and a big pit.  You bring your own guns, ammo, and targets.  When other people are around, you have to signal them that you’re going to put targets out so they stop shooting.  We turned our fire on some empty steel solvent containers with four different weapons: a Ruger pistol (.22 LR ammunition), a Ruger rifle, a Springfield 1911 (.45 ammunition), and an M1 Garand (7.62mm rounds).  After spending a couple hours shooting, I will never look at Hollywood shoot-em-ups the same way again.  Movies seem totally fake compared with the noise and recoil of large-caliber weapons.  We had fun, and we turned out to be half-decent shots (for rookies).

StackOverflow Dev Days DC

In this case, DC = Falls Church, VA.  I went to the State Theatre to attend this conference.  Considering the cost ($99/person), the conference turned out to be a great value.  I wrote up a conference report to share with my bosses and co-workers and it’s included below.  It has footnotes because I typed it up in Word 2007 and pasted it in here with very little editing (because after all this writing, I’m feeling a bit lazy).

Summary
The main reasons the creators of stackoverflow.com came up with this conference include the following:

  1. Bring together developers that are part of the Stack Overflow community[1]
  2. Teach developers something outside their immediate field[2]
  3. Accomplish 1 & 2 at low cost[3]

A fourth reason I would add is to pitch FogBugz 7.  It’s the primary product offering of Fogcreek Software, so it would have been odd for a conference it supports to not do at least a little advertising.  Spolsky also attempted to divide the venue by area for networking around certain topics, but I’m not sure how successful that was.

The conference succeeded in its main objectives.  At $99 per person, this conference was a bargain.  Given the diversity of topics and caliber of speakers, the price could have been higher and the venue would still have sold out.  Of the seven official topics presented (there was an eighth on Agile after the conference ended), only the ASP.NET MVC talk used technology that I had hands-on production experience with.  I was disappointed not to see a presentation on Android, but that was the only thing obviously missing from the day.

Keynote: Joel Spolsky
If I were to boil down Joel Spolsky’s keynote to a single phrase, it would be this:

“Death to the dialog box!”

Spolsky’s talk argued persuasively that software often forces users to make decisions about things they don’t care about, or don’t know enough about to answer correctly.  Among his examples were modal dialog boxes for products like QuickBooks and Internet Explorer, and the Windows Vista Start button.  He talked about the other extreme (overly simple applications) as well, using the “build less” design philosophy of the 37signals team as an example.[4] Equating those kinds of applications with Notepad was a reach (and clearly played for laughs), but described the limitations of the alternative to complex applications pretty well.  The examples did a good job of setting up the choice between simplicity and power.

He cited an experiment in the selection of jam from The Paradox of Choice: Why More Is Less[5] to show the potential drawbacks of too many choices.  When the results of this experiment showed that a display with fewer choices resulted in an order of magnitude more sales of jam, it put a monetary value on the design decision to limit choices.

Predictably, his examples of the right kind of design were products from Apple.  It takes a lot more effort to put a Nokia E71 in vibrate mode than it does an iPhone.  Spolsky pointed to the iPod’s lack of buttons for Stop and Power as examples of addition by subtraction.  The best example he chose was actually Amazon’s 1-Click shipping.  In addition to offering the most reasoned defense I’ve heard yet of Amazon winning that patent, he explained how it works for multiple purchases.

A few other takeaways from the Spolsky’s keynote that I’ve tried to capture as close to verbatim as possible are:

  • The computer shouldn’t set the agenda.
  • Bad features interrupt users.
  • Don’t give users choices they don’t care about.

iPhone Development: Dan Pilone
This talk successfully combined technical depth on iPhone development with information about business models for actually selling an app once it’s complete.  Pilone discussed which design patterns to use (MVC, DataSource, Delegate) as well as what paid applications are selling for in the App Store (the highest-grossing ones sell for between $4.99 and $9.99).

One of the most useful parts of the talk was about the approval process.  He gave his own experience of getting applications through the submission process, including one that was rejected and the reasons why.  According to him, 2 weeks is average time it takes Apple to accept or reject an application.  It’s even possible for upgrades of a previously-accepted app to be rejected.

Pilone did a good job of making it clear that quality is what sells applications.  He used the Convert[6] application (from taptaptap) as an example.  It’s just one of over 80 unit converter applications in the App Store, but it’s beating the competition handily.  OmniFocus was his second example.
Revenue Models

  • Ad-supported (very difficult to make money with these)
  • Paid
  • In-app upgrades[7]

Dan Pilone is the co-author of Head First iPhone Development[8], which will be available for sale on October 29.

His recommendation for selling apps in the App Store is to release a paid version first, then an ad-supported version.  This advice seemed counterintuitive to me, but I suspect he suggested it because there’s no data on the in-app upgrades revenue model.  I see in-app upgrades as Apple’s most explicit support for the “freemium”[9] business model yet.

ASP.NET MVC: Scott Allen
This talk was basically a demo of a preview version of ASP.NET MVC 2.  Allen wrote code for his demonstration on-the-fly (with the sort of mistakes that can happen using this approach), so the example was pretty basic.  The takeaways I thought were useful for getting started with the technology were:

  • External projects that add features to ASP.NET MVC
    • MVCContrib
    • MVC T4
    • You can combine standard WebForms and MVC in the same solution—particularly useful if you’re trying to migrate an application from ASP.NET to ASP.NET MVC.  Allen mentioned the blogging platform Subtext[10] as an example of one application attempting this kind of migration.

This talk left a lot to be desired.  StackOverflow is the most robust example of what can be built with ASP.NET MVC.  A peek inside even a small part of actual StackOverflow source using ASP.NET MVC would have made a far more compelling presentation.

FogBugz and Kiln
Even though this was strictly a product pitch, I’ve included it in the report because of how they implement a couple of ideas: plug-in architecture and tagging.

Plug-in architectures as an idea aren’t new—what was different was the motivation Joel Spolsky described for it.  One of his intentions was to make it easier for people to extend the functionality of FogBugz in ways he didn’t want.  He isn’t a fan of custom fields, so instead of building them into the core product, they’re implemented as a plug-in.  He demonstrated Balsamiq integration (via plug-in) as well, so the architecture does enable extension in ways he likes as well.

Tagging isn’t a new idea either—what I found very interesting is how they apply them in FogBugz.  Spolsky pitched them as a substitute for custom workflow.  His idea (as I understood it) was that bugs could be tagged with any items or statuses outside the standard workflow.  There wasn’t much more detail than this, but I think the idea definitely is worth exploring further.

Python: Bruce Eckel
His talk was supposed to be about Python, but Bruce Eckel covered a lot more than that.  The most important takeaways of his talk were these:

  1. In language design, maintaining backward compatibility can cripple a language.
  2. The best programming languages change for the better by not being afraid of breaking backward compatibility.
  3. “Threads are unsustainable.”

Eckel’s talk gave the audience a history of programming languages, as well as a hierarchy of “language goodness”.  For the main languages created after C, the primary motivation for creating them was to fix the problems of its predecessor.  So C++ was an attempt to fix the problems of C, while Java was an attempt to fix C++.  His assertion about the primary motivation behind Ruby was this (I’m paraphrasing):

Ruby intends to combine the best of Smalltalk and the best of Perl.

He made his point about the problems of backward compatibility by comparing an attempt to add closures to Java to language changes made by Ruby and Python.  An article titled “Seeking the Joy in Java” goes into greater detail on the Java side of things.[11] In the case of Java, the desire to maintain backward compatibility often prevents changes to a language which could fix things that are poorly implemented.  The authors of Python and Ruby aren’t afraid to break backward compatibility to make improvements, which makes them better languages than Java (in Eckel’s view).

Here’s Eckel’s hierarchy of programming languages:

Python (his favorite)
Ruby, Scala, Groovy (languages he also likes)
Java
C++
C

Eckel also mentioned Grails as a framework he likes.

Another one of his pronouncements that stood out was a hope that Java would become the COBOL of the 21st century.

Eckel’s argument regarding the difficulty of writing good multithreaded code is one I’ve heard before.  He pointed to Python as a language with libraries for handling both the single processor task-switching and multi-processor parallel execution models of concurrency.

Google App Engine: Jonathan Blocksom
Jonathan Blocksom gave a great overview of Google App Engine.  He’s a member of Google’s Public Sector Project Team (not the App Engine team), and I think that helped him present the information from more of an audience perspective.  He did a nice job of describing the architecture and the advantages of using it.  Some of the applications running on Google App Engine include:

Blocksom also discussed some of the limitations of App Engine:

  • 30-second time limit on asynchronous tasks
  • No full text search

jQuery: Richard D. Worth
This may not have been the best talk for those already familiar with jQuery, but for me (someone unfamiliar with jQuery), it was close to perfect.  The presenter did an excellent job of showing its advantages over regular ECMAScript.  He used a clever trick to minimize the amount of typing during his demos by using slides with only the changed lines highlighted.  The “find things then do stuff” model he explained made it very easy to grasp what he was doing as he increased the complexity of his examples.[12]

Wrap-up

After the conference ended, a “metaStackOverflow” question was added to collect reviews of the conference from its attendees.[13] The top answer (as of October 28, 2009) also includes links to slides for three of the talks, which I’ve included here:


[1] http://blog.stackoverflow.com/2009/05/stack-overflow-developer-days-conference/

[2] Ibid

[3] Ibid

[4] http://gettingreal.37signals.com/toc.php

[5] http://www.amazon.com/gp/product/0060005688

[6] http://taptaptap.com/#convert

[7] This revenue model is brand-new—Apple only began to support this within the past week or so.

[8] http://www.amazon.com/Head-First-iPhone-Development-Applications/dp/0596803540

[9] http://en.wikipedia.org/wiki/Freemium

[10] http://www.subtextproject.com/

[11] http://www.artima.com/weblogs/viewpost.jsp?thread=173229

[12] Worth used http://jsbin.com/ for some of the more complex demos.  It’s a very good tool I hadn’t seen before.

[13] http://meta.stackoverflow.com/questions/27367/devdays-reviews-washington-dc/27377#27377

A .NET Client for REST Interface to Virtuoso

For my current project, I’ve been doing a lot of work related to the Semantic Web.  This has meant figuring out how to write SPARQL queries in order to retrieve data we can use for testing our application.  After figuring out how to do this manually (we used this SPARQL endpoint provided by OpenLink Software), it was time to automate the process.  The Virtuoso product has a REST service interface, but the only example I found here for interacting with it used curl.  Fortunately, some googling revealed a really nice resource in the Yahoo Developer Network with some great examples.

I’ve put together a small solution in Visual Studio 2008 with a console application (VirtuosoPost) which executes queries against http://dbpedia.org/fct/ and returns the query results as XML.  It’s definitely not fancy, but it works.  There’s plenty of room for improvement, and I’ll make updates available here.  The solution does include all the source, so any of you out there who are interested in taking the code in an entirely different direction are welcome to do so.

Snow Leopard: Days 1-2

Thanks to a pre-order from Amazon on August 3, a copy of Snow Leopard arrived on my doorstep August 28. The install was uneventful–typical of Mac OS X installs. I put in the DVD, clicked through a few dialog boxes, went to run a couple of errands. When I got back, I logged in as usual.

So far, I haven’t noticed many differences between Leopard and Snow Leopard.  The few of note:

  • Hard drive space.  Before installing Snow Leopard, I had around 14GB of free space.  After installing Snow Leopard (and the latest version of XCode) I have 27GB of free space.  It’s quite a bit more freed space than the 7GB Apple advertised
  • Printing.  I have a HP LaserJet 1022.  I had to re-install it after upgrading to Snow Leopard and use an Apple driver.  It still works just fine.
  • Battery Status.  Apple added information on battery health.  Since my MacBook Pro is closing in on 3 years old, the “Service Battery” message is most likely correct.  Apple Support already has a thread about it.  Another thing I’ve noticed which may also be new to Snow Leopard is that I’m getting battery life percentages for my Bluetooth keyboard and mouse as well.
  • Character/Keyboard Viewer.  A new widget in the upper-right of the screen.  I haven’t found any particular use for it yet.
  • Mail.  When I first started it, the app prompted me for some sort of upgrade.  Once it was done, the notes from my iPhone showed up under a Reminders item.
  • Quicken.  I’m still using Quicken 2007 for Mac, so I saw a little prompt about Rosetta when I first launched it.  What I really need to do is get out of Quicken 2007 into something else, but that’s a subject for another post.

I can’t say I’ve noticed any speed differences one way or the other so far–but it’s only been a couple of days.

A long overdue upgrade

I’m finally running the latest version of WordPress (I’ve been way behind on upgrading).  I’d be curious to hear from those of you who visit regularly what you think of the new look.  I’d considered a couple others:

I ultimately chose this one for the random post feature that appears in the upper-right of the page.

CruiseControl.NET, MSBuild and Multicore CPUs

When I was trying to debug a continuous build timeout at work recently, I came across this Scott Hanselman post about parallel builds and builds with multicore CPUs using MSBuild.  While adding /m to the buildArgs tag in my ccnet.config didn’t solve my timeout problem (putting the same unit tests into a different class did), pooling multiple MSBuild processes will certainly help as our builds get bigger.