Kai - blah blah blah

Test first != TDD

2011-12-08T20:48:00.014-05:00

Recently I've seen a misunderstanding of TDD(test driven development), that is, if you always write test first and write code that passes that test, and voilà, you are TDDing, everything will be better now. That is not TDD. That is 100%-test-coverage-driven-development.

TDD is NOT about achieving 100% test coverage (which IMO is meaningless).

TDD is about using test to drive development.

More specifically, TDD requires three equally important types of activities:

writing test

writing the simplest code that passes the test

refactoring code that keeps tests passing

A common misunderstanding is that the refactoring step is optional. It's not.
The following is not TDD.
First the test:


   describe 'alert' do
      it 'should log the message' do 
         logger.should_receive(:info).with('a message');
         subject.alert('a message');
      end
   end

Then the method in tested class:


    def alert(msg)
       logger.info(msg)
    end

Then you are done with this method. This is NOT TDD.
First, you didn't refactor the code. Second, it's not likely that the test will help when you need to refactor this code in the future. In one sentence, the refactor-and-keep-tests-green part is missing.
So what will a TDDer do here? Simply write the code without the test. A typical argument against it is that what if some other developer accidentally delete the logger.info(msg) code? Well, that's not the purpose of TDD, that is what version control is for.

In fact, it can be argued that this test is a form of code duplication. It's just that this duplication is very easy to detect (if you change one place without the other, the test will break.)
Things could be a bit different if your code is like this.


   describe 'alert' do
      it 'should log the title and message' do 
         logger.should_receive(:info).with('a title: a message');
         subject.alert('a title', 'a message');
      end
   end

   def alert(title, msg)
      logger.info(title + ': ' + msg)
   end

There is a possibility that you need to refactor to improve the performance of the string concatenation. In this case, the test here has some value.

So, the purpose of tests in TDD is to facilitate refactoring.

In many cases, tests give you the ability to refactor code with the confidence that it won't break functionality. In other cases, you may have to change some tests to do your refactoring, because unless it's a real black box end to end test, you are always going to have some form of logic duplication in your tests.
So a test is probably helpful for some refactoring but impeding for some other refactoring.

The value of a test is determined by the likelihood of it helping refactoring v.s. the likelihood of it impeding it.

When writing tests in TDD, we need to maximize this value with as less cost as possible. Tests on constructors, accessors, constants and simply delegations are typical examples of test with zero or negative value. Pure interaction tests are likely to have less value than a more end-to-end test but it should be evaluated on case-by-case basis.
You also need to take cost into consideration - for example, end-to-end test might takes more effort to write and/or more resource to run.

There is no silver bullet. Always-write-test-first isn't one. It takes some effort to determine when to write tests and how to do so, but it's not too hard - just focus on the value of the test, that is, how much benefits it can bring to immediate and foreseeable refactoring.

queffee.js - a dynamic priority worker queue in javascript/coffeescript

2011-09-22T12:50:00.012-04:00

Recently I wrote a very simple javascript library that helps manage asynchronous tasks. I named it queffee (github). It was written in coffeescript but the compiled javascript file is available too. This article gives an introduction about this library and how it can help a web application on the client side.

queffee.js is a small library and for the most part it has two public classes: queffee.Q - a dynamic priority job queue and queffee.Worker - well, a worker. You can enqueue tasks (asynchronous functions) into the queue and start a worker, then the worker will run those functions one by one. You can also start multiple workers can they will work on multiple tasks in parallel (in a single thread).

As an example ajax web application, let's look at a picture slide show running in a browser.
Let's start with the basic usage. In the slide show, there are many picture objects, which have a preload function that preloads the picture content to the browser so that when user select to display them, they will be immediately ready. This preload function is asynchronous and takes in a callback to call when the preload is done.


  class Picture
    preload: (callback) =>
      #preloading itself in browser, callback on success

You can always simply do


  for pic in pictures
    picture.preload()

The issue here is that because preload is asynchronous, this will run all of them simultaneously, so if you have too many pictures, that might be simply too many requests to the server. You can better manage that using queffee.


    q = new queffee.Q
    worker = new queffee.Worker(q)
    for pic in pictures
      q.enQ picture.preload

The worker will preload picture one after another, so one request at a time. If you want more simultaneous connections you can always start more workers.


  anotherWorker = new queffee.Worker(q)
  #or
  _(4).times -> new queffee.Worker(q)

Now let's look at a more advanced use case. In a slide show, users might select to skip some pictures and jump to a picture further down in slide. So preloading the pictures they already skipped is probably not as important as preloading the pictures immediately after the one they are seeing now. So we need to prioritize the preloading according to the current progress of the user. queffee supports that. When you enQ, you can give it a priority function and it will be used for the priority queue. Let's say you added a priority function to your picture class


  class Picture
    priority: =>
      #calculates its priority according to the distance to the current progress

then you can enQ the preloads like the following


   q.enQ picture.preload, picture.priority

Now when users skip pictures, you just need to call


   q.reorder()

Then the preloading works will be re-prioritized according to the new slideshow progress.
If you don't need to dynamically prioritize the tasks, you can also pass in a number value as the priority.

So far so good right? Another really interesting usage of queffee is to support offline mode for you ajax application.
Back to the picture slide show as the example. With enough preloaded pictures, it should be able to work fine after the browser goes offline. However, like most other ajax web apps, even with the data available locally, it still needs to update state back to server. Specifically in this app, if user operated on the picture, it needs to update the server with the latest states. More specifically, it needs to send ajax put/post requests back to the server. We don't really need a response from the server but if the browser goes offline, such ajax requests will be lost. With queffee, the problem can be elegantly solved with the following code.


  class Updater
    constructor: ->
      @_q = new queffee.Q
      @_worker = new queffee.Worker(@_q)

    put: (url, data) => this._addJob('put', url, data)

    post: (url, data) => this._addJob('post', url, data)

    _addJob: (method, url, data) =>
      @_q.enQ (callback) =>
        $.ajax(
                url: url
                data: data
                type: type
                success: callback
                error: => setTimeout(@_worker.retry, 180000)
              )

Then just use this updater to do the ajax update


  class Picture
    update: => updater.put('/picture', this)

That's it. The picture.update() methods is offline safe now. The Updater class uses queffee to run the ajax requests one by one. If disconnection causes one ajax request to fail, it will automatically retry every 3 minutes until it succeeds and continue with the following one. The way it detects the disconnection is a bit naive here but you got the idea.
There are two not so obvious things here: 1) the worker will not proceed to the next job until the current job finishes and calls callback, so if the ajax call in the current job fails, the worker will stay with the current job 2) the worker.retry() function re-run current job again which if succeeds, will start moving things again.

Be default queffee.Worker waits on the asynchronous task indefinitely, but if you give it a ms timeout (value or function), it will move on the next task after timeout.
For example, the following code waits at most 10 seconds for the picture to finish reload, after which the next picture will get preloaded.


   q.enQ picture.preload, picture.priority, 10000

In some cases you have a collection of asynchronous tasks and you want to run all of them sequentially and meanwhile monitor the progress. I wrote a util class in queffee called CollectionWorkQ just for that.
Here is the usage, let's still take the preloading pictures as the example, except this time we don't care about the priority but we need to monitor the progress.


    new queffee.CollectionWorkQ(
      collection: pictures
      operation: 'preload'
      onProgress: -> alert('another picture ready!')
      onFinish: -> alert('finished')
    ).start()

This should be intuitive enough, the operation option takes in a function name that will be called on each item of the collection. The operation option can also be a function that takes in an item and a callback like the following


    new queffee.CollectionWorkQ(
      collection: pictures
      operation: (picture, callback) -> picture.preload(callback)
    ).start()

That's it. Thanks for reading this. I hope it can be of usage for your projects. Again, it's on github, any contribution will be great.

Why Coffeescript's fat arrow makes it more functional (than JS)

2011-08-24T19:22:00.014-04:00

We all know that in JS this is not read from the scope chain, it's reset on a context by context basis. Experienced JS programmers work around it and are quite used to it, but I think this fact made JS a lot less beautiful than it should be. Here is a simple example


var Note = Backbone.Model.extend({
   initialize: function() {},
   delete: function() {
      //do something
      this.log('deleted');
   },
   log: function(msg) { 
      alert(msg); 
   }
});
var note = new Note();

$('#delete-note').click(function(){ 
    note.delete();
});

Sure, backbone.js already makes things a lot cleaner but the itchy point is this


 $('#delete-note').click(function(){ 
      note.delete();
 });

The fact that you have to wrap the event handler within a function just make it more like a block passed in than what it really is - a function, especially when you are from a ruby background.
It really should just be


$('#delete-note').click(note.delete);

Well, you can't. If you do that, all the 'this' will be of a different meaning in the body of the delete function - in our example, it will complain that the log is undefined for HTMLElement.
Here is what Coffeescript gives you with its wonderful fat arrow


class Note extends Backbone.Model
   delete: =>
      #do something
      this.log('deleted')
   log: (msg) => 
      alert(msg)

note = new Note
$('#delete-note').click  note.delete

At a glance, it might look like just some keystroke savings. But from my experience the mind set that you can just pass any function as variables around is what makes it a lot more FUNctional.

Interesting notes for a Rails 3.1 performance issue on an EC2 micro instance

2011-08-02T19:53:00.009-04:00

For my web app, I recently switched to an Ajax intensive model where most of the html manipulation happens on client side with coffeescript. This significantly increases the number of http requests hitting the server, which caused really serious performance problem on my micro instance on EC2. The app reacts quickly for the first page but then would literally freeze for 1-2 minutes. It turned out to be a combination of the way how Ajax app, Passenger and EC2 micro instance works.

With default configuration, Passenger tends to keep a low number of instances in the pool and spawn when it needs to take care of higher volume of requests. It also recycles unused instance regularly (every 5 minutes by default). It works perfectly with the one request takes care everything model, but an Ajax app tends to fire more ajax calls and they usually come in spikes.
Passenger spawn more instance with the assumption that these requests are coming from multiple users and it needs to guarantee a reasonable response time for all of them. It's a waste for an Ajax model because the asynchronized nature of Ajax application allows them to function reasonably without a super fast server response on every request. Spawning extra instances becomes an overhead when serving a small number of users. Because the normal pattern for an Ajax application is that passenger sees a burst of requests and spawns a bunch of instances and then recycle most of them when user stops operating the app for a bit. Spawning apps is a CPU intensive operation.

On EC2 micro instance this became disastrous because these instances throttles your CPU after a cpu usage spike to prevent you from using 100% CPU all the time(they are shared). The consequence is that every time Passenger spawns 6 instance (default config value), EC2 'helps' by throttling you CPU to only 2.7% of normal computation power...

My solution to this is that I fixed the number of instances in the passenger instance pool at a lower level. This way, ajax calls might get queued a bit from time to time but 1) hardly felt at the client side because most of the ajax calls are some proactive data pre-fetching and 2) no CPU usage spikes.

