Unit Tests: Yada, Yada, Yada

If Unit Tests Were Seinfeld Characters

Code Reviews

I do not think there is a single development practice that is more under-used and under-appreciated than code reviews--regular, continuous, active, supportive code reviews.

I went through the first ten years of my career without receiving a formal code review, and only gave a handful of them. During the past three years, I have been part of more code reviews, but nothing like what my current team has been doing, and still not up to the value that I think they can provide.

This is actually the first blog post I think I have every come across on the subject of code reviews:

The Zen of Code Reviews: Best Practices

This is a subject, like #NoEstimates, that I really want to delve into at my current job and hopefully even more at my next.

Angular, Ember, Aurelia, Backbone Programmers NOT Wanted

LosTechies.com has a totally awesome and relevant new post: Platform generalists versus framework specialists.

A trend I’ve noticed especially in Javascript/front-end jobs are emphasizing, requiring, even titling jobs after specific Javascript frameworks. “Ember.js engineer needed”. “Angular programmer”. This raises a few of thoughts for me: 

• Is the framework so complicated you need someone with extensive experience building non-trivial apps?

• Is your timeline so short you don’t have time to teach anyone a framework?

My only gripe is with this line: "I want to be a web expert, a messaging expert, a REST expert, a distributed systems expert. "  Even though I love REST, I no more want to be a REST expert than an Angular expert.

For the record, I want to be a Craftsman, a Clean Coder, a code monkey, a web expert, a messaging expert, a business rules expert, an amazing technical lead and development manger, and a development god. #smallGoals :-)

Incremental Functionalism for C# Developers

Less is more: language features, by Mark Seeman

C#: Program Entirely With Static Methods

I just love that the programming world is becoming more and more functional.  Better code, less code, more testable code, less bugs, and life is always better when you get to solve a problem without having to fix the world.

So take a bite and try removing a bit of state from your methods and classes today.  :-)

Continuous Deployment

I have worked on very few projects in the past fifteen years that would not have benefited from CD from day one, and #noestimates throughout.  

These days everybody wants to try new ideas as quickly as possible in the market. We want to see whether or not our customers like a new feature. If yes then we want to work on the feature and improve it and if not then we want to fail fast and learn fast from the mistake and correct fast. 

To be able to do this a company producing mission critical software can embrace continuous deployment (CD). CD is not a tool nor a simple process, it is a whole pipeline of processes and associated culture changes in the company. CD in a nutshell manifests itself in such a way that if a developer finishes coding a new feature and pushes this feature to a central code repository then a process starts whose end result is that the code containing the new feature is in production and the feature is thus available to the consumers. All this happens fully automated and without any human intervention. This sounds scary, doesn’t it? Yes and no… but let’s look into more details what exactly CD implies.

More CD goodness from Los Techies...

Word of the Day: LINQ-Y

LINQ-y, what a great word!!

Getting More LINQ-y

To checkout later: Lambdas & LINQ in C# 

Web API 2 to MVC 6

Transitioning from ASP.NET Web API 2 to ASP.NET MVC 6

Well, isn't this interesting.  Redmond is insisting on keeping us on our toes!  My two favorite projects have been Web API 2 projects.  I'm looking forward to doing my first MVC 6 project!  :-)

No Estimates

No Estimates with Woody Zuill on .NET Rocks!

NDC 2014: No Estimates, Let's Explore the Possibilities - Woody Zuill

As my thinking has been leading me for the past few years.  What makes Agile truly successful is short iteration cycles, and business involvement.  Not project plans, but open, supportive, bi-directional communication.  And to this end the shorter you can make an iteration, the better.  Make a feature, show a feature, iterate on a feature, and deploy a feature. There is rarely a reason to group multiple changes in a release.  Pick the smallest feature possible, do it, iterate on it, deploy it.  Deploy daily, deploy multiple times a day!

Agile Culture

Today I made a series of Agile related re-tweets:

If you are not demoing at least once or twice a sprint... https://t.co/DJMgunP649

