A Recipe for Green-Field Software Development

[Re-post from Nov, 2008]

Developing Your Product and Your Customers in Parallel

I’ve been a member of a software development team since 1985.  That’s 23 years as a software developer.

Like many developers who have been around for a few years, some of my grey hair can be attributed to having worked on hellish projects, or on projects that failed outright.  Over the years, I’ve gradually added to my mental list of “worst practices”—things that tend to lead to project failure, or at least hide a failing project until it’s too late to turn it into a successful one.

It’s much easier to compile a list of worst practices than it is to pick some “perfect” development process.  But worst practices can lead to best practices simply by avoiding the bad practices.  At a minimum, we should at least avoid making the same mistakes over and over again.

If I had to pick a single worst practice (there are many), it would be this:

Not building the product that the customer really needed

This happens all of the time.  We (the developers) build a product that is bug-free, efficient, scalable, and does exactly what we intended it to do.  We even occasionally get the work done in something close to the amount of time that we said it would take.

But our well-built software still fails—for a variety of reasons.

  • It’s too hard to use
  • Users are unable to use it efficiently/effectively
  • It’s missing one or more critical features
  • Users don’t have a need for the software in the first place
  • It’s too expensive, given what it does

In order to be “successful”, software has to meet a critical need that the user has.  Good software solves a pressing problem.  Great software does so in a way that seems natural to the users.

So what do I mean by software “failure”?  Simply put, “failed” software is: software that doesn’t get used.

What are the consequences of failure?  For internal software projects, it means wasted time and energy that could have been spent on things that the organization does need.  For consulting houses, it means possibly not getting hired back by the client, or seeing your reputation diminished.  For ISVs developing software/services to sell, it means lost revenue or even bankruptcy.

For developers, failure means knowing that you’ve wasted your time, intellect and energy on something that no one is going to use.  That’s no fun.

Our goal then as developers is to build great software.  We want to see users working with our stuff, to see it making their lives better, and to see them excited about it.  That’s the true Holy Grail that many of us work towards.

The Remedy

So how do we develop great software?  We can’t all be Steve Jobs, or hire him into our organization.  So without brilliant insight, how do we figure out what the users truly need?

To understand what users need—truly, madly, deeply—we need to think beyond developing products and start thinking about developing an understanding of our users.

This focus on a Customer Development Process, rather than a Product Development Process, is the point of the book The Four Steps to the Epiphany, by Steven Gary Blank.

Blank’s main thesis is that we should work towards an understanding of our customers and their needs much earlier in the development lifecycle.  We need to fully understand what customers need and whether we can sell them our product before we go too far down the path of building that product.

Blank proposes a very detailed Customer Development Process and talks a little bit about when it should occur, relative to the typical phases of a Product Development Process.  This is a little tricky.  If we wait too long to learn about our customers, we risk building the wrong product.  But if we talk to them too early, before we’ve had time to think a little bit about our vision, we’re not really innovating, but just trying to build what they tell us to build.  That also can lead to failure.

The Product Development Process

Having worked as a software developer for so many years, I’ve seen lots of different software lifecycles.  In my first job, with Control Data Corp in Bloomington, MN, we were a Dept of Defense shop and rigidly followed DOD-STD-2167A—a very rigidly-defined classic waterfall process.  (Ask me about the 4-foot high Software Requirements Specification).

I’ve also done my share of agile development, working in groups that used various agile methods.

My main takeaway on software process is that it’s important to develop iteratively.  For me, that’s the most critically important piece of the agile movement.  Many of the other techniques, like pair programming and test driven development might be important, but don’t seem quite as critical as being able to build your product iteratively.  Short iterations allow agility.

For me, one book that really made a lot of sense in laying out a framework for an iterative lifecycle was The Rational Unified Process Made Easy, by Per Kroll.

For a lot of people, when they think about RUP (Rational Unified Process), they think: heavyweight and lots of modeling/diagramming.  But Kroll explains that RUP doesn’t necessarily mean heavy.  He refers to the number of artifacts that you’re required to produce as your level of ceremony.  And he describes RUP as:

An iterative approach with an adaptable level of ceremony

Again, iterative is the important part.  An iterative approach with very little ceremony would basically be an agile methodology.  But sometimes you work on projects that require a bit more ceremony—some project tracking, etc.  On these projects, you can still be iterative, but with more ceremony.  Here’s a picture:

rupmap

RUP talks about general phases of the lifecycle being: Inception, Elaboration, Construction and Transition.  But Kroll is quick to point out that this does not just map to the classic waterfall model.  (Requirements, Analysis/Design, Implementation, Testing).  Rather, you’d typically perform some of each of the classic waterfall activities during each iteration of RUP.  You’d likely be doing a lot more requirements-gathering in your Inception phases, but you’d also be doing some implementation.  And you’d spend a lot of time writing code during Construction phases, but you might also still be tweaking some requirements.

Here’s a nice picture of how RUP typically plays out.  Again, note that the idea of iterations is important:

rupphases