The lesson I learned from this is that a lots of rethinking is needed in many aspects of web app when we switch to the Ajax driven model.

Google, please create a real market for web apps.

2011-07-13T23:08:00.008-04:00

The chrome web store is great, but comparing to the Android market place or the Apple app store, it's almost negligible. Why? Are there less people using web? Or are there less web app developers? Obviously neither of those are true. What Google really should do about the chrome web store is to focus on the supply side and make it as much like the mobile app eco-systems as possible.

One of the major reasons mobile app stores exploded is that there is minimum cost to deliver an innovative idea into a product immediately available to the mass, (well at least for those ideas that does not require a centralized service). All you need to do is to write the code. There is minimum infrastructure needed at your side to create and distribute the product. Your revenue management is also taken care of. You can almost completely focus on your code. I think this is the key to innovation explosion on mobile platforms.

For the web apps, things are a lot more complicated. Writing the code is arguably more enjoyable than the mobile app. (RoR vs Objective-C or Swing like Java), but then you also need to do 3 things
1) get a server infrastructure and setup the environment.
2) create a store front - either put it on the chrome web store or maintain your own marketing website which is harder to get mass attention.
3) setup your revenue flow because your server infrastructure is going to cost you money. you can either embed some ads service, or you can create a subscription system and integrate with some 3rd party online payment service.

None of these 3 things are trivial. They make innovation on the web platform significantly harder than on the mobile platform.

Being a web adds company, Google is probably the only company that has the incentive and resource to push for an innovation explosion on the web platform. I am proposing that Google should create a web app platform with integrated infrastructure/marketing/revenue services. Let product developers focus on product development and this platform takes care the rest:
1) an elastic and flexible cloud computing platform that is optimized for web app deployment. Technological wise, though, there should be as less limitations as possible. It should be more like EC2 less like app engine.
2) Google already has this - the chrome web store. Make it more prominent rather than just a chrome browser/os concept.
3) A revenue sharing system to cover the cost of the cloud computing. To conform to Google's free service for ads revenue philosophy, this revenue sharing system is probably ads based. It can start from a single limited cloud computing resource (like the free EC2 micro instance.) Once the usage volume and the ads revenue increase to a certain level, higher tier of resource will be 'unlocked' for the product to allow even larger usage volume and ads revenue.

The idea is that there should be a minimum entrance cost to this web market just like the Android market and Apple app store. People can just create prototype product of their innovative ideas and throw it to the market to test the reaction. How exciting that will be.

A readability monitor IDE plugin?

2011-06-04T15:41:00.004-04:00

In large projects, developers spend a lot of time figuring out what is going on with the code before they can add functionality to it. For code base with poor readability, this activity cost a lot more and has to be repeated by multiple developers and sometimes the same developer multiple times (because human memory is short).

Is it possible to monitor the readability and its impact to the efficiency to the team? It might be achievable through monitoring the behavior of developers using development tools such as IDEs.
There are mainly two modes in which a user engages with an IDE
1) code browsing - user browse across the code base, quickly navigate between files and different parts of the file, during which user changes nothing.
2) code writing - user writes code, usually focusing on a small set of locations in the code base.

It shouldn't be too hard for an IDE plugin to differentiate the mode the user is currently in. For example, if the user hasn't change any code for a while but has been actively navigating thru the code base (such as switching between files, scrolling within them, searching and so on), he is probably in the reading mode. Otherwise if the user has been frequently writing code and running tests, he is probably in the writing mode. The plugin can then simply record the time period user spent in either modes, and provide reports of such behavior across the team.

Obviously, the ratio between the code reading activity and the code writing activity across the team would be an good indicator of the overall readability of the code base. Of course sometimes such indicator might be redundant since the quality of code might be measurable by other means. However this indicator can also provide (to the people with the money) some quantifiable cost of bad code, or in another word, technical debt. You can say something like 95% of the development coding effort is wasted in reading this spaghetti code base v.s. the same team only spend 50% on another similar sized project. You can also suggest something like if we spend X weeks, we can improve the code base so that we can improve the code writing efficiency by Y percentage for the Z weeks of future development.

Why community driven open source teams produce high quality software?

2011-05-18T00:33:00.004-04:00

A community driven open source project is an open source project that is completely driven by an online community of developers where there is no organizational structure. Developers are contributing on their own time without getting paid except maybe donation. Also, they are free to leave the project at any point. Why would such projects produce many times higher quality software than closed source software project developed by teams with scientific management and stringent accountability?

No politics. Everyone is truly for the good of the project, nothing else. For example if someone feels that a refactoring is needed, he will just do it without worrying if he should focus on features development so that velocity looks good.

Better recruiting process: 1) only people really love the project will try to get on the project, 2) skill can be tested again and again thru the patches new candidates submit. In another sentence, candidates are evaluated by the real work they do on the project and no bias of any kind. This process can take as long as needed since in the same time the candidates are contributing the project.

Developers are forced to focus on good code quality. Because every single line of code needs to be highly consumable by other committers who, when they need to continue this work, usually don't have the context and may never get the chance to talk to the developer who wrote it. Readability and tests are absolute must-haves, because that's all other developers can count on.

More sense of achievement because the well designed code can be appreciated by a much broader audience in an open source project. Some say that programming is like art (and I believe they are talking about the code not the front end UI), then artists certainly appreciate more recognition of their work.

Extreme Agile Development?

2011-04-29T23:59:00.000-04:00

What if we push all the agile practices to the extreme just like Extreme Programming does? What will extreme agile development look like?
If automated test is good, why not write acceptance criteria in automated test suites?If empowering the devs is good why not let them own the story too?
If close coordination between QA and Dev is good why not let them pair all the time?
If frequent and direct feedback from end users is good why not continuously deliver to them and collect feedback from them in an easy and automated way?

So maybe this is what extreme agile development process look like:

Provide end users a way to easily submit their feedback to application's feedback database.

Product manager(s) categorize user feedback into high level feature requests and prioritize them.

Dev pair and QA work together (tripling) to design the detail user experience story for the high level feature request (together with the original end user feedback) and write the acceptance criteria in automated test suite such as cucumber.

Product manager(s) reviews the implementation design and the cucumber tests. (optional)

Dev pair develop the story to pass the automated test suites. During which if the test suites need to be changed, the QA will be pulled in.

Continuously deliver code to end users - deploy code to production as frequent as possible.

Product managers keep monitoring end user feed back and ensure that all team members being on target with their user experience design

Is this possible?

Introducing Collectr - my first flickr App

2011-04-26T22:32:00.006-04:00

Alpha test: http://collectr.kailuowang.com/

What is Collectr?

Collectr is a web app that helps you, a flickr addicted, subscribe and explore flickr photos in a much more powerful and personalized way.

What's the vison of Collectr?

To achieve what flickr explore failed to achieve - an easy and free way to see more interesting pictures every day.

Why use Collectr?

Centralized slide show

Personalized slide show

Expendable Sources of Photos

Slide show with the best possible image quality

Easy share

A couple of tips for RubyMine performance optimization

2011-04-11T20:15:00.003-04:00

Set aside the IDE vs editor topic, one of the biggest complains about RubyMine is its performance. In a large project, without tweaking it a bit, RubyMine could be so sluggish that it becomes simply unusable. That's probably the #1 reason many RubyMine users ditch it and go back to simpler lightweight editor such as vim or TextMate. Well, there are actually a couple of things that can significantly impact the performance of RubyMine. With a little care, RubyMine can perform with an OK smoothness.
1) By default, RubyMine's jvm max heap size bound is set as 512MB, it's probably be enough if you are running it on a 32bit JDK, but on a 64bit JDK, it might be necessary to bump it up to 1024MB, since the 64bit uses twice as much memory. This will reduce the number of GC collection. Here is some guide on how.
2) More importantly, RubyMine index everything in your project to support text search/refactoring etc. So if you have some huge files that also get changed very often, such as log, spec reports, etc, it could be very expensive to have RubyMine indexing them all the time. Exclude them from RubyMine project structure is probably a good idea.
That's it. I think with a little love, RubyMine can still be a valid ruby development tool, especially for people who are used to JetBrian's IDEs.

iPad2 vs Xoom - Internet browsing

2011-03-20T01:45:00.009-04:00

This article compares the Internet browsing experience on the two devices (Xoom running Honeycomb 3.0.1 vs iPad2 running iOS4.3), in the following 7 categories:

Operation
The quick control system on Honeycomb browser allows you to go back, forward, refresh, bookmark and other actions using your thumb when holding the tablet. This is not a default setting. User will need to enable it in the settings. Once enabled, the action bar will disappear and thus give you more real web page display. You can popup an action menu by swiping either of your thumbs from edge. The popup menus will display where your thumbnail swipes and is arranged around the thumb so that you can easily click an item.

On iPad2, you move your hand to click on the buttons on the top.

Winner: Xoom

Multitab Browsing
On iPad2, to switch between tabs, you have to click the tabs button then chose a tab from the new tab grid view, this is a bit cumbersome especially if you are familiar with multi-tab browsing on a full pc/mac browser. On honeycomb, tabs are always displayed on the top just like they are on a desktop browser and switching tabs is a 1-click thing.
Also, Xoom has 1GB memory while iPad2 has 512MB, whether this translates to more tabs supported on Xoom is yet subject to test.

Winner: Xoom

Typing
The touch screen keyboard on iPad2 is designed for a phone (just like the whole OS) and thus not suitable for the bigger tablet layout. Typing on it is even slower than typing on iphone, basically you are forced to type a full size keyboard using one finger. On honeycomb, you can download the thumb keyboard input method from market (free). This soft keyboard layout the keys around the bottom left and right corner so that you can type using both thumbs while holding the tablet with both hand, pretty much like when you type on smart phone with both thumbs, and thus achieve the same typing speed.

Winner: Xoom

Screen real estate
Xoom has a higher resolution 1280x800 comparing to ipad2's 1024x768. This means Xoom displays more content than iPad 2 when viewing the same page.

Winner: Xoom

Color Rendering
iPad2 is the clear winner in this category due to the superior IPS screen it's using while Xoom is using TFT which is common on laptops. Basically Xoom gives you the same color as normal laptop, while iPad2 gives you the color as on macs.

Winner: iPad2

Flash
Xoom supports Flash while iPad2 doesn't. It means there a great number of websites that xoom can visit normally while iPad2 simply can't. According to a survey done in 2008 , somewhere between 30% and 40% of all pages tested contained Flash files. Most popular websites already started to provide versions compatible to iPad, but it could be annoying when you bump into one that doesn't.

Winner: Xoom

Speed
According to several tests, when both on the same wifi network, Honeycomb browser on Xoom is on par with if not slightly faster than safari on iPad2. However, when without Wifi availability, Xoom will be able to work on the LTE 4G network (after the coming free upgrade from Motorola) while iPad2 can only work on the slower 3G network.

For now: tied, Winner in the near future: Xoom

Readability and pair programming

2011-03-19T23:01:00.005-04:00