— Michael Randall (@mwrandall) July 1, 2015

If you are not doing meaningful retrospectives every single sprint... https://t.co/DJMgunP649

— Michael Randall (@mwrandall) July 1, 2015

If your burndowns and process prevents you from changing the length of your sprints or your team make-up... https://t.co/DJMgunP649

— Michael Randall (@mwrandall) July 1, 2015

I strongly believe that any step, and new attempted use of an Agile (or Lean) tool is a good thing. One gets better by thinking and trying, and then thinking and trying again.  So my thoughts on this are not a slam on anyone working on improving themselves or their team.  Instead, I'm just pointing out that "Agile" will only work to partial efficiency without these things.

In addition to the above thoughts, Design, Code, Release has another excellent post on Agile.

Each small change and evaluation of said change is a good thing.  Each small improvement should be celebrated and bring pride to your team.  However, no matter how Agile a development team (or even development department) is there will always be pain, there will always be a sense of beating a dead horse, unless the entire company is also Lean and Agile. This doesn't mean your first, or even twentieth thought, should be to bail on your company.  Instead one should always be working with their business contacts outside of IT to help them become more Agile.

My Standing Desk

I have known about standing desks for a number of years now.  But the longest period, up until now, of ditching a traditional chair involved using an exercise exercise ball as my primary chair at work.

However for the past month this has been my set up at work:

I've got nothing but good things to say about it.  I have an anti-fatigue mat, a step stool, a foot roller, and a chair (like a bar stool).  Standing for eight hours comes with its own problems.  But short walks around building during the day, alternating between sitting and standing every couple of hours, and using the stools and roller to vary my stance, makes for a great balance.  

10 Accessories Every Standing Desk Owner Should Have

Podcast Recommendation: TalentGrow

I recently posted a 5 star review of the TalentGrow podcast on iTunes.  I want to share that review here, and recommend the show to everyone: IT VPs, Directors, Managers, Product Owners, Product Managers, Developers, and QAs.  Whether you are a leader or not, whether you just want to be a great team member, or if you just want to be a happier, more successful person there is much Halelly Azulay has to offer.

From the first episode, I was hooked.  Halelly is a rare combination of light (almost bubbly), smart, and driven.  Seven episodes in and she has consistently had on great guests, leaders in their respective domains, and asked good questions.  I'm not sure how someone who has just started is such a great interviewer;  allowing her guests to comfortably share their stories, while keeping them on point, and her listeners engaged.   The first six episodes have ranged over a variety of topics: avoiding being overworked, goal setting, focus, creativity, and performance. But through them all there is Halelly, her love of learning, and her personal desire to improve every day -- while helping others to do the same.  Give the show a try, you won’t be disappointed.

 The TalentGrow podcast is available on iTunes and Sticher.

Agile

Having been on Agile teams that were mostly Agile, and Agile teams that were mostly not Agile. I agree with these two posts by Nathan over at Design, Code, Release : Agile is... and Agile methodologies are just tools.

As with most things, the people who know the least about a subject are usually the most dogmatic about it, and those who know the most rarely talk about it. This most certainly applies to the different Agile shops I've been in.  The most Agile development shops involve a lot of team communication, support, and respect--respect of the company for the team, respect of the team members for each other and respect of the team members for the company.

On these great teams, we talked, we helped, we supported, we did stand ups, we did sprints and sprint plannings, and backlogs, and retrospectives, and demos.  We adapted, and were given almost complete control over  what we did, how we did it, and most of the time when we delivered, Agile was our tool.  Great carpenters rarely talk about hammers and screw drivers.  The find the best, they learn how to use them, and then go about doing what needs to be done: one has tools to build, one does not build in order to talk about tools.

Nothing in Agile is set in stone.  The purpose of Agile is to allow for communication, adapt to ceaseless changes from the business, and to build great products.

First Pull Request into .Net

Getting the first PR into .NET and other tales from an OSS contributor - Adam Ralph