Personally, I like this view of the development lifecycle a lot.  This model is how I think about software development.  Work in an iterative fashion, but be aware of what main phase you’re in and adjust your activities accordingly.

Over the years, I’ve taken lots of notes to answer the question, “what activities should I be doing at each step”?  Kroll has a lot of good information in his book, but I’ve borrowed liberally from other sources.  What I ended up with was a fairly detailed “a la carte” list of activities that you might engage in across the lifecycle.

I say “a la carte” because every project will not engage in every step.  But I think it’s a nice master list to draw from.  And I think that I have the activities listed in a pretty reasonable order.

So here’s my list of high-level activities for the Product Development Lifecycle.  (See below for more detail for each activity):

  • Vision
  • Initial Requirements Gathering  (Inception)
  • GUI Conceptualizing
  • Identify Candidate Architecture
  • Define Non-Functional Tasks
  • Define Iterations  (Project Planning)
  • Write Development Plan
  • Execute Elaboration iterations
  • Write Business Plan
  • Write Test Plan
  • Write Deployment Plan
  • Execute Construction Iterations
  • Initiate Test Plan
  • Deploy Alpha Release
  • Write Customer Support Plan
  • Execute Deployment Iteration
  • Deploy Beta Release
  • Launch Product
  • Begin Planning Next Release

The Customer Development Process

I love the idea of the Customer Development Process, as Blank presents it in The Four Steps to the Epiphany.  He talks about discovering who your customers are, figuring out what they need, and then testing your hypotheses.  In other words—iterate not just on the product, but also on your model of who the customers are.  This includes not just an understanding of the customers and their needs, but also gets into the actual selling proposition and marketing of your product.

Here are the top-level activities in Blank’s customer development process:

  • Customer Discovery
  • Customer Validation
  • Customer Creation
  • Company Building

Lining Things Up

The trick is to figure out how the Product Development Process and the Customer Development Process relate to each other.  If you listed out the various phases of each process side by side, how would they line up?  At what point in your product development process should you start the customer development process?  Or should it be the other way around?

Here’s a first stab at lining the two processes up.  My goal was to come up with a high-level roadmap for doing new (green field) development, which would cover developing both the product and the customers.

Product Development Process
Customer Development Process
Vision
Initial Requirements Gathering
GUI Conceptualizing
Identify Candidate Architecture
Define Non-Functional Tasks
Define Iterations (Project Planning)
Write Development Plan
Execute Elaboration Iterations  >> Customer Discovery
Write Business Plan
Write Test Plan
Write Deployment Plan
Execute Construction Iterations  >> Customer Validation
Initiate Test Plan
Deploy Alpha Release  >> Customer Creation
Write Customer Support Plan
Execute Deployment Iteration
Deploy Beta Release
Launch Product
Begin Planning Next Release  >> Company Building
.

Should I Keep Reading?

The rest of this post expands on each of the activities in the table above, listing details of what happens during each phase.  This is the outline that I use when I’m trying to figure out “what to do next”.

Note again—this process is very much geared towards green-field development, and in a market where you are developing a product or service to sell to end-users.

Product Development Process—Details

Here’s the detailed breakdown of the steps involved in the Product Development Process.  Much of this content comes from the books I list at the end of the article, primarily The Rational Unified Process Made Easy and Head First Software Development.  But a lot of it is just my own concept of what you typically do during each phase.

Note that iterations occur in the Elaboration and Construction phases.

Vision

  • Do a short description of a handful of possible products
    • For each, describe:
      • Market or market segment  (which group of users, short description)
        • What is the problem that they experience
        • How painful to the users?  What workarounds are in place?
      • Short description of product that might help them solve this problem
      • Short feature list (<10 items, single sentence)
      • How does this product specifically solve the customer’s problem?
  • Expand on top one or two possible products.
    (For each, expand information to include):

    • Write up SIMs (Specific Internet Market Segment, Walshpg 158..)
      • Lots of details about the targeted user group
    • Other user information
      • How often do you expect each user group to user the product?
      • Why might they stop using the product?
      • Rough guess as to size of this market, e.g. # potential users?
    • Are there other non-primary users?
      (E.g. users who didn’t purchase, or just different group of users)

      • Also describe their “problem” and how product solves it
      • Are they also potential buyers, or just users?
      • What subset of the feature list might they use?
      • What else differentiates them from primary user group?
      • Also write up SIM for this user group
    • Bluesky one or more revenue models.  Answer for each:
      • What would this customer pay for this product?
        • Specify target price or range that might be tolerable
      • One-time purchase or ongoing subscription?  (or a combination)
      • Pricing tiers?  If so, describe
      • Trial period?  If so, describe
      • If >1 user group, repeat for other groups
      • What level of certainty do you have that they will purchase?
      • Why might they not purchase?  List reasons.
      • Possible ways to mitigate non-purchase reasons.
      • Does revenue model depend on continued use of the product?
      • How will you collect money?
      • What is your distribution channel?  (i.e. how do they receive product)
      • If ongoing subscription, describe what happens when they stop paying
        (E.g. limited access)?
    • Revenue model/estimates  (per yr)
      • Make rough estimate of ongoing costs, per user or account
      • List expected revenue per user, single or ongoing, per yr
      • Starting with desired annual revenue, describe # customers required to meet goal
    • Marketing / Sales vision
      • How might product be branded?
      • How is product positioned (e.g. tagline)
      • How might you reach desired users?  (make aware)
      • What is selling proposition (argument to buy)?
    • Competitive analysis
      • Assess and summarize competitive products that do similar/same thing as yours
      • What are their strengths/weaknesses?
      • Where can you improve on them?  To what degree?
      • What are you missing that competitors might have?

