+972 52-548-6969
NH ProfExposing the data that you already have
time to read 1 min | 119 words
One of the things that drove me mad with NH Prof is that at times it was hard to visually see when a session went to the database a lot or hit the cache frequently. I mean, you most certainly had that information if you drill into the session itself, but there is really no excuse for not giving that information to the user directly.
Hence, the following screen shot:
I am back to working on NH Prof full time, and I love the way everything is set up. Time to feature is ridiculously low.
More posts in "NH Prof" series:
- (09 Dec 2010) Alert on bad ‘like’ query
- (10 Dec 2009) Filter static files
- (16 Nov 2009) Exporting Reports
- (08 Oct 2009) NHibernate Search Integration
- (19 Aug 2009) Multiple Session Factory Support
- (07 Aug 2009) Diffing Sessions
- (06 Aug 2009) Capturing DDL
- (05 Aug 2009) Detect Cross Thread Session Usage
- (22 May 2009) Detecting 2nd cache collection loads
- (15 May 2009) Error Detection
- (12 May 2009) Queries by Url
- (04 Feb 2009) View Query Results
- (18 Jan 2009) Superfluous <many-to-one> update
- (18 Jan 2009) URL tracking
- (10 Jan 2009) Detecting distributed transactions (System.Transactions)
- (06 Jan 2009) The Query Cache
- (05 Jan 2009) Query Duration
- (24 Dec 2008) Unbounded result sets
- (24 Dec 2008) Row Counts
Comments
Why do you think your time-to-feature is so low? Can you attribute it to a certain technology like WPF? Is it the development techniques you're using like TDD?
My company is struggling right now with very long time-to-feature lengths for what should be pretty simple functionality. I'd love any insight on to why you've hit such low turnaround times.
Matthew,
I don't think when I create a new feature, it is something that I just do routinely.
This is a result of an architecture that works on the concepts & features style that I outlined here:
ayende.com/.../...cture-concepts-amp-features.aspx
@Matthew
I think time-to-feature is more a result of smooth collaboration between project members than source code complexity. In case of NH Prof the communication overhead is negligible because it's mainly the time needed for electric impulses to travel between hemispheres of its author's brain.
Rafal,
You do realize that NH Prof is written by 4 people in 3 different time zones?
What are the time zones? You, one in EST, and two in CST?
No, I din't know about four people, I thought there's only you and the other guy responsible for the GUI. So apparently you're doing good teamwork.
Hi Ayende,
You mention that you moved to a push model and messaging for NH Prof, on all the projects that I have worked on I have never used these. Do you have a blog post or recommend a good book to learn these techniques?
Btw, thanks for NH Prof, best tool for learning NH and optimizing it.
I have plenty of posts describing how NH Prof is built, look at the NH Prof category
Hey Oren, when do we get to see the source code, so we can learn by example?
;-)
Comment preview