The video makes some interesting observations about human-computer interactions (HCI):

• mice excel at pointing on the screen without obstructing the screen
• multi-touch should be extended to use all digits on the hand, not just 1 or 2 – but all 5.
• both hands can create touch combinations that are interesting ( see 6:42 mark in the video )
• New windows are overlaid on top of old windows in a rather cluttered manner.

Clayton Miller’s proposal involves a medium-size touch surface placed in front of the keyboard. All ten fingers are used to interact with the UI. Different combinations and number of fingers mean different operations.

Clayton Miller’s basic premise that HCI should no longer be confined to 2D interactions is quite correct. However, the proposal does not recognize the full extent of the mouse/keyboard limitations. As a result the proposal is at best an incremental improvement over what Apple offers currently. Furthermore, Clayton’s proposal assumes a desktop computer configuration. Mobile, tablet, and laptop compute configurations are ignored.

Additional limitations that Clayton must bring into the picture and address in order to be truly revolutionary:

• extensive mouse movement causes carpal tunnel syndrome
• mouse/trackpad movement requires a dedicated surface
• mouse is not useful for mobile devices
• mobile devices use a touch screen with the downside that Clayton points out in his video.
• physical handicaps of users:
  • lost digits,
  • diseases that impact muscle control
  • mouse and trackpad are still 2D surfaces and operations

Clayton needs to update this video to consider these technologies:

• Microsoft Kinect‘s motion capture eliminates the need for direct device
  manipulation
• Kinect and the Wii introduced acceleration, 3D motion and movement into the HCI arena.
• Users’ physical limitations
• Eye motion and tracking to make computers more accessible to users.
• Mobile devices in particular field use
• Non-Desktop interactions

Trust Me

Seriously, why doubt?

Sam Antar, convicted white collar criminal, says trusting is stupid clearly and explicitly:

President Ronald Reagan said:

“Trust, but verify.”

As a convicted felon, I say:

“Don’t trust, just verify.”

“Verify, verify, verify.”

As a criminal, I considered people’s humanity as a weakness to be exploited.

The inclination to trust first and then verify, gave me the upper hand.

The criminal always has the initiative.

While you initially trust us, we work on ways to solidify your trust before you verify.

Hopefully, you will never verify.

However, if you do verify, we will have corroded your skepticism to a large degree.

A word of advice from this convicted felon to the capital markets, securities analysts, journalists, the accounting profession, investors, and others:

The word “trust” is a professional hazard you can leave at home before you go to work.

A criminal says “Don’t trust”. Yet computer security experts talk about a “trust” model. When are we going to move beyond trust to verify? A google search finds endless examples of sites reassuring users that they are “trustworthy”. It should not be a surprise then that computer users are used to just entering their password or clicking o.k. when a security dialog comes up. Users are asked to always trust without any understanding. What does it mean when a certificate cannot be authenticated?

Furthermore, we now have “trusted” applications getting computer owners into trouble.

For example:

• Andre Vrignaud is a such a victim.
  

  Comcast cut off broadband access to Andre Vrignaud. A month earlier, Vrignaud said he had a “polite but irritated” conversation with Comcast’s Customer Security Department about how much data he was using. He told them he had no idea how he used so much and wondered if his roommates may have hit the limit because they watched Netflix HD streaming movies and listened to Pandora’s internet-streamed music radio.

  Why can’t Vrignaud limit easily on his end?
  Once again, a google search reveals how important being able to control and manage at the application level.

• How about the case of Matthew Brady? He is an innocent victim, like many others, framed by a poor computer security model.
  

  Until recently [story dated Tuesday, January 16, 2007], the 16-year-old Arizona boy faced life imprisonment for possessing child pornography; each of the nine images on his computer carried a possible 10-year sentence.

  The caution: Your computer could be storing and distributing child pornography without your knowledge. It could be what is called “a zombie.” A virus, worm or “bot” may have almost invisibly infected your operating system, perhaps when you opened an email attachment or clicked on the “wrong” (not necessarily adult) website.
  The “infection” allows another person to remotely access your hard drive. Often, the third party tries to capture financial information such as bank account numbers. Often, he stores data on the hard drive and uses your computer to distribute spam, including pornography.

  Benjamin Edelman, a computer security expert, indicates how quickly a computer can become infected. “I recently tested a WindowsMedia video file…On a fresh test computer, I pressed Yes once to allow the installation. My computer quickly became contaminated…All told, the infection added 58 folders, 786 files, and an incredible 11,915 registry entries to my test computer. Not one of these programs had showed me any license agreement, nor had I consented to their installation on my computer.”

  The Bandy’s two-year nightmare might be winding down, but the family has been financially ruined by over $250,000 in legal costs.

