Tuesday, March 20, 2012

Flavors of Computing Careers

I found a career categorization on an ACM site that I found particularly resonant. It breaks "software development"/IT/"computation" down into four areas:

  • Career Path 1: Designing and implementing software.
  • Career Path 2: Devising new ways to use computers.
  • Career Path 3: Developing effective ways to solve computing problems.
  • Career Path 4: Planning and managing organizational technology infrastructure.
I've though about the appropriate categorization of computing/software tasks a lot over the years. My breakdown is similar, but in a different order:

  • Technology infrastructure: DBA's, network/storage system development, architecture (ACM career path 4)
  • Software engineering: How to make software that's modular, easy to ship and robust (ACM career path 1)
  • Algorithm development: new techniques for doing computation (ACM career path 3)
  • User experience/productivity enhancement: helping people do their jobs better/more effectively (ACM career path 2)

My order is back-end to front-end. One needs to be more customer focused when moving along the axis. This is clearest in the contrast between the first and last categories, and probably only lines up this way in the support of particular domains, e.g., science/finance).

Tuesday, January 24, 2012

The Lean Startup

I just finished reading Eric Ries' The  Lean Startup, and am happy to say  that it was much better than I expected.

When I heard about the book I thought that it only applied to cloud based web startups: the kind of shops that could readily perform A/B testing over a weekend, an approach pioneered by Google early on.

My reaction to this was predictable: that's fine when you're making simple changes to web pages, but what if you're doing some heavy technical lifting, e.g., new technology (Watson), hard technology with deep foundational requirements (Dropbox), etc.

Ries describes something more subtle. He develops a general methodology that allows quantitative evaluation of assumptions, as quickly as possible, with the least possible amount of effort.

Dropbox is one of his most striking examples

The challenge was that it was impossible to demonstrate the working software in prototype form. The product required that they overcome significant technical hurdles; it also had an online service component that required high reliability and availability. To  avoid the risk of warming up after years of development with product nobody wanted, Drew did something unexpected easy: he made a video.

The goal of the video was to validate the assumption that people would actually be interested in such a product. Of course in the Dropbox case the interest was there, but the book is filled with numerous examples in which it wasn't.

Ries' core approach consists of a large scale feedback loop, shown below (taken from here):

 

startup-feedback-loop1.png

My two core take aways are

  • MVP--the minimum viable product, and
  • Measure-- the importance of making clear, tangible predictions ahead of time.

Both ideas are important in any product that has a customer focus, whether the customers are online consumers or members of an internal department.

