Splashers Geekify

I sent my resignation today again. Again because I sent it March 2006 but extnded my contract for another year. So come 28th Feb 2007 I won't be with Splashers Technologies and this time, its for real.
Well, what else do you do when you have dreams the size of Texas. Its common knowledge you cannot be richer than your employers, and according to my plans, I have just a few more years to becoming the richest man south of the sahara.

We had a talk about adopting an object persistence framework for development. As a part of standardization and

reducing project delivery time, we decided to review the OPFs we have and adopt one(?) for development.
We considered the following OPF and not so OPF frameworks:

1. Artemis Object Persistence Framework


2. Microsoft Data Access Application Block


3. NHibernate


4. Ado.Net (Traditional)


5. Ado.Net 2.0 Database Factories

We decided to not rate 4 and 5 (ADO.Net and Ado.Net 2.0 Db Factories) since they are fundamental and the others

rely on them.

We did acknowledge the easy of use for small applications and the fact that 5 (Db Factories) can support other

data providers beside SqlServer.

The serial numbers are used as keys.

To rate, we came uo with a number of criteria that have immediate consequences on our everyday coding:

1. Open sourced


2. Best Practises: Not MS Best practices per se. We attached best practice to stuff like not having to hack ugly
   
   codes tp provide some functionalities, e.g. connecting to other databases, creating an object just to return a
   
   bool etc.


3. Out of the box support for other databases beside SqlServer


4. Support for persisting datasets/typed datasets


5. Development speed/Ease of use.


6. Performance


7. Active support/development.

We rate on a yes/no basis only. Yes = 1 and no = 0

NHibernate and Microsoft data application block DAAB tied on point and after some more debate we agreed:

• Since almost all splashers job use a SqlServer backend, all new projects consider it as a first option except:


• The project uses a data source different from SqlServer and is significantly large, we consider NHibernate first. If small, we consider the traditional Ado.Net or ADO.Net Db factories.


• We continue to support Artemis OPF because of legacy projects.

Today we started refactoring our core business library for .Net aka SpCore. Remember SpCore is our equivalent of MsCorLib? We are targeting a .Net coding thats a few crazy lines of codes; better/worse than Python :).
Well we did achieve some: Yanked out the Enumeration classes that no one has been using, created an Imaging namespace and dropped the imaging and scanning classes under sub namespaces of this. We did create a Text namespace too. Sweet that unit test library we just added.
Tunde created a 2.0 version of SpCore. Only the solution file carries a different name i.e. Spcore2.0. The assemblies share names with the 1.1 version. versioning will be controlled with version numbers in the assemblyinfo.cs file and the .Net 2.0 branch will carry 2.x.x versiuoning while we continue developing the 1.1 branch simultaneosly.

Todos

1. Sese includes a validation library into SpCore solution.


2. Stan includes an encryption library


3. Unit tests for lib functions, assigned to Keni, Gbenga, akin


4. SpCore2.0 for .Net 2.0; solution created by Tunde.

Team reconvenes next week Wednesday to submit status. Codes should have been committed to source control before then.

This is an acronym for Splashers technologies library of reusable code classes. The current version targets the .Net framework 1.1 and has codes which are mostly generic for windows and web applications.
The application currently builds into a single dll, SpCore.dll.

Current code base has classes that handle Diagnostics, Exceptions, IO, Security, scanning and some utilities including some email abstractions and printing.
A number of namespaces exist under the main solution including Diagnostics. Here we have classes and static methods to push information to the Windows EventLog, we have ApplicationAssert, Auditing and application logs. Another is Exception with some exception classes that are particular to SpCore and an unhandled exception manager class.

Others include IO which has static methods to generate a byte array from a file, copy streams from a source to a destination, get file encoding and check validity of filenames among others, a security namespace which encapsulates IIdentity and IPrincipal, password hashing etc. Other namespaces handle printing of images, validations of web urls, emails, and names and so on. Also included are classes that handle serialization and imaging.

Since we will be refactoring SpCore for better adoption by the development team, we agreed to:

1. Pull out Util.Enumeration class. Most applications have enumerations particular to them and the more generic enumerations are already contained in the base class library e.g. DateTime.DayOfWeek

2. Extend the encryption and related library. This list of reusables is often used in applications and usually takes time repeat implementing

