Mapping a drive to Windows using Powershell

I recently wanted to test an installer, but it required that I have an E drive (like the server does). I could modify the install configuration, but that requires I make that change each time I want to test the installer. Instead, I want an E drive on my pc. I don't have an extra drive and I didn't want to repartition or resize the partition, etc to create a real drive. I figured out that I can create a drive letter using a mapped drive that points to a path on my local c drive. I need to run the installer in Powershell as administrator so creating a mapped drive through Windows UI won't help me since it is not accessible when running Powershell as Administrator.

The solution to the problem is actually quite easy. The secret is to create the mapped drive before I run the installer (in the Powershell session that is running as Adminstrator) using a Powershell command as shown below.

New-PSDrive –Name “E” –PSProvider FileSystem –Root “\\mylaptop\c$\E_Drive” –Persist

In this example I created a directory called E_Drive on my c drive to act as the E drive. The name doesn't matter.

Now at the Powershell prompt I can access the E drive as if it is an actual drive.

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

• Empathy Maps
• A3 - Root cause analysis
• PDSA

Keeping up

• Software Engineering Radio
• InfoQ
• Agile Alliance

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