SQL Injection

Troy Hunt has a free recorded webinar on Pluralsight: Why SQL Injection Remains the #1 Web Security Risk Today

NDC Oslo 2015: Functional Tract

Presentations from the NDC Oslo 2015 Track

NDC Oslo Videos: Todo List

My queue of NDC Oslo videos to watch:

Ian Cooper: TDD, where did it all go wrong

Bryan Hunter - CQRS with Erlang

Andy Hunt: Uncomfortable with Agility: What has Ten+ Years got us?

NDC 2015 Security Keynote

Keynote: Bruce Schneier from NDC Conferences on Vimeo.

A Thousand Times, Yes!

Organizational Skills Beat Algorithmic Wizardry

When it comes to writing code, the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity.

I came across the above, here: The most important skill in software development

Totally agree. Great stuff!

Motivation and Drive

Good Stuff from John Sonmez here:

NDC Oslo 2015 Goodness

With NDC Oslo 2015 wrapped up, lots of great goodness in the form of blog posts and videos to come.

Via @bryan_hunter, I've mostly been following the functional programming tract.  However, there is so much more and I'm looking forward to digging in.

Today's post over at The Morning Brew features a post from Dyan Beattie with lots of front-end, WebApi, and RESTfully goodness: Slides and code from NDC Oslo 2015

And finally if you do not know about all of the goodness that NDC Oslo has to offer, take a week or two off from work and go here:

https://vimeo.com/ndcconferences/videos

Jasmine

I'm about to start my first AngularJs project in almost a year.  The two biggest flaws with that last project were 1) I was on a development team of one, ME, with a three-month project timeline, and I allowed a complex form validation scheme to be part of the first release. You think I would have learned from past failures!!! 2) The more detrimental mistake -- to my sanity and my having to spend two glorious summer months, working inside, 60 to 80 hour weeks -- I made was not doing front end testing.

Although, the project did launch, albeit a few weeks late, I committed myself to never do another website release without both a suite of JavaScript unit tests, and Selenium integration tests.  The Web Api projects I have delivered (successfully and early) this year have come with suites of integration and unit tests, but now that I am doing a front end project again, its time to look at Jasmine.  There are of course other tools, and I will explore them as this project progresses, but Jasmine seems like a great place to start.

After searching the web, and watching a couple of PluralSight videos, I want to recommend this series on YouTube. Excellent presentation of the material.

Resume Thoughts

John Sonmez has some good ideas here to consider and look into.

A History of Functional Programming

An informative historical look at function programming.

Joe Armstrong, NDC 2014
Functional Programming the Long Road to Enlightenment: a Historical and Personal Narrative

Interviews: The Factory Pattern

After a recent failed job interview, it happens--even for someone like me who never has a problem getting the next job, I've been refreshing my understanding of the basics. This is always one of the struggles of interviewing, when working day-to-day, year-to-year at a job, the "interview vocabulary" is not fresh in your mind.  Even though you might be working with factories, types, and encapsulation on a regular basis, you aren't talking about it, you are doing it.  One of the values I see in doing this blog, being more active on twitter, and hopefully finding other outlets like StackOverflow and local user groups, I can be more ready for ad hoc interviews, and not just the end of job interviews that I have to time to prep for.

Now the actual feedback I received from the interviewers was not that I didn't ready have good answers to the technical questions, but that I was defensive about (or with) my answers. Unfortunately, given the situation, I was not able to get follow-up feedback on what that meant.  So although I don't have details to report on this aspect yet, I do have a plan for working on my natural tendency of being defensive in stressful situations.

Rant: God, do I hate group interviews! As an introvert, give me eight one-on-one's in a row, take up four to five hours of my day, but do make me sit in a room with two managers, an architect, and three developers.  Ugh!  I've never gotten those jobs, but ALWAYS get the job where I do a series of one-on-one interviews.