Initial Requirements Gathering
(Chap 2 of Head First Software Development)

  • Generate quick list of basic ideas, 1-3 sentences each, Title/Description
  • Ask user questions to flesh out the list
  • Bluesky to generate feature lists (Title/Description)
    • Use other people
    • Okay to spit out non-functional stuff, like specific GUI thoughts, or architecture
  • Build User Stories
    • Describe one thing
    • Language of the customer
    • Title/Description
    • 1-3 sentences
  • Pull out non-customer stories, save for later (design)
  • Refine initial set of user stories, w/customer feedback
  • Provide estimates for each user story
    • Include assumptions
  • Team estimation and revision
  • Clarify assumptions w/users, if necessary
  • Break apart users stories that are >15 days
  • Add up estimates to get estimate for total project

GUI Conceptualizing

  • Select key use cases that need GUI concept
  • User interaction goals
    • Outline some key goals of user interaction model
      (E.g. discoverability, efficiency, slick animation, etc)
    • Describe user action requirements verbally for specific use cases
  • Assess similar products’ GUIs for similar use cases
    • Pros/cons of each
  • For each use case selected
    • Paper prototype one or more possible GUIs
    • Storyboard any dynamic behavior
    • Brainstorm alternative approaches and paper prototype
  • Identify common sequences of use cases  (e.g. find/edit)
    • Storyboard use case sequences
    • Brainstorm ways to optimize the storyboard/sequence
  • Assess GUI model against several measures of good GUI design
  • Technical review of GUI feasibility
    • Build it, buy it, or freebie (part of tool or freeware)?
    • If build, rough guess as to effort
    • If buy, what is the cost?  One-time & ongoing.
  • Assess technical risk
    • Are there any aspects of GUI that need to be proven out?
  • Hammer looking for nails
    • Make short list of most compelling GUI models in new products
    • Is there anywhere in product that you might use these models?
  • Brainstorm user assistance model (help, wizards, demos, etc.–learning)
  • GUI models from competitors
    • If there are competitive products that compete in same space, summarize their main GUI elements.
    • Assess—is their GUI or user interaction model an asset or a liability?
  • Review
    • Early review internally (not w/customers)
    • Review static screen mockups (e.g. paper prototypes)
    • Look at discoverability–obvious what it’s used for?
    • Aesthetics

Identify Candidate Architecture

  • Identify one possible architecture that could support the product
  • Identify any areas of technical risk
  • Discuss pros/cons/risks
  • [For more details, see Kroll]

Define Non-Functional Tasks

  • Define additional tasks to be completed during inception that are NOT use cases
  • Possible examples include:
    • GUI proof-of-concept, for technical & usability
    • Building candidate architecture  (must do)
    • Technical proof-of-concept
    • Capacity testing for architecture (e.g. scalability)
  • Provide priorities and estimates for all tasks
    (will feed into iteration planning, along w/use cases)

Define Iterations
(Chap 3 of Head First Software Development)

  • Set target date for first (next) release
  • Work w/customer to prioritize user stories
  • Also feed non-functional tasks into process
  • Select subset of user stories to meet target date  (Milestone 1)
    • If the features don’t fit target date, re-prioritize
    • Focus on user stories that are absolutely critical
    • Baseline functionality–smallest set of features so that SW is at all useful to customers
  • Prioritize user stories in Milestone 1.0  (1-5, with 1 as highest priority)
  • Assign user stories to iterations, using 20-day iterations
    • Based on priority
    • Or user stories required to implement other user stories
    • Use velocity of 0.7  (0.7days effort for each real day)
      I.e. Each iteration should contain 14 person-days of estimated work
  • Reassess schedule and adjust schedule and/or content
    • Because of velocity, things likely can’t fit
    • Add iteration(s), change M1 date, or both
  • Get iterations & user stories into tracking spreadsheet
  • Construct burn-down graph for 1st iteration
    • X axis is calendar days
    • Y axis is person-days of work accomplished
    • Draw diagonal line as ideal burn-down rate

Write Development Plan

  • Describe everything that will happen from here on out
  • Include
    • Iterations and contained user stories & tasks
    • Milestones
    • Review points and staff
    • High-level test plan
    • alpha/beta/release plan
    • Staff
    • Schedule
    • Tools
    • Show steps in Product Development process
    • Show steps in Customer Development process
    • Show how the two processes line up
    • Include calendar alignment, if appropriate

