I was lucky enough to receive an Xbox 360 for Father's Day, this year, and it brought me one step closer to my dream of on-demand media from my own media server.  Throughout the past several months, I've been piecing together all the necessary parts.

First I purchased the WIFI add on for the Xbox.  I'm currently running a wireless G network, at home, but the adapter supports A so I have room to increase the bandwidth, if needed (and it probably will be).  I have an old desktop that I installed Windows 2003 on (Pentium, 128 Meg) and I wanted to be able to stream my media from that machine to my Xbox.  Since I wasn't running Media Center on the machine, I went looking for alternatives.  Apparently, if you have Windows Media Player 11, it will let you stream to other devices, but alas it can't be installed on Windows 2003.

Then I found Orb.  Orb includes a service that you install on your media machine that catalogs all your media and serves it up either through a web interface on their site or to devices on your network.  It was a bit slow and I kept running into files encoded in formats that Xbox wouldn't play.  Quite by accident, I then found TVersity.  Tversity works similarly to Orb in that it installs a service on the media machine that keeps an inventory of your media files and serves them up.  However, it is also smart enough to detect what type of device it's serving the content to and transcode it to a format the device can play.  You can also tell it about any video or audio podcasts you like and it will download them and make them available for viewing.

Instead of offering you a web site through which you can access your media, the server on you machine serves up the data on a port that you configure.  If you hit this port with a browser, you get a nice flash application that allows you to browse and play your media files.  One word of caution, though.  The port is not secured by any means, currently, so if you open this port on your router, your media (compromising photos?  videos?) is available to anyone who accesses the port.

I'm happy with TVeristy, but my current hardware chokes when the on-the-fly transcoding kicks in.  The good thing here, is that after the Xbox spring update the system will play many additional formats which means that less transcoding is necessary.  However, for those times when I need the raw power, I've purchased a new Dell PowerEdge server ;-).  As good an excuse as any, I'd say.

Scott Gutherie posted on his blog, Sunday, that Microsoft will be releasing an MVC framework for ASP.Net later this year.  After having spent the last few weeks emerging myself in the Rails framework, I found the list of features for the MVC framework to be very interesting, indeed.  It will provide a clean separation of concerns and allow better testability of the code, will be highly extensible and pluggable, will provide support for URL mapping and pretty URLs, and will allow you to specify "view templates". 

In my last post, I pointed out new language features in the 3.0 version of C# and how they seemed to be inspired by dynamic languages such as Ruby.  Now, I have to say, the MVC Framework seems to include several features that are inspired by the Rails framework. Shrug...looks like .Net developers won't have to go anywhere to enjoy the benefits of dynamic language features and pattern based web development. 

The MVC approach really appeals to my sensibilities, but it was so hard to implement in ASP.Net.  I look forward to getting my hands on this new framework.

For the past few weeks I've been kicking the tires on the Ruby language and the Rails framework.  This post is not meant to be a review of either, but I thought I'd note some of my impressions for other .Net developers that have been hearing the buzz and have not had the time to take a look.

First of all, I'm not planning to make a jump from ASP.Net to rails anytime soon.  However, I think there is always benefit in exploring other technologies, approaches and points of view and my look at these things was primarily motivated by curiosity.