One of the question and answers that stand out to me, was the one on the factory pattern. When asked about it, I basically gave that standard descriptor: the factory pattern is a construction, a creation, pattern.  I went into little to no detail, and drew a blank after I said I used them on my latest project. After leaving the interview I remember the awesome factory I create for creating Excel Reports. <sigh>

We had a dozen different individual Excel reports that needed to be generated.  All the reports had the same styles, header, and footer.  But the data being displayed in each report was quite different. So I created a a shared interface and a factory for generating the different Excel reports.

What's interesting to me, and this was something I did based on my gut, and not a reasoned approach, is that after several refactorings I moved from the factory pattern to the facade pattern. It would be an interesting an assignment for myself to re-approach my Excel code and see if I would make the same decisions to move to the facade pattern.  I know the primary thought I had when making the facade was that I did it during my last week on my job when my team members were on vacation.  The choice I had was to make the code as readable as possible or to write documentation.  I am a developer, so I of course chose rewriting my code.  :-)

In an earlier post, I recommend Derek Banas' YouTube series on Design Patterns. Based on what I just wrote I am going to re-watch Derek's videos on the factory pattern and the facade pattern.

Stackify

Stackify: one solution for monitoring, performance, errors, and logging.  Worth considering for your next project.

Featured on a recent episode of .Net Rocks: Instrumenting using Stackify

Agile, You keep Using That Word

Don’t Go Chasing Waterfalls

John Sonmez's latest post made me think of Inigo's sage observation.  :-)

I like to say that my position was on the most Agile team I had worked on.  But even we did not fully get the demo, feedback, revise, demo loop.

Truer words have never...

"Hire good people, and leave them alone" #agileaus pic.twitter.com/jSJ1fDtHxr

— Andrew Thorpe (@awthorpe) June 17, 2015

"Leaving alone" means being there for support, guidance, coaching, setting goals and direction, and most importantly keeping outside demands and interference to a minimum. Nothing less than this, and little more. Hire doers and let them do.

NCrunch: A Must Have

I cannot say enough good things about NCrunch.  If you are interested in unit test testing, if you are committed to TDD, not buying and using NCrunch is like seeing the value in strength training and not doing High Intensity Training. Don't understand the analogy?  That's okay, buy Doug's book, buy NCrunch, use them, and see your productivity and efficiency sore.

I am not an advocate of doing everything in your life, ever single project, to its utmost.  But I am an advocate of doing a few things in your life to the fullest--plus one.  To pushing your limits, to always improving, to taking every opportunity to see how much you have in the tank, and to doing hard things. There is just something about forcing all Visual Studio warnings to be errors, to getting as close to 100% code coverage as possible, to not allowing any method to be more than eight lines, to using the CQRS pattern every where you can, to not repeating yourself ever, ever, EVER.

NCrunch will encourage you to do all these things, while holding your hand, encourage you to do better one day at a time, while not screaming bloody murder at you because you just started.

NCrunch PluralSight Training

Type Drive Development

I came across the concept of Type Driven Development this morning.  Placing this here for future reference.

Why type-first development matters

Type-Driven Development

More Typing, Less Testing: TDD with Static Types, Part 1

More Typing, Less Testing: TDD with Static Types, Part 2

C# and Fody

Fascinating stuff!

.Net Rocks! Extending C# using Fody with Simon Cropp



Fody on Github

Uncle Bob on Mocks

This is the clearest and most thorough presentation on the various types of test doubles and their relationships to one another I've seen:

https://cleancoders.com/episode/clean-code-episode-23-p1

Test  Double, dummies, stubs, spies, mocks, and fakes.

Structure and Interpretation of Computer Programs

Structure and Interpretation of Computer Programs by Gerald Jay Sussman and Hal Abelson is recommended by Robert C Martin in hist NDC 2014 lecture Functional Programming; What? Why? When?

Unlcle Bob also recommend the MIT lectures by Sussman and Abelson.

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/

I am currently watch "Functional Programming; What? Why? When?" and am adding the above links for future reference.

Mark Rendle's Worst Programming Language Ever