Execute Elaboration Iterations
(Chap 4 of Head First Software Development – User stories & tasks)

  • Break down each user story into tasks
    • Title/Description/Estimate
    • Provide estimate for each task
    • E.g. Create class, create GUI prototype, create schema, create SQL scripts
    • Each task should be 0.5 – 5 days
  • Plot where you are on burn-down graph
    • Calendar day vs. new estimate of person-days of work left
  • Update spreadsheet w/tasks & their estimates
    • Task estimates replace user story estimates
    • Also track burn-down in spreadsheet
    • Put stickies on big board, tasks, In Progress/Complete, etc. (pg 116 of Pilone/Miles)
  • Start working on first tasks
    • Move stickies on board when they are In Progress
  • Daily stand-up meetings to track progress
    • First thing in the morning
    • Track progress–what has each person accomplished
    • Update burn-down rate
    • Update tasks
    • What happened yesterday, what is plan for today
    • Talk about any problems
    • 5-15 mins long
  • Add unplanned tasks to iteration, if necessary
    • Add user story, estimate, break into tasks, review w/customer, add to board
    • Use red stickies
    • Update burn-down, showing that you’re off
  • Next iteration
    (Chap 10 of Head First Software Development)

    • End of iteration review (pg 342-343 of Pilone/Miles)
    • Verify SW passes all tests
    • Demo/review w/customer
    • Plan next iteration
      • Add new user stories, if required
      • Update priority/estimates for everything
      • Adjust velocity
      • Feed in bug backlog as tasks
      • Priority tradeoffs include bug-fixes vs. new features
    • Follow steps from Pilone/Miles chap 4 (break down into tasks and estimate)

Write Business Plan

  • Goal isn’t to get funding, but to make a case for the product/business
    (at least on paper)
  • Include stuff like
    • Market description
    • Customer description
    • Description of competitors’ products/services
    • Product proposition
      • What is customers’ problem?
      • What is your vision for product/service
      • How does product/service solve their problem?
    • Outline of development plan
    • Outline of Product/Customer Development processes
    • Summarize revenue model
    • Summarize marketing/sales plan
    • Business structure: staffing, organization, etc.
  • Add other typical business plan elements

Write Test Plan

  • What to test, how to test, when to test
  • Plan for test-driven development, using appropriate TDD tools
  • Plan automated/nightly builds and automation of testing
  • See Pilone/Miles, chap 7, among others

Write Deployment Plan

  • How/when will software be deployed?
  • Map out alpha/beta/launch
  • Where does testing fit into the plan?
  • How will customers get the software?
  • How will they pay for it?
  • How do you track customers?

Execute Construction Iterations
(Chap 4 of Head First Software Development – User stories & tasks)

  • Break down each user story into tasks
    • Title/Description/Estimate
    • Provide estimate for each task
    • E.g. Create class, create GUI prototype, create schema, create SQL scripts
    • Each task should be 0.5 – 5 days
  • Plot where you are on burn-down graph
    • Calendar day vs. new estimate of person-days of work left
  • Update spreadsheet w/tasks & their estimates
    • Task estimates replace user story estimates
    • Also track burn-down in spreadsheet
    • Put stickies on big board, tasks, In Progress/Complete, etc. (pg 116 of Pilone/Miles)
  • Start working on first tasks
    • Move stickies on board when they are In Progress
  • Daily stand-up meetings to track progress
    • First thing in the morning
    • Track progress–what has each person accomplished
    • Update burn-down rate
    • Update tasks
    • What happened yesterday, what is plan for today
    • Talk about any problems
    • 5-15 mins long
  • Add unplanned tasks to iteration, if necessary
    • Add user story, estimate, break into tasks, review w/customer, add to board
    • Use red stickies
    • Update burn-down, showing that you’re off
  • Next iteration
    (Chap 10 of Head First Software Development)

    • End of iteration review (pg 342-343 of Pilone/Miles)
    • Verify SW passes all tests
    • Demo/review w/customer
    • Plan next iteration
      • Add new user stories, if required
      • Update priority/estimates for everything
      • Adjust velocity
      • Feed in bug backlog as tasks
      • Priority tradeoffs include bug-fixes vs. new features
    • Follow steps from Pilone/Miles, chap 4 (break down into tasks and estimate)

Initiate Test Plan

  • Begin regular testing
  • Functional, integration, system test (no customer testing yet)

Deploy Alpha Release

  • Outline goals for beta and exit criteria
  • Identify potential customers/users
  • Communicate w/users about goals & feedback mechanism
  • Feeds into appropriate spot in Customer Development process
    • Possibly at end of each construction iteration
  • Gather feedback and feed into development
    • E.g. Changes desired/required?

Write Customer Support Plan

  • How will customers be supported after software is deployed?
  • List main goal(s)
  • Decide on tools, e.g.
    • External issue tracking
    • FAQ sheets for tech support staff
  • Decide on process(es), e.g.
    • Communication w/customer
    • Looking for answer in FAQ
    • How to communicate answer, if known
    • Get closure
    • 2nd tier–investigate, look for workaround
    • Interaction between staff (e.g. support/development)
    • 3rd tier–reported bug, e.g. give bug # and have traceback mechanism
  • Escalation process

