Thursday, September 11, 2014

Upcoming Speaking Engagement

The Binary Language of Music - Take a fascinating journey into how our minds work and discover how binary and mathematical patterns found in music can be used to learn the underlying language of music theory.

When: Next Wednesday, September 17, 2014 @ 6:30pm

Where: Fayard Hall room 107 or 109.  (not sure which one yet)


Goodies/Freebies:  Free Food, Free Drinks, Free Prizes, Free Jobs, Free Capitalized Words For No Reason, Free knowledge, Free Networking.

Wednesday, September 10, 2014

Upcoming Speaking Engagement

Take a fascinating journey into how our minds work and discover how binary and mathematical patterns found in music can be used to learn the underlying language of music theory.

Saturday September 25th, 2014
The Binary Language of Music
SQL Saturday Mobile
9:00am

More Info

Friday, February 21, 2014

From Coder to Craftsman in 48 Hours

As the lone developer working for a large engineering company, all of my training had been OTJ. It quickly became apparent that I needed to find better ways to design, develop, and produce high quality software. I began to read everything I could get my hands on about software, design, usability, databases, design patterns, testing, and architecture. I was particularly interested in design patterns. I had read several books on the subject (my personal favorite being Head First Design Patterns), and was looking for new examples of the patterns I had already begun putting into practice.

While browsing the shelves at a Barnes and Noble in Houston, TX, I happened upon a book called Agile Principles, Patterns, and Practices in C# by Robert Martin. I did not realize it at the time, but that book would forever change me as a software developer (I read the book cover-to-cover that weekend).

This book is filled with a library of knowledge, but is very well edited, removing the fluff and leaving the reader with only the white meat. It often reads like the Tao Te Ching, offering insight and wisdom that must be reflected upon and internalized in small pieces before eagerly moving on. Each chapter is succinct and provides simple and appropriate working examples that can be put to use in your own code or process right away - but it does something more.

This book uses the principles as a jumping off point to introduce deeper programming concepts (“code smells”, design pattern usage, TDD, assembly and dependency management, and refactoring). Rather than a comprehensive compendium of rules and dogma (although Robert Martin does provide anecdotes and evidence to support his assertions), it provides a blueprint for agile philosophy, and you the reader, are left to implement them in the manner best suited for your circumstance.

I was profoundly affected and influenced by the substance of this book and did not want the knowledge to end. It validated some of my existing beliefs, gave new perspective to older ones, and provided me an entirely new lexicon to pull from. The principles, concepts, and ideas enumerated in this book form the basis of our core development philosophy at Envoc.

Agile Principles, Patterns, and Practices in C# can be purchased for about $60, and it is worth every penny. Put in the time, effort, energy, and erudition necessary to absorb the information contained within and you will have no choice but to become a better developer and professional.

Wednesday, June 5, 2013

7 Stages of Design Pattern Adoption

When I first read the “Gang of Four” book, one message in particular really hit home with me – software developers face problems, the same problems over and over again, and design patterns provide reusable solutions to those problems. And I thought “Wow! I’m a software developer. I have problems that need better solutions, bring it on!”. It wasn’t until later that the realization struck that design patterns, and their usage and adoption, are much more subtle than that.

At the beginning of my career, I was completely unaware of design patterns or SOLID principles, or even object-oriented programming. As I progressed and matured as a developer, it became obvious that I needed to find better ways to craft software. In that process I went through several stages of professional development leading to the eventual adoption and assimilation of design patterns into my coding process.

Stage 1: Denial

“Patterns? We don’t need no stinking patterns!”

Due to ignorance, inexperience, or resistance, many developers just flat refuse to invest time in learning about patterns, SOLID design principles, or the basic building blocks of object-oriented programming. This only serves to stifle their professional growth and credibility.

Stage 2: Curiosity

“So what were those design patterns you were telling me about?”

Eventually there comes a time when the tried and true methods of the novice developer run directly into a wall, or necessity leads them in search of new frontiers. The rot has overtaken the project and killed new development, created a maintenance nightmare, caused several to question their career decision, and accumulated a mountain of technical debt.

Stage 3: The Maslow's Hammer

“Get me some nails because I have a hammer, and its name is Strategy!”

New knowledge leads to excitement but can often lead to blinders. Until we’ve had time to disassemble the information, experiment with and implement it, and put in the requisite time to internalize it, the whole world looks like it fits into the (state your pattern name here) pattern.

Stage 4: Erudition

“Strategy does not work for everything. What else you got?”

Soon we realize that not all of our problems can be solved by, or forced to fit a single pattern. Now is the time for study. Not just study, but understanding, and for design patterns one of the most significant moments of eureka comes when you grasp the concept of intent. What is the intent of the pattern? What specific problem was identified as needing a solution and thus the pattern defined because of?

Stage 5: Restraint

“With great knowledge comes great responsibility”

The more seasoned pattern aficionado sparingly begins to introduce patterns that meet the specific criteria of the challenge they face into the domain. SOLID becomes more of a conscious decision. Analysis of the code and design becomes a deeper and richer experience.

Stage 6: Emergence

“First you learn the instrument, then you learn the music, then you forget all that and just play”

You have spent so much time, effort, energy, and erudition, that patterns naturally begin to find their way into your code. You still consciously recognize a Factory, Strategy, Façade, or Proxy, but it is merely an acknowledgement of its existence rather than an effort to find a place to introduce a pattern. There is a measurable change and improvement in the quality and structure of the code and the coding process.

Stage 7: Mastery

“Those who call themselves masters are not masters”

