There has been a lot of discussion recently on the ALT.NET list about how the ALT.NET way is so hard and complicated that it may be equivalent to a college computer science curriculum. This all started as a discussion that was geared towards building some type of cascading curriculum guide to ALT.NET software engineering principles such as TDD, S.O.L.I.D, continuous integration, unit testing, composition over inheritance, etc… I agree with this totally, We need to make some type of curriculum guide to ALT.NET principles. I am fairly new to ALT.NET and I am also fairly young. Where I work there are only two developers and we are also testers/designers/everything so when we decided that we could write better software by following the ALT.NET principles we had a hard time finding a starting place amongst all the available information. It is simply overwhelming when you are first starting, and I know we have been talking about easing the entrance barrier, but it’s just not that easy. There has to be some difficulty or is the reward is not as great in the end. However, I do believe that some type of curriculum guide would be a great tool for everyone involved with ALT.NET at any level. I think the best thing about this chart is just to show how the different principles build on each other and relate to each other so you have a reference point you can find yourself on.

Now back to the discussion on Computer Science (CS) curriculum in colleges, I graduated from a small college in Oklahoma with a degree in CS a few years ago. I personally gained a lot from college because I had a professor who had previously worked in the real world, and I worked in the real world developing software while in college so we could have intelligent conversations that only a few other students understood. This was great for me, a self motivator, but not for everybody else. I was able to demand the one on one time that I needed and to ask questions and have problems that forced the “super” students into thinking about problems other than writing a counter in a nested loop. I have now been asked to teach some software courses at the college and help, along with other alumni to revamp the curriculum that is taught in the school. In January I will begin teaching two semesters worth of ALT.NET curriculum. This will be a huge leap ahead for the students, but also for the faculty as I feel so much college faculty is out of touch with the real world anyway.

Ultimately though I think what college is really designed to do is teach students HOW to think and HOW to learn since a college cannot be expected to keep up with all the latest and greatest trends in Software engineering but it can teach students some higher level principles such as ALT.NET or at least get them started down the right path to learning ALT.NET.