Execute Deployment Iteration

  • Working on deployment tasks, e.g.
    • Installs/uninstalls
    • Distribution/delivery
    • Payment
    • Customer tracking

Deploy Beta Release

  • Outline goals for beta and exit criteria
  • Identify potential customers/users
  • Communicate w/users about goals & feedback mechanism
  • Feeds into appropriate spot in Customer Development process
    • Likely after Deployment Iteration
  • Gather feedback and feed into development
    • E.g. Changes desired/required?
  • Beta should not last indefinitely

Launch Product

  • Announce product
  • Launch it
  • Throw a big party

Begin Planning Next Release

  • Post-mortem for Product/Customer Development processes
  • Lessons learned
  • Changes to process
  • Assess organize outstanding bugs
    • Prioritize, estimate
  • Organize list of possible future features
    • Plan mechanism for using existing customers to get feedback on priorities
    • Prioritize, estimate
  • Decide on schedule for next release
  • Map out iterations
    • Each iteration either bug-fixing or new development
    • Bug-fixing phase likely first
  • Goal: All bugs fixed prior to next release
  • Continued refinement of plan, based on ongoing customer feedback
  • Back to start of Product/Customer Development processes for next release
    (follow same processes, including updating relevant plans)

Customer Development Process—Details

Here’s the detailed breakdown of the steps involved in the Customer Development Process.  This comes directly from Four Steps to the Epiphany.

Customer Discovery

  • State hypotheses
    • Write briefs, state assumptions about product, customers, pricing, demand, competitors
  • Test problem hypotheses
    • Test in front of potential customers
  • Test product concept
    • Test product features in front of customers
    • Solves their problem?
    • Also test business model
      • Must-have?
      • Pricing
      • Distribution
  • Verify
    • You understand the customer’s problems
    • Your product solves these problems
    • Customers will pay for the product
    • You have in mind a profitable business model
  • Repeat if necessary

Customer Validation

  • Get Ready to Sell
    • Articulate value proposition
    • Prep sales materials & collateral plan
    • Develop distribution channel plan
    • Develop sales roadmap
    • Hire sales closer
    • Synch up Product/Customer Dev teams on features/dates
    • Formalize advisory board
  • Sell to Visionary Customers
    • Sell unfinished product
    • Answer all sales roadmap questions
  • Develop Positioning
    • Initial positioning
    • Articulate belief about product and its place in the market
  • Verify
    • Enough orders to prove we can sell?
    • Profitable sales model?
    • Profitable business model?
    • Can you scale the business?
  • Repeat, if necessary

Customer Creation

  • Get Ready to Launch
    • Market Type Questionnaire
    • Choose Market Type
    • Choose 1st Year Objectives
  • Position company & product
    • Select PR agency
    • Positioning audits
    • Positioning to market type
  • Launch company & product
    • Select launch type
    • Select customer audience
    • Select the messengers
    • Craft the messages
    • Message context
  • Create demand
    • Demand creation strategy
    • Demand creation measurements
    • Iterate or exit

Company Building

  • Reach mainstream customers
    • Change “earlyvangelists” into mainstream customers
    • Manage sales growth by market type
  • Review management / Create mission culture
    • Review management
    • Develop “mission-centric” culture
  • Transition to functional departments
    • Set department mission statement
    • Set department roles by market type
  • Build fast-response departments
    • Implement mission-centric management
    • Create an “information culture”
    • Build a “leadership culture”

Closing Thoughts

The key takeaway for me from Blank’s book was as follows:

It’s not enough to build a great product.  You must also build a product that the customers need and that they will buy.  It’s also critical to find a workable business model to sell to the right customers at the right price.

If you haven’t yet read Four Steps to the Epiphany, I’d really encourage you to go out and read it.  Then you can start thinking about how to develop your customers, as well as your product.

Sources

I’ve used the following sources, in varying degrees, for this post:

Windows 10 Preview Install Screenshots

Time to capture screenshots from install of the Windows 10 technical preview (build 9841).  Below are the screenshots from a typical installation.

Windows logo

W10-001

Most of this stuff is going to look identical to the existing Windows 8 install.

W10-002

EULA.

W10-003

The install then gets going.

W10-004

Almost done now.

W10-005

After a reboot, we some of the standard install screens.

W10-006

 

We spend a fair amount of time in the “Getting ready” phase.

W10-007

We do another reboot and then get the first Settings screen.

W10-008

You must create a local account.

W10-009

 

Final stuff.

W10-010

Mention of the app store.

W10-011

The install is very polite.

W10-012

Finally, here’s our first view of Windows 10.

W10-013

 

Preventing PowerShell Window from Disappearing

Here’s a handy tip.  If you run a PowerShell script by right-clicking a .ps1 file and selecting Run with PowerShell, a command window will appear and the script will run.  If an error is displayed, however, the window will disappear before you can read the error.

To prevent this by leaving the window visible:

  • Open the Registry Editor (regedit)
  • Navigate to HKCR\Microsoft.PowerShellScript.1\Shell\Command
  • Edit the default property by dbl-clicking on it
  • Immediately before “-Command”, add -noexit (make sure to include spaces before/after the new text)