At this level, ideas flow directly from your mind to the keyboard without hesitation, without impediment, and without fear. But the master is restless and never satisfied, always evaluating and re-evaluating where he is and how he can be better every moment. The master sees the code not in terms of methods or classes but as an organic system of maintainable order.

Tuesday, August 28, 2012

A Religious Discussion

Have you ever heard a DBA prattle on incessantly about the importance of the database and their apotheotic role in maintaining the space-time continuum? Me too. And while databases (and occasionally DBAs) have their place in software, I would contend it is not at the same level as the code or UI.

So I am throwing down the gauntlet to all of you database gurus. I challenge you to construct a lucid, well thought out, logical argument that disproves any or all of these statements:
  • A database is for storing and retrieving data period.
  • Business logic does not belong in the database period.
  • SQL server is not a software development platform period.
Let the conversation begin.

Wednesday, February 22, 2012

Sql + RegEx = Awesome

NOTE: This is not a post about regex (if you want more info check out http://www.regular-expressions.info/ or http://www.zytrax.com/tech/web/regex.htm and http://gskinner.com/RegExr/ is a great tool for testing your regular expressions).

One of my clients called and asked me to create an auto-complete list of employee names – no problem. I cracked open the table and started looking at the data only to realize that there were names that were “not valid”, i.e., they contained invalid characters, numbers, periods, etc. When I questioned them about it, the response was “just filter those out”. Now I was ready to get to work.

Step 1, filter out all the names that begin with a number:

SELECT
    FirstName, LastName
FROM
    dbo.Employee
WHERE
    FirstName NOT LIKE '1%'
    AND
    FirstName NOT LIKE '2%'
    AND
    FirstName NOT LIKE '3%' 
    ...
    AND
    FirstName NOT LIKE '9%' 

Great, now on to step 2, filter out names that begin with a dash, period, comma, or backslash:
SELECT
    FirstName, LastName
FROM
    dbo.Employee
WHERE
    FirstName NOT LIKE '1%'
    AND
    FirstName NOT LIKE '2%'
    AND
    FirstName NOT LIKE '3%' 
    ...
    AND
    FirstName NOT LIKE '9%'  
    AND
    FirstName NOT LIKE '-%'
    AND
    FirstName NOT LIKE '.%'
    AND
    FirstName NOT LIKE ',%'  
    AND
    FirstName NOT LIKE '\%'  

Awesome, step 3, abandon all of that and find a better way. In reality, step 2 never happened and step 1 only lasted past the first where condition. I knew there had to be a better way and it is inline RegEx, and it is good.
Let’s rewrite the above query so you can see what it looks like using RegEx:
SELECT
    FirstName, LastName
FROM
    dbo.Employee
WHERE
    FirstName NOT LIKE '[0-9-\.,\\]%'

It’s that simple!

In my case, it was the best solution for filtering out data, but you could just as easily use this technique to create complex select statements too. Give it a try and enjoy!

Thursday, January 26, 2012

Structuring Unit Tests

Phil Haack wrote an article entitled "Structuring Unit Tests" (I highly recommend reading it) and it started us talking about how we could adopt this method of test structuring in our projects. The basic structure is a test class that contains test classes for each system under test.

We are a test-first shop and use MSTest as our testing tool of choice. So, step 1, write some tests that follow the structure (I am just going to reproduce Phil’s example using MSTest):

[TestClass]
public class TitleizerTests
{
[TestClass]
public class TheTitleizerMethod
{
[TestMethod]
public void ReturnsDefaultTitleForNullName()
{
//test code
}

[TestMethod]
public void AppendsTitleToName()
{
//test code
}
}

[TestClass]
public class TheKnightifyMethod
{
[TestMethod]
public void ReturnsDefaultTitleForNullName()
{
//test code
}

[TestMethod]
public void AppendsSirToMaleNames()
{
//test code
}

[TestMethod]
public void AppendsDameToFemaleNames()
{
//test code
}
}
}

Right away we noticed two problems. When you use the keyboard shortcut Ctrl+R, C all tests in the class are run. This works great using this structure because it runs all tests in the SUT class allowing you to isolate the scope of tests to run. The problem is when you want to run all tests in the top level class. If you try Ctrl+R, C at the top level, all tests in the namespace get run. This was easily solved by creating a unique namespace for the test class to reside in:

namespace TestStructure.UnitTests.TitleizerTestContainer
{
[TestClass]
public class TitleizerTests
{
[TestClass]
public class TheTitleizerMethod
{
[TestMethod]
public void ReturnsDefaultTitleForNullName()
{
//test code
}

Now we can run all tests in the class without issue.

The second problem is code duplication. If some setup is required for my class before I can perform my tests, I have to repeat it for each class because nested classes do not have access to their parent members. Our solution to this is to make all of the children inherit from the parent test class like this:

[TestClass]
public class TitleizerTests
{
protected Titleizer target;

[TestInitialize]
public void Init()
{
target = new Titleizer();
}

[TestClass]
public class TheTitleizerMethod : TitleizerTests
{
[TestMethod]
public void ReturnsDefaultTitleForNullName()
{
//act
string result = target.Titleize(null);

//assert
Assert.AreEqual(result, "Your name is now Phil the Foolish");
}

[TestMethod]
public void AppendsTitleToName()
{
//act
string result = target.Titleize("Brian");

//assert
Assert.AreEqual(result, "Brian the awesome hearted");
}
}

This is obviously a contrived case where no actual setup is required, but now the TestInitialize method will run before each test in my child classes.

Plus the test are much easier to read:

image

image

We are just stating to experiment with this test structure, but so far it looks very promising.