Tuesday, December 4, 2012
Even though the initial release is out, there's still work to be done. I had to backlog a couple of features to get the 1.0 version online faster. I have 4-5 ideas on the Issue Tracker right now, and am hoping for a few more as more people use it; I am all ears on any ideas or issues you might have to share. In the meantime, I'll be working on the existing ideas, and plan to release a new version every 4-6 weeks or so. I probably won't post any more version announcements here, so be sure to check the CodeProject page for future updates.
Hoping the app is helpful addition to your toolbox!
Thursday, November 15, 2012
Why did I start the project? Well, partially because I've wanted to work on an open source project for a long time. But even though I consider myself to be a "big picture" person, it's been hard for me to come up with an idea that hasn't been done a dozen times already and can be accomplished within my limited timebox for recreational coding. Beyond that, it solves a problem I've personally experienced.
A couple of weeks ago, I read a great article from the crew at 37signals about a new tool called 'sub' that they came up with and shared on GitHub. Basically, it's a small set of bash scripts (Unix stuff, if you're not familiar) for managing all of the scripts their teams were creating to help manage and support their environments, and really just simplify and standardize common tasks. As Nick says in the original post:
"When I started my on-call shifts, we had pretty little in the way of automation for day-to-day issues. Tasks like SSH’ing into our cluster, starting a Rails console, or doing a deep search through our gigantic mail directories, were either shelved away in someone’s [personal folder], history log, or just ingrained into someone’s memory. This pain was also felt by a few other of my fellow programmers ... The secret to automation was simple: convention, and sharing. From one command, we can run a report for a customer ... , open a repo in [source control] ... , or even search across gigabytes of log data to hunt down a bug ..."Wow, what a cool idea! As a developer and manager, I have seen this same thing on every single team I've worked with. Everyone on the team has a few really cool tools / utilities they've come up with to solve problems, but they aren't easily accessible to the other team members. Not intentionally of course, but just because there isn't a good way to collect, standardize and share them. My goal with 'wsubi' is simply to make a similar tool for other Windows / .NET users.
Anyway, I'd greatly appreciate feedback and suggestions on the project. The Documentation tab of the CodePlex site contains the base feature set, and there are a few to-dos on the Issue Tracker already that I plan to add in after posting an initial release. Hopefully this give you a sense of where I'm going with the project over the next few weeks.
I've had alot of fun working on the project so far, and am looking forward to announcing the initial release here in the not-to-distant future.
Sunday, October 28, 2012
- Fall in Wisconsin means 2 things: lots of extra yard work before winter (cleanup, raking leaves, grass seed / fertilizer, cleaning gutters ...) and Packers season. In fact, I'm watching the Packers try to eek out a win right now against the Jaguars, after having spent the morning raking my yard. Long story short, the extra day of chores and 3+ hours of football eat heavily into my weekly blogging window.
- I started working on a CodeProject sample and article on how to "Make your own simple web widget", which I was planning to tie a blog post into. I spent a bunch of time researching, coding, testing, etc. on the project, only to find a great example by Alex Marandon on how to do it just as I was writing my first draft. Frankly, his example worked better than mine, so I bookmarked it as a reference and moved on (albeit a little disappointed).
Hopefully you'll keep checking in - lots of cool stuff to come!
Saturday, September 1, 2012
I recently had need to dust off an old VB script I'd written years ago to get worksheets out of Excel files. I've also been curious about doing more with PowerShell, and besides feeling guilty about putting a VB script into use in 2012, it seemed like a really good learning opportunity.
So why not just rewrite the script in .NET? Well, you can definitely do that; in fact, the code would look very similar. However, not everyone is a .NET developer. I wrote the original VB script on a team where we were building C++ DLLs for ETL processing; .NET wasn't part of our code base. I also think there are plenty of IT roles - DevOps, DBAs, Network Admininstrators to name a few - that might find a simple PowerShell tool like this a little easier to use and/or modify for their needs.
So that being said, just copy & paste the code below into an empty .ps1 file, and you should be good to go. To use it, simply execute the following command (should work from command-line, batch file, or managed code):
PowerShell.exe -command "C:\ScriptFile.ps1" -filepath "C:\Spreadsheet.xls" -output_type "csv"
I did run into one problem / issue while writing this script - getting it to run the first time! Thanks to this great article by Scott Hanselman, I found out that there are some very tight Windows security restrictions on PowerShell scripts - particularly the ones you didn't write yourself. After reading his article, it seemed easier for me (and for anyone who wants to use my code) to just post the source code rather than a downloadable script with certificates, at least in this instance. Maybe if I write another PowerShell article I'll give the certificate thing a go.
If you get the error message I got - "The file C:\ScriptFile.ps1 cannot be loaded. The execution of scripts is disabled on this system. Please see "Get-Help about_signing" for more details." - you can enable execution of PowerShell scripts you've created by running the following command 'As Administrator':
PowerShell.exe Set-ExecutionPolicy RemoteSigned
Anyway, here's my script:CodeProject
Wednesday, August 15, 2012
I hope you're looking at metrics on your team's software code just about as often as you look at those numbers. One tool that's helped me to do that very efficiently is the Code Metrics Viewer extension for Visual Studio.
So what kind of metrics does this tool collect for you? As the author of the tool puts it, he endeavors to measure "evolvability of a software system, which is an indicator of the inner quality of software". Seems like it would be a good idea to keep an eye on that! Code Metrics Viewer makes this visible through five categories, which I'll briefly explain (technical explanations are available through the links):
- Maintainablity Index - In my opinion, this is the most important metric per class. It is a weighted calculation of the other metrics listed below; consider it as the "overall" rating. A score of 20 indicates reasonably maintainable code. However, I suggest you look for at least double that number if not more. The last two major projects I ran (both multi-tenant web applications) averaged a score of 79 across all assemblies. 
- Cyclomatic Complexity -The number of possible paths through the code, generally determined by logic blocks (IF .. THEN; FOR EACH; DO .. WHILE; SWITCH .. CASE). To me, this is probably a close second in terms of importance; think of this as the number of test cases (read: team cycles) that might be required to properly cover all the possible results / outcomes of the module. 1 is the lowest score; keep this number as low as your business needs allow.
- Class Coupling -A count of the number of other classes Class ABC depends on. Look for a score below 25.
- Depth of Inheritance- How many other classes are used to make up this class? The more there are, the tougher it can be to follow the flow of the program when modifying or debugging. A score around 3 here is good; above 6 is a warning.
- Lines of Code - pretty simple; how many lines of code are in the class.
If you don't have a metrics tool for your .NET projects, I suggest giving this one a try.
 - I ran into an odd situation while writing this article that I need to investigate further. I ran the Metrics Viewer on a small Solution that creates an .exe file. Even though the three main classes, which made up 80% of the codebase, only averaged a 56 Maintainability Index rating, the Solution received an 80. I think this is because there were some very small classes / enums that scored 90-100. My initial assumption is that the overall Maintainability Index rating is an average of all the class-level ratings, and is not weighted like the class-level ratings. In my case, this was confusing, as I had most of my major classes showing the yellow warning signals, but still received a high rating on the whole assembly. I will try to clarify this with the author.