(Default) entry should now read:

“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -noexit “-Command” “if((Get-ExecutionPolicy ) -ne ‘AllSigned’) { Set-ExecutionPolicy -Scope Process Bypass }; & ‘%1′”

Exit Registry Editor and re-run your script.  Powershell windows will now remain open after execution.

 

 

 

TechEd NA 2014 – Building Rich Apps with AngularJS on ASP.NET

TechEd North America 2014, Houston
Building Rich Apps with AngularJS on ASP.NET – John Papa

Day 4, 15 May 2014, 8:30AM-9:45AM (DEV-B420)

Disclaimer: This post contains my own thoughts and notes based on attending TechEd North America 2014 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of either Microsoft, the presenters or the speakers.

Executive Summary—Sean’s takeaways

  • Some great tips for organizing AngularJS projects
    • Organized based on modules
    • Keep Controller code separate from View
    • “Above the fold”—show interface for code at the top, without implementation
  • HotTowel is good template for creating a new project
  • SideWaffle.com also has a bunch of template for AngularJS objects
  • Use design tools in Chrome to look at Javascript, data on wire, etc.
  • Use BreezeJS to do more involved CRUD apps
    • Change management
    • Dirty bit
    • Work in Progress, persisting local data
  • Persisting data locally really improves user experience

Full video

John PapaTech Evangelist, formerly of Microsoft
@john_papa
www.johnpapa.net

Why AngularJS works

  • Results quickly
  • But then you hit walls
  • This session is—about getting past these walls
  • 10 tips

Emotional roller coaster ride

  • Not a smooth ride, need to get past bumps

Building large scale apps requires some planning

Demos can be found at

Agenda

  • How components fit (basics)
  • HotTowel
  • Coding patterns
  • Structuring your project
  • Modularity
  • Tracing data
  • Exception Handling
  • Rich Data
  • Validation
  • Local Storage / WIP

Important to know which thing you need

Tip 1 – Component hierarchy

  • Module – sort of like namespace in .NET
  • Routes to get to various views
  • Views / binding ($scope) / Controller
    • $scope – data binding
  • In View, use Directives
    • 3rd party widgets
    • Like HTML tag in View
  • Controllers can have Factories
    • Features to share across controllers
    • Factory aka Service
    • SOLID principles

View

  • HTML
  • Built-in AngularJS directives

Controller

  • Goes in module
  • Handles View’s needs
  • Contains logic for the view (presentation)

$scope

  • Data binding

Modules

  • Create module
  • Way to inject features into your application
  • Bring in modules from other places
  • Containers of related features
  • Inject functionality into your app

Routes

  • Wire up URLs to Views
  • Defines app navigation

Directives

  • ng-xxxx – angular directive
  • Callbacks
  • Extends HTML
  • Javascript can stay in controller
  • Encapsulate reusable widgets

Factories

  • Basically, services
  • Singleton instance, share code across controllers
  • A controller’s best friend
  • Controller, always get instance (new)
  • Ideal for abstracting things like logger, local storage, etc.


Tip 2 – Jump-Start with HotTowel

  • Easy way to get started, rather than looking at blank screen

Project template

  • Layout – CSS and fonts should be there
  • Angular in project
  • Other commonly used scripts
  • Starter Files – Controllers, Views, Services

HotTowel-Angular

Demo – HotTowel

  • File|New ASP.NET Web, empty
  • NuGet package manager
  • HotTowel.Angular
  • Gets dependent stuff
  • Moment – date library
  • FontAwesome – fonts

Tip 3 – Coding Patterns

Each component has one Job

  • Shorter .js files
  • Code always has interface and details
  • Name of service at top
  • Public portion with just list of functions
  • “Above the fold”

AngularJS File Templates

Demo – SideWaffle

  • Lots of great things in Add New Item


Tip 4 – Structuring Your Project

Guidelines for Organizing AngularJS

  • L – Locating code is easy
  • I – Identify code at a glance
    • E.g. Not “Factories.js”
  • F – Flat structure as long as we can
    • Lot easier to find something in flat structure
    • After 7-10 files in folder, create sub-folder
  • T – Try to stay DRY
    • Don’t Repeat Yourself

Typical – folders by type, e.g. controllers, services, etc.

  • But when project gets big, this gets unwieldy
  • Better to do it by Feature
    • E.g. Dashboard, Person, etc.
    • Easier to split out on multiple-person team
  • If someone says you’re doing it wrong—they’re wrong
  • Browser doesn’t care how you organize your code

Options for structuring your file

  • By Type
  • By Feature
  • Combination

But be consistent

Tip 5 – Modularity

Modularity

  • Iterative development
  • Reusable components
  • E.g. add new module, plug into main module
  • Reusable components to assemble an app

Modules

  • Containers of related features
  • Modules can depend on other modules

Modules are Containers

  • <html ng-app=”moduleName”>
  • Module contains all of the supporting members for the associated feature

