EDI-fication

Don't try this at home.

2011-12-07T07:53:00.002-06:00

And this is why.

Kindle,Kindle woo-hoo!

2011-11-25T10:56:00.000-06:00

So, I got my Kindle Fire Wednesday afternoon. I've had a little chance to play with it.

A full "Un-boxing and review" post will come later, but here are some quick impressions.

For what I plan to do with it, it seems fine. Browsing the internet, downloading and using apps, watching videos: all of these things are great (so far). My only problem is that I had been planning to post this from the Kindle. That didn't work.

Everywhere else I've been trying to post has been fine, so it may just be the Blogger interface, but I was hoping that short posts would be without too much pain. That seems not to be the case at the moment. Maybe I'll figure it out after playing with it some more, but that is my only pain point, it seems.

All in all, I give it a solid 3.5 / 5 on a preliminary basis.

C# In Depth 2nd. Ed.: A (partial) Review

2011-06-19T13:14:00.001-05:00

I’m currently reading C# In Depth: 2nd Edition (Jon Skeet, Manning Publications), and I thought I’d share my thoughts about it so far.

I would say I’ll do this in three parts: the good, the bad, an my take, but really there’s only “the good.”

I consider myself to be a mediocre-to-good developer. I still have lots to learn and my code can always get better. Hanging out on StackOverflow.com, I get to see Jon’s casual mastery of C# nearly every day. I can only thank him for the help he’s been to me- even if he’s never actually answered one of my questions (or, at least, I don’t remember that he has, and I think that would stick with me…)

C# In Depth is the work of a master. They say that you’ve truly mastered something- not when you understand it, but when you can communicate that understanding clearly. By that standard, Mr. Skeet has truly mastered C#.

The book begins with a look, a retrospective if you will, of C# 1. I, for one, noticed the fondness Mr. Skeet still holds for the old language (and, as he would point out, the BCL and CLR that went with it). Even as he points out its flaws- which it must have, or why even bother with C#2, 3, & 4- he also takes care to explain things so clearly that one can see a huge proponent of the language.

From pointing out the flaws in C#1, the book proceeds through C#2 and its enhancements to C#3.5 (where I currently am) and will proceed to C#4. At each level, the detail he provides about how the language actually works is quite comprehensive- or, as comprehensive as a book meant for actual consumption can be. Moreover, his explanations and examples pointed out, quite clearly, places I could improve my own code, or explained to me the “why” of things I had taken for granted.

As a C# developer who considers myself in the “Coding 201” camp (Okay, I may have graduated to Coding 202), I cannot imagine a better technical book to have at one’s fingertips. Where other books range (within the same book) from simple (and sometimes misguided) pedantry in text to oversimplification and hand-waving in examples, C# In Depths seems to have hit that perfect sweet-spot of the text being concise enough not to put me to sleep, and examples being robust enough to see what would actually happen.

I highly recommend you read the book, if you haven’t already. I can virtually guarantee that it will improve your coding game as you begin to understand why some things work the way they do.

I also recommend you go (and subscribe) to his coding blog. It’s on my must-read list.

A New Project: DoctorConnect

2011-06-14T07:48:00.001-05:00

Welcome back!

Today I’m introducing a new project- again, mostly to help me learn stuff. This one is a little more complex and will actually involve at least 2 and probably 3 sub-projects. I call it DoctorConnect.

The theory is this: Assume that a Doctor’s office wanted to enable its patients to do some basic tasks online without having to call and wait for a nurse to call them back. We’ve all had to do that, right? You’re puking your guts out, and you have to wait for the nurse to call you back before you know if they can see you today (saving you $$$) or if you have to go to some Doc-in-a-Box Urgent Care place.

So: DoctorConnect.

It will be a system in 3 parts: A database (SQL Server 2008 R2), an internal web application (haven’t decided on MVC or Web Forms, yet) and an external web page. After all that’s done, I may also design a mobile-app for the project: so users could schedule an appointment on-the-go.

This is a big project for me, and I’m going to have to master some things that I haven’t mastered yet before I get it right.

First: The DB. I’ll need to map my DB tables to Objects. This is complex enough a data model (more on that in another post) that I don’t fully trust EF, and I don’t trust my own skills at Linq-2-SQL enough. So I’ll be looking at various ORM options to determine the best way to go.

Second: Membership. Unlike the Issue Tracker, this will require a custom membership provider: I’ll need to know not only if someone is an authenticated user, but exactly what things they should be able to see. On the internal application, that may be role-based, but on the external application, it will have to be something else- some hierarchy model that allows for a Responsible Party to see all the accounts for which he (or she) is responsible, but let other patients see only their own accounts.

Third: Polymorphic Data. What I mean is this: A patient, when scheduling an appointment, doesn’t need to know all the information about a specific doctor, just their name, specialty (so they don’t go see an OB/GYN about their prostate), and availability. On the other hand, the Office Staff need to know just about everything about a patient. How should I handle that?

Fourth: Scheduling. I’ll need a way to set an appointment for a doctor and validate it against other scheduled events: we don’t want patients to be able to schedule an appointment during lunch, for instance, or while that doctor is on vacation. So I’ll need to figure that out.

All in all, this is shaping up to be a big project. So let’s start eating this elephant: one bite at a time. Next up: the data model.

"I'd like to thank all the Little People..."

2011-06-09T05:56:00.000-05:00

I'm a member of the D/FW Connected Systems User Group. Last night we held officer elections and I was honored by being selected as the Vice President of Meetings (not as big a deal as it sounds, but nice nonetheless). So expect to see a lot more content specifically related to DFWCSUG on the blog for the next year or so.

You can find us here if you're interested.

On Professionalism

2011-06-08T07:27:00.001-05:00

Yesterday, two of my co-workers, a fellow consultant and one of the client’s FTEs, were having a dispute about some procedural issues. I’m not going to discus specifics, nor who was “right,” that’s not the point of this post.

In the course of the dispute, both sent fairly preemptory emails, and exchanged harsh- though still mostly civil- words verbally as well. For the rest of us in the area, it was fairly uncomfortable, and I hope they thought so as well, once they each cooled down and thought about it.

In this particular case, the major issue was that neither side was actually listening to the other. Had either been willing to set their assumptions aside for thirty seconds while the other completed a statement, I believe the issue would have been resolved much sooner than it was.

So, for the record, let’s set out some rules about workplace disagreements.

1: Don’t have public arguments. Ever.

This is highly important. When you argue with a colleague, nothing good comes from it. More-over, you will probably hurt the group by causing it to divide into factions over who is right. Finally, you hurt the group in the eyes of any other observer who may be walking by.

When you have a disagreement, take the person with whom you disagree aside and have a private discussion. If you can secure an office or conference room, feel free to yell.

2: Listening doesn’t just mean waiting for the other person to finish speaking.

Every “conflict resolution” class ever in the history of ever has agreed on this point. When the other person is speaking, you should not be thinking about what you’re going to say next, you should be paying attention to them.

Most people don’t do things that don’t make sense- when viewed from their perspective. So, when someone is saying something that doesn’t make sense to you, you’re probably holding a different set of assumptions than the person to whom you’re speaking. The correct answer, at that point, is to check your own assumptions at the door, and try to see things from a viewpoint where what the other person is saying is reasonable. Once you’re able to do that- even if you disagree- you’ll be much more able to remain polite.

Politeness helps speed the resolution of the issue.

3: Never assume.

I mean that. Never make assumptions beyond those necessary to hold a conversation.

The argument yesterday could have been shortened considerably had either party, let alone both, stopped assuming that the other was being unreasonable (see point 2). The issue was over a particular process and whether it had been followed in a particular case. One party assumed the process hadn’t been followed, the other assumed it had, and there was no clear evidence one way or the other.

Had each party checked their assumptions at the door, the entire exchange would have gone something like this:

“Hey, when [Resource X] did such-and-such, did they make sure to follow [Procedure Y]?”

“I’m sure they did, but I’ll send an email {the other resource is off-shore} to make sure of that.”

So, the next time you have a disagreement with a co-worker, whether you or they are a consultant, contractor, FTE, PTE, or whatever, remember that the rest of the office would much prefer it if you keep things professional and civil. If you’re unable to comply with either of those, take the argument somewhere the rest of us don’t have to hear it.

MVC Issue Tracker: Where We've Been

2011-06-06T09:38:00.000-05:00

I should have the final code zipped and pushed to CodePlex as a download sometime today or tomorrow. This post is sort of a retrospective on what we've already done.

If you missed the posts, here they are in order
Introduction
Part 1- Setting Up
Part 2- Controllers
Part 2.5- Ancillary Issues
Part 3- Cleaning Up the Views
Part 4- Finishing Up

So, some impressions to wrap up:

First off, while I would have liked to implement my own authorization system, MVC3's provided version met all my needs quite well, and so there was no reason to handle that. So that got cut out at the end. I do like the fact that, for almost all scenarios, the MVC3 provided authorization model works well enough. Perhaps someone with exceptionally high security needs would be required to create their own model, but I doubt anyone with such needs would be using MVC (the product) anyway.

Which leads me to my second point. ASP.NET MVC3 seems to me like something a small company (even big for a small company, but small nonetheless) would use to get a website up and running relatively quickly. I can see that it has plenty of power for the mid-sized business as well, but once you get up to larger enterprises, I see things I believe would cause some problems.

First, I don't like the lack of separation of the code. MVC3, by default at least, throws all your code into one project. I believe that my Model code (let's face it, it's the Data Layer) should be in a separate project, at least, and possibly a separate solution. The Controller code- being the Business Layer- should, to my mind, be likewise separated- either in a separate project or separate solution.

Now, I don't see any reason you couldn't use MVC like methodology and still have those layers of separation, but MVC3, in itself, is fairly dependent upon having all that code in the same project- at the very least for auto-generating views and controllers. I may be wrong, but it seemed to me that MVC was built on the idea that all of this code would be in the same project. That's fine for fairly small and/or encapsulated applications, but a larger enterprise with multiple web applications may very well have need to separate those layers better simply because they want people to interact very differently (beyond simple authorization issues) with the same data.

Take, for instance, the sample project the good folks at MS use of Contoso University. Their MVC3 tutorial walks you through setting up a way to enroll students, or add classes, or whatnot. In a real life situation, that enrollment, and most of the administrative functions, would be handled (if they used MS Technologies at all) on an internal only application- whether an intranet application or a windows application- and all anyone logging in would be able to do is some basic maintenance of their own student account and request enrollment (with the actual enrollment being handled by some other application to ensure class sizes were set properly, etc.). This would lead to it making more sense to have that level of separation.

