All posts by David Veksler

development

Why fix bugs with unit tests?

2 Comments

I know this is nothing new, but I will share my perspective anyway:

How I fix bugs with unit tests:

  1. Write a unit test that reproduces the bug so the test fails
  2. Fix the bug so the unit test passes
  3. Send a link with both to the bug submitter

Why I like it:

  • Saves time debugging – just run the unit test instead of recreating the bug scenario every time
  • Creates a simple yes/no criteria to verify whether the bug is fixed
  • Regression can be detected quickly in the future
  • Better communication: bug is documented for other developers looking at this code
  • If you don’t have time to fix the bug immediately, write a failing test.  Then you or someone else can fix the bug later
  • An organic way to increase code coverage for existing code

development

Project highlight: Mises.org Multimedia CMS

1 Comment

In February, I did a high-level review of the Mises.org CMS admin UI.  Today I want to highlight both the public and private parts a part of it: the multimedia CMS.

The Mises.org Media Management System is part of the Mises.org open source project.  It was started around 2004, and evolved slowly from there, with the latest release around February.  It is used to manage over 6400 audio/visual files.  Total document size is 275GB.  Monthly bandwidth exceeds 10 terabytes.   (You can find  the source code at Bitbucket)

The front-end features:

  • Dynamic, AJAX-based interface build with JQuery UI
  • Advanced search and browsing based navigation
  • Detects the best media player for the current browser: HTML5, Flash, or Silverlight
  • Extensive RSS support.  Integrates with iTunes and iTunes University with iTunes-specific feed extensions
  • Optimized for scalable deployment, CDN’s, SEO, external embedding, and social network sharing

The media asset management includes:

  • Support for internal and externally hosted content: MP4, MP3, WMA, streaming video, & YouTube
  • Integrated drag and drop uploader: management interface allows uploading multi-gigabyte media files straight from the browser us
  • Meta data parsing: reads full meta information such as embedded thumbnails, duration, keywords, description, etc.  Able to process all popular audio/video formats as well as PDF.
  • Catalog builder:  organizes files in a human-friendly format: http://library.mises.org/media/
  • Define arbitrary hierarchical categories
  • Versioning and multi-volume support.

Architecture:

  • Backend: ASP.Net 4.0, MVC3 (frontend) & Web Forms (backend), Entity Framework, and SQL Server
  • Frontend: JQuery UI, HTML5,

How to get it for your site:

Screenshots:

Continue reading Project highlight: Mises.org Multimedia CMS →

development

Tips for adding optional SSL support

Leave a comment

I am excited by the growing popularity of the HTTPS Everywhere plugin. I became aware of it recently when users wrote me to complain that some part of Mises.org did not work over SSL. It turns out that our store
software redirects visitors to the official hostname, so going to https://mises.org/store would redirect to http://mises.org/store, which HTTPS Everywhere would redirect back to https://mises.org/store, and so on. I decided to fix this and also to fix the “this page includes other resources which are not secure” warning.

How I implemented automatic SSL switching:

  • SSL proxy: We use CloudFlare as an SSL proxy. Even though we already had SSL configured on our Windows server, CloudFlare makes it easy to share SSL certificates between Windows and Linux servers, which is otherwise quite tricky. But it’s also great if your web server does not have SSL support.
  • Relative (scheme-less) Urls: I removed the scheme from all our resources, so they look like <img src=”//images.mises.org/Theme/images/bf_lvmi.png” alt=”” />  We are transitioning to scheme-less URLs for everything.  It allows users to choose HTTPS even if your site is served over HTTP by default.
  • Request.Url.Scheme: I used to append the URL scheme used by the request when I was not sure if the client (rss reader, email, templates etc) would support scheme-less URL’s. But this has the disadvantage of not working with cached pages. So far, it seems that scheme-less URL’s are safe for all popular web clients.

I don’t think there was ever much sense in having the http://www. prefix in URI’s, so getting it down to just // is very nice.

How to find non-SSL resources on a page:

One frustrating debugging step for me used to be finding the http resources within a page. I would have to search for http resources in the source code. If the page references scripts that load other resources, this could get complicated. Fortunately, Google Chrome offers a simple solution – the network inspector can export information to a searchable JSON file:

  1. Open a new private browsing session in chrome (to disable your extensions, which may inject non-SSL links within the page)
  2. Alt-click and “Inspect element”
  3. Go to the Network tab
  4. Open the URL to inspect
  5. Right click inside the Network tab and “Copy all as HAR”
  6. Paste the JSON into notepad, and search for http:// resources

One last note: If you use third-party widgets or services which do not fully support SSL, please take the time to contact the vendor and request that they add full support for SSL.

News

The HD revolution is coming to the web – update your creative process today

Leave a comment

You’ve probably heard about the “retina” displays on the iPhone 4/4S and the new iPad. These devices have double the display density of most other devices. The high-DPI displays of these devices are unique, but they won’t be for long. Most analysts are predicting that within a few months, Apple will introduce the same “retina” displays for their laptops as well. Once display manufacturers like Samsung and Sharp ramp up production, the rest of the industry will very likely follow.

In other words, we are facing the equivalent of the HD TV transition for personal computing. It will come to smartphones, tablets and then desktops. Speculating about the timeline of the transition is of course risky, but I suspect that there will be many high-DPI devices being sold by the end of 2012 – not limited to Apple. Certainly within a few years, we can expect the rest of the industry to follow. Because websites and applications can display content appropriate to the viewer’s hardware, they can gain a competitive advantage without imposing costs on non-HD visitors.

Currently very few websites and desktop applications take advantage of the high-DPI displays. While Apple has demonstrated how it can be done, the specific browser-side implementation may change. For most websites and applications it’s probably too early to invest resources in the transition. However, it is not too early to start updating your creative process to include high-definition graphics and video.  If you decide to upgrade your website six months or a year from now, it will be easier to use pre-prepared HD graphics than have to re-create them from the original PSD files (which may not be easily available.) Apple’s implementation makes it possible to transition to high-DPI by adding a single JavaScript file to your website – without increasing the page size for current users.

What this means in practical terms:

  • You should start preparing double resolution graphics and video for new content, especially important elements like headers & front page content.
  • If you target iPad or iPhone users, you should already be updating your website’s technology to support HD graphics & video.
  • When initiating projects going forward, you should give increasing consideration to adding support for high-DPI resolutions.

Update: visual guide.

development

Success factors for quality software development teams

Leave a comment
Some notes from a short presentation I gave on building quality software development teams:
  • Effective teams start with good people. A business is not a charity and cannot wait for people to grow into the role required of them. Intelligence and inherent motivation cannot be taught. These and many other aspects must be screened for.
  • But hiring good people is not enough.  Getting the most of a development team requires certain environmental factors. I have organized them into three areas:  internal/motivational, structural/organizational, and interpersonal/communication. Sometimes they will conflict with practical considerations, but we ought to take them consideration whenever possible.
Motivation
  • Instill a sense of professional pride
    • Developers should take part in the technical design
    • Provide interesting, challenging work
    • Developers should own the technical solution
    • Technical architects should be part of the development team
  • Respect the developer time
    • Provide a quiet environment dedicated to development work
    • Buy the best tools for the jobs – powerful computers, large monitors, etc.
  • Reward learning and exploration
    • Take (reasonable) risks with new technologies
    • Schedule time for self-education and information sharing
  • Create a sense of project ownership
    • Delegation “ownership” of functional parts to individual people
    • Assign developers responsibility for follow-up maintenance (don’t just hand it off to a maintenance team)