Categories of Dependencies

  • Angular modules – e.g. routing
  • Custom modules – things that you write
  • 3rd party – e.g. bootstrap, Kendo

Example for a modular app

  • Modules: Layout, Dashboard, widgets
  • Share core configuration—put this in a Core module
  • Drawing dependency chart for modules

Demo – Modularity

  • app.module.js – just lists the modules at the top that you need
    • E.g. Dashboard, layout, widgets
  • E.g. avengers module
    • avengers.module.js – defines angular.module and lists dependencies
  • On GitHub, johnpapa/ng-demos
  • Each module has its own routes
    • Use routehelper.configureRoutes
    • Each module defines its own routes
  • Core module
    • core.module.js – lists Angular and custom modules that it depends on
    • config.js – general configuration stuff, like app name, etc.
    • In core because all modules use this
  • Common module
    • Defines module that is end of the chain, no dependencies, empty array []

Tip 6 – Tracing Data

Tracing the data calls ** slide **

  • View – button press “Get Avengers”
  • $scope – binds to Controller
  • Controller calls Data Factory
  • $http – Ajax
  • Hits web service
  • Note: Application is asynchronous, i.e. responsive while data is being retrieved
  • Data Factory handles async response
  • When data comes back, you need to tell Angular that you got the data
    • Angular digest cycle sees the data
    • With $http, Angular knows when data returns, automatically triggers digest cycle

Demo – Tracing Data in the Browser

  • avengers.js – gets data, uses .then for promise, indicating what to do when data comes back
  • Using debugger in Chrome

Tip 7 – Exception handler

  • One place to handle all exceptions
  • Use toast to show errors

Catch and Handle all Exceptions

  • Local and Remote logging
  • Dev vs. Debug modes
  • Consistency

Decorate the $exceptionHandler Service

  • You add to built-in exception handling features

Demo – Exception Handling

  • Look at exceptionHandler.js


Tip 8 – Rich Data: BreezeJS

  • When you need more than just simple data

Why Use Rich Data?

  • $http gives you basic access to data
  • After that, Breeze lets you
    • Track changes, etc.
  • Multiple views of the same object
  • Change data in one place, change flows to other places
    • Propagate changes

Dirty entities

  • Can do stuff like setting Enabled for widgets, based on dirty bit

Demo – BreezeJS

  • Breeze can hit against various things, e.g. Mobile Service, EF
  • Breeze keeps track of changeset – added, modified, deleted
    • Data not yet sync’d to database
  • Breeze then saves data back to cloud, but only the stuff that’s changed
  • Explicit sync

Tip 9 – Validation

  • Do you validate changes on client for better user experience?
  • When validation error occurs, show the user immediately

Model Validation

  • Where does presentation logic belong?
  • Validating in HTML
    • Appears in every view
  • Push validation down into Model
  • How do we validate?

Demo – validation

  • data-z-validate in <input> or <select>
  • If using EF, stuff like max length of field is in metadata
  • Metadata, but also custom rules

Validation on the server is mandatory

  • Always do it on the server
  • But also do it on the client

Demo – Model Validation

  • Validation rules free, out of the box
  • Also maintaining a full list of all of the validation errors
  • On New item, don’t yet show validation errors for unfilled fields

Tip 10 – Work in Progress with Local Storage

  • Why risk losing changes?

Options for saving changes

  • When user leaves page, you lose changes
  • You can’t leave (popups)
  • Auto-save as user types
    • Send to database
    • Tons of network traffic
    • Incomplete object?
  • Use local storage

Demo – Work in Progress with Local Storage

  • Note: “Updated WIP” (in Breeze)
  • Start indicates dirty bit
  • Data survives navigate to another page and back again
  • Even survives browser restart

How it Works

  • Export/Import

 

Sean Questions

  • How would Angular fit in with MVC? Can they be used together? Does that make sense?

TechEd NA 2014 – Announcing Hybrid Connections

TechEd North America 2014, Houston
Announcing Hybrid Connections: Building Amazing Hybrid Web Sites and Mobile Apps in Minutes – Santosh Chandwani

Day 4, 15 May 2014, 1:00PM-2:15PM (DEV-B307)

Disclaimer: This post contains my own thoughts and notes based on attending TechEd North America 2014 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of either Microsoft, the presenters or the speakers.

Executive Summary—Sean’s takeaways

  • Hybrid connection is a simple way to access on-premise resource from Azure
    • When you don’t want to do something more complex, like VPN / ExpressRoute
  • Connection Manager allows connecting to an on-premise TCP or HTTP service
  • Can connect to Azure web site or Mobile Service

Full video

Santosh Chandwani, Senior Program Manager, Azure, Microsoft
@santoshc1
santoshc@microsoft.com

Evolving Enterprise Infrastructure

  • Traditionally, have put everything on a corporate network
  • Azure also has its own network
    • Makes sense to move stuff into the cloud
  • But common to want to keep some critical data on-premise
  • One way to connect these networks
    • VPN, ExpressRoutes
    • Some limits
  • But sometimes you just a simple connection to an asset running on-premise
    • Simple

