Wednesday, October 29, 2014

Who chooses your tools?

What would you say if I paid you to change a tire on my car? Ok, change a tire on my car but you can only use one of those multi-tools that has pliers/wire cutters, a few knife blades, screwdrivers, a leather punch, a file, and tweezers. What do you mean you can't do it? The tool does everything! The folks that made the tool say it does. They cut a wire in like 2-seconds and it has a leather punch...A LEATHER PUNCH!!! So obviously you can change a tire with it since it can remove nuts. Oh, btw change all four tires. Needs an oil change too. Only the one tool that does it all, that's what you'll use for that also. Maybe some new breaks, they've been a little squeaky lately. I failed to mention that the keys are locked in it and it's out of fuel but why would that be important? So, when will it be ready? How about in a couple hours? A couple hours sounds right to me. I never changed a tire before, but I have put fuel in a car and that only takes like a minute so a couple hours to change the tire and all the other stuff should do. Oh wait, you're using one of those magic bullet tools, so of course it'll take half the time. I'll pick up the car in an hour. An hour later... What!? It's not ready yet? What have you been doing? The super-tool has an issue? Oh you've called the manufacturer and they said everything will be ok. Good because I really like the idea they have with that does-everything-in-half-the-time tool. BTW, did you see the YouTube video they made? The one that's all sped up where the guy using the super-tool carves out a surf board in like 40 seconds then goes surfing!? I mean how awesome was that! So you'll be done in no time because obviously you are of equal or greater intelligence than the surf board guy, after all you know me don't you? So you must be awesomer! See ya in 20 mins buddy! 20 mins later... Ok this is getting ridiculous, perhaps another person with another tool, 2 people with super-tools would surely get this wrapped up in no time. I need this done, I have to lead a parade with this car in 20 minutes! I made plans after I figured this would only take an hour given your superior intellect combined with the most versatile tool EVER! finally... Well I missed the parade, but it's good to have my car back. I'll see you in a bit when I need the muffler replaced and to get it waxed. 😎

Thursday, October 23, 2014

Recursion, really! Because it doesn't have to be complicated.

I ran across something recently that went like this: some method (a[], b[]) = { do c with a and b; x[] = getTheArray(); bool MOE = false; while(MOE) { do c with a and x; MOE = does x meet condition of egress? } } of course c was some repeated code, not it's own method. But it didn't have to be either. I ended up refactoring the "some method" body to look something like the following: { if(a && b meet some condition) { do c with a and b; x[] = getTheArray(); call this recursively with a and x; } }

Friday, October 17, 2014

on my local machine

Today the lesson is to have a plan to restore your local machine in the least intrusive way. I had a drive failure this week. I was able to back up files before replacing a single drive with 2 smaller SSD drives. I put all user files on the second drive and all install filed and progs on the C drive. I have some options ahead of me with respect to a backup plan for files. I can add a mirror drive or schedule backups to a network drive or both. That's the easy part. The harder part is to reinstall all the software. The desktop team will install the OS and all the basics, and I get to add all the dev tools. That takes at least a day. option is to use virtual machines. The whole team would benefit from that strategy since the image would have all the software installed. If anyone needs a vm with the developer image, there it is. Tough part is to keep the image maintained with all the updates and new tools. Yet another option is to install via a script. With a script install the latest versions of all the goodies would be kept on a file share. The script would point to the latest (rename latest-whatever-setup.exe or .iso or .msi). Or the script would read a config file located on the share. The script would compare already installed software against the config and install/update as necessary. This approach would be slower, bit less maintenance than an image. Why not combine the last two? Maintain the central list for updates and keep a clean image vm somewhere that runs the script (or do that manually after every update has been tested). This way, any catastrophic failures can be recovered from, and all devs can update to the latest and greatest with a click of a button.

Tuesday, October 14, 2014

Unit Test Guidelines

For reusable code, unit tests should have more coverage. The more reuse a piece of code will have, the more the coverage. In a centrally used service or widely shared library, be sure to cover every parameter and every combination of parameters that makes sense. For the following parameter types, here is some basic guidance to start with: string - null, empty string, special chars especially ()'/\."{}<>*@,:;!?&%$# -- // and do not forget "O'Leary", short strings, long strings, string with numbers, leading numbers, leading chars, ending chars, \r\n, ... whole numbers - -max, max, -1, 0, 1, null, (-max - 1), (max + 1) decimals, floats, doubles - 0.1,-0.1, null, 0, 0.0, -max, max, (max + .1), specific precisions, culturally specific formats (Germany uses 1.000,00 not 1,000.00) all numbers - rounding errors, divide by zero datetime - null, 1/1/1, 01/01/0001, 99/99/9999, 12/12/9999, today, yesterday, tomorrow, culturally specific formats (dd/mm/yyyy, etc), non-Gregorian calendars if applicable, "what day is it?", 1/1, so many time formats... be sure to always use datetime never a string that represents the datetime unless its the long representation of the datetime in .Ticks, and use UTC whenever possible. Here's a tip for UNIT TESTING classes with internal dependencies - break the dependency out. If your dependency isn't mockable via a mocking framework because it is not an implementation of an interface, create a testable subclass and override to set up your tests. If you mark getters and other methods as virtual and ensure at least protected access to the method or property.

In Retrospective

A retrospective is a meeting at the end of an iteration where the team gets together and discusses what worked, what didn't, what could be done to improve. It's pretty standard faire. Perhaps there may be a danger in deciding too many things at the retrospective, where there isn't necessarily time for everyone involved to truly think on any of the issues discussed or to truly understand any of the ideas for improvement that have been proposed. It could prove beneficial to revisit some of what was discussed before implementing any serious changes to process. If you have a well defined process in the first place it will be documented in a clear and concise way with proper change management protocols built in. I recommend creating a single document that has a diagram and supplemental text that describes the process at a level which would rarely change. There is a balance between the level of detail in the process definition and maintenance costs/usefulness. Unless you need the extra detail due to regulations, keep it simple enough so that it won't need constant maintenance for every nuance of change, but include enough detail so that everyone knows who does what, when and sometimes how. The how should be describes separately from the process document. If you are using standard procedures, just call them out by name or link to the doc or both. For example: A release process could be defined as follows: The release should have a release coordinator, a release engineer, other technical parties, and a qa engineer. A pre-production meeting should be held before the release and should cover what is going and when, the schedule should be reviewed and everyone should have a copy of the schedule. The coordinator should set up a meeting during the release and communicate to all parties involved throughout the release. The coordinator shall communicate to all external parties according to the release schedule. Etc... This should also be diagrammed with definitions for each role and domain specific terminology or link to such a glossary.

Tuesday, October 7, 2014


Model, View, Controller implies separation of concerns between the business logic and the presentation layer, but it's easy to mix them if you're not paying proper attention. One way to mix them is to put all your business logic in the controller. Since MVC is a pattern for presentation, you can separate your layers further by abstracting the data and the business rules from the entire layer. Let your controllers consume contracts and DTOs or Domain Models if you're into DDD. But map the DTO or domain model to a view model that's specific to the views in the UI. The views should only consume the view models or domain models that are contained within the app. Mapping should be defined separately and not attempted within the controllers since a view can be reused, by implication so can the model. If the mapping is separate, then it can be reused along with them.