The Ruby Language
I love this language.  Scott Hanselman has commented on how easily intent can be expressed in Ruby and Wilco Bauwer likes its rhythm.  Writing logic in it feels really natural, to me, and it seems that whenever I need a particular piece of functionality, it's available and easy to invoke without having to jump through hoops.  Without casting a vote for either dynamic languages or statically typed ones as the be-all-and-end-all, I have to say that if I were to be tasked with creating a domain specific language I'd certainly go for Ruby as my language of choice to implement it in.  It lends itself well to that type of exercise.  After all, to an extent Rails is a DSL for the web application space.  Some day to day tasks would lend themselves well to being implemented in Ruby.  Command line tasks, in particular, could be easily handled in Ruby.  The language (as implemented for Windows) supports calling into the win32 API and COM.  It does not contain any support for building windows UI, though you can do that by calling the windows API (if you're nuts) or by making use of one of the many Ruby .Net bridges that are freely available.  Just don't expect the performance of the bridge to blow you away.

Another thing that impressed me was the number of dynamic language features that are making their way into .Net languages.  Anonymous methods, continuations and extension methods all seem to have their roots in dynamic languages such as Ruby. 

Ruby is easy to learn and the code is easy to read.

Rails Framework
As one who appreciates the value of convention and likes having a process in place to grease the wheels of progress, I find Rails to be a very comfortable approach to use for web development.  As stated on many Rails-Centric sites, Rails is about "Convention over configuration"  and "DRY" or "Don't Repeat Yourself" meaning don't duplicate code.  Typical frameworks offer abstractions to make the most commonly required functionality easier and faster to use.  Rails does this well, but adds code generation and a type of adaptability that could only be achieved by using dynamic language such as Ruby.  There is also a substantial number of tools to aid the developer with ancillary tasks such as deployment and testing.  In general, Rails forces the developer to use the Model-View-Controller pattern to build their web application.  Few would argue with this approach.  ActiveRecord, which is an ORM library, is used for database access.  ActiveRecord is the stated inspiration for the Subsonic library written in .Net and greatly simplifies database access.

Many proponents of Rails claim extraordinary gains in productivity can be achieved.  I can see how productivity can be increased greatly for an experienced Rails developer, but be warned that there is a lot to remember and new Rails developers may find they are spending a great amount of time in the Rails documentation. 

There are a few IDE's out there that support Rails development.  I preferred RadRails and have been using it for the past few weeks with good success.  I found that Rails, as many have claimed, brought some fun back to the development of web pages. 

The one area I found to be a significant pain was in the deployment story.  Rails is not thread safe.  This means that each web request cannot be handled by only a new thread, but a new process.  I searched, for some time, and found some solutions using FastCgi which basically spins up several instances of a web server and feeds requests to them.  There seem to be some better solutions on the horizon , but I was not able to find what I would consider to be a "clean" solution to use immediately.

I've gained a number of insights, so far, from this exercise.  I don't see myself building my next business application in Rails (but, who knows) or even being gainfully employed as a Rails developer, but the lessons learned will continue to open my mind and make me a better developer.

I'm in a situation, right now, where scope creep is a problem.  It's frustrating, without a doubt, but I started wondering why it was such a source of stress and made some observations.

I'm a person who likes things very ordered and I suspect that most good developers are successful at what they do because they, too, like things to be organized and ordered.  If your going to be using a waterfall type approach to manage the project, ordered means having to know, up front, what all tasks need to be completed and how long each will take.  Without this information, there's no way to know if the project is on track or not as it progresses.

Business people don't seem to work well, that way.  Typically, they'll get their hands on a nearly finished product and start finding exceptions to the rules that were first specified when the design was being made.  Bottom line, here, is that there will almost always be late-breaking requirements and modifications that will be specified.  Knowing this can get you half way to a point of being stress free.

The other half of the frustration stems from the fact that these late-breaking revelations are contrary to the method used to manage the project.  The whole process used to manage the project gets stood on its ear and the project goes into a kind of suspect status because our process is not equipped to handle this disruption of the project flow.  This causes stress on the development team and causes the project stake holders to get nervous.

If we accept as fact that requirements are going to change and that users are going to think of things they didn't realize during the requirements gathering stage of the project, and make that fact a part of the process we use to manage the project, these changes don't come as a surprise to anyone involved and the stress level drops considerably.  To the developer, the change is just another item on the back log of tasks and to the business side of the house it just means they're going to get what they REALLY need.

The key, here, is that you have to start the project out with an agile approach so that everyone's expectations are set from the get-go.  Trying to switch an existing project to an agile method somewhere in the middle is a sure recipe for crash-and-burn. 

     Try it for yourself, here.

I'll go ahead and say this to get it out of the way.  I've never worked on a project that used a purely agile methodology.  I've worked for clients that chose bits and pieces of things usually associated with agile such as continuous builds and the writing of unit tests, but I've never been submerged into a purely agile experience.  So, my comments are coming not from experience with agile methodologies, but rather experience without them.

I've been curious for the past few years about the benefits that an agile approach brings.  I've read numerous books on things like RUP and SCRUM.  As I've gathered knowledge about the subject, I've had the chance to balance the experiences I've had in the projects I've been involved with against the philosophies and practices I was reading and thinking about.  I've boiled all these meandering thoughts down to a list of perennial problems I see in projects and how I think an agile approach could lesson or eliminate them.  Of all the various flavors of agile methods that exist, SCRUM seems to be the one I identify with the most, so I'll be speaking in its terms, below.  If you aren't familiar with SCRUM, you might want to read more about it, here.

• Scope Creep / Late Breaking Requirements - With a SCRUM project life-cycle, the software design is refined before each sprint.  Further, during the course of the sprint, the goal is to write the software to meet the CURRENT requirements only.  Let's face it.  Any developer who has any experience, at all, can tell you that there will always be more features requested after the project has started and that users will always change there minds about things.  If we know this will always be the case, why do we design a whole system up front and pretend it's never going to change?  In fact, we try to insure that it doesn't change by slapping a change request and approval process on the users who change their minds.  To me, the ultimate goal is to put the most useful software possible in the user's hands.  Punishing users for suggesting improvements to the software doesn't seem conducive to that.  With a methodology like SCRUM, these changes are part of the process and thus welcomed. 
•   End Product Not Meeting the User's Needs - I think a majority of the problems that occur in software projects boils down to a lack of communication.  Communication may break down because no attempt is made to convey things like project status and the way the application will work - or it may just be that the business side of the house and the IT department speak is entirely different terms.  If the project is to be a success, the users and the developers have to be on the same page.  The only way that can happen is for the two groups to talk...often and in the same terms.  There are users who never know exactly what they want until they don't get it.  In SCRUM, after each sprint is finished, the solution is presented to the users for approval.  Users can see and maybe touch and use the software in its current state.  This seems to me to be the best way to squeeze those questions and concerns out of a user that they never seem to be able to think of when they're requesting the software. 
• Developer Thrashing - In SCRUM, there is a daily meeting to determine where each developer is with there tasks and what can be done to expedite anything holding them back.
• Pushback From the Business on Length/Cost of Projects - Before each sprint, a decision is made as to which tasks will be completed during that span of time and which developer will be responsible for each.  This decision is a COOPERATIVE effort between IT and the business.  Each task has an estimated amount of time required for completion and a priority assigned by the business.  Accuracy in estimating the effort required for a task and how much effort can be expended by the development team during a single sprint can be tuned over time and this type of metric is very easy to gather from the process.  Since the the business is involved in the scheduling of tasks and would have access to the metrics, a better understanding of what takes time and why can be had.

Though my experience with agile methodologies is light, I can tell you that the apparent benefits of applying them has motivated me to push for there use in my current project.  I'll check back in with the results.

Do you thrash?  Thrashing is when you find yourself in a situation where you can't seem to make any progress on a problem no matter how much effort you're exerting.  Thrashing can frustrate and kill both productivity and timelines.  Maybe you're trying to track down an elusive bug, working in an unfamiliar language or technology, or you're doing something unique and uncharted.  The common thread in all these scenarios is a lack of information.  Where do I look next? How can I create a particular behavior with the tools I have at hand?  What tool should I be using instead?

Assuming that your thrashing is based on a lack of information, the warning signs should be fairly obvious.  Do you have a pretty good idea how you're going to accomplish your task?  If you don't, you may be on your way to a good thrashing.  Thrashing can usually be prevented with preparation. 

First, know your tools.  Be honest.  How familiar are you with the language you're using?  Do you often read code written in that language?  If not, you need to.  If you do, do you find yourself wondering what chunks of the code are doing?  As my high school English teacher said, "If you come across a word you don't understand, look it up."  Doing this will keep thrashing due to ignorance of the language at bay.

Second, know you're requirements and have a design in mind.  I can't tell you how many times code I've worked on has been held up because either the requirements were unclear or certain points in them are disputed among the users.  If you don't know exactly how the application is to behave, it's your job as the developer to clarify these things.

 If you should find yourself in a situation where you're thrashing, the best way to break out is to remember that someone knows the answer to the questions you have.  Find them and ask.  In my book, the only excuse for thrashing is the rare situation where there is no expert or they are unavailable.

Welcome to the new Enterprise Etc web site.  If you're looking for the old site with my articles and original blog, you can still find that content archived here.