UPDATE (11/27/2012): I had some extra time off over Thanksgiving weekend and was finally able to reach out to the author, Matthias, with my question. Matthias was very helpful; he confirmed my thought that the Overall Maintainability Index is in fact an average of the Maintainability Index ratings for each class, and shared the following information:
"... the formula to calculate the maintainability index for the module ... is correct ... but again, I would not give that much into that single value. The maintainability index is of course a magic number, which demands some quality feeling when working with it ... Whenever I do reviews based on metrics I use the maintainability index as some kind of pre-filter criterion to unveil the hot-spots, but afterwards I take a look at all numbers (even LoC) to detect code smell ... I am not sure if the maintainability index is good enough to express how clean and evolvable a software system is."He also said he has started work on a similar plugin for Visual Studio 2012, but ran into an impediment; the Professional version now includes a very similar feature.
My thanks to Matthias for his time in answering my questions, providing some guidance on the tool, and for building and sharing it in the first place.
Tuesday, August 7, 2012
Neither of the environments where I assumed this role had Maintenance Plans when I started - at least beyond the Full Backups. After doing some reading online, I was fairly convinced that implementing a more thorough Maintenance Plan regimen was a best practice that we should have been doing for a while - I just wasn't quite sure how to get started.
I distinctly remember thinking this book was going to be exactly what I needed after reading the following two segments: Brad's creds on page xiii (obviously very experienced with the subject matter), and his introduction for the book on page 14:
"In many cases, organizations have SQL Server instances that are maintained by a part-time DBA, or an "accidental DBA," who may be a network administrator, developer, accountant, or even an office clerk. In the worst cases, nobody is looking after the health of the SQL Servers. ... with the guidance I hope to provide in this book, [SQL Maintenance Plans] can become powerful tools in helping the "accidental DBA" to perform critical maintenance tasks, and so help to ensure SQL Server's performance and availability. In addition to learning how to use these tools you will, along the way, pick up a lot of good, general advice on SQL Server database maintenance."Sweet! Sounded like he had written it just for me!
So why should you take time to read this book and follow the advice within? Why are Maintenance Plans important to your SQL Server environment? I'll let Brad explain:
"The goal of implementing [database maintenance plans] is to help prevent [all] kinds of problems ... If implemented correctly, [maintenance plans] can help ensure that a SQL Server's databases perform adequately and, if there should be a problem, provide the necessary backups to minimize the loss of any data. Another benefit of implementing a database maintenance plan is that it helps to prevent, or to catch early, many different kinds of database-related problems. By being proactive with a good maintenance plan, time spent troubleshooting problems after the fact is often reduced."The first 4 chapters (about 80 pages) give an excellent overview of the basics of Maintenance Plans and how they work. Subsequent chapters go on to explain why you should or might want to consider implementing a certain type of Maintenance Plan, and how to do it. The "why" portion of each chapter was very valuable to me as a non-expert, and really helped me narrow down what I needed to implement (or avoid) to make improvements in my environments. The Database Mail configuration portion alone (Chapter 2) is a great process walk through. I had to do this for both of the environments I was working with, and probably would have spent a bunch of time on Google trying to piece together the correct steps from a plethora of articles.
One of the things I really liked about the book is that Brad takes the time to specifically explain all of the settings - with screenshots - and why or why not to use them. As you read it, you'll understand why this is valuable - not all of the fields mean what you think they'd mean. As an example, on page 181 while discussing the Cleanup Task, he states:
"The last option is to specify the age of the files beyond which they will be removed, using the Delete files based on the age of the file at task run time option ... This is another tricky option. First of all, don't deselect this option. If you do, the Maintenance Plan Wizard will assume that you want to delete all instances of the specified type of file, no matter how old they are. Of course, this is not what you will want to do. You will only want to delete files that are over a particular age."I also appreciated how the book is organized. It's not the kind of book you'd probably sit down and read cover to cover, and the structure reflects that well - it's a quick reference resource that you can easily go back to whenever you need to set up a new Plan. It's really easy to jump to the details on a specific Task and quickly get all the information you need to set it up or modify it.
There were just a couple of slight issues I ran into while following the examples:
- He states early in the book on page 16 that all of his screenshots (of which there are many) are from SQL Server 2008. As I was working with SQL Server 2005 in both cases, there were some differences for me in what he was describing. Overall though, almost everything worked as he explained it.
- Brad recommends setting up just a few Maintenance Plans with multiple Tasks, but I ended up having to create separate Plans for most major/daily tasks. This was because my maintenance windows were not large enough where I could pack multiple steps into a single Plan. Again, his instructions worked beautifully, it just took me a little longer to create the 7-8 Plans I needed.
In short, I highly recommend this resource, particularly if you find yourself in a situation like I did.You can get the book from Brad McGehee's site using the link I provided in the first paragraph. CodeProject
Wednesday, August 1, 2012
So why make another one? Isn't it just noise at this point? Am I really going to put forth ideas and solutions that haven't already been covered by all these other writers ad nausea?
I'll share a story.
At my very first programming job, I was fortunate to work with a great consultant named Steve. Even though he wasn't a software developer by trade, I learned a lot about making software from him. One of things I liked best about working with him was that just about every time he came to the office, he brought a new tool with him. A spreadsheet that was all set up and ready to go for tracking / documenting a specific task, a batch file with a couple lines of code for moving our files around; whatever it was, it usually made my job easier.
He never charged for them either; it was "just part of working with him" he'd say. As a consultant, he worked with a lot of people in other parts of the country programming on the same system, and used this opportunity to build small tools like these that would be useful to everyone, and then shared them as part of his visits.
I always appreciated Steve's approach in sharing the things he learned, and my intent for this blog - and to address the opening question, the reason for starting it - is to emulate him in that regard. While I'm not the most renowned expert in any area, I have learned a lot about the business and craft of software over the last 10 years. I hope that the stories, resources and tools I've collected over that time and going forward will be useful and interesting to others, and that they have the same effect Steve's tools had for me. This blog is just a place for me to share what I've learned, and hopefully to help a few people make better software.
NOTE: Steve is still sharing his knowledge with Shop Floor Experts. My thanks to him for teaching me the right way to do things at a very early point in my career.