Instead of trust, as Sam suggests: “Don’t trust, verify, verify, verify”. No application should be given a blanket “trust” but rather a conditional trust. An application should not even be allowed to ask for a blanket trust.

Instead the application must ask for permission and indicate why it is asking for the permission:

• write to a specific directory
• send data to an internet site
• receive data from an internet site
• All data sent or received is logged
• Any data the application wants to send or receive needs explicit permission from the user.

The user must be able to selectively deny or condition a granted permission at any time (not just when an application is starting) :

• Granted for 10minutes
• Data sent/received is logged
• Data transmission rate is no more than 1mb/sec
• Data transmission rate is no more than 10megabytes/month
• Data stored for only 10 days
• Data is stored is no more than 10megabytes
• CPU usage is capped as a percentage.

It is up to the application to behave well if the permission is or it is denied permission. And if it doesn’t like the permissions then well – don’t run.

The application is a guest and needs to respect the rules as a guest.

Trust. is. stupid.

I left because of a general lack of interest in doing anything substantial to improve the Triage process on BMO outside the QA community and a few others. Triage as we know it today is NOT ready to handle the Rapid Release process.

Tyler then points out that:

In Spring 2010, we hit roughly 13,000 UNCO bugs in the Firefox product on BMO. 13,000!!! We currently have 5934. This is several thousand contributors that we have told “Thank you for filing a bug report with us. We don’t really care about it, and we are going to let it sit for 6 months and just ask you to retest when you know it isn’t fixed, but thank you anyway. Oh, and Mozilla is run by the community.” Even though nobody means this, that is what we tell an end-user who just submitted their first bug and is ignored.[italics mine]

Mozilla behavior toward this ancient feature request is illustrative:

• The request was filed in 1999 (12 years ago)!
• Numerous offered patches,
• A plugin to workaround this issue,
• Accounts that offered patches are labeled as “Please Ignore This Troll (Account Disabled)”

Wow nothing says Go Away quite so effectively as being labeled a troll or being ignored.

Questions

1. How many reported issues are latent security problems?
2. How can Mozilla bug fixing keep up with the community’s bug reporting? The community is vastly larger than the Mozilla development team.
3. How can Mozilla truly leverage the community? And avoid having responsive, assertive community members being labeled as trolls?
4. How can anyone feel good about closing 1 bug out of 13000, especially if the incoming rate is greater than the fix rate?

Thoughts

This is something that every company or open-source project hopes to have: a community that overwhelms the product with love. Mozilla is doing the wrong thing if the love is unrequited.

With so many bugs churning in, developers are faced with a sisyphean task. The bugs represent community love, the developers have to view the love as not burdensome.

These thoughts really apply to every company, product and project:

Developer Bug Tool

A developer-facing bug database must only hold bugs (broken code that must be fixed),

1. NO Feature Requests
2. NO Project Plans
3. NO “technical debt removal” wishes,
4. NO minor bugs

Developers like all humans need to feel the progress, and accomplishment. Fixing one bug out of 13000 does nothing, fixing one bug out of 100 feels meaningful.

Feature requests and refactoring or changes for the future belong in a project planning tool.

Any bug, that cannot or will not be fixed immediately, must be documented in the code:

• TODO flag
• Date ( a TODO that is 10 years old not that useful – with a few exceptions )
• Person who added this comment (not necessarily a full-time developer)
• HACK flag if the code should not be an example of “how to do” things. This tells future developers to not use this bad code as a template to create more bad code.
• Discussions can happen in the code same as they would in a separate bug database

Documenting in the code not the bug database gives these benefits:

• Developers tracing a different bugs or adding new features are proactively notified without searching that:
  • the code is questionable
  • the code may be the source of the bug he is tracing
  • he may be able to immediately fix the bug documented in the issue
