DimeCasts.net Redesign - Part 1 - Getting to Know OS X Mavericks

The Current State of DimeCasts.net

Dimecasts.net (a personal pet project of mine outside my daily job) as it stands right now is a site that has been sitting there, stuck in time.  It's had static cast content that has not been updated with new content in more than 2 years, as the site had been untouched after 2012 by previous owner Derik Whittaker who had since then become busy doing other things such as now he's doing videos for Pluralsite, more blog posting, speaking, kids, job, etc.

As it stands right now the production site stack is the following:

• ASP.NET MVC 1.0
• NHibernate
• SQL Server 2005
• Tables drive the structure of the website
• jQuery (very old version)

Redesign of DimeCasts.net

One of the goals of redesigning DimeCasts.net was to venture out of the Microsoft world including code.  I've worked a lot with Subversion, a little Git, some Dojo on the job, etc. but there's a ton out there and things are so much different now that it's a shame I'm still stuck in only .NET and MS tools mainly in the jobs I've been taking.  In fact I've tried very much to stayed away from painful tools like TFS, and others that are simply bloated and get in your way rather than make it easy for you to get your job done.  One would not know the pain one is dealing with in TFS unless they have ventured out and used other tools like Subversion, Git, etc.  

Most .NET devs look at me like are you crazy, TFS sucks?  Then I ask them is that all you've ever used?  It's usually "yes" OR "I tried subversion or Git and it's not good, it sucks, or it's hard".  That's just like saying "Resharper is no use" which both are completely bogus statements to be making.  If you haven't tried to use a tool like Subversion, ReSharper for more than a day before you give up, then don't tell me TFS is the bomb either.

I wanted to get more versed in stuff like Node.js, Angular.js, Express for Node.js, Grunt, Jasmine Test Runner, etc.  And what better personal project and opportunity to apply that than Dimecasts.

And one of the main things was I'm gonna do this using the Mac OS.  Yes you can run node in Windows but I want to know how the rest of the world does hit outside Microsoft.  So I am forcing myself to use the Mac OS for redesigning Dimecasts.net.  So this first post is about just getting around and my feet web in the OS.

As I started to use OSX Mavericks, I was pleasantly surprised at what a nice operating system this is.  Previously  I was in the boat of "Mac OS sucks" which is what most .NET devs will bitch about and run away from.  However, sometimes we have to open our eyes and stop making statements that are totally outdated and monolithic and actually try things again.  After all things have drastically changed since 5+ years ago.  

If you're still naive enough to say the Mac OS sucks, Node.js is puke, and JavaScript is trash, then you are being stubborn and speaking either on heir say or you are not informed when you say these types of comments.  Unfortunately I have to say it, that most .Net devs fall into that bandwagon.  It's sad, and I have realized that there are way more things outside .Net that are far more fun and being used more and more that it's just dumb of me not to get to know it.  I think it's sad that most .NET devs that I know at least are so biased and think that the only thing that should and does live in our world is Microsoft technology.  I'm not saying I don't like C#, ASP.NET MVC and sorts but MS falls short in a lot of tools where others make your life a hell of a lot easier that you could be using with your MS codebase.

When I did Dojo & Dojo MVC a couple years ago, it opened my eyes to what a JS Framework can do for you.  Granted Dojo is the older JS framework and less desired now that there are frameworks like AngularJS, Backbone, whatever but Dojo had apparently been drastically redesigned and now uses some of what most JS frameworks have, at least some of it.  

I wouldn't use Dojo as a framework personally but still, it has MVC, etc.  And showed how JS can be elegant and maintainable and fund to code in.  These frameworks show the power of JS.  Ok, ok for those of you who must have a T-Shirt that says "JS sucks", again, don't be so naive.  Yes it's a bit of a pain to debug but try out a framework, you'll find JS can actually be decent even though it's not a typed language.  That's where you need to again open your eyes and install tools like Webstorm, IntelliJ, etc. that have super rich intellisense that will drastically change how you debug and code in JS and make a lot of the chores an d pains of coding in this language melt away.

Remember, jQuery is not a framework, it's a JS Library, those are 2 completely different things with different purposes and uses, but both can be used together of course to create powerful websites.  jQuery can live on top of a JS framework Views to provide additional functionality, but it doesn't provide an MVC framework, stuff like Angular and other serious JS Frameworks provide you.

Don't get me wrong, we'll still be looking to add a ton more casts around .NET technology but we're also looking for casts on a slew of other code subjects outside MS as well now.

OS X Mavericks

One of the first things I missed form Windows (I am running Windows 8 dual on this Macbook Pro BTW) was OneNote because I put a ton of information and notes about code as I come across stuff I want to revisit or have handy, errors I've come across and how I resolved them, family and personal info, you name it.

One of the first wins after venturing around in the Mac OSX was I found out that OneNote is FREE through the app store which rocks.

