Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

http://www.springerlink.com/content/q91566748q234325/?p=7fd98b01480f49e2925f36393c999a72&pi=3

http://blog.agiledad.com/2009/07/cost-of-bug.html

No related posts.

For some reason Visual Studio 2008 has F2 mapped to the object browser…unlike almost every other Microsoft product including Visual Web Developer.

Tools –> Options

No related posts.

Let me start off by saying I am so happy with the “New” Microsoft. An engaged Microsoft, an open Microsoft.  So to the Kobe team I say “Welcome to the real world”.

There are enough people writing about the amazingly horrible code. I’m upset with the response from the team. The response, at first glance, seems to acknowledge there is a problem and that they will fix the Kobe code.

Then I read it again…

This post is defensive and response laden with manager speak for “fuck off”. More so, they don’t even acknowledge a problem with the Kobe code!

The sample app is not a "reference application" in the context of code completeness. A "sample app" and a "reference app" are quite different in the context of code completeness, and we do not claim Kobe to be a reference app in this context.

Oh!, I am so sorry, I thought it was a "reference application" now that I know its a "sample app" all is right in the world. FAIL. What is that code a sample of anyway? After looking at the code and reading the numerous community responses its quite easy for me to say.

The Kobe code is a sample of how NOT to do ASP.NET MVC

If we now have the same understanding of the word sample; then I agree; Kobe is a sample.

Now, I am aware that Rob and the Scott are stepping in to clean this up…Oxite déjà-vu. But I need to make one final comment about the teams acknowledgement of the problems in the code.

We will review all sumitted feedback and take action to address items within the context of the intended scope & goals of the Kobe project.

That is so so so far from an acknowledgement. This is an acknowledgement.

No related posts.

As part of developing a project I created a Cross-Domain Proxy to consume the payment service. My Cross-Domain Proxy, Payment.asmx, is exposed via the JavaScript end point. Any ASP.NET web service can open the JavaScript endpoint by uncommenting line #7 in the asmx file.

Once the ScriptService line is uncommented you can test that your service is exposing the JavaScript endpoint by calling a URL similar to:

   1:  ~/WebService.asmx/JS

In the master page I pull the service in.

   1:  <asp:ScriptManager ID="ocScriptManager" runat="server">

   2:      <Services>

   3:            <asp:ServiceReference Path="~/WebServices/Payment.asmx" />

   4:       </Services>

   5:  </asp:ScriptManager>

At this point everything works. I can write JavaScript to call back to the web service methods as such:

   1:  WebService.AddItem('item', CallBackFunction, FailFunction);

   2:   

   3:  CallBackFunction = function(){

   4:       alert('everything worked');

   5:  }

Now, I pull dojo into this project.

   1:  <script type="text/javascript">djConfig = { parseOnLoad: false, usePlainJson: true };</script>

   2:  <script type="text/javascript" src="http://dojopath/dojo.js"></script>

Here is where we start to run into problems. Due to, what I believe, is having both JavaScript APIs in the same project.

If we change the order of API loading we can get a, somewhat, clearer error message.

Now looking at line 1175 we see:

Conclusion:

I believe that I have exhausted my troubleshooting efforts. although I am not sure if this is enough information to validate the existence of a bug I opened a ticket with Dojo. Then again, I am not sure who can or should fix it.

http://trac.dojotoolkit.org/ticket/7353

I blogged about this once before.

http://eric.polerecky.com/archives/dijitformvalidationtextbox-and-aspnet-ajax/

Workaround:

In my project I use dojo.xhr to make calls back to the server.

No related posts.

OOP

   1:  $user = new user();

   2:  $user.name = "eric";

   3:  $user.save(); //write to database

   4:   

   5:  $eric = user.fetchByName('eric'); //read from DB.

   6:  $eric.keepTyping();

