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.
Tuesday, July 28, 2009
Monday, July 27, 2009
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.
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.
Sunday, July 19, 2009
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.
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.
Friday, July 17, 2009
Got quite a bit of work done today:
It took some effort, but I quickly got the rest of the documents converted.
- 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.
It took some effort, but I quickly got the rest of the documents converted.
Monday, July 13, 2009
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.
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.
Sunday, July 12, 2009
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.
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.
Wednesday, July 8, 2009
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.
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.
Tuesday, July 7, 2009
Startup
This blog has been created to track the development of the NyMPH system.
More details to follow...
More details to follow...
Subscribe to:
Posts (Atom)