Structure
  • Hold people accountable for their work:
    • Use a work unit tracking system (TFS, etc)
    • Make task status publicly visible
    • Hold daily stand ups (Scrum)
    • Consider a public scrum board
    • Provide clear project requirements
    • Lean development approach
      • No time-wasting tasks (useless documentation)
      • Isolate developers from unrelated tasks (no business interruptions)
  • Hold high expectations
    • Monitor quality of work with code reviews
    • Regular training & information sharing sessions
    • Consequences for bad work
  • Set well defined deadlines
    • Don’t set arbitrary deadlines, but all work should have a deadline
    • Developers should have input on deadlines for their work units
Team Communication
  • Instill a sense of collective ownership of the project
    • Hold architectural education sessions
  • High-bandwidth communications
    • Entire team should work in physical proximity
  • Make quality visible
    • Use continuous integration and automated testing to provide immediate feedback of quality
    • Developers should fix their own bugs
    • Track quality over time
  • Explicit mentor roles
  • Mentor roles should be explicitly defined
  • Mentoring time should be scheduled into the project

 

reviews

Three jQuery-based frameworks for a rich UI

6 Comments

After spending several months refactoring a large ASP.Net MVC application for performance, I became intimately aware of certain fundamental limitations of the server-side UI approach and began looking into pure client-side UI frameworks as an alternative. Having decided on jQuery as the foundation, I’ve narrowed down the possibilities to three candidates: jQuery UI, Kendo UI and Wijmo.  Here are some of my conclusions:

 Why choose pure-client side?

My current development approach is MVC 3 “enriched” with the Telerik Extensions for ASP.Net MVC.   ASP.Net MVC HtmlHelpers are much simpler than the traditional .Net drag-and-drop Web Forms approach in that they simply return strings, without the baggage of ViewState management or a complex page event lifecycle.    This provides certain advantages: lightweight rendering, granular state management and simple AJAX – along with auto-generated HTML and IntelliSense.  But any developer-friendly server-side technology also has costs: server-processing time affects performance and flexibility, and server-side controls prevent you from having a true rich-client design which fully separates the user interface and business logic.

Presenting a new alternative to server-side MVC controls, are several client-side UI frameworks.  Much of the rich client movement comes from the open-source world with frameworks like SproutCore/Amber.js, YUI and Cappuccino.  But now that Microsoft is embracing HTML5, the two heavyweight .Net tool vendors are getting on-board as well.

There are three competing HTML5 UI/Ajax UI frameworks I want to mention.  They are pure-JavaScript libraries built on top of jQuery.

jQuery UI: 

jQuery UI provides a bunch of client-side UI widgets, “interactions” and effects.   It is semi-sponsored by industry bigwigs which include such as Microsoft and Adobe.

Pros: From the same team which brought you jQuery.  There are many plug-ins for missing functionality.  Theming is very nice. (Btw, Juice UI is server-side jQueryUI for ASP.Net WebForms – perhaps an intermediate solution?)

Cons: Key components are not included with the framework, such as Grid, Template, DataSource/DataView, Validation.

Cost: Free for commercial and non-commercial use: MIT and GPL licenses

 Telerik Kendo UI:

Kendo UI is a fork of Telerik ASP.Net MVC framework.  The first version of Kendo UI has just been released, but the client-framework is based on the two-year old Telerik MVC framework.

Pros: Complete feature set, with 16 widgets (vs. 8 for jQuery UI), including everything missing from jQuery UI; Visualization; Mobile versions of widgets;

Cons: Just released late 2011; is not jQuery UI;

Cost: GPLv3 and Commercial licenses; closed-source code requires purchasing the commercial license which starts at $399/1yr

ComponentOne Wijmo:

ComponentOne is Telerik’s arch competitor.  Their client-side offering is an “extension” of jQuery UI, and so relies on both jQuery and jQuery UI.  It is more mature (version 2.0) and they are sponsoring jQuery UI development.

Pros: mature; sponsor of jQuery UI development; works well (shares theming) with jQuery UI;

Cons: Free version comes with a subset of controls; replaces existing jQuery UI widgets

Cost: “Open” version with 18 widgets is free (MIT/ GPL v2).  “Complete” version with Grids, Charts, Forms, etc is $299-499