Not OOP.

   1:    rs.Open "Select * from Customers", conn   

   2:    for each x in rs.fields   

   3:       response.write(x.name)   

   4:       response.write(" = ")   

   5:       response.write(x.value)   

   6:    next

Ok, I am done.

No related posts.

Really, why have I waited so long to jump into a platform that is based on JavaScript…and HTML and CSS. Really, after spending 1.5 hours with Air I am totally amazed at my own stupidity. Oh’ and I started on YAAATC (Yet another adobe air twitter client) yaht-C…its like expresso and espresso…

Its rather late and I have to get up early…to go to work and code more Air stuff I guess…

No related posts.

I wrapped up the alpha version of the new Technology Aces PHP MVC Framework. Which by the way I really need a name for. TAPMF? um….no.

I don’t have any code for the model yet…hence model-less MVC..I’ll have it done soon.

No related posts.

Or just what I coded to I could lean how to use facebook connect…

Background

When facebook connect was released I wanted to code something to see how it all worked. I wanted to code something I could prop up relatively quick. Partly due to my lack of time but also because I have not released one single piece of software all year! I decided that, since I was just hopping into the land of twitter and I found it complicated to manage my twitter status and my facebook status, that I would write a small app that would allow me to update the status of each site either concurrently or independently.

Specifications

• support facebook connect : (100%)
• local uid/pass system : (80%)
• update facebook status : (100%)
• update twitter status : (100%)
• update local status : (100%)
• private status updates : (100%)
• support tags : (100%)
• support date/time updates (past, present and future) : (70%)
• provide meaningful statistics : (30%)
• support a public profile/time line page. http://pinggr.com/detroitpro : (50%)
• mobile version : (10%)
• simple API : (0%)

Out of scope

• Clone twitter
  • I am thinking that it would more sit “on top” of the status update services.
• Full “router” support aka: act like ping.fm

Features I would like to add in the future

• Twitter style reply and dm
• openid support
• more status sites

No related posts.

In the past, when building small web applications with up to a couple concurrent users, I’ve placed the database on the same system as the web server. Blasphemy!!!…not really. You see, knowing that database systems will entirely consume their allocated memory allows for clear capacity planning.

There are many factors that need to be taken into consideration when designing an architecture and for the sake of this post lets just say that:

• This system does not require a ridiculous amount of memory
• This system does not require HA

And really, while every project sponsor will tell you that their project requires the most powerful server ever built and for the sake of humanity can never go offline again, most web applications don’t require all that much memory…and the fate of the company is not dependant on 100% uptime…just check the SLA.

So what does this all have to do with “Content Segregation”? Oh, and WTF is “Content Segregation”?

Ok, ok, just one more paragraph to provide context.

Large web applications with high concurrent user counts will commonly separate not only content types across systems but also application modules. For example, there might be a small web server cluster for images or a separate group of servers for the account management modules (login, register, profile). These practices are commonly accepted and I couldn’t agree with them more. Its just that most of the applications I am involved with don’t require this type of advanced architecture even though the project sponsor would have you believe otherwise. These, not the large web applications, are those we need to discuss..

So what does this all have to do with “Content Segregation”? Oh, and WTF is “Content Segregation”?

Until recently performance and availably have been the only reasons I’ve recognized to separate content across physical servers. That is until just very recently, in a meeting of the minds it was stated, as fact, that “Items of content type X are data and should be stored on the database server”

WTF? Let me clarify, not IN the database, but on the database server file system..

Ok, I have my head around what you are saying, I understand that your an advocate of Content Segregation, I just don’t understand why, but I can tell you why not.

1. Performance

Database servers are commonly separate physical systems for performance reasons. The DB server should not be a dumping ground of user generated content. It might seem silly but there is a chance that you might really use the SQL server for something that requires its full power. Maybe some form of analytics and when that happens you need to have the available power.

2. Slippery Slope

I truly hate this argument but it fits so perfect into this context. Its not so far of a leap to go from storing images on the database file system to storing images in the database.

No related posts.

No related posts.