They are reminiscent of the techniques my group used years ago to measure uptake of product features by internal departments: if we deployed a page with a particular group in mind, we could see if they continued to use it a few weeks out. If not, we'd visit them and ask what the problem was. There wasn't any need to wait for feature requests (or to hear in a budget meeting that you weren't providing any value). We sought them out and fixed the problem, if at all possible. Monitoring at page level allowed us to make these judgments for small product increments.

MVP is simply getting something in front of people as quickly as possible -- it doesn't need to be working, doesn't need to scale, doesn't need to be fully polished, but it does need to give a feel as to why someone would want to incorporate the product into their life.

Measure is more generally important. Ries is perfectly willing to start with measurable  goals that seem almost trivial. The idea being that in short order these goals can eliminate easy workarounds, myths of low hanging fruit, etc.

In one of his examples, he aimed for a revenue of a few hundred dollars a month to start. A few hundred a month sounds trivial, and certainly isn't sustainable, but after a few months he couldn't even do that.

The point is that if his goal was the few million dollars a year he'd need for true sustainability, it would have taken him years to realize that he was on the wrong track. This because realistically, even in the best case, the million dollar goal would require a few years to achieve, pushing feedback out to years rather than months.

The Lean Startup doesn't just focus on startups, it includes of a number of examples from groups within large non-software companies (Proctor and Gamble) and established software companies (Intuit) etc. shows that startup is more an attitude than a corporate structure.

I highly recommend this book, I don't consider it so much a Lean Startup book, but an optimized effort book: How to decide if your efforts are wasting your time or actually taking you in the direction that you want to go.

To be clear: I don't think that this means that data measured at a fine grained level is the only way of gathering feedback, e.g., it's hard to incrementally identify the best design for a large website c.f., Goodbye, Google. However, even in these cases, an MVP is important. It is vital to ground your ideas with your target audience, sooner rather than later (even if it's with a short video of a simulation of your idealized goal).

Tuesday, January 17, 2012

Watir

I know I'm late to this, but I'll share anyway:

If you're actively developing or supporting anything with a web front end, take a look at watir for automated smoke and regression tests. The site has a "watir in 5 minutes" page, but probably really takes more like 3, it's that well designed.

Watir stands for:Web Application Testing in Ruby. It is:
  • Open source
  • Simple to install: just a ruby library (gem)
  • All of ruby is available when writing test scripts
  • Well regarded
  • Widely used. Here's a partial list:

Some Watir Users

Watir Limitations

  • “W3C” web only!
    • No plug-ins (active-x, flash)
  • No recording
      Recording tools are available, but not part of the core effort
Watir Advantages
  • Widely used
  • Very easy to use
  • Programmer friendly
  • Ruby is sane
  • Terse without being obtuse
Interactive Development
    You can debug scripts interactively using irb

For example, this screenshot shows a section of a browser wind and an irb window about to execute a method to click on the browser's edit button:

Screen Shot 2012 01 16 at 1 30 17 PM

resulting in:

Screen Shot 2012 01 16 at 1 30 43 PM
Page elements are referenced by
  • Type and Id/displayed-text/link destination etc
    • @browser.select_list(:id, 'StatusSelect')
  • or Index
    • @browser.buttons[3]
        Index is obviously not the preferred approach, but it is occasionally necessary, e.g., for pages with four identical “submit” buttons

On a maintainability note: I recently had to change a script from FireFox (which I'm increasingly becoming disenchanted with) to Chrome. The change only required altering 2 lines of code

#require 'firewatir'

require "watir-webdriver"

and

#    @browser = Watir::Browser.new

@browser = Watir::Browser.new(:chrome)



However, I did find the behavior a bit different between Chrome and Firefox: If a button wasn't visible on the page Chrome wouldn't click it. I never had a issue with this in Firefox.

Update:, upon further investigation it appears that may be the behavior of the newer versions of watir, rather than a Chrome compatibility issue.

Sunday, October 23, 2011

Building and Submitting iOS Apps built using user created static libraries

 

Here are my notes on getting an iOS app submittable to Apple’s app store, which includes an interesting “welcome back to header files” experience. Resolving all the issues required a fair amount of searching and futzing, so I thought I’d put together a synopsis and share:


Step 1: Compiling a project referencing a static library I created.

Background: I’m building a suite of apps centered on pdf file display, using the vfr pdf reader framework -- the developer, Julius Oklamcak, characterizes it a basic framework, but I found it both robust and easily configurable to fit my needs.

The first task was to build a library consisting of the vfr pdf reader code so that the code would be factored appropriately. Using this approach, any bugs showing up in the pdf reader require only one code change to fix all the books.

I used CarbonFive’s blog post on building and using static libraries to perform the setup.

It took a bit of tweaking to get the library incorporated/recognized by the dependent projects, and, sadly, one of those tweaks came back to bite me later.

The primary change was to put all the projects in a single Xcode workspace so that the library was readily available to the dependent project (apps). Workspace creation, followed putting the library in the frameworks folder, and making the .h files public, made the .h files visible to the dependent project.

After these changes, the dependent project could

compile and run, both on the simulator and on my test device.

 

Step 2: Archiving the Project

However, when I went to archive the app (a precursor to submission), the necessary .h files suddenly could not be found.

There didn’t seem to be any “build level” way around this -- meaning that I couldn’t find a way to eliminate this error that just entailed changing some configuration files. The only solution I could find was to move copies of (or links to) the actual header files being referenced.

Upon further consideration this appears to be an artifact of the build environment/ObjectiveC language, since even the foundation frameworks are packed with their header files (see below)


FrameworkContents

 

Step 3: Validating the Project

At this point the archive could be created without errors, but when I tired to validate and submit I got the following

"[projectname] does not contain a single–bundle application or contains multiple products. Please select another archive, or adjust your scheme to create a single–bundle application."

This was a quick issue to fix -- the answers appearing on stack overflow

Archiving project in XCode incorrectly creates multi-application bundle

The fix required changing the file visibility (back) from public to project. Changing file visibility is most easily accomplished by moving the .h files to the appropriate part of the Copy Headers section of the Build Phases tab for the target -- I will admit that this approach was advocated it the CarbonFive blog, but it didn’t appeal to my (Java tuned) sensibilities.

H file movement

Step 4: Submitting the Project

The fun wasn’t quite over, since an attempt to submit the app resulted in the response

No suitable application records were found.

After setting up the signing appropriately per Apple’s guidelines http://developer.apple.com/ios/manage/distribution/index.action

-- somewhat obscurely located here

Apple directons


(BTW am I the only  one finding it frustrating that Apple’s documentation hasn’t been fullly refreshed to reflect the Xcode4 UI?)

and reading stack overflow again,

illed out the questionnaire and I was able to submit and upload successfully.

Hope this short walkthrough proves useful.



Monday, August 15, 2011

Commenting in html, tpl.php etc.

I came across a very nice commenting convention in the drupal zen theme template files:

They close all of the class and id marked sections with

<!-- /.{classname} -->

or

<!-- /#{idName} -->

 

e.g.,

<tr class="genesis-page-header-row">

is closed  with

</tr><!-- /.genesis-page-header-row -->

 

This is nice enough in helping you to keep track of what's going on when editing the code. However, it is invaluable in understanding what might have gone wrong when examining pages in a "modern" inspector.

For example, here's how that section looks in Safari 5.1:

Drupal image upload

making it clear that the you and the browser both agree on the <tr> being terminated by this </tr> (if you and the browser don't agree, it probably indicates that something has gone awry).

 

 

Sunday, June 26, 2011

Debugging Drupal Access Denied

I just finished debugging an Access Denied problem in Drupal, and wanted to add a couple more tips to those in Simon Lane's Drupal Permissions Issues: A Debugging Checklist

First: assure that the users unable to access the content have been given the appropriate roles.

Second: check the permissions of a role that can access the content relative to one that can't -- the following query works in MySQL and is both quicker, and more accurate, than a visual check.

select permission, module from role_permission 
where rid = 5
and permission not in
(select permission from role_permission where rid = 4)

Where "5" is id of the role that has access, "4" is the id of the role being denied access.

Third, and most obvious: assure that the "inaccessible" content has been published. This was the source of my particular problem (doh!).


I echo the words of many posters, when I say "It would be nice if Drupal would log the reason for denying access. It would save everyone a lot of time"

Thursday, April 28, 2011

Drupal 7.0: broken image preview

I recently decided to use Drupal for one of my projects, since all reports are that it is both well designed and relatively easy to extend.

I'm just getting it set up locally on my MacBook Pro (10.6.7) and ran into a problem with previewing uploaded images: nothing was getting displayed for the preview, even though the images would display fine when saved.

The following errors were being logged.

Access denied

The solution, took a while to find, but was relatively simple: changing the upload location to Public files (see below), cured the problem.

Drupal image upload

(Switching it back recreated the problem) -- seemed worth sharing.