• If the questionable code is deleted as part of a later refactoring feature change, the bug report is also deleted.
• The bug database is not polluted with minor items that bury the truly critical issues.

Use Git

Get away from the Open-source Cathedral where only a few are blessed committers.

Avoid frustrating people who want to patch the product. Let them patch the product and share their patch. If the main official release doesn’t include the patch, at least the person reporting the problem can fix the problem for themselves and move on.

Prefilter bug reports

• Incorrectly formatted html: IE choose to format it one way, Firefox made a different guess. Just because FF made a different choice doesn’t make FF wrong, but that will not stop a bug report. FF should have a clear indicator that:
  

  The page in question has bad html and that it may not be displayed correctly. Click here to send a note to the webmaster about this page.

  Point the finger of blame at the webmaster so that FF does not get blamed (and avoiding the bogus resultant bug reports).

• Bad scripts: If the javascript is not functioning correctly announce it. Its not FF’s problem that the script sucks, don’t let Firefox get the blame.

Make it easy to report issues

• Built-in feedback tool
• Built-in screen capture (with redaction ability)
• Do not require registration in a bug database
• Do the bug reporting within Firefox don’t make people navigate.
• Ask if the last report by this person is related.
• Do the bug database duplication search for the user and ask if any of the other reports look similar.

Final Question

How can your product or service empower the community to self-help?

• http://css-tricks.com/
• http://quirksmode.org
• http://www.css3.info/
• Css3 tutorial

via Css Tricks:

• CSS3Please.com
• Border-Radius.com
• HTML-Ipsum.com
• Button Maker

Update ( 28 July 2011 ) :

Now for some excellent tools:

• Sass (http://sass-lang.com )
• Compass (http://compass-style.org ) Compass builds off of Sass to provide cross browser frameworks.
• Css3Pie Provides Css3 support (of a sort) for IE 6-8. Compass integration is available.

Could not find gem ‘pgw’ ( >= 0, runtime)’ in any of the gem sources listed in your Gemfile

I tried Ole Morten Amundsen’s method, but it didn’t ( quite ) work (see below)

Magic directory method

1. mkdir -p vendor/cache
2. bundle update
3. git add -A
4. git commit -m"whatever"
5. git push heroku master

All the gems public or private are installed into the vendor/cache directory.

Pros:

1. Simple.
2. It works.
3. Also allows for a locked down deployment (? not completely certain on this because heroku does report “Installing …” for all the gems including the private gem)

Cons:

1. All the gems used are installed, not just the single gem that is not available on rubyforge.
2. Magicalness feels like a possible bug. (Note: I am using bundler 1.0.13) so it may not work in future
3. git bloat – all the external gems and dependencies are now part of your repo.
4. Possible issues with machine specific deployments with other gems? ( not certain about this – but flagging it as a possibility )

Ole Morten Amundsen variant

1. gem unpack pgw --target vendor/gems
2. edit Gemfile to explicitly list the gem version and supply the path
   gem "pgw", "0.0.3", :path =>"{#File.expand_path(__FILE__)}/../vendor/gems/"
3. bundle install --local
4. git add -A
5. git commit -m"whatever"
6. git push heroku master

The resulting Gemfile.lock will have this:

PATH
  remote: vendor/gems
  specs:
    pgw (0.0.3)

GEM
...(everything else ) ...

Pros:

1. Feels more like the intended process
2. Only extra code is the private gem ‘pgw’ – none of the standard ruby gems are added to the project.

Cons:

1. More typing
2. Have to include specific version number in the Gemfile – so harder to ensure against an accidental release with old version of gem.
3. “unpacking” seems lame. Is there a way to keep the ‘pgw’ gem as a .gem file?

Questions

1. Is there an easy way to move the gems to my master project other than gem unpack?
2. should the gem be put in vendor/bundle since that is the default BUNDLE_PATH?

“Future bugs” are bugs that are currently not wrong, but will cause problems in the future. Every conditional ( if, ? :, or switch ) is a “future bug”.

For example, in this simplistic example code, there are multiple checks for this.enableLogging. If new code is added then the developer has to constantly remember to check for the this.enableLogging.

public class Foo {
    private final boolean enableLogging;
    public Foo(boolean enableLogging) {
        this.enableLogging = boolean enableLogging; }

    public void stuff1() {
         .....
         if ( this.enableLogging ) {
             Log.warning("here in stuff1");
         }

         .....
         if ( this.enableLogging ) {
             Log.debug("still here in stuff1");
         }
    }
    public void stuff2() {
         .....
         if ( this.enableLogging ) {
             Log.info("here in stuff2");
         }

         .....
         if ( this.enableLogging ) {
             Log.debug("still here in stuff2");
         }
    }
}

Of course sane developers will say that this is silly code, follow the DRY principle and have something like this:

public class Foo {
    private final boolean enableLogging;
    public Foo(boolean enableLogging) { this.enableLogging = boolean enableLogging; }

    public void stuff1() {
         .....
        warning("here in stuff1");
        .....
        debug("still here in stuff1");
        ....
    }
    public void stuff2() {
         .....
         info("here in stuff2");
         .....
         debug("still here in stuff2");
    }
    private void warning(String message) {
        if (this.enableLogging) {
            Log.warning(message);
        }
    }
    private void info(String message) {
        if (this.enableLogging) {
            Log.info(message);
        }
    }
    private void debug(String message) {
        if (this.enableLogging) {
            Log.debug(message);
        }
    }
}

This is good enough for this simplistic example. However, consider a more realistic case with complex conditionals:

public class Foo {
    private final boolean enableCall;
    private final boolean enableEmail;
    public Foo(boolean enableCall, boolean enableEmail) {
        this.enableCall =  enableCall;
        this.enableEmail =  enableEmail; }

    public void stuff1() {
         .....
         if ( this.enableCall ||  this.enableEmail) {
             doThing1();
         } else if (this.enableEmail || this.bigCheck() ) {
             ... lots of stuff1 lines  .....
        } else {
             .. some different things here....
         }
    }
    public void stuff2() {
         .....
         if ( this.enableCall ||  !this.enableEmail ) {
             doThing1();
         } else if (this.enableEmail || this.bigCheck() ) {
             ... lots of stuff2 lines .....
        } else {
             .. some different things for stuff2() here....
         }
    }
    private void doThing1() { ... }
    private boolean bigCheck() { .... }
}
...
public class Bar() {
    ....
    Foo foo = new Foo(true, false);
    ....
    Foo foo1 = new Foo(false, true);
}

Do you see the bugs?

1. Notice that in stuff2() the first conditional is different than the first conditional in stuff1(). Is this a bug? Who knows? ( Lets assume it is )
2. Because the only users of Foo set either enableCall or enableEmail, the only actual code paths through Foo.stuff1() and Foo.stuff2() result in calls to doThing1()

A developer just inspecting Foo can find neither issue easily.

Subclassing/alternative interface implementations solve this problem. The subclass created decides, at object creation, all the conditionals.

So the above code becomes:

public interface Foo {
    void stuff1();
    void stuff2();
}

//  this.enableCall ||  this.enableEmail case ( The original stuff2() check was wrong )
public class Foo1Impl() implements Foo {
    public void stuff1() { doThing1(); }
    public void stuff2() { doThing1(); }
    private void doThing1() { .... }
}

// !this.enableCall && this.enableEmail case
public class Foo2Impl() implements Foo {
    public void stuff1() { if (bigCheck() ) { ... lots of stuff1 lines  ..... } }
    public void stuff2() { if (bigCheck() ) { ... lots of stuff2 lines  ..... } }
    private boolean bigCheck() { .... }
}
public class Foo3Impl() implements Foo {
    public void stuff1() {
          .. some different things for stuff1() here.... }
    public void stuff2() {
         .. some different things for stuff2() here.... }
}

public class Bar() {
    ....
    Foo foo = new Foo1Impl();
    ....
    Foo foo1 = new Foo1Impl();
}

Note the consequences of this division,

1. doThing1() can only be called by a Foo1Impl.
2. bigCheck() is isolated to Foo2Impl
3. depending on bigCheck()’s implementation, bigCheck() may be could be called once to determine if Foo2Impl or Foo3Impl is created.
4. There is no question about the stuff2() check being correct or incorrect. ( the conditional no longer exists! )
5. And it is now obvious that only Foo1Impl’s code path is used. If this is a bug, the bug is now obvious. If not then the Foo2Impl and Foo3Impl code can be eliminated.

Hard-lessons learned here tell me this is very, very bad.

Take the time for these steps and minimize use of the computer, because it is very easy to give into the temptation to start coding. And when you are coding, you are thinking about implementation issues, not high-level design issues.

1. Write down the goals: This is the easiest trap to avoid and the trap that catches most people. If the developer knows the goals enough to write them down, they can be confident that they are building what was asked for ( just send the written description to the manager or client ). Equally important, the developer knows when they are “done” and what is “good enough” to satisfy the immediate need
2. create the use Case tests: Create pseudo-code showing the various operations needed by the project. Missing steps are discovered prior to implementation. Did a previously unknown piece of information just “magically” appear? How was that magic knowledge actually retrieved? Are operations out of order?

   To help clarify what is meant by a “Use Case Test”, here is an example of what I am currently working on:

   Peter wishes to use Amplafi to upload an image to his website.

   From Peter’s perspective,

   1. Peter uploads a image to Amplafi
   2. (Peter does other things)
   3. Amplafi asks Peter about Ftp username/password
   4. Amplafi ftp posts the file to Peter’s web site.
   
   An equivalent Use Case test looks like:

   1. Create a ResourceLocation representing the local temporary place an uploaded file will be stored
   2. upload the image from the user’s computer. (mocked, testing the use case – not the actual upload)
   3. look up the (test) ftp authentication information for the customer’s website (the ftp server is mocked as well, so username/password is fake)
   4. Determine the location the image will be stored on the ftp server
   5. create ResourceLocation holding the image’s ftp location
   6. perform the upload from Amplafi’s computer to the ftp server (the actual upload is to the fake FTP server)
   7. validate that the ftp upload was successful
   8. clean up the temporary copy on Amplafi’s server
   9. update the ResourceLocations created
   10. Notify the various statuslisteners about the transfer’s success.
   
   This example Use Case test discovers issues like:

   • The code not having access to the Ftp authentication information
   • Not being able to determine where the image should be stored temporarily on the Amplafi server
   • Not knowing when the temporary copy can be deleted.
   • No mechanism to handle a ftp upload failure ( ftp server dropped connection, had over quota error)
   • No mechanism for handling overly large files. ( 100TB anyone? )
3. create the diagrams ( use paper ) It is tempting to use a UML tool to create the diagrams; resist temptation. You want to be able to throw away ideas with abandon. Spending effort to create a nice looking UML diagram is wasted if the design concepts need revisiting. Save the tool for when the design has been validated.
4. create the interfaces: Create the interfaces needed by the pseudo-code in step 2. Define the purpose and nature of the interfaces and its implementors.
   • Are implementors expected to be stateless singleton services? Or are they database objects?
   • How are implementors created?
   • What services does an implementor have access to?
   • How much behavior should be the implementors have? For example, database objects should have minimal logic and have specialized managers do the business logic level operations.
   • What is the expected lifespan of implementors? Single transaction? Only for a session?
   • Life cycle control/ownership. Are implementors “owned” by another object and when the owner is removed so is this implementation?

   At this point, I have lots of interfaces, enumerations ( java enum ) that I am creating and destroying willy-nilly. With lots of TODO, FUTURE, and (yes even) HACK comments. Because I haven’t spent any time actually creating an implementation. I have no reluctance to discard, combine, or separate interfaces.

5. create the test framework: At this point, the interfaces are nailed down, the test pseudo-code can be converted to actual test code, and …
6. create the implementation Unlike true Test Driven Design methodology, I tend to write the implementations in conjunction with the test code. Too many times, I have discovered that nasty little issues around implementation require rethinking the interfaces and the tests. I want to minimize my investment in tests until I am reasonably certain that the production code being tested will not have major API changes because of implementation issues. (Example of an implementation issue: an external library requires data in an order that my planned implementation cannot handle)

However, many startups ignore the underlying reason and value for status updates and many big companies can easily avoid status meetings with a little bit of effort.

There is a value to status meetings!? What are you nuts?

Nope! Not talking about status meetings – status updates is where it is at.

Status updates can and should be sent by email every day. By everyone. Including the CEO.

For a status update to have value, it must:

• Be explanatory as to the reasons work was done. If the reason can’t be articulated — why was it done? (“Did X so that Y feature could be turned on in the next release”)
• Be forward looking. The status update must be usable as a planning document. When will the new feature be completed (in man-hours)
• Enable bad process to be discovered. Is something impacting all 10 developers 30 minutes/day? Solving that annoyance will save 5 man-hours a week!

The status email should have:

• successes (include “in progress” work): Brag. Celebrate successes. Explicitly indicate if:
  • work is completed as far as the sender is concerned
  • work is at a good resting point/milestone. Many times a task does not need to be “completed”, because “completed” means completely done as opposed to “major roadblock removed”
  • work still needs to be done on the task.
• planned work for next work period, with best guess time estimates/completion date. Include next time available (very important for part-time people). Plan out tomorrow today.
• frustrations arose that caused time to be “wasted” – use this to help spot problems with processes. The sender is NOT asking for help, but rather is calling out process issues.
• roadblocks that help is needed to solve. The sender must provide enough detail to form an actionable question or request. All details that the sender has discovered about the roadblock must be written. Writing out the problem with all the known information:
  • anyone trying to help does not have to duplicate already done research
  • sometimes leads directly to an “obvious” next step
  • might enable someone else to immediately provide an answer with little to no additional questions.

Its a little non-obvious but:

1. create a keyed-object in the user session.
2. the value is a Request + java Future for the result
3. return immediately with a client-side redirect.
4. while the client-side redirect is being handled, have a worker thread work on producing the answer.

By the time the client browser completes the redirect, getting the new page’s images, etc… the results are waiting for the user.

The alternative is to make the user painfully aware of how long the database is taking.

*Security Update (2011 Jan 24 ) :*

The key is vulnerable to attack since it is part of the response to the client, so

1. Generate a random key
2. Use user’s session id as a salt to create a SHA-1
3. Store both the random key and the SHA-1 in the database with (, ) as the primary key. (no separate indexing on just the RANDOMKEY.)
4. Use both RANDOMKEY and the SHA-1 as the db lookup.
5. Do not store the Session Id (avoid privacy issues with being able to corollate many entries to the same user)
6. Expire the results after 2-3 days. ( Allows a daily batch job to do the clean up and avoids creating problems for user sessions that are semi-long lasting )

This method requires any hacker to know both the session id and the random key.

This approach may seem overkill, but a redirect-hardened mechanism can be used for situations like password resets.

A purely random result key is highly problematic because of the high (and untested) impact of any collisions. I pick so strongly on this point because:

1. the developer is lulled into complacency about the actual collision rate
2. the impact of a collisions is unknown and probably untested
3. when/if a problem shows up:
   1. it will be in production
   2. the problem will be intermittent
   3. difficult to reproduce
   4. be disguised as another issue
   5. possibly cause data corruption
   6. possibly result in private user data being exposed
   7. difficult to retroactively correct.

I agree with the thrust of Jose’s perspective. Programmers should operate at the highest level possible. Thread management is very low-level and best left to the operating system.

However, asynchronous programming is valuable when used correctly. The specific cases that come to mind are:

1. Batch Operations ( for example, sending email, or file transfers). Typically the user is not waiting on the completion of the operation. The user may no longer be logged in. So deferring actual execution of the operation is useful and does not create valueless complexity
2. Transferable Operations: operations that can be transferred to another backend server for completion. For example, map/reduce operations with the eventual result being reported to the user.
3. Optional Operations: Operations that give a better user experience, but under heavy load can be terminated and a default result returned. Netflix does this with user recommendations. When Netflix is under heavy load or if the user-specific recommendations are slow coming back, the operation is timed out and default recommendations re returned.
4. Speculative “Prefetch” Operations: Operations that are done in anticipation that the result of the operation may be needed soon.
5. Network Delayed Operations: If the operation requires connection to an external service for example, sending a calendar item to upcoming.org. Upcoming.org may be down or slow. Your site’s user experience should not be impacted because of delays outside of your control. There is nothing that can be done about upcoming.org’s behavior. So decoupling your users experience from external influences via an asynchronous programming model is useful.