Friday, August 22, 2014

Unit Testing Question

Hi there. I have a question for you. I'm looking for some articles/papers/blogs/talks about Unit Testing at the right level of granularity. Could you send me some links?

 Let me try to explain what I mean. I've noticed that when you write what I'll call "good OO" (for the sake of simplicity) you tend to end up with individual objects which on their own don't do that much.  Instead the behavior that you care about emerges from the way in which the objects are composed together.  And this poses an interesting problem for unit testing.

If I define a unit as a single object, then I will write tests for each of those little objects and I'll mock/stub/fake out the collaborators.  But since each object doesn't do much this means my tests do not end up describing the behavior of the system that I'm usually concerned with.  These tests might also get in my way during new development or refactoring because the "low level" individual APIs are locked in by the tests.

Alternatively, I could write tests that exercise the full composition of all the objects.  These tests would be closer to describing the "end user" level behavior that I more likely care about.  They are also more robust in the face of change as the lower level API can change without breaking these tests.  But, they can also suffer from Cyclomatic complexity problems because they are testing many levels of objects together.

These last tests can be taken all the way to the edge of the application and written as Acceptance Tests that literally automate the web browser.  Or they can be written like a regular unit test, but the "unit" is at a higher conceptual level, not just a single object.

Finally, these are not mutually exclusive options.  I could write both kinds of tests.

So to loop back, my question for YOU is, have you seen any good resources that discuss this issue and make any recommendations?  If so, I'd love a link, or, share your opinions on the issue.  Thanks!

Wednesday, May 21, 2014

Close old hg branches with powershell

Another silly post combining my two favorite tools: Mercurial and Powershell.

If you use named branches as part of your development workflow you may occasionally forget to close a branch after you merge it back in.  Or you might abandon a branch and never get back to it.  And if you use sub repositories, sometimes it can be impossible to update back to those old revisions...  And even if you don't get an error when you update back, it's still super slow to checkout all those old files just to mark the branch closed.

To address all those issues, I just used this little powershell script:
function closeoldbranch($branchname)
{
  hg debugsetparent $branchname
  hg branch $branchname
  hg ci --close-branch -m "closes old branch"
}
I don't recommend that you make a habit of using this technique, but I did just get a lot of use out of it! So enjoy it, but be careful!

Thursday, April 10, 2014

OOP: You're Doing It Completely Wrong


OOP: You're Doing It Completely Wrong (Stir Trek Edition)

This talk, "OOP: You're Doing It Completely Wrong", was first presented at CodeMash 2.0.1.4. in January to a standing room only crowd.  It was the 2nd time I was fortunate enough to present at CodeMash and it was an absolute blast!  The feedback I got was really encouraging and someone suggested I should submit it to other conferences and recommended Stir Trek.  The video above is the recording of the talk as it was given at Stir Trek 2014 in April (to another standing room only crowd!).

Here's the abstract:
Chances are, most of us are primarily writing in Object Oriented Languages. But how many of us are truly doing Object Oriented Programming (OOP)? Objects are a powerful abstraction, but when all we do is write procedural code wrapped in classes we’re not realizing their benefits. That’s the tricky thing about OO, it’s easy to have Objects but still not be doing good OOP. This has led to a plethora of principles and patterns and laws, which are very valuable, but also easy to misunderstand and misapply. In this talk we’ll go back to the foundations of Objects, and take a careful look at what OO is really about and how our principles and patterns fit into the big picture. We’ll see why good OOP is important, and look at the mindset needed to design successful Objects. When we’re done, we’ll have a more nuanced understanding of what good OO is, what it can do for us, and when we should use it.
Between CodeMash and Stir Trek I had the time to really work through and reorganize the details of the talk, so I actually COMPLETELY rewrote it from the ground up for Stir Trek.  And I will admit that I'm really proud of the result.

This talk truly represents my (current) understanding of what makes OO powerful and how we should really think about it.  It's VERY heavy on research and full of quotes and references.  The CodeMash version was even more so.  And that reflects my belief that we, as an industry, need to work on being a bit more scientific, especially when it comes to citing our references.

I hope that you enjoy it, and I'd love to hear your thoughts!

Sunday, April 6, 2014

Visual Studio Shortcuts: The Complete Guide

So I was gonna do this whole series of posts breaking out useful shortcuts into categories in bite sized chunks.  But that didn't happen cause I got bored with it.  But I still think it's really useful.  I have actually stopped using VSVIM and I just use VS's shortcuts now.  The only thing I really miss is vim's hjkl and w and b movement keys (the arrow keys are so far away!).

So, anyway, here's the big list of all the shortcut keys I have found useful and worth practicing.  Each category is roughly sorted by utility.  Hope it helps you too!

Editing:
Ctrl+L: cuts the current line
Ctrl+del: Join lines
Shift+del: delete line
Ctrl+C with nothing selected: copies current line
Ctrl+F3: search for current select (like VIM *)
Ctrl+Enter; Ctrl+Shift+Enter: insert blank line above/below current line
Ctrl+Shift+W: select word (like VIM viw)
Ctrl+K, S: surround with
Ctrl+E, S: show white space
Ctrl+U: to lower case
Ctrl+Shift+U: to upper case
Ctrl+Shift+down/up: move cursor to next highlighted identifier
Ctrl+Shift+V: cycle clipboard ring
Ctrl+up/down: moves the scrollbar
Intellisense: use capital case to filter by camel case