One of the issues regarding readability control is that readability is a subjective concept and thus difficult to rely on a general guideline plus devs' self governing to control. Some code review process has been designed to mitigate such risks and in my other post "Another way of coding explained" I also tried to establish some more objective standards for readability. The most effective way of controlling readability, however, is probably pair programming with regular pair switch while both devs in the pair always focus on readability.

Pairing means constant code review, but for readability control purpose, this is not enough. By definition, readability cannot be reviewed by the dev that wrote the code, because obviously if you wrote the code, you don't really need to read it. You already know all the rational behind the code and everything just makes sense to you. This why regular pair switching is also critical for readability control in pair programming.
By regular pair switch, I mean pair switch every 1-2 days so that most medium and plus size stories got implemented by more than 2 devs. Each switch means a little ramp up for the new dev that gets switched into the pair. The dev that remains on the pair needs to explain the story and all the existing code and design decisions with the new dev. This is a great opportunity to put the readability of the code under test. The new dev raises all readability issues he noticed when reading the code. The old dev does (or should do) the same thing when s/he finds some code more difficult to explain than others.

So this is another reason for regular pair switching and pair programming in general.

Setup a Rails 3 app on an EC2 quick start linux AMI

2011-03-19T11:14:00.004-04:00

Just setup a Rails 3, Ruby 1.9.2 on a free ec2 micro instance (http://aws.amazon.com/free)
Started from the quick Basic 32-bit Amazon Linux AMI 2011.02.1 Beta AMI, I setup the following stack in less than 2 hours.
git
ruby 1.9.2
rubygem
MySQL
Apache
Passenger
And my Rails 3 app.

The whole process is mostly smooth. All dependencies can be found on yum.
It looks like that the free (for a year) micro EC2 instance is quite a valid solution for personal ruby projects.

Photography Assistant is open sourced

2010-12-20T12:23:00.003-05:00

Here is the github address.
https://github.com/kailuowang/LightMeter
The idea10 project files are checked in.
I am not sure if the quality of the code is good enough to be open source, I probably should've improved it further but I am a bit sick of writing Java and the painful process of running Android UI tests.
Out of the features that I really want from this app, the only one left is the photography log. I may come back to implement this in the near future. If you want to contribute, please let me know so that I will provide more documentation (like how to build/run tests and so on)

Photography Assistant 1.5 released

2010-12-19T00:32:00.005-05:00

As a holiday gift to the 16000 users of my Android App Photography Assistant, version 1.5 is finally released.
This release includes a useful new feature - select light value from scenarios. Now you can first select the category of you light scenario (namely outdoor natural light, out door artificial light and indoor), and then select your light scenario from the list of typical light scenarios. For example, you can first select the "Indoor" category and then the "Office and work areas" light scenario.
There are also some minor bug fixes in this release.

Happy holiday! Enjoy camera life!

Inheritance and class variable

2010-11-12T00:26:00.007-05:00

Yesterday I had a great lunch & learn presented by Brian Guthrie titled "Advanced Ruby Idioms So Clean You Can Eat Off Of Them"
It was a great talk and we all learned something interesting about ruby. After the talk Brian and I had a quick discussion about one of the design problems solved in the talk. It is about the inheritance problem in the custom validation framework. That is the subclass (Captain) didn't inherit the validators from the super class(Pirate).
Here is the code

Model classes
class Pirate < BrianRecord::Base
  validates_presence_of :parrot
  attr_reader :parrot
  def initialize(parrot=nil)
    @parrot = parrot
  end
end

class Captain < Pirate
  validates_presence_of :peg_leg
  attr_reader :peg_leg
  def initialize(parrot, peg_leg)
    @parrot, @peg_leg = parrot, peg_leg
  end
end

Framework base class
module BrianRecord
  class Base

    class << self
       def validators
          @validators ||= []
       end

       def validates_presence_of(attribute, opts={})
          validators << BrianRecord::PresenceOfValidator.new(attribute, opts)
       end
    end

    def valid?
        validators.each do |validator|
           is_valid = validator.validate(self)
           raise validator.message unless is_valid
        end
    end
  end

  class PresenceOfValidator
     def initialize(attribute, opts={})
         @attribute = attribute
     end

     def message
        "expected #{@attribute} to not be nil"
     end

     def validate(object)
        return !object.send(@attribute).nil?
     end
  end
end

The problem here is that the Captain class lost the validation on parrot attribute which means that you can do the following:

failed scenario
Captain.new(nil, "wood").valid?  #=>true, not as intended

The root cause here is that the @validator is only available to a certain class, both Captain and Pirate have their own @validators, so the validate method only iterate thru the @validator available to its own class.
The quick fix Brian provided in the talk was to duplicate the superclass's @validators when initialized the @validators for the subclass, as the following

Framework base class
module BrianRecord
  class Base
    class << self
       def validators
          @validators ||= if(superclass.respond_to(:validators)
               superclass.validators.dup 
           else [] end
       end
    ...

This is fine and concise but with only one small glitch, if an validator is added to the superclass after the subclass is loaded, that validator will not be available to the subclass. I brought up another possible solution and we were not sure if it will work. So I didn't a bit coding practice and it looks that the following code also works.

Framework base class
module BrianRecord
  class Base

    class << self
     

      def validates_presence_of(attribute, opts={})
        validators << BrianRecord::PresenceOfValidator.new(attribute, opts)
      end

      def validate obj
         superclass.validate obj if superclass.respond_to?(:validate)
         validators.each do |validator|
            is_valid = validator.validate(obj)
            raise validator.message unless is_valid
         end
      end
     
      private
      def validators
        @validators ||= []
      end

    end

    def valid?
      self.class.validate self
    end
  end

In this solution, I move the validate logic to the class, and recursively calls the superclass' validate method if its available. This removed the duplication of the @validators and thus avoid the problem where dynamically added validators will be missing in the subclass. Note here that now that we have a public "validate" class method instead of the public "validators" accessor, which is private now. I would argue that exposing the validate method is better than exposing the validators.

A different way of coding explained.

2010-10-12T23:24:00.047-04:00

Disclaimer: I will probably keep editing this article and thus the content is subject to change.

Recently I developed my new pet theory - a different (different from traditional TDD/BDD) way of coding that focuses on readability can be feasible and beneficial.

I am fully aware that this theory might be flawed, but I feel the need to document it here because I think although the software industry has made huge progress in software development processes (TDD, BDD, xP, etc), we still have a long way to go. We follow those processes/practices, but we still produce code that later becomes pain to ourselves. We need to keep the thinking of new coding strategies/processes going.

In this article I am going to explain this pet theory in three sections.
Section 1 is to discuss why readability is definable and can be set as #1 priority for coding.
Section 2 is about why readability should be the #1 priority in terms of code quality.
Section 3 is to introduce a difference way of coding (I call it code in units) that was built upon of the principle of extreme readability.

Section I - what is readability? what is extreme readability?

From a couple of recent large projects, I refreshed my appreciation of how import to have a readable code base. After some further thoughts and discussions with other ThoughtWorkers on this particular topic, I feel that readability should be defined clearly so that it can be used a main principle.

The first reaction many developers had when I discussed readability with them is that readability is subjective and hard to define.
To some degree I agree with this observation but I believe this problem can be tackled by taking smaller steps. First we can define some coordinates for readability, then we define the extremes on those coordinates. With such definitions, readability can be more objective to the team than subjective to each person.

It makes sense to me that we have the two readability coordinates defined as the following:
Coordinate I. Identifying logic for given code. Specifically, for a developer that is new to the project but reasonably familiar with the technology stack and the business domain, how hard will it be for him to understand the intention of a given unit of code (method or class) to the extent that he knows how to change that code to incorporate new attention.

Coordinate II. Identifying code for given logic. Specifically, for the developer described above, how hard will it be for him to locate the implementation code for a certain unit of business logic.

These two coordinates are defined based on the two main purposes for us to read the code on a daily basis.
I am not sure if it's possible to define the sad extreme for these coordinates. One way might be that it's so unreadable that no programmer can achieve these purposes before he quits.

Fortunately it's the happy extremes that interest us the most:
For Coordinate I, the happy extreme is that the developer can understand the intention of the code by browsing from the beginning to the end of that unit of code only once.
For coordinate #2, the happy extreme is that he should be able to locate that implementation through a single path of search, in another sentence, he should neither be misled to a wrong path or find out that the unit of logic is implemented in multiple places (compositely or repeatedly or both).

To be more specific, I would list here some implications of these two extremes:
For happy extreme on coordinate #1, the implication of being able to understand the code by reading it once are:

the unit of code can't be large otherwise it will be hard to keep track of what's going on when you read it the first time. For a method, less than 3 statements will be easy for reader to understand in a glance, while 5 will be probably be a stretch. For a class, there should be no more than a handful of public methods so that the intention of the class can't be easily interpreted.
there shall be no disruptive logic in this unit of code, it's difficult for reader to switch context when reading, which means that code should be cohesive.
there should be no confusing naming (variables, parameters, methods or classes). Ideally name should reflect exactly the intention of the variable. Sometimes there is a tendency to name something more generic than it should be.
the developer should not need to refer to document or tests to understand the code
tests should be understandable without description (or long method name)

For happy extreme #2, being able to locate the implementation through a single search path have the following implications:

for a certain unit of business logic, it should always be implemented only once in one place.
responsibilities should be divided clearly so that sub-logic can be easily located.
it should be avoided that some knowledge of project specific convention is required to locate the code.

If you are a believer of Extreme Programming like me, you might agree with me that we can pursue extreme readability. With the two coordinates are defined, it is rather straight forward, simply always keep asking yourself those two questions when writing the code to implement some logic: how easy will it be for other developer to find my code and how easy for him to understand my code. Make your development/design decisions on top of them.

Section II - why extreme readability can be a principle for coding

With extreme readability defined, I think it's possible to simplify the principles of coding as the following

Principle #1 - write code that works, which is so obvious that I probably shouldn't even include it in the following discussion

Principle #2 - write code that is easy to read

Principle #3 - write code that is tested or at least testable

All other software principles, such as SOLID, could be forgotten (and often they are), but as long as these 3 easy principles are followed, the project should be sound and life should be good for every developers in the team.
There is plenty of discussion why #3 principle is important, here is why I think the #2 readability principle should have a much higher priority than other coding/design principles:

I found that following some of the common design principles blindly could lead to over engineer and thus makes the development less agile. but certainly others might have different opinion which brings the second point.

The readability principle is relatively easier to be agreed upon and followed than a bunch of design principles that often times very difficult for a big team to consistently follow simply because they are not unanimously agreed upon. And if a principle can't be consistently followed in a project, the majority of its value is often lost.

Many of the design principles can be deemed as consequential to the readability principle. In another sentence, they can be driven by following the readability principle. For example, the "Single responsibility principle" could be a natural consequence if we organize code cohesively so they are easy to read. There is more explanation on this in section I. Even the principle of always automate can be deduced from the readability principle - manual processes, when documented, have a lot more readability issues than automated process due to pretty much the same reasons why code comment has more readability issues than readable code.

Readability has more importance. Many deem tests as the #1 priority, but readability could be even more important than tests. I saw plenty of unreadable code that are fully tested but you still don't know how to change them. On the other hand, I rarely found any real readable but untested code that is hard to add test for.

Readability always has value. A significant number of the design/development principles were developed to promote extensibility and thus their value can only materialize when the code is extended, not to mention that unnecessary extensibility is not only a waste but also can be a burden sometimes. On the other hand readability always have value, even when you are about to delete the code, you need to read it to make sure you delete the right one. In other words, focusing on readability is more agile than pursuing design principles that may or may not provide value.

Section III - introduce code by units

Now lets introduce a strategy, a new way of coding to pursue extreme readability defined in section I and follow the 3 easy principles in section II.

In one sentence, developers should always focus in a small unit of code (by "small unit" I mean 2-3 statements, no more than 5 ). In TDD, it means that developers are on a constant and quick rhythm of writing a small unit of test and then a small unit of implementation.

Here is simple example, presume that we are developing a website in which we need to render links to pdfs on external websites. We have the urls of the links but we are not sure the availability of the pdfs on those websites. Some urls will redirect visitor to a html page saying that the pdf is not ready yet (but it maybe in the future). Other urls will simply return a http error. We need a checker to check this so that we can avoid rendering links that do not work.

First let's see how this would be done in a traditional TDD fashion:
Step 1, first you do some research and found out that you can use the Net::HTTP to get the http response of the url, with the sample code, you write the following test

 describe UrlChecker do
    describe "#check_pdf" do
       it "return true if url responses successfully and content is pdf"do
         Net::HTTP.stub(:start).with("sample.com", 80).
           and_return(mock(:res, :code => "200", :content_type => "application/pdf"))
         UrlChecker.new.check_pdf("http://sample.com/some.pdf").should be_true
      end
    end
 end

Note that you have to do this Net::HTTP library research before you can write the first test.
Then you write the following code to have it pass

 class UrlChecker
   def check_pdf pdf_url
      url = URI.parse(pdf_url)
      res = Net::HTTP.start(url.host, url.port) {|http|
         http.get(url.path)
      }
      true
    end
 end

Then you add a failing test

     it "return false if url responses error"do
       Net::HTTP.stub(:start).with("sample.com", 80).
         and_return(mock(:res, :code => "500"))
       UrlChecker.new.check_pdf("http://sample.com/some.pdf").should be_false
     end

To have it pass simply replace the last return true statement in method with the following

 res.code == "200"

Then another failing test to make sure you the content of the http response is a pdf file

     it "return false if url responses successfully but content is not pdf"do
       Net::HTTP.stub(:start).with("sample.com", 80).
         and_return(mock(:res, :code => "200", :content_type => "another content type"))
       UrlChecker.new.check_pdf("http://sample.com/some.pdf").should be_false
     end

This time replace the last return statement as the following and the implementation is pretty much done

   res.code == "200" && res.content_type  == 'application/pdf'

Now the class and test looks

url_checker.rb

 class UrlChecker
   def check_pdf pdf_url
     url = URI.parse(pdf_url)
     res = Net::HTTP.start(url.host, url.port) {|http|
       http.get(url.path)
     }
     res.code == "200" && res.content_type  == 'application/pdf'
   end
 end

url_checker_spec.rb

 describe UrlChecker do
   describe "#check_pdf" do
     it "return false if url responses error"do
       Net::HTTP.stub(:start).with("sample.com", 80).
         and_return(mock(:res, :code => "500"))
       UrlChecker.new.check_pdf("http://sample.com/some.pdf").should be_false
     end

     it "return false if url responses successfully but content is not pdf"do
       Net::HTTP.stub(:start).with("sample.com", 80).
         and_return(mock(:res, :code => "200", :content_type => "another content type"))
       UrlChecker.new.check_pdf("http://sample.com/some.pdf").should be_false
     end

     it "return true if url responses successfully and content is pdf"do
       Net::HTTP.stub(:start).with("sample.com", 80).
         and_return(mock(:res, :code => "200", :content_type => "application/pdf"))
       UrlChecker.new.check_pdf("http://sample.com/some.pdf").should be_true
     end
   end
 end

This code looks not bad right? Well, in normal development, I would probably leave them along, but if our goal is to achieve extreme readability there are a couple of issues here:
First

"Net::HTTP.stub(:start).with('sample.com', 80)"

is actually testing the url parse and it's repeated 3 times. This makes the tests harder to read because of irrelevant information so maybe this should tested in a separate test.

  it "should use the correct host name and port to request for the pdf" do
     Net::HTTP.stub(:start).with("sample.com", 80).
             and_return(mock(:res, :code => :some_code, :content_type => :some_content_type))
     UrlChecker.new.check_pdf("http://sample.com/some.pdf")
   end

Then you can remove the ".with("sample.com", 80)" from the other tests, which helps the readability, for example:

   it "return true if url responses successfully and content is pdf" do
     Net::HTTP.stub(:start).
  and_return(mock(:res, :code => "200", :content_type => "application/pdf"))
     UrlChecker.new.check_pdf("http://sample.com/some.pdf").should be_true
   end

As you can see the new test helped readability, but it itself has some readability issue - it had to mock the response even when it's not tested at all.

Second, it didn't really test that you should use http GET to test the url. Actually these tests will still pass if you didn't write http.get(url.path) in the HTTP start block. That is definitely a fail. You probably need another test and break the two principles mentioned above.

     it "use http GET to request the pdf" do
       http = mock(:http)
       http.should_receive(:get).with("/a.pdf")
       Net::HTTP.stub(:start).
         and_yield(http).
         and_return(mock(:res, :code => :some_code, :content_type => :some_content_type))
       UrlChecker.new.check_pdf("http://sample.com/a.pdf")
     end

Again in this test, you actually don't care about the response because it's already tested in other tests, but you still have to mock it.

Now you have 6 specs with some minor readability issues other than the two mentioned above such as 1) :code => "200" is duplicated twice, you will relie on the test description to understand that it means that the response is successful. You have the same problem in the implementation. 2) I would argue that you will need some knowledge of HTTP protocol to quickly understand the intention.