Mark's talk at 15th December 2014 in London at The Skills Matter eXchange

https://skillsmatter.com/skillscasts/6088-the-worst-programming-language-ever

Component Driven AngularJS Development

Top 5 benefits after 6 months of component driven AngularJS development

Architecture: Food for Thought

Software Architecture vs. Code by Simon Brown

I've been thinking a lot of about architecture a lot over the past year, and just loved this presentation. Many thought provoking ideas:



One of my favorite ideas here is that for all the good unit testing provides, there is much baggage it comes with, and some "problems" it causes. As computers are getting faster, and as it because easier to spin up VM instances, we have so many more options.

I love the idea of relying on integration tests more than unit tests. Integration tests that run just as fast and easily as unit tests. I love the idea of component architecture. I love Uncle Bob's idea of screaming architecture and The Clean Architecture, not being implementations (MVC, SQL Server, AnjularJs, etc), but conceptual (Employees, Accounts, Payments, Users, etc): Architecture, Use Cases, and High Level Design

Lots of wonderfulness and efficiency here, if we can learn from the past (tight coupling and spaghetti code) while not over-architecting and over-layering for the sake of our tools.

Debugger Tips and Tricks

The irony, while waiting for my dentist appointment, I'm watching this:

Debugger Tips and Tricks for .NET Developers with Visual Studio 2015

My First Github Project

2015 action items for improving my technical skills, my people skills, improving my network of great people in order to increase job satisfaction and achieve some career goals that have been floundering.

Step 1: Start this blog, check.

Step 2: Get  more involved in local user groups, check and check.

Step 3: Be more active on LinkedIn and networking in general, check.

Step 4: Start a GitHub project, check.

Here is the git hub project I started earlier this week: https://github.com/mwrand/SaraCms/tree/dev

I know, I know, not another CMS system!  There is totally no need for another CMS system. However, for my entire career this is the thing I've done.  My first real exposure to professional development was as the technical lead at a couple of web design companies.  And even past that, all the projects that I have worked on have had elements that would make great additions to a repeatable, extendable framework/system that would  allow for code reuse, easy deployment of large applications, and the tools developers need to make their projects extremely valuable by leveraging past projects to allow them to focus only on the "new work" in their current projects.

Given that there are literally hundreds if not thousands of CMS projects on github, and hundreds of commercial CMS systems on the market right now, I have no idea if I can get anyone working on the project with me, but with new adventures like this you have to start with what you know, what you are passionate about.  And as a developer, a development lead, there is little that gets me as excited as development/business productivity.

In addition a CMS system gives me the opportunity to tie together code I've written, and  dreamed about writing in the FIFTEEN different jobs I've had over my 12 year career.  When you have worked as a contractor, and on short term assignments as much  as I've had there is a real (mental/spiritual) value in being able to tie all of that history together.  I also think that if I can hold my motivation on this project there is a chance a number of side projects (libraries, frameworks, etc) can be pulled out and be useful to others.

But ultimately, I want a large project, a large code base, that I can point prospective employers to, because I love working on large projects with big teams.  Having a large CMS is a great way to show my skills for working at that scale.

So you want to be a team lead...

"Don’t tell people what to do, show them. Do what you expect other people to do, yourself, first, and then let them see why what you are doing is beneficial.

"You can argue and try to cajole people until you are blue in the face, but if you really want to inspire people, if you really want to move them to action, you have to lead by first showing them the path to take and generate the results to prove that your way is best.

"If you want developers on your team to write better code, you have to start writing better code yourself and you have to write such good code that the effort you put into that code is apparent. Only then can you credibly produce a set of coding standards that will help others to write good code as well. Once they see your code, they should be inspired to write code of the same quality and understandability.

"If you want developers on your team to write unit tests or practice test driven development, you had better be not only doing the same, but having tangible results that show what you are recommending is the best way to proceed. This will require some commitment and pragmatism, so that you aren’t just preaching something because you heard or read this was the best way to do things.

