Page not rendering with IIS Express in Firefox or Chrome, waiting for localhost

There’s a lot of posts on this issue, and none of the suggested solutions worked.  In my particular case, the ASP.NET application’s page rendered fine on IE and Opera, but in Firefox and Chrome I was constantly getting “waiting for localhost”

My solution was to change the project’s web properties to use Visual Studio Development Server (screenshot below).  Right-click on the project, click “Properties”, select “Web”, and select the aforementioned radio button.  Now all the browsers can find the page.









Oddly, I have no problems with IIS Express on my laptop, so there’s still some investigation to do as to why it requires a different web server.


TDD is not the Failure, our Culture of Development Is

In the article TDD is dead.  Long live testing.  and a subsequent response The pitfalls of Test-Driven Development, both authors, in my opinion, are missing the mark by a mile. In the real world, walking into an existing code base, the reason you need TDD (but can’t use it) is because programmers didn’t spend sufficient time on good architecture practices, resulting in code that is an entangled morass of intertwined concerns, and yes, as one of the author’s points out, because the code itself was never intended to be tested except through, at best, acceptance test procedures (most likely the pen and paper variety — with the developer watching in the background hoping he rolls a 20.)  There is an overall lack of attention paid to designing a component with sufficient abstraction that it can accommodate changing requirements, and little or no attention paid to separating (decoupling) the behaviors between components such that component A shouldn’t ever care about what component B is doing. We have a philosophy of refactoring with “just get the minimum to work” to blame for that — the days of thinking about architecture and abstraction are long gone.

The metaphor of building a sky-scraper is inaccurate because anyone building a sky-scraper would know that you can’t make the walls of the first floor so weak that they can’t support a second floor. Except it is accurate because, not paying attention to the requirements and living in a “do the minimum work” philosophy, promoted by the likes of Kent Beck’s Agile Programming and Martin Fowler’s refactoring philosophies (along with their mutant child Extreme Programming), this actually is exactly what ends up happening, and thus TDD is an absolute necessary fallout of a broken coding paradigm. A more accurate metaphor would have been, the requirements called for a single story building, then the requirements changed. Again, with sufficient abstraction up front, the straw-bale walls could be replaced with titanium reinforced hay quite easily.

As for Rails (or rather Ruby, or rather any duck-typed language), TDD is again essential because duck-typing allows for variances in the behavior at runtime, both of type and function calls. The non-strictness of duck-typing is leveraged in lieu of good object-oriented design–why create sub-classes when I can just pass in an instance that quacks just like the other “ducks.” While object-oriented programming cannot be done well without object-oriented design (and yes, I’ve seen both the “P” and the “D” done horribly and have done it horribly myself) a duck-type language allows the programmer to completely eliminate the “D” — class, method, quack, quack. Perhaps we should take a clue from the name, “duck-typing”, that it is actually quackery, and like medical quackery, promises rapid “feel good” development that you end up paying for in little fragments of time running unit and integration tests because you didn’t do the necessary up front design, you haven’t clearly abstracted how the rules are handled, you haven’t clearly decoupled the behaviors of complex systems to identify the dependencies (which all complex systems will have.) If you add up all the time spent running those tests (which of course spawned whole new technologies to run those tests faster and faster) you will discover that over the lifetime of the product, you spent far more time watching little green bars (or red ones) than you would have spent on solid up-front architecture, particularly in the areas of abstraction. But nay, it quacks, and it’s fast. At first.

As for “the industry’s sorry lack of automated, regression testing”, here, let’s not blame the programmer directly even though they consistently over-promise and under-estimate, but rather, let’s blame a culture, yes, starting with “the geek” but also placing responsibility firmly on the business practices of management and the continually demonstrated lack of understanding of the importance of regression testing, and the time & cost that developing regression tests and even more costly, maintaining those tests, requires. As with essentially all other aspects of our society, we are living in a constant tension between short-term gains and long-term investment (TDD can be considered an investment) and we all know which side is winning. We have a culture that rewards quick results and punishes the methodical and (seen as) slow thinker. Some of this may be justifiable due to market pressures and real budgetary constraints, but what is lacking is the consciousness to balance planning and activity.  So what we have instead is a knee-jerk culture oriented to quick results (Agile Programming and Refactoring) which, to support a broken development paradigm, demands TDD as the “fix”, but nobody seems sees that.

