Friday, September 23, 2016

Take aways from Agile on the Beach 2016

I attended Agile on the Beach in Falmouth (England). It was really great to hear so many people with different experiences. The videos and slides can be found here. Below are some of the highlights of what I found particularly interesting.

Keynote by Dr. Linda Rising
  • Surprisingly, people are moved to action by stories NOT facts (or evidence). In fact when someone is shown evidence as to why they are wrong they only stand firmer in their belief (as a defense mechanism).
  • A placebo can be just as useful as the "real thing" because what we BELIEVE can make us fail or succeed. The placebo allows us to believe in something.
Book: Thinking Fast. Slow...The Progress Principle (I think this is the book :)

Continuous Delivery
  • Tools: NCrunch, CruiseControl.Net, R#, NANT
  • Policy: Develop to one trunk (no long standing branches). Because of this, GIT may not be the best choice.
  • Goal: Want SMALL commits frequently. For example, about once an hour and ideally 2 files.
  • Break refactoring out in a separate commit.
  • Policy: Can't commit when build is broken
  • Policy: Run all tests before commit (on local machine)
  • Policy: Don't go home until a broken build is fixed. This doesn't mean late hours necessarily. It could just mean backing out the offending commit, and addressing it the next day, then recommit.
  • Goal: a pipeline should be about 4 minutes for quick feedback.
  • Goal: it is ideal for it to be faster to redeploy a change using the pipeline than manually backing out a release.
  • Goal: 75% code coverage. Most will be between 50% and 80%
  • Use Feature Toggles when required, but avoid if can.
  • Warm up an app after deploy
  • Measure commit to live time.
