Deadly sins of software development

InfoWorld published a really good article on the 7 sins of software development.  While this is a good list, I would add the following sins as well:

8) Not picking the right technology

This one mainly due to comfort zone and failing to keep up with better tooling or proven techniques out on the industry.  It’s the old saying of trying to force a square peg into a round hole or if all you have is a hammer than everything else looks like a nail.

9) Not thinking about performance

If performance is critical for a project, test it early and test it often.  Don’t wait until near shipping to start making performance changes because it would be too late and too little then.

10) Not considering about security

Isn’t this item obvious?

11) Not talking to users

Unless you are writing the software for yourself, which I do every once in a while , get up and go talk to the users.  They would love you and appreciate your software even more.

If they tell you your software is terrible, thank them, think about what they said and improve on it.  If you get too attached to your software, you will never be able to make it better.

Microsoft.Practices.Unity Library

Recently, a development effort at ImageSource involved use of the Microsoft.Practices.Unity library, a part of the Microsoft Patterns & Practices.  The Unity piece provides tools for more modular, component based application design.  It provides simplified object creation and ability to specify object dependencies and parameters at runtime.  While I am still researching all that Unity can do, it looks like a very interesting and exciting new way to create component based applications.

For more information, see the MSDN Article about the Microsoft.Practices.Unity library.

Why Is My Combobox So Slow When Databinding?

While working on a project for ImageSource, I recently found an interesting quirk when using the .NET Windows form combobox control.  The issue occurred when I was populating the combobox’s item list with a datasource.  The data was populating at a very slow rate, slower than it was taking to retrieve the data I was using to populate it from the database.  The code I was using looked something like this:

Dim tbl As DataTable = _dataSource.ReadAllItemsFromDbTable()

cboComboBox.DataSource = tbl
cboComboBox.DisplayMember = "Name"
cboComboBox.ValueMember = "Value"

What I later found out was that the ordering of the above code made all the difference, and that by setting the DisplayMember property after setting the DataSource property, I was causing the combobox to reload all of the item data a second time.  To stop it from doubling all of the work, I just had to make a simple code change.  This involved moving the setting of the DisplayMember and ValueMember properties above the setting of the DataSource property.

Dim tbl As DataTable = _dataSource.ReadAllItemsFromDbTable()

cboComboBox.DisplayMember = "Name"
cboComboBox.ValueMember = "Value"
cboComboBox.DataSource = tbl

This fixed the issue, as the DisplayMember property is now already set before all of the items are loaded.  I hope this helps fix any issue you may have had with this control.

  

failed due to the following error: 80040154.

As a developer, I install and uninstall all sort of programs on my system so I am not surprised when some weird and random error message popped up. 

I ran into the following error dialog today when I was writing some .NET integration code with EMC AppXtender.

This exception was thrown when I was trying to create the AppXtender DBConnection object.  So I fired up the AppXtender Document Manager to verify my installation and it ran successfully.

Going back to my Visual Studio project, I verified the Interop.AEXDBLib reference and that seems right.  A quick search on MSDN on error code 80040154 showed a list of COM errors on 32-bit OS, and I am seeing this error on my 64-bit OS.

The fix is to change the Platform target of my .NET solution to x86. 

Hope this helps.

  

VB Coding in a .NET World

C# is the standard coding language for developers at ImageSource, but it wasn’t always that way.  Before, VB.NET was the predominant language of choice.  When converting some of the codebases over from VB.NET, we consistently run into areas where VB.NET specific commands have been used.  These commands either do not exist in C# or require use of the Microsoft.VisualBasic library.  Either make code conversion very frustrating when they are used.

Below are some examples of commands that should be avoided in .NET code:

• Cint, Cstr, CDate, CDbl – Use the equivalent call in the System.Convert class.
  • CInt – Convert.ToInt32
  • CStr – Convert.ToString
  • CDate – Convert.ToDateTime
  • CDbl – Convert.ToDouble
• IsDate, IsNumeric – This one is a bit trickier and requires more work, but can be a lot more useful.  C# does not have an equivalent type checker, but you can use the TryParse methods located in the primitive objects.  For example, the following VB.NET code can be used to check if a string is an integer value.

  • Dim i As Integer = 0
    Dim test As String = "213"
    If Integer.TryParse(test, i) Then
      'Hey, this check worked!
      'And the integer has already been converted so you
      'can start using it.
    End If