Tags: .NET (C#), alt.net, C#, Development, Programming, TDD

We have been working the past few days on getting the new ObjectFactory up and running with CSLA 3.6. The approach we are taking is that we really want to abstract the Data Access Layer away from the Business Object so that we have some flexibility in the future to change the way we access the database. At the current time we are planning on using NHibernate as our ORM tool, one especially nice feature is that it is able to load your objects automatically so no more LoadProperty(SomeProperty) or ReadProperty(SomProperty) a million times. This one thing alone makes this very appealing to me.

This diagram above is a representation of the basic architecture of the system. What we are basically doing is using the Repository pattern to keep data access decoupled from the business object through the use of the ObjectFactory and StructureMap. This is a setup very similar to what Frank is using in his project. However we are not using DTO objects in between the Repository and the business object. We might change this later but for now we will let the ORM load the objects directly.

I am currently working on implementing the ProjectTracker from the CSLA examples. My goal with this is to accomplish several things:

1. Learn the ins and outs of the ObjectFactory and how it works with StructureMap, NHibernate, Mock Objects, TDD, etc..
2. Provide a working drop in replacement to the “stock” ProjectTracker.Library, there shouldn’t be any changes required to the UI or anywhere else.
3. Provide the source code so others can learn from what has been done and make contributions to make it work better or smoother and have it provide a model for people to base their frameworks off of.

So stay tuned because I will be adding more information here as I get closer, should be real soon. I will probably setup the source code on Google code or codeplex, if I do that let me know if you want to make contributions to the project.

Tags: CSLA, NHibernate, StructureMap, TDD

As I have stated before, I am no expert on this subject, yet. However, I am learning a lot about it and trying to put it into practice as much as possible. I am going to give a brief overview of how I understand Test-Driven Development (TDD) and then I will provide additional links and resources for you to further your learning.

What is Test-Drive Development?

As Kent Beck states in his book, “Clean code that works, is the goal of TDD.” Now you may be thinking why do I need clean code, it’s just me looking at it. And I say that doesn’t matter you may write a piece of code for a small little thing and come back to modify it in a year, look at it and think “What the heck did I do this for?” There are really only two rules for TDD:

• Write new code only if an automated test has failed
• Eliminate duplication.

These two rules imply an order of to the tasks we perform when we are developing software, this is the Test-Driven Development Cycle

1. Add Test – Each feature begins with a test. This test will inevitably fail at first because the feature is not implemented
2. Watch Test Fail – Run all tests and watch the new test fail, this validates the test harness and ensures the context you are writing the new test into is working.
3. Write Code – You may have written a little code already, if not implement just enough code to make the test pass.
4. Run Tests – Run all tests again, they should pass now.
5. Refactor – Now the code should be cleaned up as necessary, we should get rid of any duplication that has been created in implementing the new test.

These are really the basics to TDD and I am trying like mad to force myself to do this every time I start to write a new piece of code. I write a test, watch the test fail, write some code, watch the test pass, refactor and restart the cycle over.

The biggest hurdle I had getting into this cycle and the one I still struggle with is, how do I know what tests to write? We still have to plan software and make user stories and development requirements right? The answer to that is yes, definitely, and guess what; we can develop our test lists from the requirements. Our unit tests should be very atomic so a single user story will most likely contain many unit tests that need to be developed and turned into a test list.

Hopefully I have shed a little light on the subject but in case I didn’t, here are some links below to additional resources:

Test-Driven Development

Introduction to Test Driven design (TDD)

www.testdriven.com

Tags: Development, TDD

My head has finally stopped spinning enough that I can finally write this post. Before I dig into it though let me give some context. A few weeks ago a post by Kyle Baley shows up in my feed reader which is in response to a post by Roy Osherove. Now both of these posts were on the subject of whether the entry barrier to Software Development is to high. More specifically though these posts were directly targeting TDD, Agile, Mock Objects, Inversion of Control, Dependency Injection, NHibernate, etc… Just imagine for a minute you are in a round room with doors all around you. Each door looks the same and has a small yellow light hanging above it. Now, you have to pick a door, but which door do you pick? But You can peek into the door and see whats behind it without fully understanding whats in there, but that just makes your decision even harder. That’s kind of how I have been feeling the past few weeks trying to get my head wrapped around these things. With so much information out there about these technologies you may argue that it is not hard learn any one of them well. I agree with that, in fact I am not going to try to teach you about these technologies unless I find a gaping void somewhere. The complex part comes when you are trying to learn about these technologies together and/or how they are linked to each other. This all started from a conversation I had with Colin Jack  in reference to the above posts, which by the way were not the only discussion in blog land on the topic, we decided a road-map of some sort would be a good idea for people that are new to these “New Era Development Tools”. 

A disclaimer before we begin though. I am not an expert at any of these technologies, as such I welcome comments, criticism and just good ole’ corrections for anything I post that may be misleading or wrong. What I am though is a software developer that wants to understand and learn these technologies and principals and put them into practice developing software. So again, a little background. I am a Developer/Project Manager/many more hats for a small manufacturing company in Oklahoma. Our development team consists of 2-3 people at any given point. We have successfully developed and deployed several line of business applications over the past several years using C# and Rhockford Lhotka’s CSLA Business Objects. Now I know a lot of people embracing these new technologies don’t like CSLA but it works for us and the new version of the framework is going to play even nicer with these new technologies. Two months ago I didn’t even know what TDD (Test Driven Development) stood for let alone how to do it. But I got some books, did some research and I understand WHY we should do it and as awkward as it seems we are putting it in practice on a daily basis now.

This will be the first in a series of posts where I show you the “Roadmap” that I am taking to learn these technologies and make them work together. As I said above, I am by no means an expert on these topics, but I am learning and hopefully you will be learning as well. I will start at the bottom of these Building Blocks and work my way to the top. I may also add more blocks in the middle somwhere based on things learned on the way up.

Tags: .NET (C#), Dependency Injection, Development, NHibernate, TDD