Back on track

I created a PatchDataHelper class to aid in mapping Patch instances from DataRows. I also brought in a DataMapping class that provides anonymous row/reader to object mapping using reflection. Assuming properties and column names are the same this should work nicely and save me a bunch of typing.

My initial approach seems cumbersome and unwieldy. After putzing around for a while, I decided to try wrapping the TableAdapterManager through the Database class, access all of the 'helper' code from that level, and focus on using a single typed dataset.

Hopefully I can build on this momentum and not let it slip by the wayside again...

Back from hiatus

The NyMPH project was unintentionally put on hold. My wife decided to have back surgery, which has taken most of my free time (until Christmas, which took up the rest of it).

I'm looking forward to getting back into the NyMPH project. Hopefully I can remember what I was doing. :)

Working on data access

I started working on data access code for the Keyword class. I initially added LINQ mappings to the Keyword class, created a typed datacontext, and wrote a couple query methods using LINQ. It's pretty neat.

Once I got to the 'Update' method, I realized that LINQ-to-SQL doesn't have a specific 'update' method; as I understand it changes to the object's properties are automatically persisted when the datacontext 'updates' everything. There didn't seem to be a way to selectively update individual objects.

I was eager to use LINQ to SQL, but as I read up on it to see how I could best use it for the NyMPH project it became apparent that LINQ to SQL wasn't going to be developed further by Microsoft.

As cool as LINQ seems to be, I decided to stick with typed datasets and SQL queries. This will make object/relational mapping a bit more work, but that's alright.

I also learned the built-in O/RM editor in Visual Studio 2008 doesn't work with SQL CE 3.5. That's a shame.

I've started adding persistence methods to the KeywordFactory class (poorly named; I'll probably change it later). Once I get into the rhythm of working with typed datasets for O/RM I'll probably streamline it and use it as a basis for the other domain classes.

Added Database

I found the prototype SQL CE 3.5 database I created for NyMPH and added it to the solution. I'm hoping to use LINQ for the majority of the queries.

I've implemented IEquatable and IComparable on a couple different domain classes; I will do the same for the rest of them.

I also realized that determining equality between generic List objects takes a bit of code. Right now, I'm comparing item count first (to avoid the cost of full comparison), then iterating through each item until it finds a mismatch.

I could create custom collection classes, but at this point I don't see a need to do so. We'll see how well the 'brute force' item comparison works in terms of performance.

I've also created a spreadsheet to store these changes. It is in /Solution/NyMPH_Classes/NyMPHDevLog.xls.

Cranking out code

I've gone through all of the NyMPH.Patches classes and filled in the code as best as I can for now. I also worked on the FileSystem class. Things are starting to come together, but for now this is just bare-bones minimal functionality code.

I did create a solid block of code for NyMPH.Patches.PatchBank.CreatePatchListFile(). This method uses a string builder to assemble the contents of a .pchList file. I need to add some checks for empty Patch lists, etc.

Since the PatchBank will be graphically represented in the UI as a 10 x 10 grid of Patches, perhaps using a List instance isn't the best way to go. The position of Patches in the grid will determine the order they are written to the pchList file, which in turn sets the order they are loaded into the Nord. I'd also like to offer sorting options for the PatchBank, which may become complicated with other ways of storing Patches.

I'm going to create a spreadsheet with a tab for each class. This will let me keep track of changes to each class in chronological order.

Added XML to event logger

I added some basic XML code to create an Event element with attributes of Date, Time and EntryType (severity). The inner text of each Event will contain the message.

This produces a .log file with an XML fragment; it would be a simple matter to create a root element corresponding to the log filename in order to read/search through it. I may create this as needed, but for right now the basic logging features should work.

Back to work

I'm back on track with writing code for the NyMPH project. I started using the EventLogHelper class and quickly realized I had an opportunity to make things a bit easier to use it.

I started adding namespaces to the classes I've touched so far. Since they were all auto-generated, they are all at the same 'level'.

The namespace scheme I came up with is as follows: Root level namespace is NyMPH, second level namespace refers to the 'package' a class falls under (i.e. Patches, Persistence, etc.). For example, the fully qualified name for the Patch type would be NyMPH.Patches.Patch.