Now, my thought is that MS would be saying, "You're right- so you don't use MVC for that." That's a completely reasonable expectation- but it is something to be aware of.

All in all, however, I was impressed by the power of MVC and the ease with which the application came together. Certainly it would need a lot of cleaning and polishing before anyone used it as an actual production application, but I can see the seeds in there for just such a thing. Add to that the lightweight nature of the newest version of SQL Compact for the database, and a small company could easily use such a thing- instead of some big and expensive tracking system- to track their trouble tickets. And, as with anything that contacts the database, all that really needs to happen if the ticket database grows too big is to create the same db schema in some more robust database (say, full on SQL Server, or whatever) and change the web.config connection string.

I hope this exploration has been as beneficial for you as it was for me.

MVC Issue Tracker Part 4

2011-06-03T16:53:00.000-05:00

This is the penultimate entry in this series. I’ve completed the code to the level I intend (for the moment) and I’ve verified things work as I expect (for the moment).

So, let’s look at what we had left to do:

Wire up WorkNote/Create so that it would redirect back to the underlying issue instead of to the index of WorkNote.
Provide Security.

The first was easy, instead of using “RedirectToAction(“Index”) I changed the code for "Create” to this:

        1: [HttpPost]

       2:         public ActionResult Create(WorkNote worknote)

       3:         {

       4:             if (ModelState.IsValid)

       5:             {

       6:                 var issueId = db.Issues.Where(i => i.IssueId == worknote.IssueId).SingleOrDefault();

       7:                 worknote.EnteredBy = this.HttpContext.User.Identity.Name;

       8:                 worknote.LoggedDate = DateTime.Now;

       9:                 db.WorkNotes.Add(worknote);

      10:                 db.SaveChanges();

      11:                 return RedirectToAction("Details", "Issue", new { id = issueId.IssueId });   

      12:             }

      13:  

      14:             ViewBag.IssueId = new SelectList(db.Issues, "IssueId", "Title", worknote.IssueId);

      15:             return View(worknote);

      16:         }

Ignore the “IssueId” and “EnteredBy” stuff for now. The important part is at the end: “return RedirectToAction(“Details”, “Issue”, new {id = issueId.IssueId})'; This tells the controller that, on a successful insert, it should redirect to the “Details” view of the Issue with a specified issue id.

See? Easy.

The next part required some extensive refactoring. I was going to implement my own security model, but that’s really fairly silly. MVC3 provides us with a perfectly acceptable method of Role based security, so we’ll just hook into that.

First, I removed the User class and Role enum, and all the references to same. Then, using the configuration button, I used the built-in web-based configuration to set up roles, and add a couple of users.

From there, it was all markup. Some samples follow:

       1: [Authorize(Roles="Administrators,Manager,Developer,User")]

       2:     public class WorkNoteController : Controller

This piece just says that only someone logged in as an Admin, Manager, Dev, or User can get to the WorkNoteController. I have similar authorization on Issue.

More significantly, on Issue, I marked up some of the specific methods for the IssueController:

       1: [Authorize(Roles = "Administrators,Manager,Developer")]

       2:         [HttpPost]

       3:         public ActionResult Edit(Issue issue)

       4:         {

       5:             if (ModelState.IsValid)

       6:             {

       7:                 if (issue.ClosedDate != null) issue.ClosedBy = this.HttpContext.User.Identity.Name;

       8:                 db.Entry(issue).State = EntityState.Modified;

       9:                 db.SaveChanges();

      10:                 return RedirectToAction("Index");

      11:             }

      12:             return View(issue);

      13:         }

       1: [Authorize(Roles = "Administrators,Manager")]

       2: [HttpPost, ActionName("Delete")]

       3: public ActionResult DeleteConfirmed(int id)

       4: {            

       5:     Issue issue = db.Issues.Find(id);

       6:     db.Issues.Remove(issue);

       7:     db.SaveChanges();

       8:     return RedirectToAction("Index");

       9: }

These are specific authorizations required to access specific views: Edit and Delete, respectively.

So, now, an Administrator would have to create a new user (as one would expect in a business scenario) and provide that user with the correct credentials. That user would then only be able to access the parts available to the assigned Role. Basically, a basic user can add issues and can look at issue details/status. A Developer can do that, but can also edit issues (specifically to close them, when necessary) and add work notes. Managers and Administrators have the additional authority to delete issues.

Additionally, since I’m able to use the provided Role based security, I’m also able to avoid the necessity of a “User” object, and just grab the UserName from the Session. This allows tagging that is just as accurate as building role-based security from scratch, and that is more intuitive, since I can just grab the username instead of the user’s Id, or going through some hoops to take that Id and turn it into their name.

The final code push is up on CodePlex now, and I’ll zip it all up and add it to the downloads folder soon as well.

Next Up (In a couple of days): A look back, and my impressions from working with MVC3.

And now, for Something Completely Different

2011-06-03T07:22:00.000-05:00

I'm changing lap-tops, which means porting code. To do that, I'm taking the things I think are worth keeping and throwing them up on CodePlex. One in particular, being close to my table-top-rpg-playing heart is my Campaign Portfolio Manager. Go check it out, if such things interest you.

MVC Issue Tracker: Part 3

2011-06-02T19:43:00.001-05:00

For this installment of the Issue tracker, I mostly just clean up our views a little bit. I also added a little functionality for a snap-shot page and provided the ability to add new work notes to an issue.

Let’s dive in.

First off, I added a Snap-Shot report to the ‘About’ Page, like so:

This required very little code, actually, but adds a nice little bit of polish- along with helping me get my head around exactly where we’re going here…

        1: public ActionResult About()

       2:         {

       3:             var allIssues = ctx.Issues;

       4:             var closedIssues = ctx.Issues.Where(i => i.ClosedBy != null);

       5:             var openIssues = ctx.Issues.Where(i => i.ClosedBy == null);

       6:  

       7:             var oneWeek = GetClosedInOneWeek(closedIssues);

       8:             var twoWeeks = GetOpenGreaterThanOneWeek(openIssues);

       9:             double oneWeekCount = oneWeek.Count();

      10:             double closedCount = closedIssues.Count();

      11:             var pctOneWeek = oneWeekCount.PercentOf(closedCount);

      12:  

      13:             ViewBag.CountAllIssues = allIssues.Count();

      14:             ViewBag.CountClosedIssues = closedIssues.Count();

      15:             ViewBag.CountOpenIssues = openIssues.Count();

      16:             ViewBag.OneWeek = oneWeek.Count();

      17:             ViewBag.TwoWeeks = twoWeeks.Count();

      18:             ViewBag.PctOneWeek = pctOneWeek;

      19:  

      20:             return View();

      21:         }

First, I added this to the About action of the HomeController. It just grabs the issues, then collates the ones that are closed vs. the ones that are open, and runs some quick analysis.

Heading over to the View, we added this:

       1: <h2>Issue Tracker Snap-Shot</h2>

       2: <p />

       3: <table>

       4:     <tr>

       5:         <td><b>Total Issues Logged</b></td>

       6:         <td>@ViewBag.CountAllIssues</td>

       7:     </tr>

       8:     <tr>

       9:         <td><b>Closed Issues</b></td>

        <td>@ViewBag.CountClosedIssues</td>

    </tr>

    <tr>

        <td><b>Open Issues</b></td>

        <td>@ViewBag.CountOpenIssues</td>

    </tr>

</table>

  

<h3>Issue Closure Details</h3>

  

<table>

    <tr>

        <td><b>Issues Closed In One Week or Less</b></td>

        <td>@ViewBag.OneWeek</td>

    </tr>

    <tr>

        <td><b>Percent Issues Closed in One Week</b></td>

        <td>@ViewBag.PctOneWeek</td>

    </tr>

    <tr>

        <td><b>Issues Open More than Two Weeks</b></td>

        <td>@ViewBag.TwoWeeks</td>

    </tr>

</table>

And that’s really all it took.

The Percentage part was kind of tricky, though: since there are no closed issues (as might actually happen in the first several days to couple of weeks if this were ever someone’s actual ticket tracking system) the Percentage wanted to return NaN. So I created a little extension method off of Double:

       1: public static double PercentOf(this double numerator, double denominator)

       2:         {

       3:             var temp = numerator / denominator;

       4:             if (Double.NaN.CompareTo(temp) == 0) return 0;

       5:             return temp;

       6:         }

It just goes ahead and divides anyway, and if the result returns NaN, it passes back 0. Not mathematically accurate, but business accurate.

Next, I turned to the WorkNote. Specifically, I turned to making the edit a little more accurate, and linking it to the Issue. I modified the controller and view to handle the LoggedDate automatically, and then I modified the Detail view of the Issue to provide a list of WorkNotes and the ability to add a new one. Like So:

       1: </fieldset>

       2: <table>

       3:  <thead>

       4:    <tr>

       5:      <th>Work Detail</th>

       6:      <th>Entered By</th>

       7:      <th>Date</th>

       8:    </tr>

       9:  </thead>

      10:  <tbody>

      11:    @foreach (var item in Model.WorkNotes)

      12:    {

      13:        <tr>

      14:          <td>@item.Detail</td>

      15:          <td>@item.UserId</td>

      16:          <td>@item.LoggedDate.ToShortDateString()</td>

      17:        </tr> 

      18:    }

      19:  </tbody>

      20: </table>

      21: <p>

      22:     @Html.ActionLink("Add Notes", "Create", "WorkNote") |

      23:     @Html.ActionLink("Edit", "Edit", new { id=Model.IssueId }) |

      24:     @Html.ActionLink("Back to List", "Index")

      25: </p>

So, now, when we navigate to the detail of an issue, we get:

And clicking on the “Add Notes” link gives us:

Currently, when we add a new note, it takes us to the WorkNotes Index… we’ll work on that for the next post.

MVC Issue Tracker: Ancillary Issues

2011-06-02T16:12:00.000-05:00

A more substantive post on the Issue Tracker should be up tonight or tomorrow (if I can get WLW to connect...) but for I wanted to mention a couple of things I ran into today just so I don't forget them.

While doing some view updates, I ran into two issues: first: Remember that DateTime? needs to be cast to DateTime (or .Value needs to be retrieved) to do any DateAdd functions (the reasons for this are apparent when you think about them, but there you go...). Second, I really wish Microsoft would just bow to reality and implement a C# Language version of IEnumerable.ForEach.