Objective

  • Reinforce ability to do hybrid applications on Azure
  • Extend hybrid capabilities to all Azure services (e.g. PaaS)
  • Don’t want custom code or infrastructure on-premise
  • Secure access without changing network configuration
  • Enterprise admins continue to have control and visibility

Introducing Hybrid Connections

  • Feature of Azure BizTalk Services
    • But don’t require using all of BizTalk
  • Fast, easy way to build Hybrid Apps in preview
  • Connect Mobile Services to on-premises resources

BizTalk Services FREE Edition (Preview)

  • Preview this week
  • Use Hybrid Connections at no charge
  • Hybrid Connections and Data Transfer now included w/all BizTalk Services tiers

Key Features

  • Access to on-premises resources
    • SQL Server, or resources that use TCP or HTTP
  • Works with most frameworks
    • Support for .NET, .NET for Mobile Services
    • No mention of Web API
  • No need to alter network perimeter
    • No VPN gateway or firewall changes to allow incoming traffic
    • Applications have access only to the resource that they require
  • Maintains IT control over resources
    • Group Policy controls, so enterprise admins can control

Hybrid Connections

  • Hybrid Connection Manager
    • Can discover resources on premise
  • From Web Sites or Mobile Services

Demonstration – Web sites

  • Shows web site talking to SQL Server, both on corporate network
  • Then publish web site up to Azure
  • Talking to SQL Azure database
  • Now, set up hybrid connection
    • From Azure Portal, add
    • Name
    • Hostname – on local network, also port name
    • Hostname—could it be IP?
    • Create or use BizTalk Service
  • At this point, it’s just existing on Azure—doesn’t actually connect to anything
  • Set it up from web site, so it knows that web site wants to connect to it
  • Then Remote into desktop
  • IP address could be any device
  • Manager must run on Windows
  • Listener Setup (thru portal)
    • Connected through the portal’s same account
    • They could also do manual setup, with MSI & connection string
  • Where in connection manager did we specify IP address to expose?
    Or was it because we installed it directly on the node that we want to connect to?
  • Now change conn string on web site
    • Replace connection string
  • Refresh web site, now talking to SQL Server on-premises

Lift and Shift

  • Lift web site up into Azure
  • Shift connection to point back to on-premise database
  • No code changes

Flow

  • Identify application by host name and port
  • Gave hostname and port to hybrid connection
    • Note: name could only be resolved on corporate network
  • Hybrid Connection Manager
    • Has gone through all security and threat models from Microsoft
  • Arrow directions—how is connection initiated
    • HCM initiates connection to both local resource and up to cloud
  • HCM pushes data
  • Once we spin up hybrid connection, we can use it from multiple services

Demo – Mobile Services

  • Mobile Services – .NET back-end
  • Can now launch and debug Mobile Service locally
  • Creating hybrid connection for Mobile Service from BizTalk Services portal
  • From Mobile Services part of portal, then pick existing Hybrid Connection (and BizTalk service)
  • Then set conn string to point to local database
  • Change code in Mobile Service to use the new connection string
  • Now running local app that goes to Mobile Server to get data
    • Mobile Service in turn is connected to hybrid connection
  • Remote to PC and install hybrid connection manager

Constraints

  • Supports resources using TCP and HTTP for connectivity
    • Only static TCP ports
    • Need to know ahead of time what the port is
    • Also static IP address, presumably ?
    • Maybe dynamic ports in the future
  • Hybrid Connections don’t buffer or inspect traffic
    • TLS can be negotiated end-to-end between application and on-premises resource
    • Dynamic port redirection, e.g. FTP passive mode – doesn’t work (not supported)

Security

  • Uses Shared Access Signature Authorization
    • Secure, Simple, Familiar
  • Separate roles for on-premises connector and application
  • Application authorization is independent
    • Between web site and on-premise resource

Walkthrough

  • Max 5 connections to start with
  • On-premise setup
    • Link to download MSI will be available soon
    • Can use Powershell and MSI to create connection
  • When you get the on-premise installer, the set of connection strings for the connection
  • Mobile Services not yet in new Azure portal

Resiliency & Scale

  • On-Premises Resources can be scaled out as usual
    • Clustering, availability for SQL
  • Applications can be scaled out on Azure
    • Each instance of Website or Mobile Service will connect to Hybrid Connection
    • Don’t have to do anything special
  • Multiple instances of Hybrid Connection Manager supported
    • But going to same IP address
    • Gives us scale

Enterprise IT in control

  • Manage resource access for Hybrid applications
    • Group Policy controls for allowing access
    • Admins can designate resources to which Hybrid Applications have access
  • Event and Audit Logging
    • IT has insight into resources being accessed
    • IT can use existing infrastructure investments for monitoring and control
  • Dashboard on Azure portal
    • Access to connection health, status
    • Will provide insights on usage and metrics (future)

Pricing

Summary

  • Fastest way to build hybrid applications
  • List and Shift web workloads to Azure web sites whilst connecting to on-premises data
  • On-premises data just clicks away from Azure Websites & Mobile Services