Refactoring:
Ctrl+R, R: rename
Ctrl+R, M: extract method

Windows:
Ctrl+,: navigate to window
Ctrl+W, L: opens solution explorer
Ctrl+F2: move to navigation bar (the class and method dropdowns)
CUSTOM: Ctrl+W, ctrl+left/right arrow: move window to other tab group **Window.MovetoNextTabGroup/Window.MovetoPreviousTabGroup**
CUSTOM: Ctrl+W, Ctrl+W: switch focus to other tab group **TabGroupJumper.Connect.JumpLeft, requires TabGroupJumper extension**
Ctrl+W, E: opens error window
Ctrl+K, T: opens call hierarchy window (like Find all References, but more)
Ctrl+W, O: opens output window

Debugging:
Ctrl+D, A: opens autos window
Ctrl+D, I: opens immediate window
Ctrl+D, C: opens callstack window

Misc:
Snippet designer extension: makes it really easy to create snippets
zencoding: comes with the Web Essentials extension, allows you to quickly expand HTML tag structure ex: div.content

Friday, October 18, 2013

ETB: Editing: Just 3 Shortcuts for Dramatic Efficiency Gain

Continuing on the Embracing The Beast (ETB) series, this time we're going to dive into the text editor.

If you edit at all like I used to, these 3 shortcut keys will save you a huge number of redundant keystrokes every single day.  Yep, just learning 3 new shortcut keys.

I'm not going to keep you waiting, here they are:
Shortcut Action
Ctrl+L Cut current line
Ctrl+C (with NOTHING selected) Copy current line
Ctrl+Enter Insert blank line above

I have learned tons of new shortcut keys since I started this process, but these three are the most important.  If you learn this and nothing else in this series, it will still be a marked improvement!

Why?  Let's take a look.

Cut Current Line
Like it says, this command cuts whatever line the cursor is on (meaning it copies it and deletes the line, including the carriage return).  You can use this to easily move a line up or down, or to just delete a line.  There is a command that deletes the line without cutting it (Shift+Del), but when you're just starting out it pays to limit the number of things you're learning all at once.  Ctrl+L does the same thing that Shift+Del does, and rarely will the difference ever bite you.  Start simple.

"Cool man, but like, why is this such an efficiency improving short cut?"

Glad you asked!  Here's the sequence of keys I used to hit to do the same thing Ctrl+L does in one keystroke:
  1. End
  2. Shift+Up
  3. Ctrl+X
3 keystrokes when I could have used 1!  Suppose you delete or move lines 100 times a day, which is probably crazy low.  You would save 200 keystrokes.  This paragraph is only 195 characters long.

Maybe that doesn't seem like a lot, but there is a hidden benefit here too; Ctrl+L is a single command that maps directly to a pretty high level action you wanted to take.  It may be only 2 keystrokes better than the more manual way, but you don't have to busy yourself thinking about the micro steps required to move the cursor and highlight text.  You just, BAM, do the action you want.  End. Of. Story.  Conceptual overhead here is much reduced!  

Copy Current Line
I used to do this the same as above, except I'd Ctrl+C instead of Ctrl+X.  But it turns out, if you just hit Ctrl+C when nothing is selected, VS will copy the entire line!  Brilliant!  

Suppose I copy half as many lines as I delete: 50/day =100 keys saved. This paragraph is 98 chars.

Add Blank Line Above
You might not think that you do this operation too often, but I think you'll be surprised.  How many times do you write a block surrounded by {}?  There are LOTS of ways you might do this, but the way I usually do it is I write the definition, the open {, and then the closing }, and now I want to go back up and type in the body, but I'm stuck below it!

Here's what I do:
  1. Up
  2. End
  3. Enter
That's 3 keystrokes again instead of just Ctrl+Enter!  Interestingly, this is the one I'm having the hardest time training myself to take advantage of.  That could be because how often I use it varies depending on what I'm coding, but I bet on a typical day I do this way more than I copy lines.  Lets go with 200 times a day, for 400 keys saved.  And you guessed it, this paragraph is 396 chars.

So with all three of these combined, and given my completely made up numbers, that's 700 keystrokes saved, every day, just by using these three shortcut keys,  That's clearly a good thing, but the real benefit is in the fact that you're now communicating with your editor on a higher level than just cursor up and down.

Monday, October 14, 2013

Embracing The Beast: Navigate To

Next up in the Embracing The Beast series is Navigate To.

The Navigate To feature introduced in Visual Studio 2010 is the single most important feature they added that made it possible for me to work in Visual Studio without proclaiming my longing and desire for Vim at the top of my lungs every 5 minutes.

The shortcut is Ctrl+, (Control Comma).  But the shortcut is just the beginning of effectively using this thing.

What it searches
Files, types, members, and variables.