It's quite a journey to achieve this isn't it? You will have to review the code and test carefully to identify the problem and then loose some principles to reach this sub-optimal point.

Now let's see how we would do this in very different fashion, in which we only think in very small steps and code in very small units. And we only care about readability during coding. Here, the first small unit is that this check method should request for the url and return true if a pdf is responded. As for how to request and how to request and check if it's a pdf we don't care for now.

Here is the first test

 describe PdfChecker do
   before do
     @checker = PdfChecker.new
   end

   it "#check_pdf should request for the pdf and check if response is a pdf" do
     @checker.should_receive(:request).with(:pdf_url).and_return(:response)
     @checker.should_receive(:pdf?).with(:response).and_return(:is_pdf?)
     @checker.check(:pdf_url).should == :is_pdf?
   end

Implementation

  def check pdf_url
     pdf?(request(pdf_url))
  end

simple enough, now let's worry about how to do the request, this is the time we do a bit google to find out about the Net::HTTP library. Here the test:

it "#request should use Net::HTTP to get the pdf and return response" do
   http = mock(:http)
   http.should_receive(:get).with("/a.pdf")
   Net::HTTP.should_receive(:start).with("sample.com", 80).
      and_yield(http).and_return(:response)
   @checker.request("http://sample.com/a.pdf").should == :response
 end

implementation

  def request url
    url = URI.parse(url)
    Net::HTTP.start(url.host, url.port) {|http|
       http.get(url.path)
    }
  end

Then we can worry about how to tell if the response is a pdf. First the response should be successful and then it's content should be a pdf. Again we don't worry about how to tell successful or content type yet.

it "#pdf? should only return true if response is success and content is pdf" do
  [true, false].each do |success|
    [true, false].each do |content_pdf|
      checker = PdfChecker.new
      checker.should_receive(:success?).with(:response).and_return(success)
      checker.should_receive(:content_pdf?).with(:response).and_return(content_pdf) if success
      checker.pdf?(:response).should == (success && content_pdf)
    end
  end
end
...

  def pdf? response
    success?(response) && content_pdf?(response)
  end

Then another small step, how to tell if the response is successful

  it "#success should return true only when response.code is 200, otherwise false" do
    @checker.success?(mock(:response, :code => "200")).should be_true
    @checker.success?(mock(:response, :code => :anything_other_than200)).should be_false
  end
...

  def success? response
    response.code == "200"
  end

Finally, take care of how to tell if the content is pdf

  it "#content_pdf? should return true only when response.content_type is 'application/pdf'" do
    @checker.content_pdf?(mock(:response, :content_type => "application/pdf")).
   should be_true
    @checker.content_pdf?(mock(:response, :content_type => :anything_else)).
   should be_false
  end
...
  def content_pdf? response
    response.content_type == "application/pdf"
  end

Now the class and test look like the following

   class PdfChecker

      def check pdf_url
        pdf?(request(pdf_url))
      end

      private
      def request url
        url = URI.parse(url)
        Net::HTTP.start(url.host, url.port) {|http|
          http.get(url.path)
        }
      end

      def pdf? response
        success?(response) && content_pdf?(response)
      end

      def success? response
        response.code == "200"
      end

      def content_pdf? response
        response.content_type == "application/pdf"
      end

    end

before do
  @checker = PdfChecker.new
end

describe PdfChecker do
  it "#check_pdf should request for the pdf and check if response is a pdf" do
    @checker.should_receive(:request).with(:pdf_url).and_return(:response)
    @checker.should_receive(:pdf?).with(:response).and_return(:is_pdf?)
    @checker.check(:pdf_url).should == :is_pdf?
  end
end

describe_internally PdfChecker do
  it "#request should use Net::HTTP to get the pdf and return response" do
    http = mock(:http)
    http.should_receive(:get).with("/a.pdf")
    Net::HTTP.should_receive(:start).with("sample.com", 80).
      and_yield(http).and_return(:response)
    @checker.request("http://sample.com/a.pdf").should == :response
  end

  it "#pdf? should only return true if response is success and content is pdf" do
    [true, false].each do |success|
      [true, false].each do |content_pdf|
        checker = PdfChecker.new
        checker.should_receive(:success?).with(:response).and_return(success)
        checker.should_receive(:content_pdf?).with(:response).and_return(content_pdf) if success
        checker.pdf?(:response).should == (success && content_pdf)
      end
    end
  end

  it "#success should return true only when response.code is 200, otherwise false" do
    @checker.success?(mock(:response, :code => "200")).should be_true
    @checker.success?(mock(:response, :code => :anything_other_than200)).should be_false
  end

  it "#content_pdf? should return true only if content_type is 'application/pdf'" do
    @checker.content_pdf?(mock(:response, :content_type => "application/pdf")).
      should be_true
    @checker.content_pdf?(mock(:response, :content_type => :anything_elsef)).
      should be_false
  end