"If you want developers on your team to work on developing their skills and personal development, you had better be a shining example of the same. You should spend more hours than anyone else learning new things and sharing what you have learned with others. You should be the one writing up blog posts that share what you are learning and inspiring others to do the same."

Great advice, read the rest here:

http://simpleprogrammer.com/2015/05/25/some-advice-on-becoming-a-lead-developer/

Design Patterns

It is always interesting to note how much value effective teachers and mentors have to offer, even if they are talking on a subject you know inside and out.

Having this experience right now while watching Derek Banas' Design Pattern Series on Youtube:

Design Patterns Video Tutorial

This is a very well paced, expertly taught series.  Even if you use Strategy, Singleton, Builder, or any of the others on a regular basis, I promise you will learn something from this series.

Hiring: On Working with Recruiters

Chris has an excellent post over at IExtendable for hiring managers on working with agency recruiters.

Having spent a lot of times on both as recruit and as a hiring manager, Chris's recommendations are spot on.

http://iextendable.com/2015/05/08/of-purple-squirrels-how-to-work-with-an-agency-recruiter/

Important Skills for Developers

John Sonmez's Important Skills for a Software Developer

To this list, I'd add the ability to prioritze. The ability to balance your time, the client's goals, and the software's needs is a constant, hour by hour, day by day, battle. Software can always be delivered faster, more complete, less buggy, more performat, etc, etc. But all these things can not be done at the same time, by the same person.

Update

Still working away on my WebApi project. The team is making great progress. Still struggling a bit with Git, but we have our Team City build server set up, and starting to set up some decent Git/Bitbucket/Team City workflows.  

New api endpoints are being set up pretty regularly now, and the integration with the front end project is going well.

I had a crazy Linq bug that I squashed yesterday. I may make a seperate blog post on that. 

I've spent the passed three days getting a handle on our SoftArtisan's Excel implementation. As I'm going to be work on Excel integration for the next six to eight weeks, you can expect some posts on this subject!

Jessica Kerr on Git

Git is Hard

Abandon your DVCS and Return to Sanity

"Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available. If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. But for the rest of us, I am going to assert that this is not the use case you need to optimize for when choosing a VCS. And don’t even get me started on how many developers seem to assume that they can’t get work done if GitHub goes down. Suffice it to say that I think most developers are pretty fundamentally unaware of how to use their DVCS in a distributed manner in the first place."

Also check out:
Why the Heck is Git so Hard?

Git Fundamentals -- RG Edu

Part 1
Part 2
Part 3

Git Gotchas

10 Things I Hate About Git

"The information model is complicated – and you need to know all of it. As a point of reference, consider Subversion: you have files, a working directory, a repository, versions, branches, and tags. That’s pretty much everything you need to know. In fact, branches are tags, and files you already know about, so you really need to learn three new things. Versions are linear, with the odd merge. Now Git: you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash… and you need to know all of it."

Very well said!

Git

My company is in the process of moving from TFS to Git for source control.  My team is one of the teams getting to enjoy the company Git learning curve.  All of the teams are struggling. Most, but not all of the struggle, is around merges.

I don't think anyone has done a deep dive into solutions yet, thinking we'll just learn it as we go.  Six to eight weeks into this, that approach is failing miserably for my team.

So as my first dive, I posting this here for reference:

Commit Often, Perfect Later, Publish Once: Git Best Practices

Scott McConnell's 10x

On the drive into work today, I was listening to .Net Rocks Show #727  Steve McConnell Studies Development Practices.

I think this is the first I heard of Scott McConnell's blog: 10x Software Development.  As a big fan of McConnell's Code Complete 2, I am interested in checking this out.  I'm familiar with the 10x rule of software developers: the best software developers are 10x better / more product than the worst.  This is certainly true, and it applies to every single field and is probably very understated. For example, Tom Brady is definitely worth more than 10x the worst quarterback in the NFL.  That said Tom Brady is in the 1% of 1% of quarterbacks, so the number of programmers who should be making a million or more a year is terribly small. So while I probably disagree with Scott Hanselman overall on this subject, there is much validity in what he writes here: The Myth of the Rockstar Programmer.