Search string formats
An all lower case search basically does a case-insensitive "contains" search, but it intelligently sorts the results preferring "Starts With" over "Contains".  For example, if you search for "ext", you'll find things like Properties named "Extension" or Methods named "Extract" before you'll find Properties named "Text".

But change your search string so that's it's not all lower case, "Ext", and now it does a case sensitive search which would still return "Extension" and "Extract" but not "Text".

Make your search string all upper case, and now it does a PascalCaseAware search!  For example, search for "AVE" and it will match AbstractValidatorExtensions because of the PascalCase, and "AutoSave" because of the case insensitive contains match of "ave" in "Save".  Unfortunately it returns the contains matches before the pascal case matches, so this can require a lot of pascal case characters before it will return the item you want at the top.

Put spaces between search terms and it basically does an "and" search, but it's position independent.  "auto save" will of course match "AutoSave", but so will "save auto"!  Lest I mislead you, the matches don't have to be adjacent, "location incident" will match "AddLocationToSomeIncident".

Tips
Suppose you are looking for a file, and you know part of its name and you know its a JavaScript file.  Search for "partofname .js".  The ".js" will bring .js files to the top of the results.

Suppose you're looking for the Index view of an MVC controller.  There are lots of Index views in your website I bet, so searching for just "index" isn't going to get you too far.  Try this: "views partofcontrollername index".  partofcontrollername just has to be a unique enough subset of the name of the controller to bring that folder to the top.  This illustrates that Navigate To isn't just searching the file name, but the entire file path!

If you have more Navigate To tips, I want to hear them!  Comment below or twitter at me!

Tuesday, October 8, 2013

Embracing The Beast: Where Do We Start?

The Beast, as explained in the first post, is Visual Studio, and my objective is to finally really master it once and for all.  What's the criteria for "master"?  It's not a simple question because VS has so many different parts and features...  Does mastering it mean you know when and how to use every single one of those features?  Does mastering it mean you use it as fast and efficiently as possible?  Where's a poor vim-loving-wanna-be-hippie-alt-dot-net-developer to start?

There's two main related places I believe make the most sense to start, and that I believe will help drive out learning what other bells and whistles and sirens and synthesizers VS has to offer:
  1. Let go of the mouse
  2. Touch fewer keys
That's it.  Just those two things should give us a really solid start at becoming much faster and more efficient when coding in VS.

I'm guessing I don't really have to convince most of the people reading this that this is correct.  But, you know, it's low hanging fruit, so I'm going for it anyway...  Maybe you like the mouse.  Maybe you read that one ancient article from the early Mac days that says using the mouse is actually more efficient than the keyboard.  OK.  Tell me, how often do you save the file you are editing by:
  1. Grabing the mouse
  2. Dragging waaaaaaaaaaaaaaaaaaaaaaay over (monitors are BIG these days) to the File menu, clicking it
  3. Dragging down to the save item, clicking it
Or do you just hit Ctrl+S like 100,000 times subconsciously every time you stop to think about what to do next?

I thought so.