I've read Eric Lippert's post on the issue and, while I understand what he's saying, I largely disagree. It may be "philosophical" to say that ".ForEach" would just provide "a side effect," but how many times do you find yourself writing this code:

     //Stuff is an IEnumerable
     foreach(var thingy in Stuff) { if(thingy.parameter == value) doSomething(thingy); }

or this:

      Stuff.ToList().ForEach(t => {if(t.parameter == value) doSomething(t)});

Now, to my mind, neither of these is particularly hard to read, but, in both cases, I'm having to type more than I'd like to. My preferred method would be:

    Stuff.ForEach(t => {if(t.parameter == value) doSomething(t)});

Even more useful, to my mind, is a way to handle "null" elegantly. I work with user input on a fairly regular basis, and sometimes users end up entering null values. Now- let it be said- the correct thing to do is to check to see if something is null BEFORE adding it to a collection. However, that doesn't always happen, and we should be able to handle it. So, I implemented my own SafeForEach as an extension method for IEnumerable. I'll post the code for that with my main post later.

Finally, we come to another minor annoyance: Percentages- especially "of" 0. In the Issue Tracker, I'll be providing a Snap-Shot that provides a statistic for "Percent of Issues Closed in One Week Or Less." However, right now, I have no issues closed- so how can there be a percentage of 0? Now, I could define my percentage as closedInOneWeekOrLess/totalIssues, but that's not the metric I'm looking for (though it could be a useful metric to track, now that I think about it). I want the percentage of closed issues which were closed in one week or less. Until there are closed issues, however, there is no good way to provide that percentage.

So, on Double, I wrote another ExtensionMethod (also a good way to express exactly what you want better than just doing the math in code: .PercentageOf(double denominator). This is defined as "public static double PercentageOf(this double numerator, double denominator). It then does the math, and returns 0 instead of NaN when NaN would be provided.

The code for both of these methods will be provided either as an update/edit to this post, or in the main post which should come tonight or tomorrow.

Generic Serialization

2011-05-27T17:00:00.000-05:00

Another side post, while I also work on the MVC application.

One of the things I deal with on a regular basis is serialization of objects to and from files. Additionally, I see the questions come up on StackOverflow from time to time. So, to save myself some time and effort, and, hopefully, to help educate others, I wrote a generic serialization .dll.

The project is very small at the moment, though I may expand it as I decide to explore other types of Streams. Right now, it is strictly file serialization/deserialization. The over-arching idea is the ISerializer interface which defines two methods: Serialize and Deserialize. Then each class will implement that interface. The reason I used an interface is that I really do plan to expand this code and use it out in the wild. For that reason, I need to be able to serialize to whatever Stream type is appropriate at the moment, but I need to de-couple the serialization from the objects, as well as the presentation and business layers, as possible.

So, on to the code.

As I said, I started with a simple Interface: ISerializer:

namespace GenericSerializer

{

public interface ISerializer

{

void Serialize<T>(T target);

T Deserialize<T>();

}

Notice the use of the T type designator. I want this completely generic so that ANY class which is decorated as [Serializable] will work with my code. This won't do any custom serialization, but I've never found that much need for it.

Now, my two classes: GenericXmlSerializer and GenericBinarySerializer. Again, both of these serialize only to files, at the moment. That will probably change in the future.

Here is the Xml Serializer:

public class GenericXmlSerializer : ISerializer

{

public string Path { get; set; }

public GenericXmlSerializer() { }

public GenericXmlSerializer(string path)

{

Path = path;

}

public void Serialize<T>(T target)

{

using (FileStream fs = new FileStream(this.Path, FileMode.Create))

{

XmlSerializer xs = new XmlSerializer(typeof(T));

xs.Serialize(fs, target);

}

public T Deserialize<T>()

{

T result;

using (FileStream fs = new FileStream(this.Path, FileMode.Open))

{

XmlSerializer xs = new XmlSerializer(typeof(T));

result = (T)xs.Deserialize(fs);

}

return result;

}

I elected to have a Path property because I have to have an instance anyway. So we may as well ask for the path to which a file will be serialized at the time of class instantiation. Also note that the serialization code itself is very, very basic. I just use the default settings of XmlSerializer to write out the file. Deserialization is the same, I'm presuming the type T will be defined such that basic deserialization will be okay. If it isn't, of course, I'll have a problem. But this code wasn't designed to handle custom serialization anyway, so I'm not terribly concerned.

I made the same decisions with the Binary Serializer:

public class GenericBinarySerializer : ISerializer

{

public string Path { get; set; }

public GenericBinarySerializer() { }

public GenericBinarySerializer(string path)

{

Path = path;

}

public void Serialize<T>(T target)

{

using (FileStream fs = new FileStream(this.Path, FileMode.Create))

{

BinaryFormatter bf = new BinaryFormatter();

bf.Serialize(fs, target);

}

public T Deserialize<T>()

{

T result;

using (FileStream fs = new FileStream(this.Path, FileMode.Open))

{

BinaryFormatter bf = new BinaryFormatter();

result = (T)bf.Deserialize(fs);

}

return result;

}

Now, we have our serializers, but do they work? The only way to know is to set up another project which uses them. In this case, I'll use the same solution, but a new project. In the wild, of course, we'll be using different solutions with references to the .dll.

So, SampleSerializationProject: It has a Class: Employee, an Enum: WorkRole, and a simple console application that will put together a couple of files for us.

The Employee Class:

[Serializable]

public class Employee

{

public int EmployeeId { get; set; }

public string LastName { get; set; }

public string FirstName { get; set; }

[XmlEnum]

private WorkRole role;

public WorkRole Role

{

get { return role; }

set { role = value; }

}

public double Salary { get; set; }

public bool Exempt { get; set; }

public override string ToString()

{

return string.Format("Employee Id: {0} :: {1}, {2}", EmployeeId, LastName, FirstName);

}

Note that the WorkRole could not be represented as an automatically implemented property, I had to specify the backing field to use the [XmlEnum] attribute.

The WorkRole Enum:

[Flags()]

public enum WorkRole

{

Clerk,

Laborer,

Manager,

Officer

}

Here, note the [Flags()] attribute. This allows the binary formatter to serialize to and from the enum in the same way that [XmlEnum] allows the XmlSerializer to do so.

Finally, the program itself:

static void Main(string[] args)

{

var Employees = new List<Employee>

{

new Employee() {EmployeeId = 1, LastName = "Smith", FirstName = "John", Role = WorkRole.Clerk, Salary = 10.00, Exempt = false},

new Employee() {EmployeeId = 2, LastName = "Doe", FirstName = "Jane", Role = WorkRole.Laborer, Salary = 15.00, Exempt = false},

new Employee() {EmployeeId = 3, LastName = "Zachary", FirstName = "Marcus", Role = WorkRole.Manager, Salary = 50000.00, Exempt = true},

new Employee() {EmployeeId = 4, LastName = "Goodner", FirstName = "Allen", Role = WorkRole.Officer, Salary = 80000.00, Exempt =true}

};

GenericXmlSerializer gxs = new GenericXmlSerializer(@"C:\Testing\testXmlSerialization.xml");

GenericBinarySerializer gbs = new GenericBinarySerializer(@"C:\Testing\testBinarySerialization.dat");

gxs.Serialize<List<Employee>>(Employees);

gbs.Serialize<List<Employee>>(Employees);

Employees = null;

List<Employee> Employees2;

Employees = gxs.Deserialize<List<Employee>>();

Employees2 = gbs.Deserialize<List<Employee>>();

Console.WriteLine("Output from Xml Deserialization");

Employees.ForEach(e => Console.WriteLine(e));

Console.WriteLine();

Console.WriteLine("Output from Binary Deserialization");

Employees2.ForEach(e => Console.WriteLine(e));

Console.ReadKey();

}

Here you see I'm creating a List of Type: Employee. I then create two generic serializers (one for each type I built) and provide the path I where I want the files to go. I Serialize to disk, then I null out the first list and create a second- just to prove that both types worked. I deserialize from both files, and then write the output to the Console.

Please, feel free to copy this code to your heart's content. If anyone needs me to, I'll happily post the compiled .dll on Codeplex.

MVC Issue Tracker: Part 2

2011-05-26T13:46:00.002-05:00

Apologies for the delay: But, I’m back in business now, so we’ll pick up where we left off…
Before we can begin with our Controllers, we need to finish one part of the data model: the Database Context.
Entity Framework makes this easy for us, in MVC3. First, we add a new connection string

<add name="IssueTrackerDbContext"
         connectionString="Data Source=|DataDirectory|IssueTrackerDb.sdf"
         providerName="System.Data.SqlServerCe.4.0"/>

Then, we add a new folder under our Models folder. I just called it “Data.” To this folder, we’ll add two classes: IssueTrackerDbContext is our context class.

public class IssueTrackerDbContext : DbContext
    {
        public DbSet<Issue> Issues { get; set; }
        public DbSet<WorkNote> WorkNotes { get; set; }
        public DbSet<User> Users { get; set; }

        protected override void OnModelCreating
            (DbModelBuilder modelBuilder)
        {
            modelBuilder.Conventions
               .Remove<PluralizingTableNameConvention>();
        }
    }

This just sets up our entities for our Controllers. Now, so that we’ll have data to play with as we make other changes, we add the IssueTrackerInitializer.

protected override void Seed(IssueTrackerDbContext context)

var Users = new List<User>

new User()

UserName = "Agoodner",

LastName = "Goodner",

FirstName = "Allen",

Password = "dontdothis",

Role = Role.Administrator

};

Users.ForEach(u => context.Users.Add(u));

context.SaveChanges();

var issues = new List<Issue>

new Issue()

Title = "Sample",

Description = "A Samle issue.",

CreatedBy = 1,

CreatedDate = DateTime.Now,

AssignedTo = 1,

AssignedUser = Users[0]

};

issues.ForEach(i => context.Issues.Add(i));

context.SaveChanges();

var WorkNotes = new List<WorkNote>

new WorkNote()

IssueId = 1,

UserId = 1,

Detail = "A Sample Note on a sample issue.",

LoggedDate = DateTime.Now,

AttachedIssue = issues[0]

},

new WorkNote()

IssueId = 1,

UserId = 1,

Detail = "Another Sample Note on a sample issue",

LoggedDate = DateTime.Now, AttachedIssue = issues[0]

};

WorkNotes.ForEach(w => context.WorkNotes.Add(w));

var wnIssue = context.Issues.Where(i => i.IssueId == 1).Single();

WorkNotes.ForEach(w => wnIssue.WorkNotes.Add(w));

context.SaveChanges();

This will allow us to have some sample data when we first initialize the application.
Now we can begin on our controllers. We’ll start with an Issue Controller. Whereas I skipped [Class]Model naming convention with the Models, I’ll leave the ‘Controler’ portion on our controllers.

For now, we’ll leave the Controller as we find it, but we will update the views. First, the Index:
Most of our changes are cosmetic: Thus:

@model IEnumerable<MvcIssueTracker.Models.Issue>

@{
    ViewBag.Title = "Index";
}

<h2>Open Issues</h2>

<p>
    @Html.ActionLink("Create New", "Create")
</p>
<table>
    <tr>
        <th>
            Title
        </th>
        <th>
            Detailed Description
        </th>
        <th>
            Created By
        </th>
        <th>
            Created Date
        </th>
        <th>
            Assigned To
        </th>
        <th>
            Last Updated Date
        </th>
        <th>
            Closed By
        </th>
        <th>
            Closed Date
        </th>
        <th></th>
    </tr>

We changed the <h2> heading to “Open Issues” and we modified the column header names so they look a little more friendly.
The only thing of substance we did was to make the view aware of if an issue is closed or not:

@foreach (var item in Model) {
    if (item.ClosedDate == null)
    { 
    <tr>
        <td>
            @Html.DisplayFor(modelItem => item.Title)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.Description)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.CreatedBy)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.CreatedDate)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.AssignedTo)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.LastUpdatedDate)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.ClosedBy)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.ClosedDate)
        </td>
        <td>
            @Html.ActionLink("Edit", "Edit", new { id = item.IssueId }) |
            @Html.ActionLink("Details", "Details", new { id = item.IssueId }) |
            @Html.ActionLink("Delete", "Delete", new { id = item.IssueId })
        </td>
    </tr>
    }