After installing OneNote, I was ready to rock and roll because now I could document and create screen shots of stuff for both blogging and just for remember wtf I did in my journey to recoding this great site.

Second, being a Mac OS n00b, I noticed that Ctrl + C is not a shortcut in the MacOS for copy.   Not to mention you scroll in the opposite direction in the Mac OS in order to go up and down compared to what I'm used to in Windows.

Third, I wanted to get a pic off my DimeCasts twitter page to put in this blog post.  In windows 8, all I had to do was to use the OneNote very handy screen capture tool that lets you drag and select an area of your screen and then puts that into your clipboard for you...very convenient.  I thought to myself hmm, where is their image editor and how can I copy full or partial parts of my screen to the clipboard? TBH, other than of course resorting to searching the net, there was nothing in the apps or utilities list in the OS that yelled out at me as "Hey I'm an Image Editor!"....or "hey you can use me to capture parts or your entire screen".  I didn't even know how to print screen in the Mac OS.  So I started to get to know the Mac OS Maverick Shortcuts.  And then how would I get that image from my clipboard and into a file so that I could work with it in a graphic editing program?  And I quickly found out by doing a search that Preview is the default image viewer & editor in the Mac OS for image editing.

So far, other than finding an image editor and how to work with the clipboard and screen capture, the journey has been smooth.  

Stay tuned for Part 2.

CodeZest: Buying an Espresso Machine - Advice to the Novice

CodeZest: Buying an Espresso Machine - Advice to the Novice: I wanted to take some time to share my experience with buying and owning espresso machines.  I want to share some things so that you don...

Buying an Espresso Machine - Advice to the Novice

This is a picture of my semi-automatic espresso machine at home, a Rancilio Silvia.   We all spend money on hobbies.  And this is just one of my hobbies which has saved me a TON of money and I love good coffee so it was worth my investment.  I no longer have to go to coffee shops every day.  I have something that makes great if not even way better coffee than most the shops out there...and I'm not kidding, this machine rocks.

No I'm not rich, not even close.  And in fact this machine if you think about it along with a very good grinder which is required totals only around $1100 ($600 for the machine and + $300 for a good burr grinder + $200 for a PID added on at checkout on seattlecoffeegear.com).  You can buy semi-automatics all the way up to 5k, or full automatics.  I found that you don't need to spend that much money to get espresso that is just as good as any coffee shop you find out there.  Mine is nothing fancy, but it is solid and proven.  It's made by Rancilio, a very good Italian company...and these have an average lifespan of 12-15 years if you look up info on it.

I wanted to take some time to share my experience with buying and owning espresso machines.  I want to share some things so that you don't make the same mistake I did, which is buy a super automatic espresso machine.  Instead if you are gonna spend some serious money, save your wallet, I have the solution for you without blowing a hole in your pocket.

Most super-automatic espresso machines cost anywhere starting at the low-end from $500 all the way up to $5000 or more.  

Right now I'm on my 3rd espresso machine.  And I'll tell you why all I had to do is buy the right espresso machine and I could have saved myself around $3000 because I wouldn't have had to buy the other two which lasted only 5 years and 2 years.

Super-Automatic Espresso Machines

A Super-Automatic Espresso Machine are ones that provide the following functions:

• Some have a full frothing solution which minimal effort
• Some have a frothing wand, which takes more effort but you get a lot more control and typically.  Others will have complete froth automation to where you have to do almost nothing manual to get froth generated
• They are all push button, there is really nothing manual that you have to do to prepare and brew the coffee or espresso
• They offer the option to create a full cup of coffee or an espresso shot
• They usually provide some temperature variation that you can set that determines how hot the coffee comes out
• They are very programmable, things like # of shots per pull, # of cups for coffee per pull, etc.
• They all use burr grinders, the best grinder grade which is required for espresso machines to even operate well because burr grinders grind a very consistent and even grind and so you get much better coffee out of evenly ground coffee.  You may think your $50 grinds is good, but i'ts not.  Get a burr grinder, they are anywhere from $100 - 600 and well worth it and you will notice a huge difference even in your regular coffee machine
• They allow you to tweak the grind somewhat, making it finer or courser
• They are very low maintenance
• it's easy to change water
• it's easy to clean
• it's easy to descale
• They last anywhere from 2-7 (7 years if you're very lucky)
• They are more expensive than semi-automatic espresso machines
• Usually all parts inside are plastic

Semi-Automatic Espresso Machines

A Semi-Automatic Espresso Machine are ones that provide the following functions:

• They have a frothing wand, and usually do not have a non-manual frothing solution
• They are much less programmable.  Some are not programmable at all
• think of it like a Professional SLR vs. an Amateur SLR Camera.  Professional is usually very manual so that it allows more control and precision whereas Amateur cameras do not provide a manual option and make it easy for the less serious, non-experienced photographer
• They only allow the option to pull espresso shots, not full cups of coffee (however you can add water to the espresso shot in order to make essentially regular coffee)
• They either come with what's called a PID or not.  A PID allows you to control temperature to a very precise degree which allows you to tweak your shot to make the best possible tasting shot.  Without a PID, the temparature is usually variable so not every shot can taste the same.  One shot might taste awesome, while another might taste sour if the temperature is too high or too low at the time you pull the shot
• They require us of an external burr grinder whereas super-automatic has a burr grinder-built inside
• They are more maintenance, but not that much more than a super-automatic
• A lot of them are cheaper than super-automatic machine
• All the parts are typically commercial grade.  Meaning most companies that make very expensive semi-automatic machines sell a consumer espresso machine.  These consumer machines almost always contain top notch parts inside that is comparable or the same as their big machines.  You will not see any plastic inside, so they are much more durable

Super-Automatic vs. Semi-Automatic Espresso Machines

Now listen up closely, this section is critical for you to read if you are thinking of spending $600+ on a machine.

Do not go with a Super Automatic Espresso Machine ever!

If I would have known to try a semi-automatic first, I would have saved myself a lot of money and would have been pulling much better shots and savoring much better coffee for the 7 years that I had super-automatic machines.

Yes I know the super-automatics look really cool with their digital displays and slick design but trust me, it's not worth it.

Here is why I say this, lets compare.  I'll take the points above for the super-automatic that I listed and debunk and tell you why what sounds good really isn't that good with them.

Traits of a Super-Automatic Machine and Their Downside

Some have a full frothing solution which minimal effort

      Counter

• This might fine if you don't care about not being able to create think vs. think froth and are not that picky with the result of the froth and that you have no control over it during the process.  But I look at this as totally limiting.  You will find that you will want to change the froth to suit your tastes, believe me

Some have a frothing wand

      Counter

• Yes, but usually the pump that is in these machines are weak.  They don't produce a ton of steam.  You may think they do but wait till you get a super-automatic.  So this affects the quality of froth.  Now you may not care about that, but I know I do, as I want to do latte art and have fun
• The wand usually has some kind of plastic somewhere.  Either the wand itself is plastic or the parts that it connects to are plastic.  This is bad because obviously plastic doesn't wear well but also you have more parts to take out in order to clean it and plastic does not clean well.  Over time you get stuff caked on it which is very hard to remove like milk build-up and such

They are all push button and that's it, piece of cake

      Counter

• Sounds great right?  I don't have to lift a finger except to push buttons, horray!  Well think again.  Buttons introduce more electronics into the machine that can potentially fail.  A friend of mine can be the first one to tell you it happened to him after only months of owning a $700 super-automatic espresso machine (Gaggia to be specific) and that's bogus.  Go online and you'll see this is not an uncommon issue either
• What you see is what you get.  If the options are not there or the options do not do what you want well, you're stuck with them

Of the buttons that are on these machines they usually allow you to specify a full cup of coffee or an espresso shot to pull

     Counter

• That's cool right?  Yes, some people like shots for either sipping straight up or making lattes and mochas.  Some people just want a plain cup of coffee.  There's really nothing I can say bad about that, so I can't really debunk that one and surface any cons for that except for again my friend had problems with buttons on a Gaggia Breva whereas he'd press the button to create a cup of coffee and no matter what it'd pull an espresso shot every time instead.  Now that's a real problem!

They usually provide some temperature variation that you can set

      Counter

• Sure, but you only usually get about 3 levels of temperature and a lot of these machines are not producing very hot coffee even on its highest level

They are very programmable

      Counter

• Again, this might seem nice, but you are banking on the machine not malfunctioning in terms of the motherboard behind it.  People have had problems with their board where buttons go wacky, and it's not that uncommon.  Do you really wanna deal with that possibility?  That means you send your machine in, get it repaired and it's not cheap, and you get it back only hoping it doesn't happen again

They all use burr grinders

      Counter

• It's a requirement for any kind of high-end espresso so pretty much all have them, nothing to report here except that you have more control over the type of burr grinder, the type of material the grinder is using, and you have a whole range of grinders to choose from if you go with a semi-automatic machine.  I'd much rather be able to select different grinders than be suck with one, the one that comes with the machine.  The ones that come built into semi-automatic are very hard to clean as well and you can only clean so much of it

They are very low maintenance

     Counter

• Sure, but again that's because you have less control, the machine gives you what you get and that's it

They last anywhere from 2-7 years  (7 years if you're very lucky)

     Counter

• Yep, my last one was a Gaggia Breva and only lasted 2 years as no water was coming out one day by the pump
• My Gaggia Titanium lasted me 5.  The pump simply got worn out.  Now being a rookie, I should have sent it in to get the pump fixed.  That is not cheap.  But the parts in these machines fail often, remember that.  So chances are I'll be fixing this thing a lot over its lifetime

They are more expensive than semi-automatic espresso machines

      Counter

• yes, because they are more complicated machines to produce.  They are harder to engineer and require many more parts and digital interfaces in most cases so the cost to design and manufacture them is much more

Usually all parts inside are plastic

      Counter

• Those parts break down sooner than later.  Why do you want to be seeing plastic parts after you pay $600+.  That's an insult to customers if you ask me.  If I pay that much I expect non plastic parts driving my very expensive machine
• There are a higher number of plastic parts.  When you pop open a super-automatic vs. a Semi, the super-automatic will be a cluster f full of parts and it's amost impossible to repair yourself or get at some parts easily because it's so tight in there as the parts are many and have to be jumbled together in a very small space.  It's a mess of low quality parts essentially in sum

Wand and Froth Are Important

When I owned my last two super-automatic machines, I thought the froth was great.  That is until I wanted to create latte art.  I kept trying and trying but I just couldn't get the milk right.  I'd get very course bubbles in my froth no matter what I did to try to minimize that.  

I found out later after purchasing my semi-automatic that eventually I had such flexibility that I would be able to do latter art later as I practiced more. 

The reason that the semi-automatic machines create better froth, micro froth needed in order to create art is because of two reasons:

• Semi-Automatics have more powerful water pumps for the frother
• And they allow you to change out frothing tips or come with a tip that is much better than what a lot of super-automatic machines come with

Powerful Steam

The tip and the power of the steam both are critical in being able to create the right micro foam.  You will have a hard time doing that if not impossible with an super-automatic machine.

Espresso Shot Quality Is Important

Thicker Crema

Super-Automatic machines simply won't compare to a semi-automatic in terms of the quality of the shot.  Quality of the shot is what makes your latte or mocha or just straight up drinking takes awesome.  If your shot is too weak, too acidic, or doesn't have any crema  on top, it's useless.  It might test pretty good, but I can tell you once you get a semi-automatic, it'll blow it out of the water.

After buying my semi-automatic, the first sip just blew me away.  It was better than any coffee shop in town and I'm not exaggerating.  I live in the suburbs of Chicago so there are plenty of coffee shops to go around and I've also gone to Intelligensia, Star Lounge, and more.  I can tell you there is no coffee shop around my immediate area that compares to the coffee I can produce with my semi-automatic.  A $3000-5000 super-automatic can't even compete either.  I've tasted shots from those very expensive machines (Jura, etc.) as well at places like Williams & Sonoma, Sur La Table, etc. and again, it just does not compare.

What I noticed with my semi-automatic as compared to my last 2 super-automatic machines is I have total control.   I can get the shot as stong as I want, way beyond the levels the super-automatic provided me.  I can produce a much thicker crema as well, which is necessary for drinking a good shot of espresso...as well as helps with being a thick base for latte art which is necessary, as well as I can make sure I do not get sour shots.  I can play with it and get it to a point and fine tune it at a very micro level.  You simply can't do that with a super-automatic.  Again what you see is what you get with those.

Manual is Preferred over Automated

While semi-automatics don't have the cool interfaces on them (some due but very limited), it doesn't matter, you don't need them.  You don't want them.  You want to control it yourself anyway so you can fine tune your shots and froth anyway.

Yes, semi-automatic is a bit more manual but not by much.  About the only thing that is more manual is the fact that you have to grind the coffee yourself with an external burr grinder, and that you have to pack and place the shot before you pull.  Big deal, it might add 2 more minutes, which is trivial.

They clean up just as easy if not easier than super-automatics because there are less parts to deal with inside.  All you really need to do is just descale it.  super-automatics make you slide out the internal components as well and rinse them.  You don't do that with semi-automatics because they are designed in way that they don't have such complicated parts and all they need is a descaling.  

You do have to clean your porta filter, but again, big deal.

Lifetime

I had a very poor experience the length that super-automatics last.  Because they are made with all plastic parts inside, it's pretty obvious they will have a far shorter life-span than a machine with commercial grade components inside.

Just for comparison, a Gaggia Titanium ($1200 retail price) lasts around 5-8 years.  My $600 super-automatic Rancilio Silvia which has been around for 20 years, has been said to last on average 12-15 years if maintained properly.  Clearly it's smart to go with a semi-automatic.

Conclusion

Overall the amount of flexibility you get in terms of being able to tune your machine, control the quality of shots, and get that micro foam just how you want it is why you should be buying a semi-automatic.

Also, they last a long, long time as the parts are commercial grade inside.  Much longer than a super-automatic.

They cost much less and you'll taste far better coffee, closer to what good shops pull...and you find yourself almost never going to those places.  With my super-automatic I still found myself going to coffee shops because again, the super-automatic while good still didn't produce the level of quality that coffee shops produced.  My semi-automatic did.

What Model do I have?

I bought the Racilio Silvia v3 which is a very popular and proven Italian machine.  And I bought the Baratza Vario Burr Grinder.  This machine and grinder combination produces outstanding coffee, and rivals any other semi-automatic at higher prices levels by far.  I am still blown away to this day how good every shot comes out.  I can't think of anything better than the shots coming out of this machine.

I bought mine at seattlecoffeegear.com.  I like these guys better than a place like wholeLatteLove because they are just more insightful and willing to do more for you.

Make sure you add the option for PID!...it's critical:

Blurring out areas in an image

This isn't really a post I'd normally write, but since I get this question all the time from colleges, I thought I'd mention it.

I often blur stuff out in images on my blog or in just quick print screens I create at work sometimes for whatever reasons.

But first I will say I do not use free paint programs like Paint.NET or GIMP.  They just don't cut it for me for the following reasons:

• while you may not care about quality in simple print screens for documentation or blog posts, well I do.  When I create images for my blog or even for pasting stuff in OneNote for work for remembering how I did stuff, clarity, sharpness, and just overall look matters to me.  Don't asky me why, it's just en-grained in me
• The tools are sub par.  Sure they attempt to do the same things Adobe does, but again, you end up having to either take a lot of steps to do the same thing or you can do the same thing as in Adobe or the results areis just not that good when you apply effects or filtering I've noticed as compared to Adobe products.  Sure sounds stupid but this stuff matters to me

I can't afford Adobe Photoshop.  So the next best thing is Adobe Elements and I highly recommend it for developers at least.  IMO it's basically a very dumbed-down version of Photoshop probably and it's good enough for me.  It's got high quality and advanced tools, just enough for a developer but not over the top which this wouldn't hack it for a designer.  So it's perfect.  Elements is only $50 people, it's not like it's gonna break the bank.  Get it, it'll save you time (efficiencies) and provide you much better and more powerful control over the fine grained stuff as compared to Paint.NET, etc.  In fact Costco carries it for even cheaper sometimes.  Check there.

Anyway back to how I create that blur effect.  It's simply the Gaussian Blur.  

Pay attention to the options.  You can tweak the transparency (how strong the blur effect is) by moving the transparency bar left or right to get it just how you like it:

Note that in PhotoShop Elements, after you apply the filter once, then you get a nice keyboard shortcut that's activated that you can use from that point on to quickly apply the blur again

So I do this a lot with code to protect sensitive info:

Cheers.

Using ReSharper to remove Code Smells and Keep Code Cleaner

I promote ReSharper always as a necessary tool that I feel all developers should definitely be using.  In fact there are teams I've been on that require it as they've decided that the tool is so useful that everyone should be on board and using it because it helps so much that it became a requirement to use it literally.  And on those teams developers didn't debate using it, they were already using it or if they weren't they were all for it because they saw how it can literally help the team to be more efficient in so many ways.

One of the big reasons to try and make it a standard on your team is about is keeping code clean.  Some people don't think they have any use for a tool like ReSharper.  They're "proud of manually coding everything without much assistance from intellisense".  Well that's just ignorant.  And most likely those kind of developers are producing code smells for the rest of the team and they don't even know it or causing themself extra pains that they weren't even aware were walls/pains in the first place on a day-to-day basis!

And remember your code is everyone's code.  The code base belongs to the entire team, not just you.  So if you think it's ridiculous to keep even the smallest lines of code clean and it's below you, you might consider another profession.  Do you think accountants allow messes?  Doctors?  The answer is no and it should be no different in our profession as Software Engineers or "Craftsmen".  What you do affects everyone in your development team so you need to view the code YOU write as such at all times and be thinking about how it might be reusable, cleaner, etc. for everyone else who has to work with it in the future.

Turning back to ReSharper.  It's such a gem in that it clearly points out unnecessarily code in every class and every line of code in that class.

There's no reason if you have ReSharper installed that you aren't by habit removing unnecessary code as you come across it, which is part of the boyscout rule, keeping the code campground clean.  As you know the boyscout rule that so many great teams abide by is that every time you check in code, it should be a little better than what it was before you check it in.  Robert Martin's Clean Code book emphasizes the boyscount rule.

When you are in a class and you have ReSharper installed, this stuff just screams out at you.  And for me it's just a habit to remove it.  It feels gross to have it in here...and you should feel the same way.  It takes up no more time doing this;  It does not slow me down as it's just a few seconds to remove this stuff as you go and as you see it elsewhere in an entire class.

Look at these examples where ReSharper has pointed out/grey out unnecessary code (I pointed it out with yellow here):

unused usings

unecessary "this." where there is no object type conflicts whatsoever

unecessary Fully Qualified Types where you should have added a using statement

unnecessary explicit conversions:

unnecessary chatter:

unnecessary default assignments at times

Would the examples above give you "code itch" if you knew about them?  It's very much code smell, and it really should make you itch if you truly care about keeping your code base clean.

Why should we removed this stuff? for READABILITY, simple as that.  And having more readable code leads to easier maintenance for all.  Don't be lazy, get rid of it NOW while you are working in that class before you check it in.  ReSharper makes it stupid easy and quick do do this, and It's part of being a professional Software Engineer to keep this clean.

One of the things I do just by good habit right off the bat is when I make a new class in C#, I immediately remove the default usings that are generated at the top as initially they are unused anyway.  half the time you won't end up need a lot of them once you are done with the class anyway.  ReSharper will simply hint and allow you to add using statements quickly and easily anyway when it detects you need them.  So start off with a nice clean template is what I highly suggest so that this stuff is removed initially to start with.

Now you may be thinking "hey I like to show things explicitly to make code more readable". You know what?  you're actually making it less readable.  For instance if you think you still need to do something like establishing a variable with default such as int someVariable = 0; and you know though in certain cases you don't need to explicitly show that you're setting it to zero.  Seriously, stop over thinking and just get rid of it.  It's like the same with commented out code, get rid of it, it's clutter.  99% of the time you'll never use that commented code again.

ReSharper's Marker Bar

Now another thing that people who have even used ReSharper for a while don't know about or notice which for me is an awesome feature is  the Marker Bar.

When you open a class, look to the right.  ReSharper outlines problems, hints, or suggestions in code making it very easy to see an overview of your class in terms of code quality and errors that exist:

And all you have to do to get to that line of code that is a problem is to click on that colored bar on the right.  

ReSharper shows different colored bars to the right to point out different things:

Don't you love that?  In fact there was a team I worked with who decided that a good standard for the team as part of cleaning up code would be to check this in every class you've made changes to BEFORE you check in the code.  

So get rid of unnecessary code or use the hints to make the code more compact, do it, then check it in.  You start to view your classes different with this feature too.  Because when you open classes, you start to look to the right automatically and it just becomes a habit to use this feature to see if you can clean something up before saving your code and checking it in.

This just touches the surface in how ReSharper can help a team keep code consistently clean and uniform.  There are many more features that I'd like to resurface later in a future blog post.

While most ReSharper users already know about this, there are plenty of developers who have never heard of a tool like ReSharper, refuse to use it, or don't understand some of its benefits.  So I like to resurface some of this stuff once-in-a-while hoping a newbie finds out about ReSharper and some great stuff they and their team are missing out on.

A Journey to TDD - Part 3 - Creating a TDD test with ReSharper

To learn TDD takes time.  It takes time to learn how to do it, but also to do it in the way that is efficient as possible.  So that shouldn't stop you from doing TDD.  That includes using and learning tools like ReSharper and keyboard shortcuts to make generation of production code fast.  VERY fast.

Again when I talk "production code" in the context of TDD, that is code you create AFTER you code the lines in your Unit Test of things that don't exist yet.  "Things that don't exist" could be anything from the core class you need, new methods in that core class, or properties that you want to populate as part of your TDD Unit Test.

So I wanted to find the fastest way to generate the classes, methods, whatever from my Unit Test...that is generate the stubs that do not yet exist as fast as possible.

After researching a bit, I found that there are 2 ReSharper keyboard shortcuts that you'll need and that's literally it!  Those are the following:

• Alt + Enter
• F6

At first I found the Efficient Navigation when doing TDD/BDD with ReSharper video from JetBrains but it's very old.  It talks about TDD with R# but that's ReSharper 5!  Apparently they have not updated their videos in 10 years or so.  While most of this is still valid, I found a better option, F6 for the moving of the cla

Anyway, I found it, was just what I was looking for.

Later, after applying Alt + Enter and Ctrl + Shift + R (refactor menu), I found yet a quicker way which was just F6 for the refactor menu.

So lets take a look at how you would apply this in Test Driven Development because that will also show and explain how ReSharper will help you in this process once you get the keyboard shortcuts down by habit just from routine practice.

Using the Red, then make Green, then Refactoring principals of TDD, here's what that looks like and how I used the shortcuts to perform a typical creation of a unit test against a use case and necessary classes related to one particular unit test:

1) Always Start with a Use Case (Story) to drive what tests you need

Eventually this will just come naturally through time as habit, but intil then, be sure to keep reminding yourself and try not to forget that TDD tests themselves are a form of living documentation.  When a team looks at TDD tests they should feel confident that those who created those tests did it with Use Cases driving them...and that they are not some abritrary guesses.  

So you should feel good that with TDD you have guidance.  You don't just blindly start off guessing what you may need for "possible" requirements in the future like many devs have done without TDD and who create much more code than is needed in a lot of cases (wasted time).  Instead, you don't need to guess where to start.  TDD tests are and should be driven by Use Cases (Stories)

Your test classes should therefore act as documentation itself.  Meaning anyone should be able to go into a test class and it can be viewed as a footprint for business requirements.  Tests in your class were written for business requirements so the intent and reasons why those tests are there should read like documentation.  Meaning your test names should be clear on what they are testing.  And each unit test has a direct relation to one or more Use Cases that drove the creation of these tests.  So these tests are the business requirements literally from use cases.

Also all your tests serve as a form of documentation to other devs.  If you want to know how to call something, look at the tests!  They show you exactly how one could call a certain method in many ways as if you're coding via TDD you'll have a lot of tests per method usually.

And as a result, you are driving your team to create LEAN code.  Since Unit Tests are driven by Stories and you are to make sure unit tests are as small as possible each, some seemingly ridiculous to newbies, they are not too small.  Because by creating small tests, you are thinking about the parts you need to satisfy those business requirements.  And a unit test by definition means you test ONE very small thing.  That could literally be testing to make sure a method does not return a null instance or doesn't return an empty string.  All these kinds of little tests are things that could go wrong while you code methods and classes for the use case.

And remember you aren't going to know what tests you need instantly even if you have a use case right in front of you.  One of the good things about TDD is that it forces you to think about what you need for a use case.  So you're only creating the code you need, at its leanest.  Just enough code to pass the tests that make sense to support the business use case.


So lets start with a hypothetical Use Case:

    Figure 1 - a user story in Jira

So this user story has a couple tasks (we'll only talk about the first two):

• create an initial Web Service class stub
• create some method stubs we think we'll need to support facilitating calls to various payment processors
• Create some utility methods for parsing proprietary XML, sending API requests, creating request tokens, etc.
• ....

So this is a business requirement.   Tests we create should make sure our code is satisfying that business requirement.

The first two tasks are dependent on each other so our tests will naturally involve the two anyway (you need a service and you need methods after that)

1. We'll create a new PaymentServiceTests.cs class to hold our unit tests for this service
2. We'll start thinking about what this service should do/provide, if it needs a constructor and some initially wiring up on a constructor for any reason, and how it might start out. This is the part of TDD that forces you to think about what you need now and at its leanest.  This is the best way to discover what you need based on the Use Case
3. As we go, we'll naturally start thinking about and as a result discover how we'll implement the production code in these methods and class to make our tests go green

Now Lets start on the Tests to Support these requirements

First lets create the service Interface.  Note we could also be creating a class but we'll do it by an interface for now since that's normally where I start when I create a web service because I start thinking about what methods we'll need for the service and there are several reasons I'm using an interface here that I won't go into in this post

To go about this, lets start creating tests in our PaymentServiceTests.cs class:

Usually most TDD tests start out with checking the absolute very basics.  We're talking about stuff like making sure you even have an instance of the service object itself.  When you do TDD again nothing is too small to test.  It may seem absurd to test something like a valid object but you'd be surprised that these things can fail at any time in the future if people start changing the implementation of the class, initialize it wrong, or whatever...

So the first test simply checks that we have a valid instance (object) of the service we want to use, in this case our PaymentService.

    Figure 2 - our first TDD based unit test for our new PaymentService and using 
    Roy Osherove's convention of method naming as well as comment guiding parts of the test     code inside (Arrange, Act, Assert)

Because I want to base my service off an interface, we know we'll need an Interface AND a service class that implements that interface.  We also know we'll need methods in both places right?  A method stub in the interface and method implementation in the Service class. 

(Some may argue we don't need an interface here but I can argue some reasons that we benefit from having one here.  I'm not going to debate that now, so just follow along...the point is to get a test of how to start TDD which again I'm learning as well but figuring out more and more every day at work.  We do not have a certified TDD guru on board so we're all in the same boat, learning and trying to do TDD right.)

The Service Interface will house those methods that we want to expose publicly to the client/consumer of this Web Service.  In TDD you want to only unit test public members for several reasons that I will not get into in this particular blog post.

The Service Interface is also where we will house and define the WCF or other specific attributes that the methods will rely on.  We are adding attributes in this case because we are creating a RESTful WCF service.

So if you look at the test above, I thought to myself ok, at the very least, we need a valid service instance before all else.  This is typical in the TDD world.

One interesting thing to note.  For now, I like the approach of creating the assertion first.  By doing so it makes me think about what the test expects as an outcome to support the use case  

Then after creating the assert, going backwards to create the non-existing class or methods and code as if they are available but we know they are not that the assert is using.  This is called Failing First (going Red first).  Meaning you code as if those interfaces and classes already exist but we know they don't.  That's ok and what you want to be doing, it will feel awkward at first but you will see the beauty of this later as you get more practice with TDD and start seeing the light as to why this is the first thing you do if you are coding via TDD principals.  

Again, don't be tempted to go create theses files (class and interface).  When you do TDD, You want to generate the actual class and interface files from your test.  And this is where ReSharper will really automate that and help you do it quickly.

So first I create the assert:

    Figure 3 - initial assert to support this Unit Test.  This unit test will be one of many to                               come as we create more tests support our Use Case
    
   This asserts says I expect that I always have service object instance to work with at the very     least.  We need that do do anything period if anyone wants to start using our service.

Next, lets start creating production code (implementing the actual method, class, interface, etc)  to support the assert:

    We needed to create the variable called  serviceInstance.  To do so, that means we'll 
    need both a ServiceInterface and related Service class that implements that interface.  
    Again the interface just abstracts out WCF specific stuff and also defines the public 
    contract which is very common when creating WCF services.  We could define a public 
    contract for WCF with just a plain class, but I have my reasons for 
    doing it this way, there are many benefits in this particular case.

    So I just started right in creating the variable as if everything exists.

    And what you end up with is red invalid service and interface references.


Next step is to create the production code.  Meaning we need to start making this test green.  Putting another way, we need to make this test REAL.

Now here's where ReSharper is very handy.  There are a couple things we want to do to accomplish creating our interface and test class here:

• We need an IPaymentService.cs interface and a PaymentService.svc.cs class
• We need to be able to create new files for these
• We need to be able to decide where we want to create those files as we don't want them located in our Test itself
• We want to be able to reference the namespeces for those new classes in our test project so it knows about them (in other words we'll need using statements for these at the top to recognize they exist)

Now the nice thing about ReSharper is it helps us do this very easily and quickly which othewise would take minutes.  

Here's what ReSharper can do for us in response to the steps we'll need to take in the list above:

• We'll need only 2 ReSharper based keyboard shortcuts already built into ReSharper to assist us
• ReSharper will automatically inject the using statment in our Test class after all is said and done (you don't even need to think about it, nice right?)
• Optional benefit:  I like using the ReSharper test runner, which to me is more powerful and easy to use rather than MSTest runner or NUnit's crappy test runner

Now here's how we'll finish the rest efficiently with ReSharper:

First lets create the Interface class stub and file:

Place your cursor at the beginning or end of IPaymentService and press Alt + Enter.  Nice right?!!!  you immediatley get an option instantly to create a new interface:

This will create the interface stub in your test class:

    That was Jimmy Johns-like freaky fast right?  Huge time savings right there, no excuse to 
    say TDD is slow (well after you practice and get this down pat that is)

Ok and now lets create the PaymentService class stub, same deal, Alt+Enter:

Nice right?!?!  but wait, look again.  ReSharper also helped us out by the fact that it knew the context.  It knew not only to create that class but to automatically implement
IPaymentService based the context of the line of code where you told it to generate that 
class from.  Awesome right?  You should be saying damn straight...because this is the kind 
of stuff Visual Studio doesn't do for you...stuff like this that saves you so much time.  This 
goes beyond basic generation, this is smart generation at the same time saving you a few 
more steps.  ReSharper is smart people.

Finally you say to yourself, well that's stupid, we don't want this here, these should reside in our WCF Service project.  How can I move these and also create a new file at the same time?

Again ReSharper to the rescue.  All you need is F6 on your keyboard.

All you need to do is place your cursor at the beginning or end of what you want to move, this being the PaymentService class and choose "Move to Folder":

   Then this brings up a quick dialog to allow you to finish that move and also specify what 
   project and where in that project you want to move this and also create a file for this:

    Ok great.  However it defaulted to the location being our current test class.  Lets change         that.  Backspace a little and ReSharper automatically adjusts the list to show you more and     more up the tree of projects and folders in your solution:

    Ok cool, but I want to go all the way back to the root of my solution and choose a different 
    project.  So instead replace it and type in the name of your project and you'll get a broader     list up the stack to choose from.  Then just arrow down to which one you want:

   Once you select the right project, then add a slash "\"  at the end and it'll start showing 
   you the folders within that project to choose from:

    OPTIONAL: Also notice you could use this icon at the top right for another way to visualize     the solution stack as well:

    
Anyway, I've told it where to generate the class and now it just did.  It created the .cs files and placed them where I told it.  

I repeated the same set of steps we just did to move the Interface as well.

Now our Test class is clean again and just contain tests:

And look!  And since I use the ReSharper Test runner, it automatically detected what Unit Test Framework is on, so it added a nice little icon to the right that we can click on to run the test:

And results shown in the ReSharper Test Runner shows our test now runs green!  We've just created just enough production code to make this particular test past.  So we've just created what we need and only what we needed for that test.  We're creating LEAN code and that's just one of the benefits of doing TDD and following its principals in order.

Actually I had to change it up in the end to make it go green, just an example of how TDD makes you think about stuff and make it work

Tools used in this example:

• VS 2012
• ReSharper 8.0.2
• My Brain and thinking based on the Use Case

Till next time, work hard and learn TDD ok?  Stop Making Excuses. It's worth the work now, you'll benefit beyond your wildest dreams later once you get this stuff down and it becomes habit / no brainer later on.