That's the thing about keyboard shortcuts, once you have practiced them to the point where they are engrained in your muscle memory, they are fast and require no thought and no time lag, allowing you to forget the physical steps of editing and focus on the more abstract ideas of what you are editing.  But lets not skim over the most important part of that last sentence: practice!  Real practice.  The kind of practice familiar to most people who have played a musical instrument of some kind, which mainly consists of repetition, repetition, repeating yourself, doing it again, and again, repetition, slow repetition, fast repetition, and then more repetition.  And if you didn't study music but instead spent your time going to sporting rehearsals (is that what they're called?), you probably experienced much the same thing.

So, if we are going to let go of the mouse, and touch fewer keys, we're going to have to practice shortcut keys.  For me that practice usually looks like:
  1. Learning a new shortcut key
  2. Writing it down
  3. Trying it out a few times
  4. Purposefully finding opportunities to use it
  5. Paying close attention to my coding and if I miss a chance to use it,
  6. leaning on undo
  7. doing it again with the shortcut
Repeat, repeat, repeat, repeat, repeat.  It's also important not to stretch yourself too thin all at once.  Focus on a couple things at a time, work 'em to death, then do some other things, then go back to the first things again, etc.  Some of this is going to be extra-curricular.  Some of it can happen on the job.  Some of it will slow you down a bit.  It's OK, you're going to be happier for it soon.  And it's not going to take as long as it feels like it does.  I have no studies to prove this, I believe it on blind faith alone, and encourage you to take my word for it.  We're software developers after all and that's how we do this.

OK, cool.  So we need some shortcut keys to learn.

The Basics
These are the essentials, chances are anyone who's used VS for any amount of time knows these already, so let's get them out of the way.

ShortcutAction
F6 or Ctrl+Shift+B Build
Ctrl+F4 Close Window
Ctrl+, Navigate to
F5 Run
F9 Toggle Breakpoint
F10 Debugger Step Over
F11 Debugger Step Into
Ctrl+R, T Run Tests
These you already know cut, copy, paste, undo, redo, save

Slightly Better Than Basic
Moving a tiny bit up the scale toward shortcuts that are still bread and butter, but might be slightly less well known.

ShortcutAction
Shift+F5 Stop Debugging
Ctrl+E, C Comment Selection
Ctrl+E, U Uncomment Selection
Ctrl+M, M Toggle Outlining
Ctrl+M, L Toggle All Outlining
Ctrl+G Go to Line
Shift+F6 Build Current Project Only

Learning shortcut keys isn't all there is to mastering an editor, but it's a big part, and it's certainly the first step.  With these basics out of the way, we can move on to more interesting stuff.

Friday, October 4, 2013

Embracing The Beast

The year was 2001, the language was VB, the editor was Visual Studio 6.  It was the first time I used Visual Studio and, to be honest, I didn't give it any thought.  Before that, I'd been developing in Turbo C and Brief.  I really liked the Brief editor.  It helped that my dad loved it and knew it pretty well too.  In any case, it was the first editor I ever took the time to learn.

Like your first language, your first editor molds your expectations.  Brief was a keyboard driven, light weight, text focused editor.  It was brief.  And it had really really good (and brief) help.  I no longer remember any of it's shortcut keys or even much about it's interface, but I still remember spending hours navigating through it's help like it was Wikipedia, "oh that sounds interesting." *click* "huh, what's that?" *click* "oooh!  that sounds cool!" *click*.

But I was working and schooling in the land of the beast now, so no more Brief.  And compared to Brief, Visual Studio is a BEAST!  Slow, mouse oriented, cluttered with tool windows sliding in and out from every direction, toolbars everywhere with countless incomprehensible icons.  And no help.

I think I did C++ in VS for a full year before I learned about the debugger, arguably VS's killer feature.  Isn't the whole point of all this UI mouse driven stuff to make it more discoverable?  It didn't work for me.  It wasn't my expectation from my Brief days and with the really bad help, I had no way to learn it on my own.  I finally learned it from one of my classmates, watching over their shoulder as they tried to fix a bug.  My life changed that day: no more print statement debugging!

I learned a lot of Visual Studio after that, but I never liked it, and I never found a good resource to help me learn more about it.  I didn't feel bad about it, cause VS was still a slow, ugly, bloated beast.  And, I seriously hated it so much I invested ALOT of time configuring Vim to do C# development completely outside of VS.

But that began to change about 3 years ago with VS 2010.  It got faster and more usable in some key ways (though slower in others), and suddenly I found myself spending less time in Vim and more time in VS.  It also helped that I was doing more web development than winforms or wpf development.  Then with VS 2012, it got dramatically better still.  I installed VsVim and hardly switched into Vim at all anymore.

It took awhile before I realized I really didn't hate Visual Studio anymore.  And awhile longer after that before I realized, "Hey, I bet if I studied this thing the way I studied Vim back in the day, I could wring a lot of performance out of it".  So I started paying attention to how I was using it, and I started researching VS tips, VS shortcuts, VS productivity.  I haven't found one single good resource, but there's plenty of random blogs with scattered tips.

Then this week, I took a big step.  I turned off VsVim.  **gasp!**

So far, it's been a surprisingly good experience.  Better than I was hoping.  I'd like to write up some of what I'm learning here, much like the Vim series.  But I'm still working on ideas of how to present it.  It's harder than with Vim, VS being such a beast and all...

Wednesday, August 7, 2013

Powershell: Open Files Matching a Search

Have I ever mentioned how much I love Powershell?

What do you do when you want to search a bunch of source files for a given string, and then open all the files that matched your search?

First you have to be able to search a bunch of files, my earlier post Powershell Grep has you covered there.  This outputs objects (a MatchInfo if you want to know) that list the files and lines that matched.  If a file had multiple matching lines, it will be listed twice, so we need to do something about that.  Then we'll need to assemble all the file paths and pass it into our favorite editor (Vim, no surprise there).

In Powershell V3 syntax the command is:
gvim (grep SearchString | group-object Path).Name
In Powershell V2 syntax you have to use ForEach-Object:
gvim (grep SearchString | group-object Path | %{ $_.Name })
If you're a programmer, especially if you're a .NET programmer, powershell is just so wonderfully intuitive (even if it is a bit verbose)!

If you develop on the Windows platform and you haven't given Powershell a look yet, you really really should.  I learned it by reading Windows Powershell In Action, a book I really enjoyed for its brevity, good examples, and awesome asides about how and why certain design decisions were made in the language.

Tuesday, June 4, 2013

Powershell: testing string length validations

Every time I do this it makes me smile.

If you write apps that have input fields that have max lengths that are validated, then occasionally you may need to test your validations.  I used to do this by typing "this is a really really really long string that should break the validations" and the copying and pasting that over and over until I thought I'd gotten it long enough to exceed the max length.

Now I just switch over to powershell (which I always have conveniently open and ready) and I type:
"quite long" * 100 | clip.exe


"quite long" just happens to be exactly 10 characters long, so this generates a string which is 1000 characters long that looks like "quite longquite longquite long..."  Piping that string to clip.exe saves it on your clipboard. Now just paste into the field you want to test and you're all set!

Saturday, April 13, 2013

Insight in Plastic Containers


Two simple small plastic containers.  The one on the left is a considerably better design:
  • They nest inside each other because of the tapered shape
  • The base of the container snaps into the top of the lid
  • The lids snap into each other
I love examples of good design like this, but that's not why I took this picture!  

On the one on the left, see how the lid is facing down and the container fits on top of it, like this?
We have way more left-type containers and only a couple right-types.  The right-types don't fit into each other, and the lids don't snap on the bottom, so there isn't any great way to store them.  I usually just stuff 'em in the cabinet.  But today I opened the cabinet door and noticed the lid on the right-type as in the photo:
FLIPPED!  It's facing up instead of down, and the container nests relatively nicely inside it.  I couldn't help but smile at this!  

I have been fixated on the lids facing down because we have many more of the left-type containers, the idea of simply flipping the lid never occurred to me.  It's wonderful to reflect on the insight of just flipping the lid around.  A terribly simple idea that has been there all along, but I never saw it.  

An admittedly silly example of lateral thinking... Or maybe it's not really lateral thinking, maybe it's just closed mindedness through familiarity.  But in any case, when I saw it today it made me go "neat!"

Monday, February 11, 2013

POODR's Duck Types

I recently read Practical Object-Oriented Design in Ruby by Sandi Metz.  It's a really wonderful book.  I can say without any hesitation it has made me a much better Object-Oriented programmer.  I honestly wish I could have read this 12 years ago when I was first learning an Object-Oriented language.

Although the book is totally focused on Ruby, the OO practices it presents are easily applicable to other OO languages, including static languages like C#.  This makes it one of those timeless books you can be happy to have on your shelf knowing it's not going to be outdated in a year.  I highly recommend it!

I intend to write a few posts highlighting some of the good ideas that struck me the most from this book, but in this post I just can't help but take a few shots at it's treatment of static vs. dynamic languages.

My programming language lineage started by dabbling in C, then taking classes in C++, followed by Java, and finally C#.  Most of the real world code I've written has been in static languages, and I've been programming professionally in C# for the last 8 years.  This makes me a static language guy.

When I learned ruby, about 5 years ago, I fell in love with it's clean syntax and amazing flexibility.  I wrote a few simple tools in it for work, and I've written alot of rspec/capybara tests, plus I dabbled a bit with Rails.  I feel I have a decent understanding of the language, but I'm by no means an expert and I definitely still think in classes and types.

I tell you this to explain where I'm coming from.  Static languages are what I know best and are what I'm used to.  I'm not a dynamic language hater, I'm just comfortable with static langs.  Which brings us back to POODR.

POODR talks a lot of about "Duck Types" which are defined in the book as:
Duck types are public interfaces that are not tied to any specific class.  These across-class interfaces add enormous flexibility to your application by replacing costly dependencies on class with more forgiving dependencies on messages.
I was surprised at this definition because it describes the "Duck type" as being a thing, but in Ruby there is no thing that can represent this across-class-interface.  Most treatments of duck typing from Rubyists I've seen usually just talk about how it's a feature of the dynamic nature of the language.  They talk about "duck typing" but not "duck types."

In C# we have interfaces, which can be used as explicitly defined duck types.  The Dependency Inversion Principle and the Interface Segregation Principle are both trying to get you to use interfaces in this way, instead of just as Header Interfaces.  It's good OO because it focuses on messages instead of types.  As POODR says, "It's not what an object is that matters, it's what it does."

I think there is a lot of power in Ruby's implicit "duck types," but I also think the lack of explicit interfaces is a serious liability, and I was very entertained by how many hoops POODR jumps through to try to work around this problem, all while trying to claim that it isn't a problem at all, and in fact, it's great!

At the end of Chapter 5, there's a section that tries to convince you that Dynamic typing is better than Static typing.  Unfortunately, it just builds up a straw man version of static typing to make it easier to tear down.  What it leaves out is interfaces:
Duck typing provides a way out of this trap.  It removes the dependencies on class and thus avoids the subsequent type failures.  It reveals stable abstractions on which your code can safely depend.
If statics langs didn't have interfaces, this might be true.  But they do have interfaces!  And worse, interfaces represent a significantly more stable abstraction that is dramatically safter to depend on than these invisible "duck types."  POODR demonstrates this itself with examples where the "duck type" interface changes, but not all "implementers" of the interface are updated.  There's no compiler to catch this.  And standard TDD practices wont catch it either.  Your tests will be green even though the system doesn't work.  So you have to write manual tests that you can share across all the implementers to make sure the message names and parameters stay in sync.  Nearly all of Chapter 9 is devoted to testing practices that simply wouldn't be needed if there was even just a rudimentary compiler that could verify just inheritance and interface implementations.

The lack of explicit "duck types" just seems so problematic to me...  Keeping them in sync is a chore, and a potential source of error.  The worst kind of error too, because the same code may work in one context but break in another based on which "duck type" is used.

Another problem I've run into is when trying to understand some code that takes in a "duck type", how do you figure out the full story of what will happen?  How do you find all the implementers of that "duck type"?  Just search your code base for one of the method names?  Try to find every line of code that injects in a different duck type?

Not being able to surface an explicit interface leaves you stuck in a situation where you have to infer the relationship between your objects by finding every usage of them.  Seems like a lot more work, as well as being a recipe for tangled and confusing code.

So what do you think Dynamic language people?  Am I making a bigger deal out of the problems of dynamic typing just as Sandi made a bigger deal out of the problems of static typing?  Is this just a lack of experience problem?  Do you just not run into these issues that often in real world usage?

UPDATE 2/20/2013:
Here's an interesting presentation by Michael Feathers about the power of thinking about types during design.  I felt like it had some relevance to the conversation here.

Monday, February 4, 2013

In The Midst of Wonders

"Where the uninformed and unenquiring eye perceives neither novelty nor beauty, he walks in the midst of wonders" - John Hershel, from The Age of Wonder, originally from A Preliminary Discourse on the Stud of Natural Philosophy

Tuesday, January 29, 2013

Custom and Example

"I thus concluded that it is much more custom and example that persuade us than any certain knowledge, and yet inspite of this the voice of the majority does not afford a proof of any value in truths a little difficult to discover, because such truths are much more likely to have been discovered by one man than by a nation." - Rene Descartes, Discourse on Method and Meditations

Thursday, January 24, 2013

The Basics

Some body I follow on twitter retweeted this tweet from Tim Ottinger:
My first pompous thought was something like, "how obvious."  I was about to go back to work when a memory hit me out of no where.  I remember very early in my career F5-hacking on some code and thinking about creating a method but worrying about not reusing it, or about someone else reusing it incorrectly, or about the extra lines of code the added syntax would add to my already 1000+ line Windows Form class.

I remember programming like that.  There was a time, not long ago, when I didn't think I should extract a method unless I meant to use it more than once!  And it's weird because I don't remember having the epiphany that took me from where I was then to where I am now.  I once thought A, I now think B, and I don't remember changing my mind.  It's an interesting lesson in the way the mind works.  And it reminded me that everyone was a newbie once, and that most likely, I still am a newbie I just haven't figured it out yet.

Friday, December 21, 2012

Slicing Concerns: Implementations

In Slicing Concerns And Naming Them I posed a question about how to go about separating different concerns while still maintaining a clean and relatable code base.  Some interesting conversation resulted, and I wanted to follow up by investigating some of the different approaches to this problem that I'm aware of.

Inheritance
public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
}