Quality Control
  • Broken Windows Effect - one broken window (bug, issue, technical debt, not tested unit, etc) begets more broken windows.
  • As developers we spend 70% of our time reading code (ours or someone else's) and the rest of the time copy and pasting. Consider poorly written code to be a broken window and copy and pasting that implementation pattern the creation of more broken windows.
  • Anti-patterns: Fat controllers, large models, functionality grouped into services or managers (not sure I understand the last one...).
  • Enforce standards on each commit and fail the build. Could be formatting rules, naming conventions, etc. This will make code diffs be much easier because we only have to read meaningful changes, not changes to code formats.
  • Code that is easy to change (opposite of code smell) has: High Cohesion, Loosely coupled, little duplication, low cyclomatic complexity.
  • Tools: ESLint (for JavaScript checking), Resharper, Visual Studio, NDepend, NCover
Problem Solving
  • Shorten Feedback loop: Idea -> Test -> Measure -> Learn -> (loop back)
  • Gall's Law: Solving complex problems (or systems) from scratch in one go does NOT work, but starting with simple case that works and iterating works (summarized from quote from John Gall).
Testing with Continuous Delivery
  • Testing Pyramid (GUI testing, Acceptance testing, unit testing)
  • Interestingly, only 20%-25% of the audience in the Testing in CD talk at AOTB used TDD. Maybe it isn't so surprising because people that already know it and use it may not attend a talk on it when there are new topics to be heard.
  • Interestingly, only 10%-15% of same group used BDD. 
  • Hypothesis Driven Development - Can be written as statements in the following format: We believe <this capability>, Will result in <this outcome>, We will have confidence to proceed when <we see measurable signal>.
Pen Testing (Penetration Testing) 
  • Expect 20-30 minutes scan time depending on application size
  • Run on UI and API.
  • Use BDD to describe security tests (see BDD Security) to have human readable tests for security.
  • Tools can find 70-80% of vulnerabilities, but the rest needs to be manually done.
Pen Testing Tools
  • Static code review using tools like Veracode.
  • BDD_Security - Define security tests using BDD style scenarios.
  • Mittn - define a hardening target using human-readable language
  • Arachni-Scanner - free with source and runs on Windows, Mac, and Linux
  • Gauntlt - may be useful as well to coordinate security tools.
  • ZAP - free security tools / scanner.
  • SSLyze - checks for mis-configurations affecting SSL Servers.
  • Nessus - a paid PCI vulnerability scanner.
Business Agility
  • Process: Test Hypothesis -> Quick delivery and release -> measurement -> repeat
  • Big Bang never works or at least very scary.
  • Use The Strangler Pattern to avoid big bang.
  • Postel's Law - Architect for testability, develop for evolve-ability.
  • Last Response Moment - wait as long as you can (so you have more information), but no longer.
  • Beware of the silver bullet
  • Continuous Delivery - automate as much as you can. Note, you can still have approvals in your process, but the action once approved is still automatic.
  • Conway's Law - organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
  • Keep systems poised for change.
  • Don't think yes, no to ideas, but instead think what are the risks and benefits. Then the other person get's to decide if it is worth it.
  • Do the simplest possible thing that might work because the complexity may never be needed.
Understanding the problem
Keeping up

Thursday, September 22, 2016

Open a Command Prompt (shell) on a Remote Windows computer

You can quickly open a Powershell prompt to a Windows computer. From here you can execute commands and command line applications. The script below allows you to do this easily and not have to put your password in in script file. It has the added benefit that you can execute it again (in the same Powershell session) and it will not re-prompt you for your credentials and instead use them again. This allows you to change where you connect to easily by just changing the name of the computer in the script

$username = 'domain\username'
$computerName = 'MyComputerHere'
if (!$cred) { $cred = Get-Credential -UserName $username -Message "Enter your Active Directory Credentials in format (domain\username)" }
Enter-PSSession -ComputerName $computerName -Credential $cred


Friday, August 26, 2016

ZAP (OWASP Zed Attack Project) Basics

ZAP Overview

OWASP Zed Attack Proxy Project (ZAP) is a popular Java-based and open source security tools. It is useful for performing penetration tests on your (or ones you have permission to test) web site for security vulnerabilities.

It works similar to Fiddler, but has several tools for helping to find the vulnerabilities, not just give you the ability to hack at requests. It does this by having you change the proxy in your browser to point to ZAP and then point ZAP to your corporate proxy or the web site itself.

It is extensible via a plug-in architecture. There are lots of videos and tutorials on how to use ZAP. For more details there is an excellent ZAP Getting Started Guide that you can use to get everything installed and explains how to start using it.

Another great resource is: Getting Started with ZAP and the OWASP Top 10: Common Questions

Manual Tests

It is important to keep in mind that not all kinds of penetration / security checks can be done automatically and ZAP does not cover them. It is probably worth reviewing the information on the OWASP .NET Project for .NET security specifics.


Installing ZAP

On the home page for ZAP there Download ZAP link, but you can also use this direct download link to the page.

Monday, August 22, 2016

OpenXava

OpenXava is a nice Java based model driven development model such that you only have to create the domain classes you want to model. You then decorate the properties to add additional details such as relationships, if it is required, specify views, etc. The UI and database is generated automatically for you. This could be a very nice tool to do a quick POC or demo. It is open source that uses Eclipse as the IDE. It could be a good replacement for projects that used IronSpeed Designer and don't mind switching from C# to Java.

Wednesday, July 20, 2016

Customizing Code Coverage in VS2015

The code coverage in Visual Studio 2015 by default includes the test code itself. This is often not desired. Below are some links go pages to help with this.

Customizing Code Coverage Analysis
Using Code Coverage to Determine How Much Code is being Tested
Troubleshooting Code Coverage
Troubleshooting missing data in Code Coverage Results

My conclusion is that the default settings that comes Visual Studio 2015 is not sufficient because it includes the test code in the test results. I found the .runsettings file to be a necessary change. When I did this, I was tempted to exclude test assemblies to the list of modules to exclude, but found this actually stopped the tests from being reported on. Instead I found it better to use namespace exclusions using the function tags.

For example,

   <Functions>
              <Exclude>
                <!--Exclude (Tests from the results) any functions in namespaces that have Test in them-->
                <Function>.*Test.*</Function>

I also found it useful to exclude tests (classes or methods) from the code coverage results that use particular attributes on them. For example,

 <Attributes>
              <Exclude>
                <!--Don't forget "Attribute" at the end of the name -->
                
                                <Attribute>^Microsoft\.VisualStudio\.TestTools\.UnitTesting\.TestClassAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.GivenAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.WhenAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.ThenAttribute$</Attribute>


I did however add any assemblies that have their own unit tests and code coverage reports to the list of modules to exclude. That way the code coverage of these assemblies is not counted twice.

The rest of the .runsettings file can be just as the sample file from MS.
Also, Here is a reporting tool that helps show code coverage results in a more user friendly manner.

Monday, June 20, 2016

Links for Powershell

Microsoft Team Foundation Server Client - Nuget package to integrate with TFS (version control, work item tracking, build, etc via REST APIs

Get Started with the REST APIs - shows the url format, usage, etc for TFS REST APIs.

TFS API Part 33 - Get Build Definitions and Build Details - example of how to get Build definition details.

Creating a Build Definition using the TFS 2013 API - actually in C#, but should work for Powershell also.

Pester - PowerShell testing. Support in VS2015 now.

NuGet Links

NuGet Package Restore - tells how to configure NuGet, TFS, etc to support different NuGet restore models.

Migrating MSBuild-Integrated solutions to use Automatic Package Restore

New-NuGetPackage Powershell script - create and publish NuGet packaes using a .nuspec or project file from Explorer or Powershell.

NuGet Package To Automatically Create Your NuGet Packages

TFS 2015 Build: NuGet restore from an internal repository