When one of the author’s writes “I have yet to see a concrete illustration of how to use Test-Driven Development to test a back-end system interacting with a 20-year-old mainframe validating credit card transactions” I laugh because I have done just that — CC validation systems all have the means of simulating transactions, it’s actually trivial to write TDD’s against such systems. Yes, the author does have a point that much of the “…source code [encountered in legacy systems]…was never designed to be tested in the first place…”, but again, that’s missing the point — TDD is clearly the wrong tool for those systems. TDD works best in an environment:

  • lacking architecture,
  • most likely using duck-typing languages,
  • and, most importantly, one that has started from ground zero with testing as one of the coding requirements.

This is independent of whether it’s a 200 line gem (as in Ruby library as opposed to a “great thing”) or a 100 million line application. If those 100 million lines were written with the intention of being unit / feature tested, then there is no problem. Except that it’s TDD and probably not well architected out of the gate.  And let me be clear that TDD, when applied to a well architected application, is a perfectly valid and beneficial practice, but then TDD is also simplified because it ends up testing behaviors, not architectural flaws and geese trying to pretend to be ducks.

So, is the failure TDD? No. The failure is in a culture entrenched at all levels of software development that says that Agile Programming and Refactoring can replace thinking and it’s brothers “design” and “planning.”  We have Kent Beck and Martin Fowler (I commit sacrilege in criticizing the gods) to squarely blame for that “regression”, excuse me, “story.”  And it’s those two aspects (pun intended) of programming that should be given the boot, not TDD, which has a validity in and of itself under the right conditions.  However, even Agile & refactoring are merely symptoms  (or victims) of a cultural disease that demotes thinking (we need only look at our K-12 education systems and Common Core for proof) and promotes the short-term gain (as demonstrated by our economic, medical, agricultural, etc. practices.)

Ruby on Rails Portfolio After One Year

I realized today that it’s been about a year since I started working with Ruby on Rails.  I ended up putting together a portfolio of the work I’ve done with Ruby / Ruby on Rails in the last year.  Here it is!

GitHub Projects

Database Spider UI:
Article: Day 1: Spider Database Navigator Website

Dynamic Server-Side Property Grid
Article: A PropertyGrid Implemented in Ruby on Rails

Where are my Facebook Friends:
Article: Where In The World Are My Facebook Friends?

Basic Authentication (not using Devise):
Article: User Authentication in Ruby on Rails

Other articles on Ruby / Ruby on Rails:

Comparing Ruby and C# Performance

Function Composition, Function Chaining, Currying, and Partial Functions / Application in F# and Ruby

C# and Ruby Classes

Ruby on Rails Websites

personal projects implemented in Ruby on Rails

websites developed for my clients:

(these websites use significant pre-existing work from the open source community as well as other team members, so I certainly cannot take full credit for them, but I have made significant contributions to them):

Why you should never use MongoDB

An excellent real-life story of actual experience with MongoDB:

I recommend that anyone considering a “document-based” database read this and thoroughly understand what Sarah is talking about…

…because the world IS relational.

This rebuttal was brought to my attention:

Personally, I find this statement: “And yes, this is a somewhat relational model.” amusing.  Well, since it’s relational, doesn’t a relational database seem like the right tool?  And what does “somewhat relational” mean?  It either is or it isn’t, in my opinion.  There’s no “somewhat” here.

A PropertyGrid in Ruby on Rails

Using JQuery UI and minimal Javascript to create a dynamic server-side property grid editor control that can be initialized in a fluid programming style or with a minimal DSL.

Get the code: git clone


  • Collapsable groups
  • Support fo jQuery UI controls
  • Easily extensible to support new control types
  • “Fluid” programming of grid groups and properties
  • Don’t like a “fluid” approach?  A minimal DSL is provided
  • Minimal javascript, most of which is auto-generated
  • Control is generated on the server-side

screenshotI needed a general purpose property grid editor that supported some fancy things like date/time pickers, color pickers, etc., based on record fields known only at runtime (this is ultimately a part of my next installment of the “Spider UI” article series.)  There’s a snazzy Javascript-based property grid here, but I wanted something that was minimally Javascript and more Ruby-on-Rails’ish.  I also wanted a server-side control that could interface well with record field types and that would dynamically generate the grid based on schema information like table fields.

I have put together is a set of classes to facilitate building the content of a property grid control on the server-side.  You will note that I opted for actual classes and a “fluid” programming style, but if you don’t like the way the actual implementation looks using a “fluid” technique, I have also put together a very minimal internal Domain Specific Language (DSL) that you can use instead — basically just method calls that hide (using static data) the internal management of building the property grid instance.

As in my previous articles, I will be using Sass and Slim scripting for the CSS and HTML markup.

…  The rest of this article is forthcoming!