I added a 'generic' method to the ELH called WriteEvent(). This method looks at the instance that invoked it to see if it should write to a log file, write to the Event Log, or write to the Application Event Log. It tests the FileInfo object for null, followed by the EventLog object for the 'custom' log.

I then used preprocessor directives to create an instance of ELH using a log file (for debugging), or registered Event Log and Event Source names for the 'release' version (which will create the log and source values during installation).

This allows me to simply call the WriteEvent() method as needed without having to check for 'debug mode' each time.

For each class, then, I will use the fully qualified name for log files. Errors that happen in the FileSystem class, for example, would be written to the same directory as the executable as NyMPH.Persistence.FileSystem.Errors.log.

For writing to log files, I should probably implement something a bit more structured for writing errors than just dumping the Message onto a single line. I may create an XML file or something to do this.

I also need to start keeping track of individual classes as I write code for them. Specifically, I need to keep track of the following states:
untouched (generated code only)
in process (working on them)
on hold (have worked on them but waiting for something)
almost ready (can be tested but contains 'TODO' markers)
ready (can be tested fully)

Been away

Life has gotten busy lately. I've been able to add 'logfile' capabilities to the Event Log Helper. There's a class that parses a file path to determine if it's a directory, a file, invalid, etc. This all occurs with broad exception catching.

In use, this class allows a potential log file name to be 'qualified' as one or more 'types'. The constructor accepting a file path string can quickly determine if it is valid or not.

I've run several function tests; it all appears to work on a Vista system (no admin rights) and handles every possible input I could type into the immediate window.

With this chunk of support code done I can return my focus to the domain classes.

On another note - I've been reading up on Linq to SQL and typed datasets. This isn't something I have a lot of experience with but it definitely looks easier than manually mapping objects to relational data and vice versa.

It is worth further study...

I added Google Analytics to the project site as well as this blog. While I don't expect a lot of attention on this project, it would motivate me to keep posting progress if someone was actually looking at it (or waiting for a beta version to be compiled).

Finally entering Implentation Phase (first round)

I've already started flushing out the domain classes (Patch, Patch Bank, etc.). I quickly realized a need for error management, so I wrote a class that provides static methods for writing to the Application log called EventLogHelper.

The EventLogHelper (ELH) class provides static methods to write to the Application event log. It creates an Event Source to match the name of the calling assembly using reflection.

The ELH can also be instantiated multiple times. The Log and Source values are passed in the constructor to 'assign' the instance of ELH to a specific log. Methods are available for writing messages to the specified event log using one of the three types (Information, Warning, and Error).

It works well with admin rights (specifically, permission to add Event Sources and Event Logs to the local system). On Vista machines or those without admin rights a security exception is thrown when the ELH attempts to create a new log file and/or add a new Event Source.
If a security exception occurs, the ELH writes the message to the Application log using the Application source. It also writes a message indicating what could not be created because of insufficient privileges. No matter what, something is written somewhere in the event logs

This description of the ELH is from memory; I wrote it a week or so ago and some of the details may be fuzzy. It definitely needs improvement, and I would love to find out how to 'assert' or 'demand' security permissions for this assembly and not rely on thread security for the calling assembly.

I may pick this apart this weekend, clean it up, document it better, and add methods for file-system logging. I think this would work around the security issues and make it OS-independent. It will simply write to a log file within its application data folder.

Lunch is almost over - will work on this more later...

Done with Documentation!

I moved the 'current status' portion of the Main Wiki into it's own page and fixed a couple links.
I had already updated the database diagram and put in some specifics.

Now that the NyMPH project has all of the existing documentation online and things look good, I can finally spend some time actually working on the project instead of writing about it.

Finished Task List

I was able to take a snapshot of my Nord and use it in the Wiki pages.

I also converted the task list and TODO items into Wiki. Completed items are struck-through so they can be referred to.

My Nord Modular

I've created a utility class for handling event logging. At this point it doesn't work as well with non-admin rights (or in Vista), but when run with admin rights it creates new Logs and/or Sources in the local Event Log for the application.
I'd like to use this for non-UI classes to record errors instead of just silently failing.

