sfeldman.NET

About over a year+ we had a little application that was leveraging NHibernate for a simple domain. Along all the requirements, one was to generate a pre-defined report with a few simple filters on it. Initial thought was to leverage the same domain we’ve worked out and build report based on that. It was obviously not the best solution there, but once we got the profiling, it was obviously the worse one we could come up with. Re-hydrating entities for reporting was a little bit of a waste. So what would be an alternative without re-investing a lot? We ended up re-using same NHibernate, but in a slightly different manner.

NHibernate has an option to execute raw SQL queries, option exposed through ISession.CreateSQLQuery(sql_statement). The returned ISQLQuery object exposes functionality SetResultTransformer(IResultTransformer) that can be used to (quoting NHibernate documentation) “”change” the shape of query result”. Let’s look into it.

To start-off, we’ll define our Report Data transformer, based on the ReportDataDto

This DTO is going to present what the report has to show – post ID, post title, and first 50 characters for a post body as a preview, followed by ellipsis. ERD derived from the domain entities is a bit more reach with attributes, and has association, which for the given report we intentionally want to remove.

Also, we want to have a meaningful name for body preview in the DTO, and that will be an alias change, that we’ll have to capture in result transformer.

(IReportDataDtoTransformer is extending NHibernate’s IResultTransformer)

At this point we are done with "“changing” the shape of results". All we need is to get the results. This is a sample only, therefore query will be embedded within the code, where normally it would be externalized with or without parameters, depends on requirements.

Execution of this query is literally execution of the SELECT statement defined in SQL statement. No entities are created, but simple dumb DTOs. No state management, no overheads, plain data in objects form for reporting purpose.

This is definitely one of the ways to accomplish the task, and not the only. It is not suitable for complex and dynamic report, but efficient and quick for static ones. Our new college, Dragosh, has proposed to look into read-only NHibernate session and leverage LINQ 2 NHibernate to accomplish the same result, but using entities. I haven’t looked into that, but definitely worth experimenting.

First it was classic ASP, then ASP.NET with WebForms. At the previous company I used to work with it implementing Model-View-Presenter. Since then, I have not touched web development a lot. A lot has changed, and the biggest addition was ASP.NET MVC Framework. Now, there’s a new kid on the blog, that gives ASP.NET WebForms a second change – WebFormsMVP. Check it out.

Back in 2008 I joined Cortex. I was lucky to join a dynamic and growing development team, not afraid of experimenting and pushing the boundaries of Test-driven development. We were on the learning curve from classical state and interaction-based testing to something bigger. Terry and I started to look into ways to reduce the friction and repetition of test initialization and mocking framework usage (RhinoMocks at that time). This was the beginning of the BDD (behavior-driven development) test framework at Cortex that has since evolved into our standard for all of the projects.

Over time, the Cortex BDD test framework had evolved and grown, thanks to the entire team consistently improving upon the initial designs. I am excited to see it going public at the Calgary .NET user group presentation that will take on February 25^th, presented by our colleague, David.

If you are doing classic TDD or looking into BDD, I encourage you to attend the presentation to see what we are doing.

See you all there!

Lately I’m involved in a side project for my son’s school web site. It is a simply basic thing and my part was to observe that the school gets a final result that is possibly to maintain and grow when needed. Decision was made to go with a specific “service provider” that would create the solution. It was agreed on ASP.NET 3.5 – simple.

Boy was I surprised by incompetence and, what’s worse, by unbelievable lies, the school was fed during some 4 weeks of the project.

Project was running on Assembla (for Subversion repository). “Service provider” has provided us with the following final result, where a quite a few files were just plain missing… The cool part was the answers from the “service provider” for a few questions I threw out there to question there credibility. For example, the awesome answer to my question “how come files were missing” and Default.aspx as a concrete example, the answer was:

“The Default page is not being used so we have not committed to the repository.”

Amazing. Now these people claim to have “hundreds of successfully delivered projects”. Right…

Bottom line – software business is one of those where a nice wrapper can deceive a client about the quality of solution sold. Looks like some “solution providers” are taking advantage of that, completely ruining opinion about software development in general.

Development, QA, Deployment, Production Support, Infrastructure,… it doesn’t matter what aspect of software you are affiliated with. Automation is your best friend. And if it is not, you are living a worse nightmare without yet realizing it.

Our team is striving to as much automation as possible, where possible. But how much automation you can be satisfied with? The sky is the limit. You start seeing ROI of automation a little down the road, probably 3 to 6 months after you’ve committed to apply it no matter how difficult it is.

Automating development is somewhat simple. You can follow principles applied in the code (SRP, No-Duplication, etc) and way you go. Build scripts to automate compilation, right tools to avoid re-inventing a wheel, and so forth.

Deployment can be automated fluently with development. CI helps that a lot. Build server can be an initial trigger and the appetite kicks in, where you want more and more of that ‘great stuff’.

Production support IMHO is a bit trickier. There you need to satisfy your hidden customer that support the applications. A good way is to become partners. They have to live on a daily basis with what we create, so they need to be a part of equation, not ignored.  Once they are, they can be given tools and ways to automate and streamline their work, causing in overall product line to improve.

Infrastructure does not live in a separate universe. It’s a part of the same game. Proper infrastructure vital for proper QA and quick development. After all, if you spin your wheels on something that not even a bug, what good does it make?

QA automation IMO is as possible and important as development. After all, QAs are trying to verify that application is working as expected by customers and developers both. Therefore, they need as effective ways to perform their tasks as developers. They also need to be able to do it in a timely fashioned manner, which with growing complexity of user requested features cannot be achieved without automation.

Button line – if you are in software business and have no automation on you radar, you are either living last days of your prehistoric existence, or excessively wasting your clients money and trust. Adopt the change, automate it!

Looks like more people are looking into OODB. This post I found recently is experimenting with db4o, as well as has a healthy discussion in the comments section. This is ties into what I felt and thought a while ago after reading a book on db4o.

If you are into trance music, check armadamusic out.

This is a good joke. As always, in every joke, there’s a lot of truth.