3. Redefine the architecture.
There will be a 1.1 version targeting .Net framework 1.1 and another targeting 2.0 and subsequent releases of the .Net framework.
• Library for .Net framework 1.1
• Library for .Net framework 2.0
Maintenance and reuse: Separate class library projects will be created for different areas e.g. SpCore.Securities, the names will not change between frameworks as framework information will be reflected in assembly versions.

We will introduce dependency libraries like SpCore.Shared to handle inter library dependencies and eliminate cyclic redundancies. Typical assemblies will have names like SpCore.Utilities.

As mentioned above, windows hold version information, SpCore does not carry target platform in its library i.e. SpCore1.1.Utilities or SpCore2.0.Utilities. Instead we will simply have SpCore.Utilities and use versioning and assembly signing to handle the target framework.
Environmental variables like web, windows do not reflect in assemblies ordinarily.
When we do need to get specific however, we append .Win or .Web or .Mobile e.g. Spcore.Win.Scanning or Spcore.Web.Scanning. When it’s generic, it simply carries SpCore.Scanning;

4. Planning for scalability: Ownership of contributions is primarily with the author.
When developers make interesting hacks or breakthroughs, the teams do a code review and decide if the code is redefining functionalities in the base class library or fit for SpCore. SpCore gets reviewed intermittently for additions and subtractions.

5. Documentation. We stick with Xml documentation and use tags like remarks to add additional/upgrading information.

6. Testing: - Owners submit unit test/test plans with code submission to SpCore. Core review may evolve additional plans and ethics. Generally codes will be added that conforms to naming standards and best practices.


Immediate steps:
• Refactoring SpCore to adopt new architecture: at code review 14th October 2006

• Fill out existing codes that contain stubs and pull out duplication of BCL

Overview
BELLAGIO EMR (Electronic Medical Record) is a custom solution targeting healthcare providers. Its purpose is to automate common record keeping and retrieval, document management and scheduling. Medical records are patient centric and it uses windows form as a front end.
The core modules of BELLAGIO EMR include patient registration and encounter management module, task/scheduling module and a document module. Others are Form Builder/BELLAGIO EMR survey, EMR Reporting and a couple of other modules are in development.

Architecture
BELLAGIO EMR is built primarily with c#.Net. SqlServer database serves as its backend. Other technologies in use include Sql server Reporting services, Office Automation, Office 2003 Reporting, Xml. Tools and platforms include VS 2003 and Infragistics toolset for the presentation layer.
Authentication and authorization is done with Active directory.

The application has two physical layer: A heavy client and a database server. Logically the partitions include a Windows form UI project, a BusinessFacade project that implements the façade pattern. The BusinessRules class library defines CRUD functions and some entity specific operations, mostly making database calls via an object persistence framework OPF. The ObjectPersistenceFramework (OPF) is an in-house library that abstracts ADO.Net classes and provides method calls like Create(), Update etc. There is a BusinessEntities project that is just a handful of transport objects with public properties for setting and getting member variables. It does some little manipulations on strings, dates and numbers which are sometimes not persisted to the database..
Other class libraries included in the solution is a Utility project containing enumerations, some date and string manipulation functions and some logging functions. The SpCore class library abstract reusable codes and is not directly tied to EMR.

---

---

The only visible pattern we identified in EMR is the Façade pattern.
We did identify the solution would could have benefited from an MVC pattern. An Observer pattern using events and delegates would have been ideal for updating the multiple views in EMR, an approach that would make the application more scalable and reduced maintenance headaches. This could also provide a framework for automation and plug-ins
.
We identified inconsistencies in coding approaches. There are places where the entities are pure abstract class and some concrete. A call to create an entity in the UI returns a business rule object cast as an entity in places and others are simply a concrete instance of the entity class. Also, the BusinessFacade manipulates the OPF’s database objects (bypassing the BusinessRules) where in other places the Façade leaves OPF’s database manipulation to the BusinessRules library.
We recorded some issues with reuse at the BusinessEntities and Rules. We had some issues with serializing business entities over web services.

At the UI level, threading, refreshing and bulky interface are the main issues. A lot of threads access the UI thread and tries to manipulate it. This has resulted in erratic behaviors reported by clients.
The bulky interface is due in parts to the early versions of Infragistics Toolkit and largely design. Forms are bulky, a good example is FrmMainEMR. Opening it in the designer often takes up to a minute. We agreed building the form as a collection of different UI controls would have resulted in lighter, more disconnected and scalable architecture.
Refreshing the UI is often a problem. The problem is now reduced after limiting the result sets and making upgrades to the OPF.

