31 August 2010

Mohamed Bray Sugsa August 2010

This month's sugsa was a cross-talk from the Business Analysis community.

The Talk

Mohamed described an iterative process as just multiple quick failures (wagile, thanks Karen), if we decide to skimp on requirements. His stat was that 70% of defects are injected during the requirements phase. After gathering, the challenge becomes requirements management and communication. This communication is difficult because the audience is broad and diverse.

Requirements communication should have a few characteristics.

  • connect: we need collaboration and traceability
  • actionable: when is it done? get commitment (intention ≠ commitment)
  • units: time & money

Communication is not just representation.

Babok

Interesting (and new) fact to me is the existence of the Business Analysis Body of Knowledge (BABOK). Although the $30 pdf ($60 for print) price has put it onto my library backlog, and not too near the top.

Questions

Traceability

Peter Hundermark probed a bit on whether traceability was really important.

To me, as a developer, traceability had always meant the lengthy and painful process at the end of waterfall where we point to screens an show where each feature can be found.

Mohamad extended this backwards to linking requirements to stakeholders and the origin of the item, so that we can get feedback on the intention when required. "Where it came from and where it went". Which is actually quite appealing.

BA Smells

Marius de Beer was looking for the "smells" or indicators that BA has gone bad.

Requirements that are not quick to apprehend are smelly. They should be easy to interpret upfront. In that context, 90% of requirements are not clear. As an example, when we talk about oranges, you should get a vivid picture of an orange in your head.

Context-free

Asking context free questions is a technique to probe further while attempting to listen with a solution in mind.

Parting thought