end

Note that I used a small trick here to test private methods, that detail is hidden here.

In this version, our code has better readability. The intention of the class can be quickly understand by reading the public methods. Implementation detail can be easily located in the private methods. Each private method is very easy to read. On the test side, there is no duplicated tests (no logic is tested more than once) or duplicated mock (no logic is mocked more than once). Every test can be easily understood without reading the description. We can say that this code satisfies the definitions of extreme readability. Interestingly, this kind of unit thinking resulted in a code style that is more functional than imperative.

The specs here are separated into two groups - the normal describe PdfChecker block tests the public interface. However, in our case, instead of testing the behavior, it's more like a description of what the code does than a test. That's actually due to the fact that now the code body of the public method is merely delegation to internal helper methods. So maybe we can replace this block with some more end to end functional tests ( which happen to be difficult in this case).

On the other hand, at least too very common practices were not followed: 1) do not mock the class you are testing and 2) do not test private methods. Also there is minimum level of integration tests. In order to do this thinking in small step and then coding in small unit fashion, we dramatically changed our way of testing. We need to examine if this new controversial way of testing is a price too high to pay. From now on, we are going to call this style of coding "code in units"

We can try do some preliminary examination by trying to add some extra features to the code and then some hypothetical bug fixing.
1, adding proxy support, 2, adding cache function, 3, changing HTTP Library.

Round 1, let's add proxy support to the class so that it can also work in an environment where proxy is needed to reach external websites.

Let's assume that we are going to store the proxy settings as instance variables when instantiating the checker and use them when doing the checker.

In the traditional coding, you will add another test like the following

    it "use proxy to do HTTP request" do
      http = mock(:http)
      Net::HTTP.should_receive(:Proxy).with('proxy.host', 8080).and_return http
      http.stub(:start).and_return(mock(:res, :code => nil))
      UrlChecker.new('proxy.host', 8080).check_pdf("http://sample.com/a.pdf")
    end

It's mostly okay except that you are forced to mock the http response although you are not testing it. It will take reader a bit time to figure out that :code => nil is irrelevant to this test.

Then you modify the class code

     def initialize(proxy_addr = nil, proxy_port = nil)
        @proxy_addr, @proxy_port = proxy_addr, proxy_port
     end

    def check_pdf pdf_url
       url = URI.parse(pdf_url)
       res = Net::HTTP::Proxy(@proxy_addr, @proxy_port).
          start(url.host, url.port) { |http|
             http.get(url.path)
        }
        res.code == "200" && res.content_type == 'application/pdf'
     end

All tests pass again. It might be a bit surprising for people who are not familiar with the net/http library, because in the code it's using Net::HTTP::Proxy.start while all the other tests are mocking Net::HTTP.start. It is passing because when proxy_addr is nil, Net::HTTP::Proxy(proxy_addr, proxy_port) simply returns Net::HTTP. Surprise is not a good thing when talking about readability. It also means now our tests actually depend on a library's implementation detail although from the tests, it looks like that we are mocking it. And from those tests it looks like the class is using Net::HTTP directly. To solve this problem, we will need to change all of our tests to mock Net::HTTP::Proxy instead. That is to replace "Net::HTTP.stub(:start)..." with the following

      http = mock(:http)
      Net::HTTP.stub(:Proxy).and_return http
      http.stub(:start)...
  

What about in code in units fashion? We change the existing test on the request method to the following

   it "#request should use Net::HTTP::Proxy to get the pdf and return response" do
      connection = mock(:http)
      http = mock(:http)
      Net::HTTP.should_receive(:Proxy).with(:proxy_addr, :proxy_port).and_return http
      http.should_receive(:start).with("sample.com", 80).
         and_yield(connection).and_return(:response)
      connection.should_receive(:get).with("/a.pdf")
      PdfChecker.new(:proxy_addr, :proxy_port).
        request("http://sample.com/a.pdf").should == :response
   end

Then we add the same constructor in the pdf checker and change the request method as follows

      def request url
        url = URI.parse(url)
        Net::HTTP::Proxy(@proxy_addr, @proxy_port).start(url.host, url.port) {|http|
          http.get(url.path)
        }
      end

That's it. There is no impact at all to other tests. All interactions between our class and the net/http library are captured in one private method and one test on that method.

Round 2, let's add a cache function so that the result of the check can be cached to prevent excessive http requests.

Let's assume that once a pdf becomes available it will always be available. So we want to provide another public method which also returns the availability of the pdf url. This method, however, will do the http request checking if the url is not http checked before or it's checked before but was not available at that time. If it is checked before and it was available, the result (true) will be returned without any http request.

First, traditional code style, we construct the tests based on the spec mentioned above.

 describe "#available?" do
   it "should only call http request once if an url is available and checked before" do
     http = mock(:http)
     Net::HTTP.stub(:Proxy).and_return http
     http.should_receive(:start).
             and_return(mock(:res, :code => "200", :content_type => "application/pdf"))
     checker = UrlChecker.new
     checker.available?("http://sample.com/some.pdf").should == true
     checker.available?("http://sample.com/some.pdf").should == true
   end

   it "should recheck by http request when the url was checked before and not available" do
     http = mock(:http)
     Net::HTTP.stub(:Proxy).and_return http
     http.should_receive(:start).
             and_return(mock(:res, :code => "500"))
     checker = UrlChecker.new
     checker.available?("http://sample.com/some.pdf").should == false
     http.should_receive(:start).
                 and_return(mock(:res, :code => "200", :content_type => "application/pdf"))
     checker.available?("http://sample.com/some.pdf").should == true
   end
 end

The reason I wrote two tests at the same time rather than having the first test pass and then write the second one is that after I wrote the first one, I realized that it is easier to implement it in a way so that both tests pass. Here is the implementation:

  def available? pdf_url
    @cache ||= {}
    @cache[pdf_url] ||= check_pdf(pdf_url)
  end

All tests pass now. Three issues here. 1) I was forced to mock the http response code and content_type again. 2) HTTP protocol knowledge is required to understand the intention of the tests, you need to instantly translate the "code => '500'" to an available pdf and ":code => '200', :content_type => 'application/pdf' to an unavailable pdf. 3) In the second test, the intention is to test if the available method returns the result of the second check. However, we only tested the scenario when the pdf became available in the second check, we should've also checked the scenario where it's still unavailable, but the benefit of this such might be canceled out by the duplicated code introduced.

Alright, now let's try do this in the code in units fashion. The way to proceed this is different from the traditional way. First you read the code before writing the test. The only public method is check

 def check pdf_url
       pdf?(request(pdf_url))
     end 

It's extremely easy to see that it's doing a request. In the code by units testing fashion, the tests can be written to test if the new method calls this check method correctly.

 it "#available? should only check once if it was available" do
   @checker.should_receive(:check).once.with(:url).and_return true
   @checker.available?(:url).should == true
   @checker.available?(:url).should == true
 end

 it "#available? should re-check if it wasn't available during last check" do
   @checker.should_receive(:check).with(:url).and_return false
   @checker.available?(:url).should == false
   @checker.should_receive(:check).with(:url).and_return :new_result
   @checker.available?(:url).should == :new_result
 end

Note how easy these two tests are to read comparing to the ones written in the traditional fashion. They avoided all the issues mentioned above in the traditional ones. In the second test, it also effortlessly tested that the available method should return the result from the latest check. Of course, it has its own issue, it didn't really explicitly test that the http request was not sent when not necessary. But I can hardly think of a scenario where someone change some code so that these tests still pass but fail on the intention. Maybe someone change the available? method so that it does its own http request checking too. Provide that the code is very readable and the idea is that other developers should read the implementation code (not just the tests), such chance should be low.

The implementation is the same as traditional way

 def available? pdf_url
   @cache ||= {}
   @cache[pdf_url] ||= check(pdf_url)
 end

Round 3, let's pretend that the HTTP library we are using was changed, which introduced a bug which we need to fix

Assume that we upgrade to a new HTTP library but we didn't know that the response code attribute in HttpResponse is changed from code to resp_code.

First of tests in both coding fashion will fail to discover this because they both mocked the response. The fix on the implementation side is quite easy, just change res.code to res.resp_code. However all the tests written in the traditional ways are broken, because they all mock this code. So all of them have to be changed. On the other hand, only one test written in code by units is broken because the resp.code is only mocked once.

In all these 3 rounds, the tests in the code in units fashion were less painful to work with, partly due to the fact the interaction between this class and the http library it uses. They also consistently provide a much better readability than the tests written in the traditional fashion. The only extra trade off we are taking here is the integration points between the private methods are not tested. There are two obvious risks associate with this: 1) existing hidden bug with these integration points not detected, and 2) future changes on these integration points will not be guarded. These are legitimate risks.

However two arguments can be made here. First, as a result of the code by units fashion, these internal integrations points are very simple, mostly just simple delegations. Actually most of such integration points(in another word, private methods) were introduced due to this code by units fashion. There shouldn't be much to test about them. Second, we often not test the integration between classes (by mocking one of the classes), and these class internal integrations are normally simpler and with definitely narrower scope. If we can take the risk of not testing the integration points between classes, why can't we take risk on these even "easier" integration points for the benefits?

There is another trade off here, that is, since we are no longer doing BDD, we lost the class specs that can tell developers the behavior of it. The idea here(as mentioned in Section I) is that the implementation code in the class itself should be readable enough so that the behavior can be interpreted easily without going to its test. This idea might need more test than other ideas in this theory though.

Conclusion

Congratulations!! if you reach here, your superior patience just won you a grand prize: a 25% discount on a two-hour personal boudoir package provided by the world famous photographer - Kai, checkout the detail out at Kaipic.com.

That aside, in conclusion, my pet theory is that first we can define readability, second we can use readability as a principle to guide coding activity and last the principle can be followed easier if we use a different way of coding, that is, code in small units. The trade off of this different way is that we no longer test the integration points inside a class, and my guess now is that it's gonna worth it.

I will continue testing this pet theory in my personal projects (I fully understand that only in a real sized project, the benefits/shortcoming/feasibility can be truly exposed,) and keep you posted.

Short update about Photography Assistant Beta

2010-09-03T08:49:00.005-04:00

So far the feedbacks I got from users are pretty good. No major defects found. I did some testing myself, and I love the DoF calculator! (with manual exposure setting :)
It's going to be a hectic month Sept for me. I wouldn't expect new features any time soon ( I might release 1.5 with some minor fixes ). But the I already decided what to add the next release - Photography Log, which will allow you to record all exposure setting (iso, shutter speed, aperture, subject distance, GPS location and even an optional cell phone camera pic of the motif) in your log. I would hope that this will be helpful mostly for film photography beginners. The GPS location might be helpful for most digital photographers too.

What drives my designing in TDD

2010-08-31T10:22:00.010-04:00

