I thought that was a word when I first wrote it. But I was thinking about other words like curmudgeon or something. Anway...


A set of big projects came along in work that consisted of some of the same pieces, in a high level of thinking. Get data from a service, store it in a database, generate html based on the data. I guess it doesn't matter that HTML is generated. Generate formatted output based on the data. That's better.

The services are not consistent in their details. One was a WSDL Web Service, one is a JSON service, and two are just schemaless XML. This part was pretty annoying. Schemaless XML and JSON need to go away. We are in 2018, the dynamic typing experiment is over ;)  (that's sure to ruffle some feathers).

When looking over the data that was coming back, 2 responses returned types that have 130+ fields in them. This would have to be represented in a SQL Table, in stored procedures, in a C# class and interface. Looking over 130+ fields, I immediately thought there's no way I'm typing all of that by hand.

A really lazy person (like me) would probably try to use a text editor with regexp find/replace functionality, copy a list of the fields in and run regexp find/replace to format it in the way that I would need it at that given moment. Like, in a list of parameters to a stored procedure, or as a list of parameters to a constructor, or generating properties on a POCO (plain old C# object). I am definitely lazy, but I'm also too lazy to do that each time.

A championship caliber lazy person (like me) would probably write CRUDGEON.  I also don't know why I keep doing it in all caps. "crudgeon" is equally acceptable for those who's caps lock and shift key are just too far away.

So what is it?

Basically, you give it a fake C# list of properties, and it'll generate whatever you need it to. Right now it'll generate:

  1. Database Table
  2. Stored procedures for Get, Update, and Delete
  3. C# objects with appropriate attributes for pulling data from services, like XML attributes, JSON "DataMember" and "DataContract" attributes, and so on.
  4. A convenience "map" script which does the copy from a service object to your POCO, in the case of WSDL objects where you don't want to have the WSDL generated type available to everyone, and hence depended on by anything except what you control (I always do this by the way... never expose WSDL types, they should only be internal. But I digress).

The has a lot of info on using crudgeon. It also has example inputs and outputs within the git repository itself. I wrote it for these specific projects in mind, and the generated C# code has references to things I wrote specifically for these projects, but if I come across any other project that needs to courier data and store it locally, I will definitely be broking open the ol' VS Code again. I wrote sqlrun in conjunction with crudgeon because I needed a quick way to run all those SQL files it was generating. I've used it hundreds of times in the week since. After testing, I'd find that I'd need a new attribute, or a column needs to allow null, or something. And I'd regenerate all of the code, run sqlrun at the SQL that was generated, and begin importing the code again, all withing like 10 seconds of each other.

Maybe you'll find some use for it. I know I definitely will. Like I said, it was definitely written with these sets of projects in mind, but with little modification, maybe they can be used more broadly. Or maybe with no modification! I'll know later when I find an excuse to use it again :)

Happy Coding!

Grunt Work Principle

One word that I've used to describe my work style, but not really my programming style, is "lazy". This can be a word that describes behavior that is often considered detrimental. Non-flattering.

However, in the programming world, it is a very good trait, if employed with other proper attributes. Like, being a bad programmer and lazy isn't good. But being a decent programmer with good work ethic and lazy is actually pretty good!

Lazy definitely doesn't describe my work ethic. Lazy describes how I am when confronted with grunt work. I have been trying to describe it with a principle or some other short definition. Out of pure laziness and lack of creativity in general, I'll call it the "Grunt Work Principle". You can feel free to put my name in front of that. I couldn't be bothered to.

Grunt Work Principle

If the amount of grunt work presented exceeds 1 minute, and the grunt work can be automated, no matter how long the process to automate, it will be automated.

In practice, this will take the form from anything like my last post on Sitecore Doc, to something simple like taking 100 lines of short text and compacting them to 100 characters per line. For that compacttext project motivation in particular, each time I would have to do it would not exceed 1 minute probably, but easily add up all the times I've had to do it and it's in the 3-4 minute range :)  That project probably took me 1 hour total to create but it can be used indefinitely.

There is no upper limit on the amount of time automating will take. There is only the restriction of whether it can be automated. For instance if it requires human interaction or things that aren't so easily determined by a computer alone. Even then I'd probably find a way to automate as much as I can. For instance, with the Sitecore Doc project, I could automate getting items and renderings from Sitecore, generating output, but at the time (and I plan to integrate source-d into my workflow) I could not easily figure out a way to map method calls to renderings. So that part I had to do manually, which was a few hours worth of grunt work. Oh believe me, tracking calls to methods is grunt work when all you are doing is producing documentation!!

Benefits of Automation

Future re-use: The top reason to always automate the current task at hand is for future re-use. You may initially very specifically automate for the task at hand, but then in the future find a way that you can re-use that but with small modifications. Or even a complete rewrite. Or completely as is. This is all fine.

Consistency: Automating will produce consistent results. In my compacttext example, the output is predictable. If I specify 100 line length in that example, the same input will produce the same output 100% of the time. If a human were doing it, there's no guarantee as eyeballing the line length can skewed by things like screen size, font size, caffeine consumed, etc.

It is usually too soon to optimize, but wtf are you waiting for with automation?!  Get to it!!