The difference between regular analysts and BBND analysts (Mohamad's employer) is that they are 100% responsible for delivery.

Posted on Tuesday, August 31, 2010 by campey

No comments

07 June 2010

Complete Word

A long while back I included the "Complete Word" shortcut:

Ctrl-Space

in my coding practice, avoiding the tricks I had developed to prompt the visual studio intellisense back into giving me suggestions for word completion.

This saves a lot of "micro-time" and improves flow.

Parameter Info

Another time when I found myself coaching intellisense is when looking at the parameter info. This would be achieved, e.g. by re-typing a comma or the opening ( of a method call.

On Friday I realised there had to be a keyboard short-cut, tonight I hunted, and found the treasure:

Ctrl-Shift-Space

Ahhh, the joy!

Posted on Monday, June 07, 2010 by campey

1 comment

12 May 2010

The problem

Stored in a varchar column, payload_xml, we have xml that looks something like this:
<?xml version="1.0" encoding="utf-16"?>  
<ReceiveMoneyParameters 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">    
  ...
  <PaymentArrangementExternalReference>
    JT00009084
  </PaymentArrangementExternalReference>    
  ...
</ReceiveMoneyParameters>
I need to return the underlined section as a varchar.

The solution

With the help of Tim Chapman's article Shred XML data with XQuery, I've arrived at the following code:
select cast(cast(cast(payload_xml as nvarchar(max)) as xml)
.query('data(//ReceiveMoneyParameters/PaymentArrangementExternalReference)')
as varchar(max)) as PaymentArrangementExternalReference,
Which is, admittedly a bit of a mess, but each part has its purpose, and it works!

Observations

Interesting observations from inside out:
  • cast as nvarchar so that the encoding matches "utf-16"
  • otherwise sql server fails with the cryptic 'XML parsing: ... unable to switch the encoding'
  • data() function returns the actual content of the node, not the whole node
  • I didn't need to use [] indexers because there is only one element.
Lesson learned: use the xml datatype for the column.

Update

To handle different namespaces, e.g.

  <?xml version="1.0" encoding="utf-16"?>
  <PremiumDistributionRequest 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <Payment>
      <PaymentId 
       xmlns="http://il.net.za/Agreement/Payment">
        14079
      </PaymentId>
 

add a namespace declaration to the query as follows:

select @x.query(
  'declare namespace ap="http://il.net.za/Agreement/Payment";
  data(//PremiumDistributionRequest/Payment/ap:PaymentId)')

Posted on Wednesday, May 12, 2010 by campey

3 comments

18 February 2010

Last night I ran through a basic tutorial on Fitnesse and .net. It went a little something like this.

Download and run Fitnesse

Download, double-click. And then...

Huh? I double clicked the jar file, got a question about enabling network comms, and nothing else happened.

What had actually happened was some files were extracted and the server started running and listening for connections.

Best plan for getting started is to run it as above from the command line using "[path to java bin]java.exe -jar fitnesse.jar

Create a test page

The tutorial pointed to FitNesse.DotNet.DotNetFitServer, which is an empty wiki page. Throwing caution to the wind, I bravely soldiered on.

All looked fine until I clicked the test button and was presented with a nice red X in the upper right corner, clicking on which yielded the detail: java.io.IOException: Cannot run program "fit.FitServer": CreateProcess error=2, The system cannot find the file specified, which I was pretty much expecting, so off I went to find a suitable program.

I downloaded both FitSharp and FitnesseDotNet because I couldn't tell which would be right for me. Updating the TEST_RUNNER to the full path to the FitServer.exe from the FitnesseDotNet distribution did the trick (FitSharp is for slim testing and has a different COMMAND_PATTERN and TEST_RUNNER).

Create & Hook fitnesse to the .net Class

Initially fitnesse couldn't find the type in any of the loaded assemblies. Removing the namespaces (as per a useful comment), got it to hook up, and I did a little "dance, or a jig".

Get to Green

Well, not quite green because one of the quotients in the table is incorrect. But the tests shows up this as an incorrect result.

Yay.

Next step is figuring out what fixture to use to get complex types into fitnesse.

Posted on Thursday, February 18, 2010 by campey

No comments

21 January 2010

Just learned something new about the DOS copy command from this comment on a keyboard ninja article.

copy /a *.txt aggregate.txt

Will aggregate the contents of all the .txt files into aggregate.txt. This is useful to me for .csv files.

(to disambiguate: 1.txt contains "one one one" &c.)

So cool; not often I find out something new about DOS.

Posted on Thursday, January 21, 2010 by campey

No comments

20 August 2009

Or, how I learned to read the assembly name

In which I include dll's

I was trying out this tutorial on Geekpedia and the references were invalid. I removed the two (Microsoft.SqlServer.Smo and Microsoft.SqlServer.ConnectionInfo: yes, the dll names are missing the .Management part from the namespace they contain) and re-added them. Simple enough. Then there was an issue with the unreferenced Microsoft.SqlServer.Management.Sdk.Sfc, after running the installers (all just said repairing), I found the dll, but I'm not sure if it was there before. The dll in this case has the same name as the namespace, unlike the previous two dll's which are missing the .Management portion, so I was looking in the wrong part of the list.

In which I question my sanity

All was relatively sane up to this point, then I started to think I was crazy. The Backup class was missing from the namespace. I checked the documentation for Microsoft.SqlServer.Management and sure enough, Backup was there. After turning to google for a while and reading all about people finding and GACing the dll, I headed to %systemroot%/assembly to see what I had. It was at this point that I saw there was a dll Microsoft.SqlServer.SmoExtended. Inquisitively, I added a reference to this dll. And, lo! the classes were found. Looking at the documentation for the Backup class, I now notice:
The Backup object provides programmatic access to Microsoft SQL Server backup operations.
Namespace: Microsoft.SqlServer.Management.Smo
Assembly: Microsoft.SqlServer.SmoExtended (in microsoft.sqlserver.smoextended.dll)

A curious discovery

So, multiple dlls can add classes to the namespace. Who knew? Not me. And, w.r.t. Microsoft.SqlServer.Management.Smo, their structure must have changed somewhere between the dlls that Andrew Pociu (Geekpedia) was using (I'm assuming 9.x) and the 10.0 dlls.

Post-script: local help is outdated

While writing this post, I thought to check my local help where the documentation is out of date, so perhaps I have a valid excuse.

The Backup object provides programmatic access to Microsoft SQL Server backup operations.
Namespace: Microsoft.SqlServer.Management.Smo
Assembly: Microsoft.SqlServer.Smo (in microsoft.sqlserver.smo.dll)
fin

Posted on Thursday, August 20, 2009 by campey

6 comments

26 May 2009

After my last post on building WSP in TFS, I was at a stage where I thought the WSP file was ready to go. It's recognised by WinRAR, opening it up in there shows the expected dll's.

But there was something missing...

feature.xml

Attempting to deploy the WSP threw:
Failed to find the XML file at location '12\Template\Features\IL.SharePoint.Workflows\feature.xml'

This TechNet page on InstallFeature clears up the exact cause being a missing feature.xml. It also cleared up that the 'root' of the WSP is equivalent to 12\Template\Features\ a location in the "12 hive".

Opening up the WSP, sure enough there was no sign of feature.xml, so it was time to head back into WSPbuilder.exe -help where I found...

-12path

The default for the 12path is the current directory, here again, since we're not running from the project directory, the current directory isn't much good, so I needed to set the 12 path.

Setting the 12path to the location of the feature.xml got it included in the WSP, but the manifest.xml included it in the RootFiles element. Based on our manually built WSP, we saw we needed it to be in the FeatureManifests element.

After some searching I looked again at the before build image on the WSPBuilder CodePlex site. Turns out this is rather useful once you know what you're looking at. There you'll see the path WSPDemo/12/Template/FEATURES/WSPDemo/; after seeing that, it dawned on me that I had actually read something about "putting the contents of your 12 hive into the project folder" - so that's what they meant.

So finally the files were included in the WSP in the right location:

-DeploymentTarget GAC

Because of the way our solution is set up we need to target the GAC, we were getting:
<Assembly Location="IL.SharePoint.Workflows.dll" DeploymentTarget="WebApplication" />
in the manifest.xml. Changing the DeploymentTarget from the default of Auto to GACyielded the required:
<Assembly Location="IL.SharePoint.Workflows.dll" DeploymentTarget="GlobalAssemblyCache" />

-BuildCAS False

The default for this is True, with it on, the manifest file was spammed full of CAS information and trying to deploy gave the error:

The solution "IL.SharePoint.Workflows.wsp" needs to add Code Access Security policies. If you fully trust this solution, use the -allowCasPolicies parameter to deploy.
True, using -allowCasPolicies did remove the error, but adding -BuildCAS False cleaned up the manifest file and removed the need for this switch to stsadm.

Revised WSPBuilder command line

All this meant the following amended Exec command in the tfsbuild.proj.

    <Exec Command='"C:\Program Files\WSPTools\WSPBuilderExtensions\WSPBuilder"

          -DeploymentTarget GAC

          -BuildCAS false

          -SolutionPath "$(OutDir)"

          -BinPath "$(OutDir)"

          -OutputPath "$(WspDir)"

          -12Path "$(OutDir)12"

          -WSPName IL.SharePoint.Workflows.wsp'

          />

Posted on Tuesday, May 26, 2009 by campey

No comments