Now, with the controller and view in place, we run the app and navigate to /Issue…

Similar work to the User Controller generates:

And with the WorkNote Controller produces:

We’ll stop there, for now. Between this post and next, I’ll clean up those views, and hook up the Issue to the WorkNotes…

Coding 201 – Separating your Code Layers

2011-05-17T21:40:00.001-05:00

Above the Post Edit: In response to a request, the source code is available on CodePlex @ http://movielibrarydemo.codeplex.com/

Original Post:
One thing that has come to annoy me recently is the fact that, despite how much we talk about it, we never show new developers how actually to go about separating their code tiers, or layers, from each other. Then they get into some jam where good, object-oriented code would help, and they completely have to refactor.
Something like this came up today on StackOverflow.com (where I ask/answer as AllenG) when someone was building a simple library app to sort and store movies.

As soon as I heard this, my brain said to me, "Self," it said, "If I were doing this, I'd have an object layer with a Movie object and a Library Object, and they'd both be Serializable. Then I could just call an XmlSerializer and let it do the work." Which is, more or less, what I said. Unfortunately, the questioner did not understand how to go about making that happen. Well, out of a sense of fun, I had thrown the same project together anyway, and was going to post something about it (Don't worry, my next installment for my MVC3 series is slated for Thursday, unless something comes up). With his questions, I decided to go a little more into detail.

So, first, even for small projects, I believe that code should be broken into all three tiers: data, logic, UI. In very small projects, you could just manage it with folders, but I tend to use separate projects within a solution just to maintain the habit.

So, I created a solution (sorry, no screen caps- I'm on a different computer at the moment) which I just called MyMovieLibrary. The first project was a Class Library. I used it to create the following classes:

Movie : Serializable
1. Title
2. Genre (an enum) //I had to make this an old style field/property to get it serialize with the XmlEnum attribute
3. MPAA Rating
4. Running Time
5. Personal Rating
Library : Serializable
1. List<Movie>
LibraryManager
1. Library
2. Methods to use the Library's List<Movie>.

Then I created the Genre enum.

If I were building it for real, I'd probably move most of the code from LibraryManager just into library, but there would be enough that I don't think the Library should know about that I'd still have all three classes.

Once I had my classes, I created a new project in the same solution that I called WinMovieLibrary. It referenced my class library project, and was a simple form.

The big thing that the OP needed was how to make the list-view work. So here that is, in all its glory (again, sorry for the formatting- I should be back on my main machine for the next MVC post…)

public Form1()

{

InitializeComponent();

manager = new LibraryManager();

if (File.Exists(ConfigurationManager.AppSettings["SaveLocation"]))

{

manager.Load();

}

else manager.Library = new Library() { Movies = new List<Movie>() };

this.movieList.DataSource = manager.Library.Movies;

}

As you can see, this is the Form initializer. You see that it calls an already saved file (if it exists) and loads the records into the library. Then, even if there are no movies, yet, it sets the DataSource of the ListBox to manager.Library.Movies.

When I update the library (say, by adding or deleting a movie), I then call this code:

private void UpdateMovieListBox()

{

this.SuspendLayout();

movieList.Invalidate();

movieList.DataSource = null;

movieList.DataSource = manager.Library.Movies;

this.Update();

}

This suspends the layout of the form, invalidates the movieList control, and then forces the DataSource to update. Finally, I allow the form to update. Which then gets me whatever the current version of the list is.
For serialization (where this started), as I mentioned, I simply marked up the Library and Movie classes as [Serializable], and my LibraryManager actually serializes them with this code (Save first, then Load):

public void Save()

{

using (XmlWriter xWriter = XmlWriter.Create(ConfigurationManager.AppSettings["SaveLocation"]))

{

XmlSerializer xSer = new XmlSerializer(typeof(Library));

xSer.Serialize(xWriter, Library);

}

public void Load()

{

using (XmlReader xReader = XmlReader.Create(ConfigurationManager.AppSettings["SaveLocation"]))

{

XmlSerializer xSer = new XmlSerializer(typeof(Library));

Library = (Library)xSer.Deserialize(xReader);

}

Now, back to my original point. Something I've noticed (and I've noticed it in everything from instructional books to tutorials online, to college level classes) is that we do not teach new developers this simple, foundational stuff. Had the OP known, from the beginning, that Movie should have been a class, and that his ListBox should just attach to a list for a DataSource, then his confusion over Serialization would not have required (probably) a question on SO followed by an exchange of comments. Even if he'd had to ask his question, as soon as someone said "Make your object serializable, then call an XmlSerializer" he'd have been all set.

So, for those of you who teach others how to write code, please incorporate this fundamental into your training material. It's not that hard to do, and it can save someone much time when they find they need to add functionality they hadn't thought of.

Issue Tracker: Setting Up

2011-05-15T21:34:00.001-05:00

To set up the project, I simply selected a New Project, selected ASP MVC 3 from the Web templates, renamed, and clicked OK. That brought up the ASP MVC3 Dialog, where I selected an Internet Application, Razor view syntax, and did not choose to enable HTML 5 semantics.

That got me this:

A basic Website Set up. If I run it, it says, essentially, “Hello World.”

Right-click the solution and select “Add Solution to Source Control” and it’s even on CodePlex for me.

That done, it’s time to move onto the models. As I said before, we’ll have 3 table entities- Issues, Work Notes, and Users, and an enum value for Role. So, first off, an Issue class…

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.ComponentModel.DataAnnotations;

   4:  using System.Data.Entity;

   5:  using System.Linq;

   6:  using System.Web;

7:

   8:  namespace MvcIssueTracker.Models

   9:  {

  10:      public class Issue

  11:      {

  12:          public int IssueId { get; set; }

13:

  14:          [Required(ErrorMessage="A Title is required.")]

  15:          [StringLength(100, MinimumLength=15)]

  16:          public string Title { get; set; }

17:

  18:          [Required(ErrorMessage="A Detailed Description is required.")]

  19:          public string Description { get; set; }

20:

  21:          public int CreatedBy { get; set; }

  22:          public DateTime CreatedDate { get; set; }

23:

  24:          public int AssignedTo { get; set; }

  25:          public DateTime? LastUpdatedDate { get; set; }

26:

  27:          public int ClosedBy { get; set; }

  28:          public DateTime? ClosedDate { get; set; }

29:

  30:          public virtual User AssignedUser { get; set; }

  31:          public virtual ICollection<WorkNote> WorkNotes { get; set; }

  32:      }

  33:  }

Note that I dispensed with the convention of calling it “IssueModel.” It’s in the Model folder (and, therefore, the MvcIssueTracker.Models namespace). I went ahead and added my data notations as well, since I’ll need them eventually anyway.

One down, two (and a half?) to go.

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.Web;

   5:  using System.ComponentModel.DataAnnotations;

6:

   7:  namespace MvcIssueTracker.Models

   8:  {

   9:      public class WorkNote

  10:      {

  11:          public int WorkNoteId { get; set; }

12:

  13:          [Required(ErrorMessage = "Details are required.")]

  14:          public string Detail { get; set; }

  15:          public DateTime LoggedDate { get; set; }

16:

  17:          public int IssueId { get; set; }

18:

  19:          public virtual Issue AttachedIssue { get; set; }

  20:      }

  21:  }

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.ComponentModel.DataAnnotations;

   4:  using System.Data.Entity;

   5:  using System.Linq;

   6:  using System.Web;

7:

   8:  namespace MvcIssueTracker.Models

   9:  {

  10:      public class User

  11:      {

  12:          public int UserId { get; set; }

13:

  14:          [Required(ErrorMessage = "UserName is required.")]

  15:          public string UserName { get; set; }

16:

  17:          public string LastName { get; set; }

  18:          public string FirstName { get; set; }

  19:          public string Location { get; set; }

  20:          public string Password { get; set; }

  21:          public Role Role { get; set; }

22:

  23:          public virtual ICollection<Issue> AssignedIssues { get; set; }

  24:      }

  25:  }

And, finally, the Roles enum:

   1:  namespace MvcIssueTracker.Models

   2:  {

   3:      public enum Role

   4:      {

   5:          User, //The base user- able only to create issues and add worknotes

   6:          Developer, //User functionality + close issues

   7:          Manager, //Same functionality as Developer- listed differently for audit type purposes

   8:          Administrator, //Developer + Delete issues

   9:      }

  10:  }

So, a quick Save All, and a Build to make sure nothing obvious is immediately broken… And we’re done. A set of classes for our data model.

In the next installment, we’ll look at getting the DataContext set up, and begin building controllers and views.

ASP.NET MVC: A Journey

2011-05-13T17:08:00.000-05:00

Hello, Gentle Readers.

I'm going to try something new: a journey on which you're allowed to ride along- and encouraged to back-seat drive.

As a developer, it pays to keep my skills up-to-date; this is something my current support posting makes more difficult than it might otherwise be. So, I decided that I should add some actual web development to my repertoire, and share the journey with you.

I'll be using ASP.NET MVC3, with its Code First abilities, to design a very light-weight, overly simplified Issue Tracking system. This is enough of a departure from the MV3 Tutorials that exist through Microsoft's site to show that I actually understand what I'm doing, and close enough to what they've done that I can crib from their notes when necessary.

I'll be hosting the project (as I build it) on CodePlex as MvcIssueTrackerDemo.codeplex.com. Go there for the latest code, and feel free to post recommendations/bugs/comments both at CodePlex and here in my comments.

Now, the best journeys begin with some idea of the destination, and the most successful have some idea of the stops along the way. So, to do our best to ensure a successful demonstration, we'll take the time to define what we're doing.

The Destination: A functional, if overly simplified and not-at-all secure Issue Tracker. It should be able to accept new issues, close issues, add work logs, and provide user maintenance and some basic statistics.
So, first, we'll design the Entity model, then we'll go about tackling each of the Entities to get them to behave like we expect.

The expected steps:

Object Model
Set up the Project
Define the Models in code
Create both Controllers and Views for each model- one at a time
Prove it works
Over view of the process.

So, in this, the first post, it only makes sense to discuss the object model.

I see the three following "entities" and one enum: Issues, Work Notes, and Users round out our entities, and we'll add a Role enum to enable some role-based security along the way.

Our Issue Object will include:

IssueId
Title
Detailed Description (I'll just call it 'Description')
CreatedBy (the User Id of the user who logged the issue)
CreatedDate
AssignedTo (the User Id of the user to whom the issue is assigned)
LastActivity (a DateTime)
ClosedBy (the User Id of the user who closed the issue)
ClosedDate
A virtual User for the Assigned User
A virtual ICollection<WorkNote> for the work logs.

Our WorkNote object will be very simple:

WorkNoteId
Details
UserId
DateTimeStamp

Users will have:

UserId
UserName
LastName
FirstName
Location (A vague term- I'll probably use it a Cube/Office number or something)
Password (In a real application, this would be a password salt and hash)
Role
A virtual ICollection<Issue> for the issues assigned to the User.

In the next post, we'll go through setting up the project, and defining the models.

Negative Confirmation: Show Me the Code

2011-05-04T22:07:00.001-05:00

I’ve blogged the last couple of days about Negative Confirmation as a Sender of data. That is, I believe that the person or organization who sends a file should have some process whereby files expected to be sent are flagged when they fail to go.

To that end, I’ve mocked up a little something that will do just that. First, here’s an overview

1) An Interface ILogReader with a single (overloaded) method: ReadLog which accepts either a Stream or a string. This is to enable the reading of virtually any kind of data. It would probably need to be modified to read a DB, but since this was more in the nature of a Proof-of-Concept, I’m not too concerned about that.

2) A Class DelimitedLogReader which Implements ILogReader- for this PoC, I’m just reading a pipe-delimited file of my own design.

3) A Class LogEntry to define the structure of log entries. In real code, this should probably be a struct, now that I think about it…

4) Classes for handling the Scheduling- these need some work. At the moment, I have a class for the ScheduleConfigurationSettings (pulling from app.config- I tried some custom settings, but that wasn’t working and wasn’t worth pursuing for a PoC). I have a ScheduleMarshaller- which grabs the actual schedule data from app.config. Finally, I have a ScheduleResolver- the real meat of the solution- which compares the schedule as provided by the ScheduleMarshaller to the logged files provided by the DelimitedLogReader.

So this works like this: The application instantiates DelimitedLogReader and grabs the log entries from a file specified in app.config. The application then instantiates the ScheduleResolver which instantiates the ScheduleMarshaller to get whatever files were scheduled to be sent the previous day. The Resolver then compares the scheduled files to the log entries and provides a list of the expected files which did not go.

Here is ILogReader in its entirety

DelimitedLogReader implements ILogReader- you could do this any number of ways, here’s mine:

The ReadLog(string path) method just returns a call to ReadLog(Stream stream) by instantiating a FileStream based on the path provided.

Things get a little more interesting with the ScheduleMarshaller

The call to “translateToDayOfWeek” takes a formatted string from the ScheduleConfiguration object and then translates that as a DateTime.DayOfWeek. “translateToDate” takes the expected day and turns it into an actual DateTime object.

The Resolver then does the actual work:

With the list of strings “fileInError” you can then handle them however you want. In my case- for my PoC only, I just did a simple console application:

And there you have it- a more-or-less functioning Negative Confirmation process which will alert me as the Sender when I have failed to send a file.

In a real-ish scenario, I would add a module to the end of any process that sends a mission-critical file to write to the log the name of the file and the DateTime when it was sent. My Resolver would then run once a day- late enough that anything that hadn’t gone would be in error- and alert me (probably via email) of any files that didn’t go. Better- it would not send an empty email if there were no results- it would just quietly finish and wait for tomorrow’s run.

EDI Process – Positive vs Negative Confirmation: An Objection

2011-05-04T08:33:00.002-05:00

As a follow-up to yesterday’s post, and before I get to posting some actual code, I thought I’d address what I see as the most likely objection to my combined Sender Negative/Receiver Positive confirmation scheme. It is this: “We don’t like relying on a third party for our confirmation.” Or, put another way, “Our clients don’t expect to have to watch the process constantly, they just want it to work.”

Now, to my mind, these are good, solid, sales-person type answers. Unfortunately, so is, “Absolutely we can have this new major functionality that should take about 4000 man-hours to complete ready for you and in production by Tuesday!” So you’ll excuse me if I don’t give them too much credence.

However, as they are objections that will be raised, they should be addressed. And so we will, in two parts.

The first part is this: We’re not relying on a third party for confirmation, we’re providing the confirmation that makes the most sense for us to provide- if the other guy doesn’t do his, then he’s culpable for any fall-out of a failed process. For the Sender, this means making sure you’re aware of any file that didn’t go so you can get it out the door as soon as possible. For the Receiver, this means making sure the Sender is aware that you only got files X, Y, and Z- so that if you should have received W as well (and how would you know, for sure?) that they can send file W right along.

The second part is this: If a file is important enough that it being missed would be a “resume generating event” for someone, doesn’t it make sense to confirm every major step in the process has worked? And isn’t sending the file a major step in the process? Isn’t receipt of the file a fairly major step?
Ultimately, I find this objection (or variations on the theme) fairly weak. They assume that the only person who should have skin in the game is your organization. Partnerships don’t work that way, and when you’re working with EDI, even if one group is technically a “client,” you’re working much more as a partnership than you are as an employer/employee relationship.

EDI Concepts: Positive vs Negative Confirmation

2011-05-03T17:30:00.000-05:00

In EDI (the process, not as a file format), we are concerned with the delivery of data- often in some form of file. These files are usually automated, repeating processes which are delivered on some kind of schedule.

One of the perennial problems in EDI is how to keep track of what has been delivered. More importantly, most of the time, you have to keep track of what hasn’t been delivered. The problem with this, I’m sure you will agree, is that it is much harder to look at a list of items to see what isn’t there than it is to see what is there.

This causes a debate to arise- often between developer/EDI profession and end users- of what confirmation style one will use- positive confirmation or negative confirmation. Positive confirmation is when I, the receiver, tell you, the sender, that I have positively received a file with name XYZ. If I can include a record-count or byte size and a timestamp, so much the better. Negative confirmation is when I, the receiver, tell you, the sender, that I did not get file ABC which was expected in window DEF.

Both of these have their problems.

Negative confirmation is very, very difficult to achieve, from the receiver standpoint. A schedule must be established and rigorously maintained, and the entire process can be very brittle. Further, it puts the receiver on the hook for making sure the file is received, rather than making the sender responsible to ensure the file is delivered.

Positive confirmation, however, is often wasteful and ultimately useless. When a process runs almost every day exactly as expected, a positive confirmation process generates vast amounts of “confirmation” data that no one will review. However, for positive confirmation to be useful, those positive confirmation notices must be reviewed diligently every time they are received. No one, no matter how well intentioned, can do that for very long; eventually we just begin to see what we expect to see.

So, I suggest the following Confirmation process- Negative Sender/Positive Receiver.
In this process, the Sender maintains their schedule and is responsible for checking it. When a file is not delivered- for whatever reason- the Sender is alerted and can act. Once the file is listed as “delivered,” a confirmation should still be forthcoming from the Receiver to acknowledge actual receipt of the file.
This style of combined confirmation helps ensure that business critical files (such as invoices or other payment related files) are sent in a timely fashion.
Positive confirmation is very easy to establish, as a Receiver. Most modern FTP server packages allow for an email to be sent in response to a file received. Failing that, an application attached to a file watcher, or some kind of Messaging Framework or Service Bus can be used to detect a new file and send the appropriate notification.

Even from the sender standpoint, negative confirmation is still difficult. Telling a computer “Tell me what isn’t here” is nowhere near as easy as your users probably think it is. However, in a follow-up post, I’ll show some quick-and-dirty code which should point to a good solution for Sender side negative confirmation.

Testing and Debugging

2010-07-17T23:45:00.001-05:00

In this, the second follow-up post to my previous posting about a small project at work, I’m discussing issues that came up in testing and debugging.

First, click back on that older post (here). That’s okay; I’ll wait.

Okay, done?

Now, did you catch my problem? I didn’t until I ran against a specific scenario. What happens when there’s a blank line? In the case of my code, I got caught being too clever. I tried to edit out blank lines. My problem is that I added a “break;” when blank line was found. That made my “while” loop think it was done, and then left off anything after the blank line in that file.

Oops.

Then, I discovered something else. A requirement I had interpreted as “sometimes there will be blank lines” was actually, “Sometimes, in an otherwise populated line, you’ll receive UNIX nulls.” That’ll break a StreamReader. If someone knows a way to handle those in a StreamReader, I’d appreciate an email. However, I don’t know such a way, and so decided the best thing to do was just copy the bytes over. Then, since I’d be working with bytes, it wouldn’t matter if it was the UNIX byte that said “null,” it’s still a byte and would get copied over.

Looking for a way to do this, I turned to the ultimate in developer help: StackOverflow.com. Once there, I discovered, once again, that Jon Skeet is awesome. I’m not posting his code, since I mostly just added Exception Handling, and changed names so they fit my solution better, and basically used his code.

So, how did I discover these problems: Testing and Debugging. I know it’s a long way to have gotten to what is supposed to be the point of the post, but I wanted to show how much pain it saved me, since I would have pushed to production based on the fact I knew my code “functioned as designed.” The problem is that it would have been designed wrong.

Using the VS testing functionality (my client is on VS2005 btw), however, wasn’t enough. You see, my test passed when I ran it. However, I believe whole heartedly in having actual output that I can verify. Again, my code functioned as designed. It wasn’t until I opened up the test output that I found my problems with those blank lines.

So, three quick things about Testing your code:

1) Always Unit Test your code. Once I started making changes, I did start failing my Unit Test. If I’d only checked my output, I might not ever have known there were additional problems.

