I’ve taken the plunge…  After years of just tinkering with a blog on Tumblr, I have finally committed and purchased this space for all of my blogging needs.

I’m still tinkering with the look and feel, but I think this is pretty close to where I need it to be.

The old tumblr posts are here, and you should be able to search the old content.  It does not appear that SquareSpace has indexed my old tags and dates for those widgets in the vertical toolbar.  I’ll contact support and see if we can work that out.

Look for a LOT more from me on these pages.  I have a handful of development series posts regarding Asp.Net that I’m writing and will be sharing here.

Stay Tuned!

I’m a bit late on this, but I wanted to document my experience at the Philly.Net Fall 2012 Code Camp.  This is a wrap-up post that I need to write more often, as these events are awesome ways to get connected and inspired from some of the developers in the community.

This year, I was caught between jobs for the Code Camp event.  This was the first time that I introduced myself as an “Independent Software Developer”.  I’m not sure how I felt about that.. but not something I need to worry about any longer.

My presentation this fall was “An Introduction to SignalR”.  I have posted my sample code and slidedeck on GitHub at:  https://github.com/csharpfritz/IntroSignalR 

This talk covered the concepts of what the “Realtime web” is and I ran through Damian Edwards excellently simple “Move Shape” demo.  This demo, for those who haven’t seen it, shows how to transmit information from one browser to another through the webserver with no interaction in the other browser.  During the talk, we did a deep-dive on the network interaction between browser and server as well as discussed how SignalR is designed to failover network connectivity based on client capabilities.

I showed a simple console application that could be configured with the SignalR  client library to listen for events from an Asp.Net webserver.  This strategy allows the client to stay connected over the network through network port 80, and thus require no changes to firewalls to maintain connectivity.

Finally, we wrapped up the session by bringing up the fun MMO sample game “ShootR” in our browsers and showing that realitime communications on the web can even power an “Asteroids-like” game.  You can find ShootR at:  http://shootr.signar.net

If there’s some interest, I’ll record a screencast covering this topic and post it here in the weeks ahead.  I will probably write up the content of the talk as a ‘How-To post’ in the next week or so, after I move the blog to its new home.

Finally, I am currently putting together a mid-level SignalR talk that will discuss using SignalR with WebForms and vendor’s control sets.  I hope to give this talk in the Spring at a user group near you.

The story is finally out:  After 7 years, I have been given my release by my former employer.  

I have no regrets about my time with that organization or how it ended.  There are many very talented individuals writing, testing, and analyzing some amazing code there. I had a great time working in their environment, and learned a lot from the size, scale, and agility of the development team’s practices.

I am actively speaking to some organizations about roles on their teams.  It is an exciting time for me, as one of these companies has shown significant interest… and I am positively thrilled to be considered for a position in their awesome organization.

In the short-term, I have a project or two that is occupying my time.  Additionally, I can now resume working on the qUnitMetro project, and I see a handful of feature requests out there begging to be answered.  They shall be handled in the weeks ahead.

I can also begin working on some long overdue blog articles as well as other publications that I am interested in.  There are a handful of screencasts inside me that are begging to be published… and I want to re-engage that process.

You’ll probably see a bit more of me in the next few weeks on Twitter and the blog discussing Asp.Net techniques, technologies, and c-sharp development practices.  I look forward to getting more involved with the community, and seeing where my future leads me.

You can find my details on LinkedIn at: http://www.linkedin.com/in/jeffreytfritz and you can contact me at: jeff@csharpfritz.com

It’s almost time for lunch… let’s eat!

I’ve had several interesting discussions over the last few weeks about the topic of “Technical Debt”.  Besides the negative connotation of the term, it is used to refer to a software design that was not fully implemented to meet a given set of requirements.  Another way to explain it is that developers “cut corners”.

Wikipedia defines Technical Debt as follows:

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Source: https://en.wikipedia.org/wiki/Technical_debt

In contrast, the Agile methodologies prescribe that software should be built in an evolutionary fashion.  This suggests that designs are crafted for only what is required at the time the software is written.  

This leads to an interesting crossroads.  In the early phases of writing a website, it is acceptable to optimize performance for a few hundred to a few thousand users as part of the requirements at that time.  The development team does not know the full scope of the traffic the website will receive, and performance can be tuned at a later date.  When visitor traffic patterns change, performance concerns start to become more noticeable.  

How should an agile team address these concerns?  Is it technical debt, or have the requirements for the system changed?