I have certainly met and worked with developers who deserved $200K to $400K a year while the rest us on the team were under $100K.  And as I have improved my skills and knowledge over the years, I would love to be in situations to start earning those numbers, and more.

Fun With Antipatterns

DevIQ Antipatterns 

I admit that one of the big draws of getting in software was not having to deal with people.  But that's just not how life works.  If you want to grow, learn, and advance in your career, you absolutely must interact with people, and interact with them well. For me, one of my big life mistakes is not recognizing other people's perspectives and thereby giving them the respect they deserve.

The advice here in Deadtech's post is rather basic, but so very important:

Lifting the Curse of Knowledge

Beck Design Rules

I could not agree more with Kent Beck's list: BeckDesignRules.

Design Priorities

1. Passes the tests
2. Reveals intention
3. No duplication
4. Fewest elements

Craftsmanship

This weekend's gems:

Craftsmanship and professionalism.


One's tools and frameworks should not be their architecture.


And when you need performance, you need to know your framework inside and out:

Writing High-Performance .NET Code

WebAPI GZip and Deflate Compression

Today, I implemented the ability to compress our return Json.

After trying a number of options, this was the one that seemed to give me the flexibility and consistency:

Microsoft.AspNet.WebApi.MessageHandlers.Compression

And although I've not found a lot of documentation to this fact, best practice seems to dictate that you do not want to compress every single response.  For objects less than ~4kb the time, and server resources, it takes to compress is more than the time save for sending the smaller package over the wire. I would love to see more on this subject, though.

Web API Performance tips

A truly excellent list:

The Web API Checklist — 43 Things To Think About When Designing, Testing, and Releasing your API

Project Assemblies and Tools

Architecture, third party assemblies, and tools for current work project:

Web API, returning JSON

Ninject for dependency and interception/AOP

Hand-rolled usage and error logging

Service/Business Layer 

Entity Framework (without any repository pattern or datalayer)

Using Command Query pattern as much as possible

MS Unit for unit testing

MS Unit for performance testing/benchmarks

Looking into using CacheCow. Additional assemblies and strategies are being considered and will be documented as they come up.

Visual Studio 2013, .Net 4.51

SQL Server 2008

SOAP UI

Textpad++

Resharper 8

NCrunch

Ghost Doc Pro

Web Essentials

Nuget

Git/Bitbucket

Chrome App: Postman

Write everything so that it is testable, no set meteric for code coverage. Currently have 180 unit tests. Performance will be tested. If a performance issue is caused by a code change, we want to know, ASAP. 

So Here Goes..

Like everyone, I should have started this blog twelve years ago when I first began programming professionally.

To be able to market your skills, work on your writing, create connections, get feedback on your difficulties, and have a resource for your problems and solutions to look back on, there is little that can compete. To my team, to those who I will work with and hire in the future, to those who are just starting out, and to those who have been in the field for decades, start a blog, you won't regret it!

I am a journeyman, a generalist, and someone who takes great pride in what I do. I love solving problems for businesses, and for those I work with. Over the years I have built the smallest of brochure sites, for the smallest of small businesses to work on the largest of applications for major corporations. I have worked on over fifty project at more than a dozen companies.

I'm currently working for a mid-size, international company (in the data research and reporting space) and loving every bit of it.  Agile team of four developers, and a scrum master. No project managers! In total, the shop has thirty developers, with additional BA, QA, and managerial support. The current project is a Web API, using C# and Entity Framework. Given the multiple purposes, long term goals, and level of usage, maintainability and performance are the primary architectural concerns of the project.  Probably, the first time I have had to be cognizant of both of these features at the same time and to this degree.

I have a number of thoughts of how I would like to see this blog developed, but 1) I just hope I keep at it 2) It will serve me well over the next six months while I finish up the first phase or so of our Web API project.