• VBCRLF – The new line command in VB, necessary because VB.NET does not allow you to write special characters in strings, so special characters need to be concatenated onto the strings.  Instead of VBCRLF, use the Environment.NewLine command, as this exists in both VB.NET and C#.
  • Optimally, code converted to C# should convert any instances of VBCRLF to \n in the string.  However, using Environment.NewLine will at least get it to compile without need for the Microsoft.VisualBasic library.
• With - Avoid the With statement, as it does not exist in C# and you’ll just end up having to put the object reference in anyway.  It is not that much harder to just write the objectName.Method or objectName.Property, and it makes the code easier to understand.

So hopefully this brief overview will help you to write better VB.NET code.  Remember, the .NET framework exists in both VB and C# form, and making the two easily compatible helps code maintainability and portability.

Microsoft Office Metadata Made Easy

Have you ever been writing an application and needed to retrieve or edit the properties of a Microsoft Office document?  Did the thought of having to write code to perform Word or Excel automation send chills down your spine?  Were you worried that your documents’ precious metadata would forever be trapped behind the taunting shield of the Windows Explorer property window?

So close yet so far.

Fear not, all hope is not lost.  For there is another way to retrieve and edit the details of your Office files without even needing a version of Microsoft Office installed on the PC.  Microsoft has been kind of enough to provide the dsofile.dll, a handy ActiveX component that allows easy manipulation of the file details.  There is even demo code provided for VB6 and VB.Net.

But you may be asking yourself, “How can I get such a mysterious and powerful tool to work?”  Fortunately, dsofile is simple to use, just add it to your project and your ready to go.  Check out the sample code below for an example of how to use dsofile to retrieve information out of our document.

private void ReadOfficeDocumentMetadata(string fileName)
{
   DSOFile.OleDocumentPropertiesClass document = new DSOFile.OleDocumentPropertiesClass();
   document.Open(fileName, false, DSOFile.dsoFileOpenOptions.dsoOptionOpenReadOnlyIfNoWriteAccess);

   //Display document metadata
   txtTitle.Text = document.Properties.Title;
   txtAuthor.Text = document.SummaryProperties.Author;
   txtSubject.Text = document.SummaryProperties.Subject;
   txtCategories.Text = document.SummaryProperties.Category;
   txtComments.Text = document.SummaryProperties.Comments;

   document.Close(false);
}

Wow, it’s just that easy!  Let’s see it in action:

Take a moment and savor the sweet smell of success.

But don’t just take my word for it, try out dsofile.dll yourself.  The download comes with couple of sample applications that are worth checking out and provide a more in depth look at what this tool can do.  ECM Developers at ImageSource have already found uses for this wonderful tool, and so can you.

  

ECM Best Practices: Unit Testing and NUnit

Everyone agrees that testing is a good thing. Not everyone agrees on how much testing is cost-effective and what exactly the kind of testing is right for a specific piece of software or product. But automated unit tests cam help you ensure your software is healthy.

Unit tests operate on the smallest possible section of code, on logical modules. In software design, a program of any decent size will be broken down into modules. These modules have inputs, outputs and behaviors. These inputs and outputs and behaviors are used by other parts of the program to perform work and can be monitored or tested by the test software.

Often, a software module is deeply bound up inside the containing framework and it is not obvious how to test a subset of the code in isolation. (Testing multiple modules together is referred to as “integration testing” and will be discussed in a later post). Fortunately, there are software constructs available to mimic or “mock up” objects which the module under test needs.

A case in point is a product we are revising called ILINX Release Script 9.0. The ILINX Release Script is a module which is run mainly inside the process space of Kofax’s Ascent Capture product. There are a number of complex environmental elements which supply runtime context for the various ILINX components.

Because we are developing in C#, and are using the NUnit testing tool, we are able to make use of the NUnit’s Mock objects to help in mocking up objects to test against.