Test Driven Development provides a very structural way for agile coding. One of the steps in TDD is refactor, and this is when we improve our design, but to what extent can it still be deemed as being agile? To remind myself, I would like to write down the *only* two factors that I think are agile to drive this design step:
1) no duplicated code - if the new code is some sort of duplication of an existing logic, or it is destined to be reused by other developers in the team, I would improve the design to avoid (potential) duplication.
2) no unreadable code - if the new code is hard to read, or it makes the existing file(s) difficult to read (for example, the new code might make it harder to navigate), I would improve the design to achieve readability.

That's it. If I find myself designing due to any factors other than these two, I would feel myself being less agile. It happens a lot, sometimes due to the limitations of the technical platform, sometimes due to the "process", but I would keep reminding myself (and maybe the team) that it's not what I preferred.

Testing private methods in RSpec

2010-08-29T20:36:00.037-04:00

Why testing private methods? Well, it's not really about private vs public, if you want really fine granular unit tests that always only test no more than a couple of lines of code, you will need to do partial mocking and test private methods.

I heard argument that testing private methods exposes too much implementation and thus makes later refactoring harder. My argument is that unit test is part of the implementation. Fine grained "real unit" tests is very easy to read and understand. They help clarify the intent of that couple of lines of code in your target class. If you change implementation code, it should be perfect normal if you also need to change that simple unit test. On the other hand if your tests are in a larger granularity, then in each test, either you test a lot of code or your use a lot of mocking. Either case, chances are whenever you change implementation, you would need to change even more test code.

Another common practice is to extract private methods to another class and make them public and test from there. To me, there are only a few valid reasons to introduce a new class (or in general, to design), being able to test private methods isn't one of them.

Alright, with excuses all said (your argument is welcome), here is how I test private methods in ruby with rspec. I defined a global method in a file called describe_internally.rb in my test folder

def describe_internally *args, &block
example = describe *args, &block
klass = args[0]
if klass.is_a? Class
saved_private_instance_methods = klass.private_instance_methods
example.before do
klass.class_eval { public *saved_private_instance_methods }
end
example.after do
klass.class_eval { private *saved_private_instance_methods }
end
end
end

then whenever I need to test private methods for a class (say Foo), I use "describe_internally Foo" instead of "describe Foo". If you prefer, you can organize these two types of tests in the same file as the below example (say Foo is a class with two methods-a public one: "kick" and a private one: "aim" which returns the target to be kicked)

describe Foo do
describe "kick" do
it "should kick at where aim is" do
foo = Foo.new
foo.should_receive(:aim).with(steve_jobs).and_return :a_place
foo.kick steve_jobs
steve_jobs.should be_kicked_at :a_place
end
end
end
describe_internally Foo do
describe "aim" do
it "should aim at where the butt is" do
Foo.new.aim(steve_jobs).should be steve_jobs.butt
end
end
end

(Although in this case, I would just put all specs under the describe_internally block, because the first spec also requires knowledge of the private method and from my experience there is seldom any problem caused by that)
If you need an even more fine control of the scope of where you want private methods exposed, Jay Fields wrote a blog long ago giving another approach to achieve it http://blog.jayfields.com/2007/11/ruby-testing-private-methods.html

Test Driven Development on Android

2010-08-21T23:42:00.006-04:00

Although at the very beginning, TDD, especially the UI part, looked challenging on Android, now after about 90 tests and 4,5 epic stories, I am comfortably to say that Android app can be developed in a TDD fashion reasonably smooth. You just need to accept that you can't test the interaction between UI and domain model using mock framework. Then you design in a way so that such need will be reduced to minimum. Some Android API might not be test friendly, you can solve that by introducing some middle layer abstraction.

Light Meter renamed to Photography Assistant, 1.5Beta released

2010-08-21T20:43:00.003-04:00

I am very glad to announce that Photography Assistant 1.5 Beta was just released to the Android Market.
Features:
+ Aperture priority, Shutter priority and Manual mode for exposure setting calculation
+ Auto Exposure Value (Light Meter function) using ambient light sensor
+ Hyperfocal distance
+ Depth of Field

It was renamed from Light Meter to Photography Assistant.
Please help test this Beta version.

Update about Light Meter

2010-08-10T08:47:00.003-04:00

3 weeks from the first release, Light Meter was downloaded more than 2,400 times.
The development went smooth, I just need time. Currently I am working on adding Manual and Av mode, which is going to be release 1.1. The manual mode could be helpful for the app to work with an incident light meter.

Light Meter 1.0 released on Android Market

2010-07-29T18:25:00.004-04:00

The release of 1.0 EAP has been getting great responses. In less than 10 days, it got 866 downloads and 11 ratings with an average of 4.5 stars. So here is the 1.0 release.
Changes
+ calibration so that it can work with different ambient sensors on different phones.
+ be able to remember settings
Two help related features pushed to 1.01
Enjoy.

One Polish comment on LightMeter 1.0 EAP

2010-07-25T09:33:00.004-04:00

It says "Aplikacja która w przyszłości może będzie dobra, ale na razie jeszcze dużo jej brakuje."
Google translate told me that it's Polish and in English it means "Application that the future can be good, but for now its still a lot missing."
I guess this user must haven't seen the statement I put in the market: "This is an Early Access Preview version , so very premature yet."

The commenter left a rating of 2 stars which changed the 100% 5-star rating so far (5 ratings before this one)

Lesson learned: you can never go too far to manage user expectations.

Road map for Light Meter

2010-07-19T23:41:00.003-04:00

1.0 - add calibration function so that the app can work with ambient sensors from multiple manufactures.
1.1 - add depth of field calculation
1.2 - add hyperfocal distance calculation
1.3 - add a depth of field priority mode.

Light Meter 1.0 EAP released.

2010-07-19T22:56:00.003-04:00

Go to your Android Market and search for "Light Meter."
It's an Early Access Preview version with only very basic functions.
Give it a try and send me feedback if you would. I will really appreciate it.
Thanks!

Android UI Test note

2010-07-03T21:15:00.003-04:00

If you are using the ant script to run the ui tests, that script only detects changes in the java code in the target and test project. The R resource file is somehow not included. If you make any change to the layout which requires some change in the R file (your IDE might be able to help you with that), if you then immediately run a simple "ant run-tests", you might get some weird error. It seems that the new layout file has taken effect while the R file has not. In this case, you need to run a "ant clean compile" in your target project and then "ant clean run-tests" in your ui test project.

Android LightMeter update

2010-06-26T09:22:00.003-04:00

It seems that at least on EVO, the light meter reading is unstable, it could vary up to two steps in the same light situation. Also without the integration sphere the reading is too directional, which could also introduce an error of 1-2 steps. Other than calibration, some sort of alternative approach is needed. I am thinking about giving a guidance EV value table to assist.

MacPorts selfupdate not working behind firewall?

2010-06-22T11:25:00.002-04:00

Here is the solution:
Modify the last part of /opt/local/etc/macports/sources.conf as follows

# To get the ports tree from the master MacPorts server in California, USA use:
# rsync://rsync.macports.org/release/ports/
# To get it from the mirror in Trondheim, Norway use:
# rsync://trd.no.rsync.macports.org/release/ports/
# A current list of mirrors is available at http://trac.macports.org/wiki/Mirrors
http://www.macports.org/files/ports.tar.gz [default]

Android Light Meter App

2010-06-21T00:18:00.004-04:00

After one day of spiking, I now know that a light meter app is possible on Android (at least on EVO). I wrote an app that can display illumination value on screen. The next step will be adding an exposure value calculator to do aperture priority calculation.
Although it's kind of using the same mechanism as incident light meter, the accuracy of the light sensors on normal smart phones is probably not good enough to replace a professional incident light meter such as Sekonic ones. I haven't done a lot of testing yet but I already noticed that the accuracy is certainly not good enough for low light situations. On my HTC EVO, the accuracy below EV 6 is doubtful and it certainly can't tell anything below EV 2.
With that in mind, I still think it could be helpful for day light metering especially for those who are using mechanic film cameras without any built-in light metering.
I will keep everyone posted here.

UI testing on Android 2.1 - an simple example

2010-06-19T14:46:00.010-04:00

This tests a simple button click action that sets the text of a TextView to "1".
Several things were done in the following code to make it work 1) set focus on the button in the UIThread, 2) disable keyguard so that you can send the keyEvent


public class MainWindowTest extends
    ActivityInstrumentationTestCase2 {
private Instrumentation mInstrumentation;
private MainWindow mActivity;
private Button mButton;
private TextView mSensorReadView;

public MainWindowTest() {
       super("com.kaipic.lightmeter", MainWindow.class);
}

protected void setUp() throws Exception {
 super.setUp();
 mInstrumentation = getInstrumentation();
 setActivityInitialTouchMode(false);
 mActivity = getActivity();
 mButton = (Button) mActivity.findViewById(R.id.read_button);
 mSensorReadView = (TextView) mActivity.findViewById(R.id.sensor_read_text_view);
}

public void testClickButton() {
 assertEquals("", mSensorReadView.getText());
 mActivity.runOnUiThread(new Runnable() {
     public void run() {
         mButton.requestFocus();
     }
 });
 mInstrumentation.waitForIdleSync();
 this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);
 assertEquals("1", mSensorReadView.getText());
}
}

...
public class MainWindow extends Activity {

public void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 disableKeyGuardForTesting();
 setContentView(R.layout.main);
 Button readButton = (Button) findViewById(R.id.read_button);
 readButton.setOnClickListener(new View.OnClickListener() {
     public void onClick(View v) {
         TextView sensor_read_text_view = (TextView) findViewById(R.id.sensor_read_text_view);
         sensor_read_text_view.setText("1");
     }
 });
}

private void disableKeyGuardForTesting() {
 KeyguardManager keyGuardManager = (KeyguardManager) getSystemService(KEYGUARD_SERVICE);
      keyGuardManager.newKeyguardLock("com.kaipic.lightmeter.MainWindow").disableKeyguard();
}
}

in the AndroidManifest.xml you also need to have the following code under the tag manifest

<uses-permission name="android.permission.DISABLE_KEYGUARD" />

Email productivity trick - display the "important" Emails on the top

2010-06-15T09:14:00.000-04:00

Gmail has a multi-inbox feature in the lab (you can enable it in settings-lab and then go to settings-multiinbox to configure).
With this feature you can setup your own search query to display Emails in groups in the inbox.
For example, in my inbox now, I display the unread, non-spam and non-project-team-group Emails in the top pane, all the unread project-team-group Email in the second pane, and then everything else in the bottom pane.
This way, all the "importantly" Emails will mostly likely always show up on the top.

Here is the query string I am using if you are interested:
pane 0: -label:project_name in:inbox is:unread -subject:([All ThoughtWorks]) -subject:([spam])
pane 1: label:project_name is:unread

"project_name" is the label I am using for my project-team-group emails. I have filter that automatically apply that label to Emails sent to that group.
I hope this helps.

The concept of contributing

2010-06-10T10:51:00.004-04:00

Every developer should work in a self-governed open source project team for at least 3 months to understand the concept of contributing, which has the following two sides:

Ownership: in an self-governed open source project, every team member share the ownership of the whole project. If you want a new feature, you shall be able to add/modify any code any where to implement that without impacting other features.
Accountability: You are responsible to make sure every piece of the code you are going to commit is readable, tested. Because other people could work on your code, or has code change that might impact your code at any time.

Many developers only know how to finish a task assigned to them, and thus lack the understanding of ownership and accountability. Plenty of software projects failed because of that.

Joined Thoughtworks

2009-04-22T11:32:00.003-04:00

I am very glad to announce that I have joined Thoughtworks as a consultant starting April 20. 2009.
I will continue contribute to the open source community. It's actually part of my job now.

Just released NHibernate.Burrow 1.0.2 GA

2009-02-19T15:08:00.001-05:00

Here is the release note:

NHibernate.Burrow is a light weight middleware developed to support .Net applications using NHibernate (maybe also referred as NH in this article) as ORM framework by providing advanced and smart session/transaction management and other facilitates. Documentation and examples are available at http://NHForge.net Any feedback can be sent to NHibernate user group(http://groups.google.com/group/nhusers). Issues can be submitted to http://http://jira.nhforge.org/ They will be greatly appreciated. Please go to http://sourceforge.net/project/showfiles.php?group_id=216446&package_id=272688 to download

Build 1.0.2.GA
========================
Bug

* [NHB-14] - Ambiguous match found exception when loading statefulfield
* [NHB-16] - NHibernate.Burrow causes controls on the page to DataBind too early in the page cycle
* [NHB-21] - QueryString should not be parsed for Conversation information during postback

Improvement

* [NHB-15] - Clean up transaction and session mangement code
* [NHB-23] - Improve WEbUtilHttpModule to ignore unecessary Handlers

New Feature

* [NHB-17] - Provide ways to stop stateful field processor from traverse control tree
* [NHB-19] - An interceptor for configuring NHConfiguration before Burrow creates SessionFactory

Patch

* [NHB-20] - Get a session by persistence unit name instead by class type
* [NHB-22] - Burrow throws a null reference exception when added as a module in IIS7 and static content is served

NHibernate.Burrow 1.0.0 Alpha 1 is

2008-04-20T10:52:00.001-04:00

The next generation of MindLib Core - NHibernate.Burrow just released its first version:
1.0.0 Alpha 1 .

NHibernate.Burrow is a light weight middleware developed to support .Net
applications using NHibernate (maybe also referred as NH in this article) as
ORM framework by providing advanced and smart session/transaction management
and other facilitates.

For information please go:
http://nhcontrib.wiki.sourceforge.net/BurrowHome

Announcement

2008-02-07T10:51:00.000-05:00

I am very glad to announce that I joined NHibernate Contrib team and will be working with Ayende Rahien, Dario Quintana, Fabio Maulo, Karl Chu and Pierre Henri Kuaté.
Our goal is to deliver a set of tools to facilitate application development based on NHibernate.
The core part of MindLib was extracted as a new proj called NHibernate.Burrow. Together with NHibernate.Shards, NHibernate.Validator and probably NHibernate.LINQ, it will become one of the new products scheduled to release with NHibernate 2.0.
MindLib will continue being maintained as it's supporting NHibernate 1.2.X. but there probably will be no MindLib 2.0.

MindLib is also on Code Project now.

2008-01-10T13:26:00.001-05:00

An article about MindLib is created on CodeProject.com.
Here is the link.

MindLib, Asp.net-NHibernate application development simplified!

2007-12-26T19:33:00.000-05:00

As a real brief introduction, MindLib is a feather weight framework that helps glue Asp.net with NHibernate and thus dramatically simplify the development of Asp.net-NHibernate applications. Its main features includes:

transparent session management that supports both OpenSessionInView and LongSession pattern - transparent here means that you don't needs to know what pattern to use, the framework will automatically chose one based on the current conversation status - see item 5.
generic DAO base that eliminates the need for developers to interact with NHibernate session - they don't even needs to know what NHibernate session is - guaranteed.
easy stateful field support that make Asp.net UserControl and Page no longer stateless - the values of particular fields of UserControl or Page will be persistent over multiple http requests. All you need to do is to mark a field of your UserControl or Page with an attribute. The life span of such fields can be fine grained.
transparent multiple databases support. "transparent" here means that your classes do not need to designate which database to use, the framework will automatically figure out. Basically you write your application like it's using one database.
easy conversation support. The meaning of the term "conversation" here is very close to the conversation concept introduced in the Seam framework. Easy here means that you don't need to define a conversation - you just call the framework to start a long conversation and call the framework to finish it when you are done - only two lines of code is needed.

MindLib is already setup as GPL open source project on SF.net and I just released 1.3 Beta1.
Now I am building the project wiki site where you can find more information about MindLib.
I already finished the introduction and quick start guide.

MindLib is setup on SF.net!!!!

2007-12-18T21:46:00.000-05:00

Here is the Url: http://sourceforge.net/projects/mindlib/
The code is already available on svn.
Wiki site will be built shortly.

Be prepared for an new SF open source project

2007-12-17T22:20:00.001-05:00

MindLib -A light weight library that facilitates ajax.asp.net applications built on NHibernate framework by providing transparent support
for 2 major session/transaction patterns: Open Session In View and Conversation(a seam concept) and a lot more.

NHibernate debugging Could not save object

2006-06-21T21:31:00.000-04:00

NHibernate.Util.ADOExceptionReporter [(null)] <(null)> - Could not save NHibernate.Util.ADOExceptionReporter [(null)] <(null)> - Could not save objectSystem.NullReferenceException: Object reference not set to an instance of an object. at NHibernate.Property.BasicSetter.Set(Object target, Object value) at NHibernate.Persister.AbstractEntityPersister.SetPropertyValues(Object obj, Object[] values) at NHibernate.Impl.SessionImpl.DoSave(Object theObj, Key key, IClassPersister persister, Boolean replicate, Boolean useIdentityColumn, CascadingAction cascadeAction, Object anything) at NHibernate.Impl.SessionImpl.DoSave(Object obj, Object id, IClassPersister persister, Boolean useIdentityColumn, CascadingAction cascadeAction, Object anything) at NHibernate.Impl.SessionImpl.SaveWithGeneratedIdentifier(Object obj, CascadingAction action, Object anything)2006-06-21 21:15:41,187 [5260] WARN NHibernate.Util.ADOExceptionReporter [(null)] <(null)> - System.NullReferenceException: Object reference not set to an instance of an object. at NHibernate.Property.BasicSetter.Set(Object target, Object value) at NHibernate.Persister.AbstractEntityPersister.SetPropertyValues(Object obj, Object[] values) at NHibernate.Impl.SessionImpl.DoSave(Object theObj, Key key, IClassPersister persister, Boolean replicate, Boolean useIdentityColumn, CascadingAction cascadeAction, Object anything) at NHibernate.Impl.SessionImpl.DoSave(Object obj, Object id, IClassPersister persister, Boolean useIdentityColumn, CascadingAction cascadeAction, Object anything) at NHibernate.Impl.SessionImpl.SaveWithGeneratedIdentifier(Object obj, CascadingAction action, Object anything)

The reason is that one of the mapping property does not have a setter, it only has a getter.
This is a hard one to find because normally Nhibernate will tell you that it cannot find the setter of the property, however, instead, it throws a null reference error.
The way with which I found this is to comment out some part of the mapping file and see if the error still occurs when this part of the mapping file is comment out. So I can locate which mapping property is causing the error.

How to avoid over generalization

2006-04-01T17:24:00.000-05:00

Signs of over generalization:
1) Most important standard: what your system can do with the generalized type? For an example: If you generalize Customer and Administrator to a type called Human, what your system can do with a Human type object? If there is very little, then you probably should remove the Human type to simplify your system.
2) The generalized type itself has little work. What code you can put in the Human type?

javascript error in ASP.NET

2006-03-01T10:30:00.000-05:00

javascript error in asp.net page
check if you use <!— --!> to comment out any asp controls.

NHibernate debug

2006-02-28T14:07:00.000-05:00

NHibernate “Can’t save to null “ adoexception
When you failed to maintain your relationship between entities correctly, and there is a cascade saveupdate, you will probably see this error.
<class husbande>
<one-to-one class=wife cascading=save-update>
….
Husband tom = new Husband();
Wife jane = new Wife();
tom.wife = jane;
sess.SaveOrUpdate(tom)

since you missed the jane.husband = tom;
you will get that err.

Aspnet 20 debug

2006-02-28T14:00:00.000-05:00

Asp.net 2.0 debug

If you saw a runtime error keep asking you to turn the customErrorPage mode=off, no matter it already set as off, it probably means that your web.config is corrupt.

ASP.NET 2.0 Building model

2006-02-24T18:17:00.000-05:00

In Asp.net 2.0 every control and page is in its own namespace. In the code, you won’t be able to reference to another control without register it in the ascx page. Ugly, absolutely ugly.

Running Asp.net 2.0 and 1.1 on IIS 6.0

2006-02-21T13:04:00.000-05:00

From John Brennan's Blog
Configuration tip: running ASP.NET 2.0 apps on IIS 6.0