2) Set up Unit Tests which will test your assumptions as well as the code itself. I could have used only files with complete data in them to test, and I would never have found my issues at all.

3) Always provide yourself actual, verifiable output, whenever possible. If I hadn’t done just that, I would never have known about my problem at all.

An Explanation

2010-07-17T23:17:00.001-05:00

I posted a couple of days ago about a process we’re writing as a console application. Since I want this to be the highest possible quality code, I believe I should defend/explain the reasons I did things the way I did.

After that, there will be a couple of additional posts explaining some issues we encountered and how we corrected them.

So, on with the explanation…

As I see it there are two basic questions (feel free to send others, though). 1: Why a console app instead of a service? 2: Why chained streams?

Why A Console Application?

Because this is specifically requested as a temporary solution, and we were given an outer limit of days (45) that it might be needed, it didn’t make sense to do anything more complex than a Windows Service or Console application. This already feeds into a BizTalk solution, so we could have gone that route, or we could have created a WCF service that would get called somewhere, but those seemed overly complex for what is, in essence, an automated version of “CTRL+C" “CTRL+V.”

So, between a Windows Service and a Console app, they both have their advantages and disadvantages.

A service hooked to a FileSystemWatcher could merge the files at the moment the daily file comes in. Since the process that uses the merged file runs on a schedule, that could be a good thing, since we’d know that it was always ready to go when needed. On the other hand, if it fails, we would have to specifically look at the file location to verify that, and if we had to re-run the process we either have to re-drop the file or find some other way to get the service to kick off.