I’m still getting started with this approach, so I’m not sure which framework is best.  They are all good alternatives to a server-side framework (whether Web Forms or MVC).  They all have a learning curve and are probably less efficient from a developer perspective – especially one used to writing server-side controls.  On the other hand, they enable a different development methodology (isolation of UI and the service stack) which may be more efficient overall and better for performance and scalability.

My tentative suggestions:

  •  jQuery UI for open-source, small projects, low budgets, simple or non-form heavy UI, and minimal support or learning-curve availability
  • Kendo UI to leverage Telerik MVC expertise and maintain compatibility with MVC
  • Wijmo when a rich UI is needed as well as compatibility with JQuery UI or the open-source world
tips

Four tips for more effective web design projects

Leave a comment

I want to share some strategies for maximizing the productivity and effectiveness of  web design projects.  I’ve used them when the project has a large scope but minimal budget for a professional design team, such as non-profit organizations.

1: Visualize your users with analytics, personas, and user stories

The most important consideration in web design is to meet the needs of your users. There are two aspects to this:

First, collect statistical data on the demographics and usage patterns of existing users. Use web analytics, (GA), in-page analytics (GA events, crazyegg) to understand exactly how users use the site, what content is popular, and how that relates to revenue goals.  There is no need to rely on hunches and guesses when the relevant information is easily available.

Second: visualize the kind of customers you have and want to have with personas and user stories. Understand their goals and visualize the best way to meet them.

2: Steal ideas from the best

Web design consists mostly of weaving together design patterns from other projects. Coming up with entirely new design paradigms is very rare, difficult and risky. With that in mind, how can we choose the best design patters for a projects? By systematically borrowing from other successful designs.

One of the nice things about web development is that it is much easier to copy successful designs than in other fields. So why not pick the very best websites on the web? There are many websites which have spent millions on market research and high-end design firms. I systematically research successful designs and borrow the best elements from each. Many people make the mistake of only looking at their competition for inspiration.  But looking just like the competition won’t inspire users and limits you to a very narrow sample.

Here are three ways to find sources for inspiration:

  • Look for winners of web design awards
  • Frequent web design blogs & magazines
  • The easiest way: go straight for the websites with the biggest design budgets.

For #3, I sometimes use Wikipedia as a resource to find proxies for design budgets and just go down the list. For example, I use the list of the wealthiest charitable foundations or the largest market caps.  I go straight down the list and note the designs I like.
For example, #5 – the Ford Foundation has a very effective design.  The useful information we can gather goes far beyond visual elements.  By researching their site, press releases and job ads, I was quickly able to identify their technology platform, content management system, the person in charge of their information technology (technical people at non-profits are often willing to share expertise) and some of the contractors they hired to work on it.  The cross-section of people visiting the Ford Foundation and your site is likely to be very small, so you can borrow more liberally than you could from a competitor.

3: Develop a design language

A “design language” is a set of visual concepts which we can use as building blocks for a web design. A design language helps us share ideas visually and then create consistent look and feel for the site, even if multiple people or multiple iterations are involved. A coherent design pattern is very important for a site. I suggest something like a Google Docs document with screenshots of elements from other sites and mockups. Eventually we can weed it down to unique elements representing key building blocks: header, menu, tabular data, form, product list, etc.

A design language is also important for controlling costs, as it is cheaper to pay a designer to create a reusable set of elements than to pay them to create each page from scratch.

4: Aim for the web technologies of the future

The lifetime of the average web design is about three years, though many last much longer. Three years is a long time in web design – paradigms come and go very quickly, as does the need to respond to competitors. That’s why it’s important to find the right balance between targeting emerging technologies while controlling risk. For example, most people don’t have smartphones with full web browsers, but they are likely to in a year or two. It thus makes more sense to invest in full-featured mobile sites and not the last-generation WAP version. At the same time, we don’t know if the Apple, Android, or Windows Phone platform will be most popular in the future, so it’s best to build mobile web versions than native apps in today’s hottest platform.