I also created a project logo. It looks like the rack-mount Nord Modular sitting two feet away from me. :)

For fun, I Googled Nord Modular Patch Librarian and this blog showed up. I think it's best if I provide a link back to the code project for those who find their way here.

Almost done creating Wiki pages

I've converted the rest of the analysis and design written artifacts into Wiki pages. I went through and created links to other Wiki pages where possible.

I noticed the UI elements specified for a couple of the use cases were inaccurate or over-complicated, so I spent some time changing them. For example, the use case specifications originally indicated a separate form for Archiving a Patch; however, this was since replaced with a single Patch attribute of IsArchived (instead of a complicated process of literally 'moving' things to the 'Archive', which was not required when taking a database approach to storing Patch Files).

I created Wiki Pages for the rest of the diagrams I have available. I also made a table of contents Wiki to serve as the side navigation bar.

This navigation bar will need to be cleaned up at some point; it's gotten rather large.

I've also noticed some of the sequence diagrams have some note objects overlapping the first instance object. This is a byproduct of resizing them in UModel and can't be helped right now. :)

There aren't sequence diagrams for everything in NyMPH; more are probably required for some of the complex processes involved.

But, at this point, most of the documentation available is up on the Wiki.

Got quite a bit of work done today:

• All of the written analysis and design artifacts have been converted to Wiki and put on the Google code page.
• I've created a sidebar navigation Wiki with all of the current items.
• I've also created a couple pages that link to the UML diagram images I uploaded earlier.
• I expanded the Main page to describe the project in greater detail.

I've found that Notepad++ is a good tool for converting text to Wiki. I performed a find-replace on multiple files simultaneously to do some formatting. I also created a couple macros to assist in converting the numbering format.

It took some effort, but I quickly got the rest of the documents converted.

Making progress

Saving Word docs as text files first and adding the Wiki markup later is definitely faster. I've gotten the rest of the business rules specifications added to the Wiki.

Tomorrow I will try to get a bunch of use cases put in. Later, I will see if I can embed diagrams in the Wiki pages.

I found a contrived means of importing Word documents into Google Code Wiki pages. It isn't pretty:
1. Saved the Word document as a filtered HTML file. (I created a macro to do the save with one click). This produces a less polluted HTML file than the normal Word HTML format.
2. Copied the HTML and pasted it into jtidy.de, which converts most of it into Wiki format
3. I paste it into a new Wiki page in Google Code.

Unfortunately, this is not a perfect process and I often have to correct spacing errors or missing lines of text.

This makes converting Word documents to Wiki a slow process, especially with the more complex ones.

Saving it as straight text is probably easier because I can add the formatting myself. I will try that tomorrow.

First Wiki

Made my first Wiki, too. I bet there's a way of exporting Word documents as Wiki files...

Upload design artifacts

I've uploaded most of the requirements gathering, analysis, and design artifacts created so far in this project.

Requirements Gathering was fairly easy, since I'm the user.

The documents are in the source code system; this allows me to update them from multiple locations (work, home, etc.).

The main piece of documentation is the "NyMPH Analysis Master.docx" file. This is a master document with a bunch of sub-documents linked internally. This document describes use case specifications, business rule specifications, and UI element specifications (which are mostly placeholders for items mentioned in the use cases).

There is also a "NyMPH TODO List.docx" file that contains a generalized development plan followed by a 'scratch list' of things to do. Many of them are crossed off but kept as reference.

Finally there is a "Domain Glossary.docx" file that defines many of the terms used in this project. For instance, it specifies what a 'Patch' is in terms of the Nord Modular system to help differentiate it from a Patch File (which is the *.pch file containing the Patch Data), Patch Data (which is the raw textual data that makes a patch), and so on.

I will be adding UML diagrams later as time allows. Note that my use of UML diagrams was to gain experience doing them, not necessarily thoroughly diagramming the NyMPH system. :) Not getting paid by the hour for this, so I've avoided over-diagramming the system.

Startup

This blog has been created to track the development of the NyMPH system.

More details to follow...