A Console application, on the other hand, has to be scheduled through the Windows Scheduler if it’s going to run as an automated process, and that means balancing the needs of running the merge early enough to be ready for the secondary process, and late enough to be sure we’ve got the file. On the other hand, if it fails, it’s easy enough to pull it up and run it manually or, even, pull up the solution in TFS and run it in debug mode (to catch what the error is). And, since it’s scheduled, we can know exactly when to check to verify it ran properly.

In the end, it was decided it was kind of “six of one, half a dozen of the other,” and my Programmer’s Virtue of Laziness said that since I was going to have to write a console app during the debug phase anyway, I may as well just keep it as a console app.

Why Chained Streams?

Really, was there another choice? I could have converted the streams to byte arrays, but that seemed overly complex for what we were trying to accomplish (turns out that was wrong, but I didn’t know that at the time). We’re trying to do the equivalent of opening one file, hitting “CTRL+A” then “CTRL+C”, opening a second file, hitting “CTRL+END” then “CTRL+V”, and then saving the merged file to a folder for an automated FTP process to pick up.

Reading the files and writing directly to a new, merged file, seemed to fit that need quite nicely (and would have, too, except for something I found out later).

So, there you go, there was our reasoning. Fairly simple and straight forward. If you have other questions, please post them in the comments. Maybe I’ll do another follow-up based on those.

A Hack solution Doesn't Mean Hacky Code

2010-07-14T23:12:00.001-05:00

Today at work we ran into a little situation with a currently running process. The process is fine, but one of the parts of the business feeding data to our BizTalk orchestration needed a change. For whatever reason, the requirements for a file that gets sent through BizTalk had changed such that the file would be much, much bigger. The business unit responsible for that file said they couldn't supply the whole thing new every night (the current required process) because it would kill their other processes. What they proposed was to send one static file (old data that has to be sent every time) and then they would send the rest of the data (which changes) in the current daily process.

This left us with a bit of a quandary. Since the current Orchestration looks for two files (the one from this unit, and one from another) adding a new file would cause us to have to re-write the Orchestration (which would mean un-deploying it, then re-deploying it). This was a non-starter because this requirement should only be in place for a month or so, and then we'd have to go back to the old process.

So, the decision was made that we would take the static file, append the daily file to it each night, and then send it through the current process (now a single file) as normal.

I was tasked with creating the code that would do that. After a brief discussion with my team mates, it was decided we'd use a Console Application which would be called by the Windows Scheduler. We considered a Windows Service, but opted for the Console App because we can see the possible need to run it manually.