public class NotificationTask : Task
{
  public override void Save()
  {
    bool isNew = IsNewRecord;
    base.Save();
    if (isNew)
      Email.Send(...);
  }
}

public class TasksController : Controller
{
  public ActionResult Create(...)
  {
    ...
    new NotificationTask {...}.Save();
    ...
  }

  public ActionResult CreateWithNoEmail(...)
  {
    ...
    new Task {...}.Save();
    ...
  }
}
This works, and the names are reasonable. But of course, inheritance can cause problems... I wont go into the composition over inheritance arguments as I assume this isn't the first time you've heard it!

Decorator
public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
}

public class NotificationTask
{
  Task task;

  public NotificationTask(Task t)
  {
    this.task = t;
  }

  public void Save()
  {
    bool isNew = t.IsNewRecord;
    t.Save();
    if (isNew)
      Email.Send(...);
  }
}

public class TasksController : Controller
{
  public ActionResult CreateTask()
  {
    ...
    new NotificationTask(new Task {...}).Save();
    ...
  }
}
This is not really the decorator pattern... At least not as defined by the GoF, but I have seen it used this way often enough that I don't feed too terrible calling it that. Really this is just a wrapper class. It's similar to the inheritance approach, except because it doesn't use inheritance, it opens us up to use inheritance on the Task for other reasons, and apply the email behavior to any kind of task.

