NerdNotes.Nethttps://nerdnotes.net
Notes from a Technology NerdSun, 18 Feb 2018 04:49:55 +0000enhourly1http://wordpress.com/https://secure.gravatar.com/blavatar/43de35baaef3c8ed0e63fd84f5b765ea?s=96&d=https%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.pngNerdNotes.Nethttps://nerdnotes.net
A New Tool Suitehttps://nerdnotes.net/2016/11/26/a-new-tool-suite/
https://nerdnotes.net/2016/11/26/a-new-tool-suite/#respondSun, 27 Nov 2016 06:07:01 +0000http://nerdnotes.net/?p=62Today I started a process that I didn’t expect I’d ever choose to start while working as a software engineer

It’s time to say goodbye to Visual Studio Enterprise Edition. It’s not something I’ve considered lightly, after all I’ve had a Visual Studio Enterprise (aka MSDN Universal or equivalent) subscription since somewhere around or before 2000. Long ago while working at SAIC as a software engineer primarily focused on Mumps programing and looking to shift my career to Microsoft technologies like C/C++ v7.0, COM and ASP.

My thoughts then mirror my thoughts now – a good craftsman always maintains their own set of tools. Even if a company has a set for you to use – you always have your own tools.

Back in the 90’s, it was an investment in my skills and in making sure I could move beyond my current technology stack, and in my opinion it paid for itself. Having the subscription initially not only helped me grow my skills it allowed me to start my authoring with SQL Server magazine and its family of newsletters and was instrumental in my ability to author Wrox titles.

Over time many of the years I’ve had a subscription were complementary based on having Microsoft Most Valuable Professional award status. In fact, the one request I had as my focus moved to my role as IT executive for Rubio’s was that as I leave the MVP program Microsoft allow me to renew my subscription vs. starting over. Even last year after I moved on from Rubio’s when the renewal came up, I kept my tools. The subscription continued to provide the tools and resources around the skills I was sharpening. While the overall market had shifted, it was for me, still the best option at that time.

However, even then and more-so over the past year working at Hunter Industries I’ve noticed changes not only in the market, but in Microsoft. In reviewing my renewal this year, I was looking at a very large cost to renew when I was only using a subset of the components. After all I wasn’t looking to set up a personal TFS, or a copy of SharePoint.

I itemized the cost of another option to see what it would cost to get the components I wanted

My primary concern were the features in Visual Studio. In reviewing these however (they are available here: https://www.visualstudio.com/vs/compare/, I could see that the core loss in features were outside the scope of my needs – or replaced by the Resharper Ultimate subscription.
Thus, today I uninstalled Visual Studio Enterprise Edition…

The result is that the cost will be about one-third of renewing an enterprise subscription.

]]>https://nerdnotes.net/2016/11/26/a-new-tool-suite/feed/0billsheldonuninstallIndecent Exposurehttps://nerdnotes.net/2016/10/15/indecent-exposure/
https://nerdnotes.net/2016/10/15/indecent-exposure/#respondSun, 16 Oct 2016 01:34:14 +0000http://nerdnotes.net/?p=11Well, it’s time to move past the point of good intentions and get started actually writing again. I took a hiatus from my blog for a long time but my goal is to write one short post each week to get me back in the habit. As noted the blog has migrated to a free WordPress site since I don’t see a need to drive my own stack and we’ll see how this goes.

For this post I’d like to discuss testing. In my current role I’m with an organization that is truly dedicated to a Test Driven Development methodology. What this means is we really work to ensure that we write tests before we start developing. (https://msdn.microsoft.com/library/aa730844)

Another piece of background information is that we have strong teams and use a development style known as mobbing. I could reference several links to go into details but I’d like to save that topic for another day. (http://mobprogramming.org/)

However, a good summary is to state that our code is under constant review. As such we tend to strive for code which is very clean. We look to minimize what are known in the industry as “Code Smells”. Something else for a future post: (https://blog.codinghorror.com/code-smells/) – this is currently my favorite post on the topic.

So now in my fourth paragraph, lets get to the point already. As part of our process we create a ‘Test’ project to accompany each assembly (executable or library). This is considered a best practice – however, I’ve seen a code smell consistently emerge from this process. In short we’re frequently guilty of ‘Indecent Exposure’.

As defined at Coding Horror (link above) this means we are guilty of unnecessarily exposing the internals of our classes. We are taking methods which should be private and exposing them as public. (Note my own name for this was ‘interface pollution’ however I think that term may have an overloaded meaning and I like indecent exposure better.)

The issue surfaced during a discussion about interfaces where I was explaining how in C# interfaces are primarily available to allow for polymorphism where we would otherwise look to multiple inheritance. While this is an engaging topic in and of itself, part of my comments were that we need to remember that each class defines it’s primary interface based on it’s public properties and methods.

I then shocked another experienced engineer when I said, that I was looking at potentially suggesting that we consider a ‘test folder’ vs. constantly taking methods which were and/or should be private and making them public to allow our unit tests to access them directly. I also added – in the same breath – that this wasn’t a solution I was suggesting, but something I needed to continue investigating. Note this is yet another great blog topic, but suffice it to say – I favor using separate test projects when feasible.

The challenge of course is that for a really focused test you want to call a method directly at a very low – single action – level. However, most such methods are part of a larger process and shouldn’t be exposed publicly.

In some cases I’ve heard people suggest that we write a test, test the method and then disable(ignore) or discard the test. However, I’m almost as repulsed at this idea as continuing to indecently expose methods. One of the core features of TDD, is that as development continues, it is possible to verify that nothing has broken – and ignoring tests means you lose the largest return value of tests.

Fortunately I was able to find what I consider to be an excellent compromise. Under Visual Studio it is possible to add an attribute to the assembly you are looking to ship that allows it to specify another – test assembly – which can see internals of your implementation. This means you can have your production code register an assembly that can see those methods you designate as ‘Internal’.

[assembly: InternalsVisibleTo(“UnitTestProjectName”)] – this attribute added within your assembly.info file allows you to insert the name of your unit test project and write tests that don’t require the pollution of your public interface.

]]>https://nerdnotes.net/2016/10/15/indecent-exposure/feed/0billsheldonA new hosthttps://nerdnotes.net/2015/08/11/a-new-host/
https://nerdnotes.net/2015/08/11/a-new-host/#respondTue, 11 Aug 2015 23:55:47 +0000http://n3rdn0t3s.wordpress.com/?p=4I’ve had the NerdNotes.net domain for many years, and it’s time to bring it to a new host. My old host was custom and to be honest was probably just waiting to be hacked. So I’ve moved to a simple new host on Word Press for now and over the weeks and months it may change or expand but for now it’s time for a new host.
]]>https://nerdnotes.net/2015/08/11/a-new-host/feed/0billsheldon