So, even though this is a hack process for a hack requirement, I decided that my code should be the highest possible standard- partially for personal and professional pride, and partially because no "temporary" requirement ever really goes away. So, with error checking removed (since that's a custom thing for my client), here are the basic guts. I, personally, think it's good, but please feel free to fire away with any problems you see...

   1:  public class FileMerge

   2:      {

   3:          public string StaticFilePath { get; set; }

   4:          public string DailyFilePath { get; set; }

   5:          public string MergedFilePath { get; private set; }

   6:          public string FinalFilePath { get; private set; }

7:

   8:          public FileMerge() { }

   9:          public FileMerge(string statFile, string dailyFile, string mergedFile, string finalFile)

  10:          {

  11:              StaticFilePath = statFile;

  12:              DailyFilePath = dailyFile;

  13:              MergedFilePath = mergedFile;

  14:              FinalFilePath = finalFile;

  15:          }

16:

  17:          public void MergeAndDrop()

  18:          {

  19:              FileInfo mergedFile = Merge();

  20:              if (mergedFile != null && mergedFile.Exists) Drop(mergedFile);

  21:          }

22:

  23:          private FileInfo Merge()

  24:          {

  25:              using (StreamWriter sw = new StreamWriter(MergedFilePath))

  26:              {

  27:                  if (File.Exists(MergedFilePath)) File.Delete(MergedFilePath);

  28:                  using(StreamReader staticReader = new StreamReader(StaticFilePath))

  29:                  {

  30:                      while (staticReader.Peek() != -1)

  31:                      {

  32:                          string line = staticReader.ReadLine();

  33:                          if (!string.IsNullOrEmpty(line.Trim())) sw.WriteLine(line);

  34:                      }

  35:                  }

  36:                  using (StreamReader dailyReader = new StreamReader(DailyFilePath))

  37:                  {

  38:                      while (dailyReader.Peek() != -1)

  39:                      {

  40:                          string line = dailyReader.ReadLine();

  41:                          if (!string.IsNullOrEmpty(line.Trim())) sw.WriteLine(line);

  42:                      }

  43:                  }

  44:              }

  45:              return new FileInfo(MergedFilePath);

  46:          }

47:

  48:          private void Drop(FileInfo fileToDrop)

  49:          {

  50:              fileToDrop.MoveTo(FinalFilePath);

  51:          }

  52:      }

File Scrubbing – whether you want to, or not

2010-07-09T23:30:00.001-05:00

As an EDI guy, I’m supposed to get to work in industry standard formats. Since I mostly have done healthcare in the past, this primarily means the ANSI X12 4010A1 standard. However, in the real world, the standard doesn’t mean much.

There are clients with proprietary formats, vendors with old versions of the standard, and just plain screw-ups that we deal with on a day-to-day basis.

So, with that in mind, I bring you the first in a new occasional series of posts: Public Code Review. The following code is a scrubber I created to handle known, recurring issues with client and vendor files. It uses Regular Expressions to find said known issues, and can either just remove them, or replace them.

First, I created two Interfaces: IScubber, and IConfigurable. IScrubber is the interface which will do most of the work; IConfigurable just allows anyone else who wants to use this code to use their own configuration to set it up.

   1:  interface IScrubber

   2:      {

   3:          string Scrub(string original, string match);

   4:          string Replace(string original, string match, string replacement);

   5:      }

   1:  interface IConfigurable

   2:      {

   3:          void Configure();

   4:      }

Next, comes the class ScrubRule. This simply holds two strings: the Regex to match the errors, and the replacement string.

   1:  class ScrubRule

   2:      {

   3:          public string Match { get; private set; }

   4:          public string Replacement { get; private set; }

5:

   6:          public ScrubRule(string m, string r)

   7:          {

   8:              Match = m;

   9:              Replacement = r;

  10:          }

  11:      }

With our base items created, I can now create the actual scrubber. In this case, I’ve called it “BasicScrubber.” It implements both IScrubber and IConfigurable.

   1:  public class BasicScrubber : IConfigurable, IScrubber

   2:      {

   3:          private List<ScrubRule> rules;

4:

   5:          public BasicScrubber(string configPath)

   6:          {

   7:              rules = new List<ScrubRule>();

   8:              Configure();

   9:          }

10:

  11:          public void Configure()

  12:          {

  13:              foreach (string s in ConfigurationManager.AppSettings.AllKeys)

  14:              {

  15:                  ScrubRule sr = new ScrubRule(s, ConfigurationManager.AppSettings[s].ToString());

  16:                  rules.Add(sr);

  17:              }

  18:          }

19:

  20:          public string Scrub(string original, string match)

  21:          {

  22:              Regex rx = new Regex(match);

  23:              return rx.Replace(original, string.Empty);

  24:          }

25:

  26:          public string Replace(string original, string match, string replacement)

  27:          {

  28:              Regex rx = new Regex(match);

  29:              return rx.Replace(original, replacement);

  30:          }

  31:      }

As you can see, the scrubber gets it’s configuration (in this case) from the System.Configuration.ConfigurationManager class pulling from app.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key ="RegexHere" value="ReplacementValueHere" />
  </appSettings>
</configuration>

So that if we replace “RegexHere” with the Regex: (?<=\.\d*)0+(?=\D|$)

and if we replace “ReplacementValueHere” with “”

we get a scrubber rule which will trim trailing zeros after a decimal place.

Wire this class up to a windows or console app, point it at your file in error, and let it go.

One of the great things about Regex is its speed at just this kind of process. Before I started using Regex, I tried using basic string manipulation with string.Replace(). The problem is that when you start playing with special characters, or if something is off just a little bit, string.Replace() is a little unreliable for my tastes. Additionally, it’s slow. Running string comparisons and manipulations against a normal X12 835 file used to take a couple of minutes. With Regex, it’s seconds. As in, two or three, not thirty or forty.

So, let me know what you think. This code should be highly portable. Without much effort, it can be database driven instead of app.config driven, or you can even configure in some custom way.

How to Cure Insomnia

2010-07-08T20:19:00.002-05:00

Read technical documents for 8 hours straight. I've been at the client site for almost a full week now (technically, I guess it's a week's worth of days, but Friday before a three day weekend does not count), and I've been waiting for my system access to come through. Because of that three day weekend thing, it's been a little slower than it would otherwise have been so I haven't had much to do. What I have had to do is read technical specifications. And project plan documents. And more technical specifications. I'm sure it will get much better tomorrow or Monday (I should have all the access I need by then) but for this week, it's been like fighting narcolepsy...

Changes

2010-07-03T09:30:00.002-05:00

This week I left my position at ESI for a new position with Sogeti USA's Irving office. I am now a consultant with Sogeti- my first gig will be providing BizTalk support while the current lead on that project goes on vacation for a month. It should be a good way for me to get some more in depth knowledge of BizTalk with people who know more than I do about its practical capabilities. I'm looking forward to the new adventure. I leave the folks at ESI without regrets, but certainly with fond memories. ESI was my first "real" development position, and I will always be thankful for the opportunity I was given there. The whole team were "good people." And, if you're from Texas, you know there is little better praise than that simple phrase. So, as I begin the next phase of my journey, I say "thank you," to Jeff, Milton, Kim, and the gang at ESI. Thanks for the opportunity. Thanks for letting me learn. Thanks for the memories.

When to say "No."

2010-06-15T23:45:00.003-05:00

Okay, let's be honest. Sometimes, as developers, we have to say "no." Sometimes the case for this is clear. Something like the following: Business Process Owner: We need an application that will do your thinking for you! We can call it the AwesomeApp!! Developer: No. Other times, it's less clear. Say, when you're developing a new business application, and one of the stakeholders wants to change something fairly trivial because it would be easier for them "right now." For instance, take a situation at my job. We have a database to store records relating to medical insurance eligiblity requests. One table holds the actual subscriber (insured) information. Each subscriber gets two records: one for the request, and one for the response. The way the process is designed, there is some information that goes out on the request which is stored with the request. Some of that information can come back differently on the response- this information is housed in the response record. Some of that data cannot (according to industry standards) be changed, so we decided not to store it on the response record. Since the data structures are sufficiently convoluted to require multiple joins to get any useful data anyway, we decided one additional join wouldn't hurt anybody. Also that storing redundant data is kind of silly. One of the BPEs wants that duplicate data in the response record so that a "basic 'What happened to account so-and-so" query won't require joins. Normally, I'd say "Okay" and make the change. In this instance though (again, due to the convoluted nature of the data we send and receive) a received record without it's sent counterpart (and, for that matter, related records in other tables) has absolutely no context and would be worthless even for those "basic" querries. So, I said "no." I will continue to say "no" until over-ruled. What about you, readers? Am I way off base? What are your "Just Say No" stories?

Lambda Expressions - The Shuttle _Tidirium_ of .NET

2010-04-28T15:35:00.003-05:00

Actually, I just said that 'cause I wanted to get my Star Wars geek on. Today I ran across this article while trying to wrap my head around lambda expressions. I was trying to wrap my head around lambda expressions because they're cool (that is, useful and geeky). So, to sum up the artical (without using his example) let's look at some code I just modified to use Lambdas. Old Code:

User u = (from u1 in Users where u1.UserName == userName select u1).First(); CurrentTicket.Reasign(u);

New Code:

CurrentTicket.Reassign(Users.ToList(). Where(u => u.UserName == userName).First());

As the article points out, these are really saying the same thing. The Lambda Expression is just more concise.

Remittance Headaches

2010-04-22T23:51:00.003-05:00

For those of you who've worked with X12 835 Remittance documents, you may know my pain. Some time ago at work, I was tasked with finding a more efficient way to handle remittance advice documents for our clients. Since I like BizTalk, I figured this would be a good time to prove its abilities, and I got to work. In short order, I was able to write the remits to a set of tables. With one, teensy problem. BizTalk is (necessarily) unaware of Database relationships. Using the WCF LOB Adapters for BizTalk worked for blowing the information into the DB very quickly, but I couldn't find a way to maintain referential integrity among the tables. Eventually I decided on an "organic key" made up progressively larger strings as one walks down the tables. So, for instance, a Claim Group (LX, TS3, and TS2 segments) would refer back the check on which they're found by using a string made up of the ST02 segment and the Check number. A Claim Payment record would refer back to the claim group by adding onto it the LX identifier and so forth. This works very well, actually, and if I know exactly the check number I want, I can find it very quickly. However, this doesn't actually take care of all of our problems. Those pesky end users want -gasp - to be able to search for remits by Patient! or Provider! What are they thinking?!?! So, I have to fix my database. But how? I mean, I still haven't found a way for BizTalk to keep that referential integrity for me, and having BizTalk pass the 835 to a .NET application kind of defeats the purpose, so what to do? Barring some divine (or reader) intervention, I've settled on this: I'm writing a .NET application which will bundle up remits at the batch level (that is, i have batch object which contains my batch data as well as a list of check objects, which, in turn, hold my check data and a list of claim group objects, and so forth). Once that is done, I'll write the records into a new database (probably nightly?) in a fashion which can be aware of record identities and referential integrity. Please, if anyone has a better option, email me or leave it in the comments- it would be a God-send.

XML: Nillable="True" vs MinOccurs="0"

2010-04-20T09:54:00.004-05:00

This came up at work today, as a coworker was strugling with a WSDL for an outside vendor. I only knew it because BizTalk runs into exactly this kind of error occassionally. The situation is this: A WSDL is defined with several elements. Let's use this for an example:

What you see here is a bunch of elements in an which my coworker is trying to show as null by not including. That is, when, for instance, "address" is null, it simply will not exist in the XML document. Here's how the same code looks as our vendor expects it.

Now, leaving aside the question of why the only way to pass data to the web method is allowed to be null, we can see that the vendor's wsdl expects the nodes to exist. Therefore, instead of simply leaving out "address" the XML document should contain a node like this: <> It makes sense when you think about it in terms of code as well. How many times in C# do we pass something like "foo = new foo(new bar(), null)?" Is there any question that this is different from "foo = new foo(new bar())"? Not really. (At least, not until C# 2zillion when Microsoft decides that any parameter which can accept a NULL is automatically an optional parameter.) I did manage to help steer the coworker in the right direction, and provided him (as I am you) a pretty good synopsis on this whole thing from IBM's website. Link here. (http://www.ibm.com/developerworks/xml/library/ws-tip-null.html) So, in summary, pay attention to your WSDL and Schemas. Nillable is not the same as MinOccurs="0".

MS .Toolbox

2010-04-07T22:41:00.002-05:00

I've been working my way (slowly) through Microsofts new http://www.microsoft.com/design/toolbox/ site. For anyone who wants to know more about UI design (which should be every Mid-tier and back-end developer everywhere), it's a really good resource. But it brings me to something I see to much in the developer world: the idea that if the "functionality" works, UI doesn't matter. "Just give 'em a button" seems to be the mantra all too often. My take on it, however, is this: If the User can't make it do what it's supposed to, or if the user decides the old way was easier than your new way, your program doesn't work. The UI is how the users interact with your functionality; if it's not good, then it's bad. There is no middle ground. With WPF and Silverlight, this consideration has become much easier to handle. Simply implement INotifyPropertyChanged on your Business Layer objects, and then use MVVM to set up the UI. However, for people not using WPF or Silverlight, some consideration has to be made at design time for how the UI will look. If you'll be populating a ListBox control, you probably need a collection of some kind, for instance. This is a place where I've fallen down in the past, and I plan not to do so any more. You should make a similar pledge.

WCF WTF: Update

2010-04-06T08:44:00.003-05:00

I attempted the solution I discovered yesterday when I got into work this morning, and it wasn't working either. I did a little more research and discovered that, for WCF to work with Streams, you really need to pass them via a BasicHttpBinding. As I'm not that great at WCF yet, I've been using the default WSHttpBinding that Visual Studio creates when you add a Service Reference. I didn't really want to spend too much more time working on this- we were already getting to the point of "diminishing returns." So I decided to take stock of where I was and move forward. The OperationContract was defined as a Stream output with a Stream input. However, since I know that a Stream is really just an Array of Bytes, I decided on an alternative approach. I created a new OperationContract (called DecryptBytes) which accepts (and returns) an array of bytes. Then, in my .svc.cs file, I created the new method which really just changes the bytes into a MemoryStream, and then hands the memory stream to my original method: public byte[] DecryptBytes(byte[] inStream) { MemoryStream _iBytes = new MemoryStream(inStream); MemoryStream _oBytes = this.Decrypt((Stream)_iBytes) as MemoryStream; return _oBytes.ToArray(); } So, for 5 lines of code (including the Attribute Tag in the Service Contract, and the Method declarations) I was able to correct the issue. I feel a little silly that it was that hard to figure out, but I'll chalk it up as "lesson learned" and archive it here in case I need it again...

WCF WTF

2010-04-05T22:37:00.003-05:00

So, I have a WCF Service I created to handle PGP encryption/decryption using the BouncyCastle .dll. We wanted just the one, internal, service so that everyone who needs to be able to decrypt data can without having to ask the developers all the time. This service receives and passes streams of data. Unfortunately, I did not realize that this doesn't actually work real well in WCF. Unless I can find a way around it, WCF changes my nice FileStream or even just a base Stream and hides it in a System.ComponentModel.Dispatcher.StreamFormatter (from memory, so that namespace may be a little off). Which is not seekable. My service requires a seekable stream. I'm sure you see the problem. I didn't discover this little gem until about time to go home today. So, tomorrow I'll write a nice little wrapper around the stream that gets passed into the service so I can treat it as a normal stream. I'll post the code here when that's done, so I'll have it someplace relatively safe.

AWOL

2009-08-26T22:49:00.004-05:00

"So," I hear you asking, "Where have you been for three months?" And I answer, Nursing my wife through the last two months of pregnancy, and welcoming my second child (Emily Marie) into the world. So I've had more important things on my mind than this blog. I'll be getting back to the "regularly scheduled" stuff pretty soon, but I wanted to go ahead and chart out some of what I'll be posting about in the next few weeks so I don't forget. So, here's the list: * BizTalk 101 * Pipelines * Adapters / Accelerators * Basic Architecture * EDI 101 * Internal Standards * External Standards * SOP * New work project So, here's hoping I'll be able to get this back up and running...

Well, Gee...

2009-06-09T22:01:00.002-05:00

So, at work I've been trying to get a BizTalk solution together- both to alleviate some actual pain points and as a 'proof of concept' and it's been a real pain in the donkey. It took much longer than it should have to get BizTalk installed and configured, but we finally did it, and now I'm actually coding the solution. Yipee for me. Mostly it's going ok, but I keep running into things which make me wish (again) that I had some kind of formal training. I'm sure these questions are basic, BizTalk 101 type questions, but I can't find the answers anywhere- or, at least, not illustrated well enough to teach the concept. So, dear reader, I'm wondering if you can help me. Below is my list of "Man I wish I knew" for BizTalk:

how to: evaluate the inbound filename of a file and make a decision based on that
how to: establsih and use a Send Port Group
if multiple send groups are necessary for different types of send ports (e.g. SQL Adapter vs. FILE)
best practice for sending results to SQL for update, and archive file to seperate folder.
how to: use SQL Send Adapater
how to: set up SQL Stored Procedure to INSERT or UPDATE DB instead of only querying
how to: Configure a .NET assembly/class for use with BizTalk and call it from an orchestration

A Call to Excellence

2009-05-30T23:49:00.003-05:00

DISCLAIMER: This will be one of my Political Opinion posts. If you're not interested, then don't read it. If you are, and I upset you, I'll be more than happy to trade emails. You have been warned. ************************************************************************************* For the last decade or more, some in our country have attempted to make America and Americans to be less than we are. One in particular speaks of "American Arrogance" and says that we "are one nation among many." I call B.S. Among the nations, America alone has stood as the defender of all men's rights to liberty. Even when we do not act directly to secure it, we do not deny it's existence, and lend what support we are able. Twice in history have we stood up to Evil when we could easily have stayed at home. In WWI, we had no legitimate reason to go to war. One passenger ship was mistakenly sunk by German forces. But we, who had been looking for an excuse, took it. In WWII, the only nation we had reason to fight was Japan: we focused on them second. Instead of spending our considerable might crushing the Japanese, we sent innumerable troops to shed their blood once more on foreign soil fighting for the rights of Europe. We have spent our blood, our sweat, and our treasure to secure freedom, liberty, and hope for as many as we can. Domestically, we have advanced the human condition to such a point that humans are free to believe that animals are more important than we are. Health care is such that any person can get immediate, life saving care with no thought to their ability to pay. People by the millions brave dangers we can hardly imagine- literally risking death- to come here; and the vast majority of those are willing to come and settle for a less-than-second-class existence because that is better than their "middle class" existence in their home countries. Despite all this, we are told that we are arrogant, not excellent. We are told that we are "one nation among many," not "the bright, shining City on a hill." My fellow Americans, I call once more for American Excellence. Our country was founded on the idea that free persons, pursuing their passions without government interference, could become the best place on Earth. Despite this, there are those who wish us to cede more and more of our freedom in the name of security. We are told that only the Great-and-Powerful Federal Government can save: our banks, the car industry, our health care, and even our own computers. This is the same Federal Government which has: bankrupted Social Security and Medicare, instituted policies which encouraged and(by one interpretation) required the banks to make loans to people who could not afford them, encourages sloth and indolence by rewarding them through welfare programs, and has usurped the rights of "the several States, and the people." So I call for Excellence. I call for "We, the People" to stand up and say, "no more." We can take control of our own destinies, and we can succeed in anything we wish. To do so, we must no longer assume that those who "have not" are victims. Calling them "victims" denigrates them and makes them less than us. They, too, are free Americans, able, by the fruits of their labor, to overcome obstacles and to succeed in life. Do not enslave them to the state by saying they are unable to care for themselves, and do not enslave the rest of us by saying we must care for them. To be free means to be responsible for oneself. It means taking chances and risking failure. Liberty means that what I work for is mine. It means the Government does not interfere with my life any more than necessary for any reason. Most of all, Freedom and Liberty mean that all men are truly equal in worth, and equal in opportunities. Freedom does not mean a right against being offended. It does not mean that I do not have to worry about my next meal. Liberty does not mean that I will be cared for. It does not mean that I will never be worried. Most of all Freedom and Liberty do not mean that others must work so that I can live well. To find your worth, go and be excellent. Find what you do best and be the best. Don't let anyone tell you that you are unable to succeed, and, most of all, when you fall down, pick yourself up, dust yourself off, and keep trying.

X12 != EDI

2009-05-27T21:20:00.003-05:00

I had a brief discussion with a friend about this, and I think I need expound on the subject a little. In the world of Development, if you say "EDI" people automatically assume (in America) ANSI X12. Some of the more enlightened also consider EDIFACT (for our European counterparts) and HL7 (healthcare). I'm here to explain that none of these are, in fact, EDI. Yes, you read that correctly. ANSI X12, EDIFACT, HL7, and Joe-Bob's Custom Layout all share one thing in common: they are file specifications. EDI goes far beyond file specification and, in the original sense of the term (first widely used by Financial institutions, IIRC), doesn't really care about format at all. EDI is, litteraly, "Electronic Data Interchange." EDI is much more concerned with parties and transport than it is with specific layout. Indeed, my trading partners and I can choose any layout we wish - including making up our own - and we'll still be doing EDI. As long as I'm sending and receiving electronic data (in the old, CS101 sense of "raw facts given to the computer") with one or more external parties, I'm doing EDI. Now, why is this important? I don't guess it is really. On the other hand, I believe it will become increasingly important, with the myriad of file specifications in addition to transport specifications, for the demarcation to be clear. AS/1, 2 & 3 are EDI. ANSI X12 is not. FTP over SSL or SSH is EDI. EDIFACT is not. HTTPS is EDI. HL7 is not. This demarcation becomes important because there is so much to know about each world. I'm one of those who still gets FTP/SSL and FTP/SSH confused. I certainly couldn't tell you the difference between AS1 and AS2. On the other hand, I can explain in detail why I prefer XML or Looped files (Such as the X12 standard) over Fixed-Width or delimited (Comma, Tab, or otherwise) flat files. I can explain why, if I must have a flat file, I prefer delimiters to fixed-width. I do not prettend that those who can explain the difference between AS1 & AS2 are not EDI professionals. I recommend that you not do so either.

BizTalk 101 - Installment 1 - HIPAA EDI

2009-05-20T22:18:00.004-05:00

As I mention in my bio- I'm new to this. And one thing I've found is that it is very difficult for newbies like myself to find information that everyone else 'just knows.' So, fairly frequently, I'll be posting some of these 100 & 200 level tidbits, in case some other young developer comes along and says "That's great! But how do I get from nothing to that point!?" So, the first installment has to do with HIPAA. I work for a Health Revenue Cycle Management company, so we do a lot of HIPAA EDI (ANSI X12 837, 835, etc.). For one particular client, we don't actually do anything with the files we receive except forward them on, but we do need to know what's in them so we can log them properly. Now, for any normal implementation, that would be no big deal: the filenames would follow some standard which could be used, or the ISA 05/06 & 07/08 information would be sufficient, or whatever. Oh, no. That would be too easy. Anyone already in the HIPAA EDI world may know that Medicare and Medicaid often use Third Party Administrators - sometimes including normal, commercial insurance companies - to handle their claims processing. This can mean, in the right circumstances, that a file comming from, say, CIGNA, might actually be full of Medicare claims. This prevents us from just using the ISA sender/receiver information. Instead, we have to parse out the entire file, just so we can read the first instance of a Patient level NM109 for the Insurance member Id to determine if this is a Medicare or Medicaid file, or if this is really a commercial payer. Luckilly, BizTalk is our friend in this. And this is where that long lead-off gets to some BizTalk 101. I spent the last couple of days trying to figure out how to get BizTalk 2009 to parse out those records. I knew that my friend Tim Rayburn (http://timrayburn.net) had addressed something similar, but it took me a while to find (in his blog, no less). The secret, as is said in Kung-Fu Panda, is that there is no secret. The entire process is 7 steps. 1) Open your BizTalk project (a new one, in my case) 2) Locate the HIPAA maps (harder than you'd think- look for a self extracting zip file burried in the BizTalk folder structure). 3) Add the necessary maps to your project. 4) Deploy the project. 5) Create/Configure a Receive Port & receive location. 6) Create/Configure a Send Port. 7) Restart the BizTalk application. There are a whole lot of specifics that are left out here. But this should be enough to point anyone in the right direction to get such a thing up and running. Tim calls this "From zero to Claims Processing in 15 minutes or less."

Windows Services in C# (.NET Framework 3.5)

2009-05-20T22:10:00.003-05:00

Okay... maybe I'm just completely mis-remembering, but IIRC, when authoring a Windows Service in C# 2.0, there was a nifty 'Installer' class you could just add to your project that would be nicely configured for you. You'd have to set the service name and a few other things, but, other than that, you could just build your application and install via MSI or (as I normally did) through InstallUtil.exe. I guess the guys in Redmond decided we were too lazy, though, because I and two of my buddies at work (both rather more experienced than I) spent most of yesterday and a fair deal of time today figuring out why we couldn't get a @#*&%# service to install. We kept getting a strange error message: "No Public Installer with RunInstallerAttribute.Yes was found." We [SEARCHENGINE]-ed the message and we kept getting posts talking about setting up the installer class, but that wasn't good enough for us. "Who wants to know how to do that by hand" we said. Apparently, anyone using Visual Studio 2008. For the life of us, we couldn't find the prebuilt installer. So, because I'll forget if I don't have it listed somewhere... You must create your own Installer Class (which must inherit from Installer) to install a Windows Service created in VS2008. If anyone knows of an automated way to do this, I'd appreciate the comments...

Console.WriteLine("Hello World!");

2009-05-07T21:07:00.002-05:00

Does anyone get really bored by that statement? I never really understood how it was supposed to be an introduction into programming... So, welcome to my blog. Don't mind the mess, it's still under construction. This is the first post, so I'm not going into too much depth. I've been developing in C# for the last couple of years, but just got my first "real" gig, so I figured I'd share as I got deeper into the world of programming. I'll probably also post questions here, occassionally, so feel free to chime in if you have answers or comments. Besides posts about C# and BizTalk, you'll occassionally see political and/or religous posts. I'll try to put a nice disclaimer on those so if you find yourself thinking "shut up and code!" you can just ignore those posts and go on. So, with that, I introduce you to EDI-fication, and hope you'll learn as much as I do.