The naming is a bit suspect, because NotificationTask is not really a task, it just has a task. It implements only one of the task's methods. If we extracted an ITask interface we could make NotificationTask implement it and just forward all the calls. This would make it a task (and a decorator), but would also be crazy tedious.

Service
public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
}

public class CreatesTask
{
  Task task;

  public NotificationTask(Task t)
  {
    this.task = t;
  }

  public void Create()
  {
    t.Save();
    Email.Send(...);
  }
}
This service represents the standard domain behavior for creating a task. In an edge case where you needed a task but didn't want the email, you would just not use the service.

The naming is pretty nice here, hard to be confused about what CreatesTask does... However, this path leads to a proliferation of <verb><noun> classes. In the small it's manageable, but as they accumulate, or as they start to call each other things get confusing. For example, if you know nothing about Task and you have to start working on it, would you know you should call the CreatesTask service? Would you know it exists? And would you be sure it was the correct service for you to be calling?

Dependency Injection
public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }

  INotifier notifier;

  public Task(INotifier notifier)
  {
    this.notifier = notifier;
  }

  public override void Save()
  {
    bool isNew = t.IsNewRecord;
    t.Save();
    if (isNew)
      notifier.Send(...);
  }
}

public class TasksController : Controller
{
  public ActionResult Create(...)
  {
    ...
    new Task(new EmailNotifier()) { ... }.Save();
    ...
  }