By stubbing out the functionality of the execution context, we are able to exercise specific portions (or units) of code with very specific and controlled data and confirm the software’s behavior and output. If you are using .NET, I encourage you to look into NUnit (http://www.nunit.org/index.php) it’s ability to generate Mock objects.

  

ECM Best Practices: Integration with ERP

Integration with ERP is something most SE’s (Systems Engineers) and PMs (Project Managers) should keep in mind when designing a project.  ERP, or Enterprise Resource Planning, is the process of using modularized software and hardware within a centralized network and datastore.  In regards to ECM, proper integration with ERP is important for maintaining data integrity with the larger organization.  ImageSource has successfully incorporated ERP Integration with many of it’s customer partners.

As an example, ERP Integration can be done within an Oracle IPM Process Workflow, using a combination of scripts and forms to access the centralized data store for use within an IPM Package.  The centralized data is usually populated and maintained by sources within the organization, but external to Oracle IPM Process Workflow.

The following examples demonstrate how ERP Integration can be used to maintain data integrity.  In this example, we have a workflow package that requires 3 pieces of Vendor Information: the Name, Address and ID Number.  Information about all of our example organization’s Vendors is located in a pre-existing database.  We can harness this data within the workflow, using some techniques demonstrated below:

Oracle IPM Workflow Screenshot

The above screenshot illustrates one way that ERP Integration can be handled within a process workflow. The package would enter the workflow containing a rudimentary amount of metadata gathered during  the Document Capture phase.  It would then be processed by the Vendor Lookup Script, which would use data in the package (like the Vendor Name) to query the centralized data store for the appropriate vendor information (like Address and ID Number).  If matching data is successfully found, it would then populate the package with it.  From there, the package would move on to the Review Queue where all of that data would be made viewable to the user.

ERP Integration can also be handled within an IPM Process Workflow form.  Observe the ERP data lookup demonstrated below:

IPM Process Form with data populated from the Vendor Lookup Script.

If the user needs to change the Vendor Information, they can do so by clicking on the Vendor Name dropdown.  The dropdown list is populated with vendor names pulled from the centralized data store.

List of Vendor Names from the centralized data store.

Upon selecting a new Vendor Name, the workflow form performs a query against the data store for the matching vendor information, as pictured below.

Vendor Information after a lookup in the centralized data store.

As you can see, the only data that was needed was the Vendor Name.  The Vendor ID and Address were updated to reflect the change on the form.  This kind of ERP Integration keeps data intact and makes metadata capture easier for the user, as they do not need search through piles of paper or external applications to find the appropriate information.

Richard Franzen
ImageSource, Inc.

ECM Best Practices: Document Capture & Metadata

Document Capture is the on-ramp to ECM.  Without documents and the ability to import them into a system, ECM is meaningless.   Document Capture can be done in a variety of ways; scanning, faxing, emailing, API integration, etc.  However you stuff your documents into your ECM system, their is one major obstacle to making those documents useful, metadata.  All ECM system’s use metadata, even file systems .  A good metadata model is perhaps the most important component to ensure the success of an ECM implementation.

Some metadata is obvious, like author/creator, date created, and the primary identifier (think primary key for those of you RDBMS folks).  All of the systems that I have worked with have these metadata fields, whether they expose them to the user or not.  This leaves the ECM architect to determine what other metadata fields to associate with the documents the ECM system manages.  I have come up with four guidelines, when it comes to creating metadata fields.

1. What fields would be useful to help users find content.  This guideline seems obvious.  But how you go about answering this question may not be.  The first place to start, is your end users.  Ask them how they currently find documents.  When they look at documents, what information in the document is most important to them.  It is also helpful to look at the documents themselves to find helpful metadata fields.  If you have an AP document, chances are it has a date specifying when a bill was paid.  This may also be good candidate for a metadata field.
2. What information needs to be stored with the document, but is not a part of the document itself.   Often times a user may want to make a comment about a document.  Or a document has a revision number that needs to be captured.  This information is important, but will most likely not be in the document itself.
3. What are your metadata dependencies. While you are architecting your metadata model, look for metadata dependencies.  For instance, say you have the metadata fields Business Unit and Document Type.  The Accounting Business Unit will have documents of Document Type Invoice.  You don’t want users in the Business Unit Professional Services having access to search Invoices.  If your ECM system supports this functionality, you will want to group specific Documents Types with Business Units.
4. Keep the number of required, user entered metadata fields to 5 or less.  If your users are required to enter values for more than 5 metadata fields, you run the risk of data corruption.  Entring metadata into a checkin form is not fun, and users can get bored of it fast.   Use automated methods to catch as many fields as you can.

If you are considering creating a metadata schema for an ECM system, this list should give you a good head-start.  You should also consider how the particular ECM system you are using handles metadata.

If you are intered in learning more about Document Capture best practices, I suggest you check out ImageSource’s upcoming Nexus Conference.

Tyson Magney
Senior Developer
ImageSource, Inc.

EHLLAPI – The Olde Way to Integrate

I came across this title on one of Inventu’s pages when researching an integration issue for a customer…I must admit, it made me smile, and if I LOL’d, I would’ve…