This is something I came across this morning when deploying an ASP.NET 2.0 application. I installed .net framework beta 2 on to the box. I then configured the site through IIS to use .NET 2.0 version of the framework. (For those who aren't aware of this, .NET 2.0 inserts a new tab into your web site properties in IIS. This tab which is called "ASP.NET" enables you to set the version of the framework under which your application will run. It also has a few other cool features such as editing your web.config file through the UI).
Anyhow deployed the app and an hour later I got this error saying: ASP.NET Application Service is unavailable. First thing was check the event log on the IIS box which had a really informative error message:
It is not possible to run two different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process.
The solution from TechNet site was to create a seperate application pool for .NET 2.0 applications. My existing v1.1 apps continue to run in the defaultAppPool while my .NET 2.0 app now uses my AspNet2AppPool. The steps involved were:
A. To create a new Application Pool in IIS 6.0
Open the IIS management console and expand the local computer by clicking the plus sign.
Right-click the Application Pools folder, point to New, and then click Application Pool. The Add New Application Pool dialog box appears.
Enter the new pool name in the Application pool text box, and then click OK.
B. To assign my ASP.NET application to the new Application Pool
Open the IIS management console, expand the local computer by clicking the plus sign, and navigate to the folder that contains the ASP.NET application.
Right-click the application and then click Properties. The application's properties dialog box appears.
On the Directory tab, select the desired pool designation from the Application Pool list.
Further information available at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconconfiguringaspnetapplicationforaspnetversion.asp
posted on Thursday, October 27, 2005 9:22 AM by jbrennan

NHibernate debugging

2006-02-15T16:55:00.000-05:00

If you keep getting an error like the following:
Exception Details: NHibernate.HibernateException: Cannot instantiate abstract class or interface: XXX.XXX.ISomeInterface
It's probably caused by the broken of the data integrity of the database, somebody has modified your database manually.

Generic Sets and Collection Wrapper

2006-02-04T20:49:00.000-05:00

Download source code - 86.9 Kb

Introduction

This simple library is developed for working with NHibernate 1.1 or lower. If there is no benefit of having a generic Set<T> that also implements Iesi.Collections.ISet from NHibnernate, you might be more interested in the C5 collection library or the PowerCollection.

This is a simple extension to JasonSmith's Iesi.Collections to offer a generic version of the ISet and its implementations. Also included are five wrappers which help in using old non-generic collections as generic collections. This could be helpful if you want to wrap a non-generic collection from an old application as generic ones in your application.

Like in .NET 1.1, there is need for a generic ISet in the .NET 2.0 environment. There are already some implementations based on JasonSmith's famous Iesi.Collections.ISet. One of them was found on NHibernate' JIRA which is, according to G77 (thanks!), authored by David Marquam. The implementation of this article is basically a modified version of that implementation. I would like to make it clear that most of the credit of this extension goes to him. I posted this version here so that more people can take advantage of this nice work.

However, David's implementation could not perfectly meet our needs because of several facts:

The ISet<T> in this implementation also inherits the ISet. This inheritance caused the lost of the type safe characteristic that a generic collection normally has.
The ISet<T> does not have the bool Add(T o) method like the ISet has. It only has the void ICollection<T>.Add(T o); the ability to tell whether the item has been actually added might be missed.
The generic extension was included in the assembly of JasonSmith’s Iesi.Collection, which makes some difficulty in working with the original Iesi.Collection.

Using the code

Thus I decided to modify this implementation so that the ISet<T> looks like the following:

public interface ISet<T> : ICollection<T>, ICloneable {…}

In the meantime, I think it could be very helpful if the base Set class still implements the ISet interface since it has been widely applied, including by NHibernate. In this way, you can still have the collection mapped by NHibernate.

public abstract class Set<T> : ISet<T>, ISet {…}

As a reminder, here is the declaration of ISet from Iesi.Collections:

public abstract class ISet : ICollection, ICloneable {…}

For the usage of this ISet<T>, please refer to JasonSmith's article about his Iesi.Collections.

Since Set<T> brought the scenario where a generic collection needs to work with old non-generic collections, I added five simple wrappers:

public struct EnumeratorWrapper<T> : IEnumerator<T>{…}
public class EnumerableWrapper <T> : IEnumerable<T>
public sealed class SetWrapper<T> : ISet<T>
public class CollectionWrapper<T> : EnumerableWrapper<T>, ICollection<T>
public class ListWrapper<T> : EnumerableWrapper<T>, IList<T>

These wrappers support using regular collections under a generic collection interface by wrapping the regular collection as an inner collection and delegate all the functions to it. Also, the Equals() of the wrapper are also overridden to delegate to the wrapped, so that wrapperA.Equals(wrapperB) will return true when and only when wrappedA.Equals(wrappedB) is true. The usage of these wrappers are very simple, here is a sample code:

IList = new ArrayList(3);
list.Add("one");
list.Add("two");
list.Add("three");

ICollection<string> cln = new CollectionWrapper<string>(list);
IEnumerable<string> enl = new EnumerableWrapper<string>(list);
IList<string> lst = new ListWrapper<string>(list);

The Iesi.Collections.Generic is in an independent assembly so that use can have more flexibility with using this together with the Iesi.Collection.Generic.

I will keep working on the implementations since my development greatly relies on them.

Important Notes

This implementation is based on the source code from NHibernate which does not override the Equals method, so the a.Equals(b) in this implementation will only return true if a==b;.
The generic SynchornoizedSet has not been implemented yet.

Latest Update:

Feb 6, 06

I added the Iesi.Collections.Test from Nhibernate1.0.2.0. 67 out of the 87 tests were passed using the generic implementation.

The four ExclusiveOR tests could not be passed before I did a very minor modification to the original Iesi.Collections: in the original Set, the method ExclusiveOr was written as follows:

public static ISet ExclusiveOr(ISet a, ISet b)
{
    if(a == null && b == null)
       return null;
     else if(a == null)
       return (Set)b.Clone();
     else if(b == null)
        return (Set)a.Clone();
     else
       return a.ExclusiveOr(b);
}

Note that the clones of a and b are unnecessarily down cast to Set. While, in the Union method of this class, these two clones are down cast to ISet. I modify the original code as follows:

return (ISet)b.Clone();
...
return (ISet)a.Clone();

After this modification, the Iesi.Collection still passes all the Iesi.Collection.Test, and the generic implementation also passes the four ExclusiveOr tests.

Latest update: This small bug of Iesi.Collection.Set has been fixed in the NHibernate version 1.1-alpha1 [ 10081 ], so you don't need to worry about this problem if you are using Iesi.Collection from the later versions of NHibernate.

There are still 16 tests that cannot be passed. They are all operator tests. Since operators can only be used between classes not interfaces, the operator tests down cast the ISet to Set to do the tests, and our generic implementation cannot be downcast to the non-generic Set which causes the failure of the 16 tests.

Don't use Visible property to store any state for a control

2006-01-30T21:51:00.000-05:00

For .NET (1.1, 2.0) controls, do not use the property “Visible” to store any information. If the parent control’s Visible is set to false, you won’t be able to set the subControls’ visibility to true. And there will be no exception thrown out. The system just ignores your
<code>MyControl.Visible = true;</code> if any of the parent or parent of parent control’s Visibility is false.

Using Java API in .NET

2006-01-30T18:11:00.000-05:00

Using Java API in .Net application

IKVM.NET is an implementation of Java for Mono and the Microsoft .NET Framework. It includes the following components:

A Java Virtual Machine implemented in .NET

A .NET implementation of the Java class libraries

Tools that enable Java and .NET interoperability

The following article states how to use IKVM.NET Bytecode Compiler (ikvmc.exe) to convert a java API to .NET CIL (dll’s and exe’s).
http://www.ikvm.net/userguide/ikvmc.html

Setting up Subversion in VS.Net/Windows environment

2006-01-25T20:57:00.000-05:00

Setting up Subversion in VS.Net/Windows environment

This short article is just about client side setup, for server side installation, here is a real good article from Miguel Jimenez’s blog.

we’ll need the following softwares:

TortoiseSVN, a Subversion Administration interface that integrates with Windows Explorer as a Shell Extension.

RapidSVN, a GUI Subversion Client application if you don’t prefer shell extension.

AnkhSVN a Subversion addin for Microsoft Visual Studio .Net

This article is based on my experience with TortoiseSVN-1.3.1.5521 , Ankh 0.5.5 and VisualStudio .Net 2003 on WindowsXP.

1, install TortoisesSVN, should be painless without any difficult setting to do.

2, before we begin with any project, let’s do some settings in TortoisesSVN, right click on any where in an windows explorer, select TortoisesSVN ( settings. In the general page there is a textbox called Global ignore pattern, if you are mostly working with .Net projects, you can set this setting as the following:
*.tmp *.bak */bin */obj bin obj *.~?? *.suo *.user *.webinfo */CVS CVS *cvsignore* *resharper* .#* *ReSharper* Ankh.*Load
All the files whose file name conforms to these pattern will be ignored by SVN.
Of course you can add or remove patterns, just use space to separate them. Click OK to apply the change.

3, now we can bring a project under control (for project that is already on the server, you just need a simple checkout ) I assume that a repository is already setup on the server. Say you have a project called MyProject

Right click on any where in an windows explorer, select TortoisesSVN ( Repo-browser. In the Repository Browser, right click on the folder where you want to place you project ( commonly YourRepositoryName/trunk ), select create folder. Enter “MyProject” as the name. Then click OK to exit.

Use windows explorer to browse where your project located ( Visual Studio Projects\MyProject\), within the project folder, right click on blank and select SVN Checkout. In the url of repository enter the url of the folder you just created, for example: svn://yourserver.com/YourRepostioryName/trunk/MyProject, and click OK. You will get an alert window, saying the target folder is not empty! Blah blah… click Yes. Then Tortoise will do a real quick checkout, and create a “_svn” folder in the project folder.

Now if you right click on blank space of your project folder in windows explorer, you will see the SVN Commit option, click it. In the popup commit window make sure you check everything you want to include in the control and uncheck everything that you don’t (for example web.config/ App.config). click OK and go get a cup of coffee.

After committing is done, under the project folder, select SVN commit again, this time you will see all the items that you don’t want to be included in the source control, select them and right click on them chose ignore then you can select to ignore the file only or all the files with the same extension.

Done with the TortoiseSVN part, lets go to the VS.net addin AnkhSVN

4, After installed AnkhSVN, open VS.net, go to Tools( AnkhSVN ( Edit the AnkhSVN config file, you will see the configuration file, at the end of the file you will see a sentence

If your TortoiseSVN is using _SVN as the adminDirectory please
uncomment this sentence so it becomes:
<Ad_inDirectoryName>_svn</Ad_inDirectoryName>
This way the AnkhSVN will work with TortoiseSVN well.
Now open you project, AnkhSVN will popup a messagebox saying it has detected that this project is under the Subversion Control, do you like to enable AnkhSVN for this project. Off course, click yes.

Now you will be able to commit or update in the VS.net, if you add/remove something, it will also be automatically add/removed to/from the Subversion. You just need to commit the whole solution. Sometimes you will see question mark which probably means that some new item is unknown, please update or add or ignore that item.
If you want to get to some file out of version control without losing it, please do the following:

Move the file to somewhere safe, not inside your working copy.

TortoiseSVN → Commit the parent folder. TortoiseSVN will see that the file is missing and you can mark it for deletion from the repository.

Move the file back to its original location.

Add the file to the ignore list so you don't get into the same trouble again

Nhibernate debug note

2006-01-25T20:18:00.000-05:00

Nhibernate debug note
2, avoid reassign a persistant collection property
Students = someIList; //avoid this
3, refer to log file from the begining of debuging

NHibernate with Interface Oriented Programming

2006-01-25T20:17:00.000-05:00

NHibernate with Interface Oriented Programming

Hibernate does not check the property's claimed type. It will always work as long as the object pass to it is assignable to the type NHibernate expect.
This is very important to Interface oriented programming with Hibernate.
The following code works:
<class name="Husband, Domain" table="tbHusband">
<id name="m_Id" access="field" type="Int32" column="HusbandId" unsaved-value="0">
</class>
<class name="Wife, Domain" table="tblWife">
<many-to-one name="Husband" class="Husband, Domain" column="Husband_HusbandId" unique="true" />
</class>

public class Wife : IWife
{
private IHusband m_Husband;
public IHusband Husband
{
get{return m_Husband;}
set{m_Husband = value;}
}
}

public interface IHusband
{
}
public class IHusband
{
}

here is a topic about this pattern
http://forum.hibernate.org/viewtopic.php?t=953412&start=0&postdays=0&postorder=asc&highlight=

NHibernate Note 1-24-06

2006-01-25T20:16:00.000-05:00

NHibernate
always use Varchar column for string Discriminator