  public ActionResult CreateWithNoEmail(...)
  {
    ...
    new Task(new NullNotifier()) { ... }.Save();
    ...
  }
}
I'm going to ignore all the complexity around the fact that this is an ActiveRecord object which the ActiveRecord framework will usually be responsible for new-ing up, which makes providing DI dependencies difficult if not impossible...

The idea here is to pass in an INotifier, and then when you find yourself dealing with a task you'll build it with the notifier you want it to use.  If you want no notification, you use the Null Object pattern and pass in an INotifier that doesn't do anything (called NullNotifier in the code example).

But this has the ORM-framework draw back I mentioned above.  Plus it requires the code that is constructing the task to know what behavior the code that is going to save the task will require.  Most of the time that's probably the same code, but if they aren't, you're out of luck.

Operational vs Data Classes
public class TaskInfo
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
}

public class TaskList
{
  public TaskInfo Create(TaskInfo t)
  {
    t.Save();
    notifier.Send(...);
    return t;
  }
}
Here I've separated the data class from the operational class. I talked about this in the Stratified Design series of posts.  This separation hides ActiveRecord, giving us the control to define all of our operations independently of the database operations they may require.  If we needed to save a task without sending an email we could just call TaskInfo.Save() directly from whatever mythical operation had that requirement.  Or we could do some extract method refactorings on the Task.Create method to expose methods with just the behavior we need.  Or we might extract another class.  Naming is going to be hard for these refactorings, but at least we have options.

If I missed anything, or if you see an important variation I didn't think of, please tell me about it!  As always you can talk to me on twitter, and you can still fork the original gist.

Monday, December 17, 2012

Slicing Concerns, And Naming Them

Naming is hard.  Especially in OO.  To name something, you have to understand it at it's deepest level. You must capture it's true essence.  This is hard when you're giving a name to a thing that already exists, but it's orders of magnitude harder when you're simultaneously creating the thing out of thin air, and trying to decide what to call it.  Which is after all what we do when we're designing code.

The "essence of things" correlates closely with concepts like Separation of Concerns and the Single Responsibility Principle.  You can slice any object into ever smaller concerns or responsibilities.  You can slice it right down to it's constituent atoms!  Many design problems, like tight coupling and loss of flexibility, are in large part due to having concerns and responsibilities defined at too high a level.  Could this be so common simply because it's so hard to find names for the smaller concepts?  It's frequently easy to see what those separate concepts may be, but terribly hard to think what to name them!

Let's have an example:
This is entirely fictional code, but it's not so different from a lot of real code I've seen in the wild. And it illustrates this problem of slicing concerns very well.

At first glance, it seems very simple. The domain has a Task concept which has a default due date (set in the constructor), and which sends a notification email after it's inserted (using an ActiveRecord hook).  This very nicely and completely describes what a task is and how it behaves in our system.  And the names make it very intuitive.

Or do they?  Is it really the case that every single time we insert a task in the database it should send an email?  Unlikely.  We should slice that behavior out and put it somewhere else:
public class _WhatShouldThisBeCalled_
{
  public class _WhatShouldThisBeCalled_(Task t)
  {
    t.Save();
    Email.Send(t.AssignedTo_UserId, "New Task", "You have been assigned a new task");
  }
}
This is an incredibly simple refactoring, but I have no idea what this class should be called. The method is a bit easier, it could be InsertAndNotify(Task t) or something similar. But what is this class? What concern does it represent?

No, really, I'm actually asking you.  What would you call it?

Or how else would you write it?  Maybe you'd do something like a fire an event and have someone hook it?  How would they hook it?  Maybe we need an EventAggregator?  This is getting awfully complex for such a simple requirement!

And it's not done, because it's not really so great that it defaults the DueOn date in the constructor.  Is every single task really due tomorrow?  Or is it just a certain kind of task, or tasks created in a certain way?  And where will we put that code, what will it be called?

I sincerely believe this is both a significant design problem, and a significant naming problem.  I want to know how you'd tackle it.  Please do leave a comment or tell me on twitter or even better, fork the gist on github!

These concerns need to be separate!  But what a cost we pay for it!  The simple OO domain model of a Task has turned into something much less relatable.  Either it's event driven spaghetti code with strange infrastructure objects like EventAggregators.  Or it's a hodge-podge of service or command classes, none of which actually model a relatable thing...  They only model functions, features, behaviors, use cases.  Or maybe we try applying inheritance, and then we end up in a whole different world of confusing names and surprising behaviors.

Can't we do better?  Is there some way we can do the slicing of concerns we need but still maintain the modeling of real relatable things?  Even if that may require a different way of thinking or not using the design patterns that led us here (Active Record, in this case).

Friday, December 14, 2012

The Fundamental Software Design Problem

The most fundamental software design problem, that this the the most important problem which underlies all design decisions, is:

Choosing the right amount of abstraction


Say you're starting a brand new project that you don't have any previous experience with.  What sort of architecture should we apply?  We have a lot of choices, some listed here, ordered in increasing complexity:
  • SmartUI
  • MVC w/ Active Record
  • Ports and Adapters
  • SOA
  • CQRS