Documentation exists but is not adequate. A lot of public methods exist without proper Xml documentation. Also, some complex logics are not always commented.

For code reuse, EMR started out the SpCore project. This is a library on non-EMR specific functionalities.
We identified unintended misuse regarding OPF; for instance there are places where returning demoralized data via the OPF would have resulted in a lot of performance gain by reducing database calls i.e. loading related records by doing database joins. Junction tables were returned as business entities object where they are not really entities in the system e.g. PatientContact which is a junction between Patients and Contacts.

EMR followed and actually caused some QA standards to be adopted. Scripts are packaged along with the solution.
The immediate issue with QA is the way QA documents are generated with text files or Word documents.

Probably due to the large numbers of developers that have worked on BELLAGIO EMR or management deficits, adherence to Splashers/Artemis coding standard is low. This is partly due to the fact that most of the standard came after BELLAGIO EMR.
Pascal casing for classes and methods is adopted but not 100%. Variable naming is very inconsistent though.
Methods are often very long and lengthy codes are entered into case statements. Logics are repeated in certain places. Some of these issues have since been corrected.
Best practices in string manipulation and formatting are not stringently followed. Object lifetime are not very well managed, a lot of public class variables and static calls exist. Often forms have lots of constructors and codes are not well utilized.

General exception handling blocks litter EMR. These blocks have since been replaced by specific ones and have revealed some developer errors. Before now some of these have been muted by exception handlers.
The middle tier Façade and BusinessRules had try finally blocks everywhere. A side effect of this is lengthy code. Development team have since revised the code using RAII’s techniques for .Net..

The UI is inconsistent. Forms have different appearances and messages boxes carry different captions and behavior. Xp icons are not used everywhere. Forms are often modal and user feedback suggests less usability.

Miscellaneous issues reported include office automation and com interoperability issues, usability of Sql Reporting services as at VS 2003

Team Monks (to be re-christened soon) will be handling the next Splashers geekify session. The topic is stated above. The links below present the necesary pre-requisites for next week:

Model View Controller (MVC) Using C#, Delegates and Events in .NET
MVC in Asp.Net 2.0
Model view controller
Microsoft Word Like Object Model

You will see why we should never write code the conventional way after this. Gym up guys, it promises to be a tough session.

Intro:
Relius Conduit is a small application that synchronises data in an exchange contacts folder (“Relius/People”) and an Sql Server database.

After a short review, we came up with a couple of "concerns"

1. 
   Product version: This was hard coded on the command line. The AssemblyInfo.cs file holds version info. A direct reference could not be made to the version info but an indirect way of doing this will be creating a reference to System.Windows.Forms. After this, developers will be able to make calls to Application.ProductVersion.
   


2. 
   Connection polling, Extensive use of DataReader. A DataReader requires an open connection; instances exist where an SqlDataReader was opened while another was still open. A solution would be using DataTables in this situation and in the particular case of Relius Exchange; a disconnected Dataset will be very appropriate.
   


3. 
   Hard coded values in code e.g. "Relius/People", Configuration files exist for situations like this..
   


4. 
   Very large numbers imput parameter to a function,
   
   e.g. ret = x.CreateContactInPublicSubfolder("Relius/People", person["ID"].ToString(), person["FRIENDLYNAME"].ToString(), person["TITLE"].ToString(), person["ORGANIZATION"].ToString(), person["TELEPHONENUMBER"].ToString(), person["HOMEPHONE"].ToString(), person["FAXNUMBER"].ToString(), person["STREET"].ToString(), person["CITY"].ToString(), person["STATE"].ToString(), person["POSTALCODE"].ToString(), person["COUNTRY"].ToString(), person["HOMESTREET"].ToString(), person["HOMECITY"].ToString(), person["HOMESTATE"].ToString(), person["HOMEPOSTALCODE"].ToString(), person["HOMECOUNTRY"].ToString(), person["EMAIL1"].ToString(), person["EMAIL2"].ToString(), person["DEPARTMENT"].ToString(), person["PROFESSION"].ToString(), DateTime.MinValue, person["TEXTDESCRIPTION"].ToString(), true);
   
   Passing structs and classes will suffice
   
   

Upnext is PG (Pivotal G, not parental guardian :) ) team on some sazzy web stuff...Effectively using divs/css and eliminating table Kung-fus in web page designs.