For some problems just a glance is enough to know it needs a more abstract and complex solution.  Equivalently, some problems quite clearly should be as simple as possible.  But most problems lie somewhere in between.  And generally there's really no way up front to know exactly where on the complexity scale it will lie.

Worse still, in a large enough application different portions of the application might be more or less complex.  Some areas could be simple crud with no logic, while other areas involve heavy data processing and complex workflow and queries.

And even worser, this is a moving target.  If I had a dollar for every time something I thought was pretty straight forward became much more complicated either because of changing requirements, scope creep, or just misunderstanding...  Well, I'd have quite a few dollars!

As I see it, there are basically two strategies for dealing with this problem:
  1. Start as simple as you possibly can, and evolve to more complicated designs as things change
  2. Start slightly more complex than may be strictly necessary so that it's easier to make changes later
I would expect people from the Agile and Lean communities to balk at the very mention of this question.  They'd probably bring up stuff like YAGNI and evolutionary design.  And I agree with this stuff, I agree with it completely!

But I also think boiling frog syndrome is a real thing.  Even a great team with the best intentions can easily find themselves stuck in the middle of a big ball of mud.  That's just life.  Little things change, one little thing at a time, and you do "the simplest thing that could possibly work" because hey, ya ain't gonna need to do a big overhaul now, this will probably be the last tweak.  And next thing you know, everything is a tangled mess and all your flexibility is gone!

To add insult to injury, when you find yourself wanting to do a significant refactoring to a more abstract design, it's frequently your unit tests that are the primary problem spot holding you back.  Those same tests that were so useful when you were building the code in the first place are suddenly locking you into your ball of mud.

I can hear you now.  You're looking down your nose at me.  Huffing and puffing that if I'd had more experience it never would have come to this!  If I'd just listened to my tests, the ball of mud wouldn't have happened.  If I'd just understood the right way to build software!  blah blah blah.  Sorry, I don't care.  I build real software for real people with a real team, I'm not interested in idealism and fairy tales.  I'm interested in practical results!  I'm interesting in making the correct compromises to yield the best results while constantly striving to do better!

And that's ultimately my point!  No matter what design I start out with, I want it to allow me to strive to do better.  If the simplest thing that could possibly work is going to be hard to evolve into something more flexible, that's a problem.  Accounting for change doesn't necessarily mean doing the simplest thing, in some cases it means doing something a little more complicated, a little more abstract, a little more decoupled, or a little more communicative.

If this ticks you off, please come argue with me on twitter!

Thursday, December 13, 2012

The Dizziness of Freedom

"A man stands on the edge of a cliff and looks down at all the possibilities of his life.  He reflects on all the things he could become.  He knows he has to jump (i.e. make a choice).  But he also knows that if he jumps, he'll have to live within the boundaries of that one choice.  So the man feels exhilaration but also an intense dread."  - Jad Abumrad quoting Kierkegaard

Wednesday, December 12, 2012

Neat F#: Custom Operators

F# has support for custom operators.  The best use of this I've seen so far is in the canopy web testing library.  Canopy allows you to write code like:
"#firstName" << "Kevin"
"#firstName" == "Kevin"
That code is the same as this code written with the Coypu web testing library:
browser.FillIn("#firstName").With("Kevin")
browser.FindField("#firstName").Value.ShouldEqual("Kevin")
As you've likely deduced, the "<<" operator has been overridden to lookup the field and set it's value, while the "==" operator has been overridden to lookup up the field and assert on it's value.

In this case, both of these operators do exist already in F#, but they obviously aren't usually used to drive a web browser.  So this is a powerful use of operator overloading.  But F# allows you to define custom operators that have no definition in F# as well.  They can be any combination of a certain set of characters.

For example, there is no "=~" operator in F#, but you could define one to do a regex match as follows:
open System.Text.RegularExpressions
let (=~) input pattern = Regex.IsMatch(input, pattern)
And you'd use it like:
"some input" =~ ".*input"
And you could also define one that is case insensitive:
let (=~*) input pattern = Regex.IsMatch(input, pattern, RegexOptions.IgnoreCase)
These operators are not overloaded, they're just custom defined.

There is clearly a tradeoff here between explicit code and concise code.  Look back at the first example from Canopy again.  If you knew that was web testing code, and you recognized "#firstName" as a css selector, you would probably figure out what it was doing.  And this conciseness is going to be really nice in a situation where you're executing the same type of operations over and over and over again (say, like, in a Selenium web test!).  So while there's no mistaking what the Coypu code is doing, I'd rather write the Canopy code!

However, in the regular expression example, since =~ and =~* are not part of the language, how would you know what they do.  Certainly there's a similarity to ruby, but I've never seen a =~* operator.  So introducing stuff like this to your code base runs the risk of making your code harder to understand.

In the end, I think it's an awesome feature to have at your disposal.  And I think a good rule of thumb is to be willing to try some custom operators when you have a high and dense repetition of operations.  That is, it's not a one off operation, or it's not used always by itself in far flung sections of code.

In any case, this another powerful, and very neat, feature of F#.