Archive for March, 2009

Cross-Platform .NET Business Applications?

10 commentsWritten on March 19th, 2009 by
Categories: Silverlight

Was just going over the new Silverlight 3 features. One thing in particular that i find very interesting: the out-of-browser capabilities:

The new out of browser experience in Silverlight 3 enables users to place their favorite Silverlight applications directly onto their PC and Mac, with links on the desktop and start menu—all without the need to download an additional runtime or browser plug-in.

So we can create .NET applications that run on the Mac now :)

Sure, they'll be sandboxed and you can't do everything a real native application could do, but this could still be a pretty compelling deployment choice.

Continuous Integration 101

2 commentsWritten on March 17th, 2009 by
Categories: Continuous Integration

More and more people are working in teams where Continuous Integration is used. Not everyone truly 'gets' it though... Below is a quick list of things you, as a member of the team, need to keep in mind.

Before you commit your changes to the repository:

  1. You update your local copy to get all of the changes that were committed since you last updated your local copy
  2. If there are conflicts, you resolve them in your local copy... you DO NOT simply overwrite other people's changes
  3. You compile your code (You'd think nobody would forget this one, right? Think again...)
  4. If it doesn't compile, you fix it (Again, you'd think nobody would forget this one....)
  5. If it compiles, you run the tests. At least run the fast tests, and i do mean all of them, not the ones you just wrote or modified. If you have thousands of slow tests, then you obviously can't run them every single time you need to commit. But you can and should definitely run the fast tests. Yes, all of them!
  6. If a test fails, fix the code that broke it, or fix the test if it's no longer correct. Repeat this process until none of the fast tests fail.
  7. Commit your code, and begin working on your next task, take a break, go home, whatever is most appropriate at the time.

For the next section, i'm going to assume that everyone has at least something that continuously visualizes the state of the automated build, either TV's on the wall (like we have), or at least a system tray notifier (like we also have).

When the build breaks:

  1. If none of your team members beat you to it, look at the build results to figure out why it broke
  2. If it's a compile error, alert the team (so they don't accidentally update their local copy with the broken code), and figure out who's responsible. MAKE SURE THE COMPILE ERROR(S) ARE FIXED ASAP. As a team, punish the guilty one for wasting the team's time (make the guilty one buy donuts, pizza, make them wear a dress for a day, whatever works...)
  3. If it broke because of failing tests, look at the failures. Where you the last one to touch those tests or the code that was being tested by them? Then fix it ASAP. Was it someone else? Discuss this with the person who's responsible. If the developer who's responsible has time to fix it, then he/she must fix it at once. If the developer can't fix it instantly, then someone else has to step up and fix it. DO NOT WAIT FOR SOMEBODY ELSE TO FIX THEM. Discuss it with the team and agree on someone to fix the tests. If you're not sitting with the rest of the team, pick up the phone, use IM, whatever. But at least do something!
  4. Repeat these steps until the build is green again.

As a member of the team, you have certain responsibilities. Every team member has them. You have to take your responsibilities seriously, if not, you're just wasting your team members' time. At the same time, you should hold your team members accountable when they fail to take their responsibility serious. Don't fight about it, but talk about it as a team. When people don't do what they are supposed to do, discuss it with the entire team and after a couple of times (at most) people will feel that social pressure to not let the team down again. If they don't, well then maybe they shouldn't be part of the team in the first place but that's a whole other story.

Why Don’t We Learn?

16 commentsWritten on March 17th, 2009 by
Categories: Rants

Most of us are working in object-oriented environments, right? How many of us are working in a truly object-oriented manner? How many of us merely think that we're working in an object-oriented manner?

I just happened to read the following (who it's from or where i read it doesn't really matter):

When i was learning OOP back in the early 1980s, ...

A statement like that just makes me cringe. Here we are, in the year 2009 and we're all trying to continuously get better at our craft, our hobby, our passion, or maybe just our job. An increasingly larger number of .NET developers are basing their improvement on solid OO principles and practices. And i don't just mean Uncle Bob's SOLID principles. I'm talking about learning from the experience which others before us have gained 20, 30 years ago. How sad is that? I mean, learning from others is great, but how sad is it that all of this great knowledge is something that only a portion of us seek to learn, and usually only after having been active in this profession for a while.

This is an industry where we are supposed to advance rapidly in our way of working, to achieve better results. To produce higher quality software at a lower cost, ideally striking a balance between short-term cost and long-term cost. Yet we are still having difficulty trying to get the majority of us to accept and embrace what others have learned many, many years ago. Oh sure, we might have achieved a higher level of automation within our development process these days due to the availability of more advanced frameworks and tools. But take a look at the principles that are behind most of these frameworks and tools... Most of them have been around for a long time and it's a pretty sad state of affairs that these kinds of principles are only starting to become popular in the year 2009.

Personally, i would put most of the blame with the large software vendors. They continuously hop on whatever bandwagon is popular at the time, while always promising increased productivity with their latest products. You can create a web application just like that (snaps fingers). Want some AJAX goodness? Oh just drag this component on to your web page and voila, you're done! Need Web Services? Just put some of these attributes on top of your methods and there you go! Or better yet, let's just all design some models and generate a whole bunch of code which will save us a tremendous amount of money!

So far, that hasn't really worked out, has it? Yes, most of these 'innovations' increase short-term productivity and best of all, they don't require expensive training and education. Everybody wins! In the longer term, this usually leads to software which is just waiting to be killed off and rewritten and developers who are even more fucked up than they already were.

This has some pretty interesting non-technical consequences as well. What is the general perception of normal people when it comes to the average quality of software that they experience on a day-to-day basis? A lot of people not only accept the fact that software is often buggy or unreliable, they've even come to expect it! Software that crashes? Oh that's ok, just restart it. Weird error messages? Oh that's ok, just click on them and they go away. Is it slow? Well everything is slow these days! I've often wondered exactly how we ended up with this culture of accepted and expected mediocrity. At least there is one benefit: if you're not a complete idiot, you've got a pretty good shot at a successful career in this field.

We're always looking ahead for newer versions of whatever it is that we use, newer tools, approaches that avoid problems that we're currently facing, the silver bullet that is going to solve all of our problems, etc... And that is important, we need continuous progress. It just would be nice if people realized that in order to truly create progress, you need to keep learning from the past as well.

Book Review: NHibernate In Action

3 commentsWritten on March 15th, 2009 by
Categories: Books, NHibernate

As far as Object Relational Mapping (ORM) in the .NET world goes, NHibernate is one of the more mature, powerful and popular options available. But learning how to use it properly can take some time. NHibernate In Action aims to lower that learning curve significantly.

The first 2 chapters offer a general introduction to ORM, some reasons why NHibernate is the authors' preferred ORM, and a step-by-step guide to creating your first NHibernate application. Topics such as NHibernate's (high-level) architecture and configuration are also covered here.

The book then proceeds to cover some important NHibernate concepts in depth. First up, writing and mapping classes. This particular chapter doesn't cover really advanced mapping scenarios (a later chapter takes care of that), but it does cover most of your options very thoroughly. This isn't just basic mapping though. You'll already learn about various types of associations you can have and the three available strategies for inheritance mapping.

Once you've learned how you can map your objects, you can start working with them, which is what chapter 4 covers. You'll learn about the persistence lifecycle, working with transient/persistent/detached objects, dealing with object identity depending on the current state of your objects, transitive persistence (cascading options), and you are introduced to some of the possibilities for object retrieval.

Chapter 5 teaches you how to deal with transactions, the various options to deal with concurrency and it also covers NHibernate's caching features very thoroughly. All 3 of those topics should be very clear to you after this chapter :)

After that, the authors revisit the subject of object mapping again in Chapter 6, this time covering some more advanced options. The stuff you'll learn about in this chapter is very interesting, but in most cases you won't need these features. But it's good to know that they are there in case you need to handle more exotic mapping situations ;)

Chapter 7 is probably one of the most important chapters of the book, as it deals with various ways and methods to retrieve objects efficiently. You'll get great coverage of HQL in this chapter, and you'd be surprised how powerful it is. In most cases, you'll see the equivalent of the HQL statements using the Criteria API of NHibernate, but (and this is one the few gripes i have with this book) for some of the advanced concepts (namely projections and grouping) they completely ignore the Criteria API and focus solely on HQL. I'm a pretty big fan of the Criteria API so i obviously find that a little bit disappointing. It does cover pretty much everything else you want to know about querying with NHibernate though.

The final 3 chapters deal with using NHibernate in the real world. These chapters might be of use to people with little experience in (proper) software development, but i don't really think most people will really get a lot of value out of these last 3 chapters. Topics covered here: layered architecture, common design goals you should aim to achieve, some options with regard to generating code/mappings/database, dealing with legacy database structures and more. Again, this might be interesting to some, but definitely not to all.

Overall, i would say that everyone working with NHibernate would benefit greatly from reading this book. If you're just getting started with NHibernate, it will indeed lower your learning curve significantly. If you already have experience with NHibernate, you will most likely learn some tricks that you didn't know about yet. It's a good book to read cover to cover, but at the same time it will be of great service to you as a reference book. Chapter 3 through 7 especially are chapters you'll probably revisit frequently while you are working with NHibernate.

There is one thing to keep in mind though... this book targets version 1.2 of NHibernate, which is a bit of an old release. This is rather unfortunate since NHibernate 2.0 and 2.1 introduced a lot of great new features. Obviously, these great new features aren't covered here, but the most important things of working with NHibernate are all covered thoroughly so don't let the 1.2 version number make you think that this book isn't relevant to the current versions. This book is by far the best source of information on how to get the most out of NHibernate.

Upgrading To NHibernate 2.1

20 commentsWritten on March 15th, 2009 by
Categories: NHibernate

This is something that a few people (those who don't read release notes ;) ) are going to run into, so i figured i'd post the solution here.

If your application uses NHibernate 2.0, and you want to upgrade to NHibernate 2.1 you need to add something to your NHibernate configuration. If you just replace NHibernate.dll with the newer version and start your application, you will get an exception with the following message:

The ProxyFactoryFactory was not configured. Initialize 'proxyfactory.factory_class' property of the session-factory configuration section with one of the available NHibernate.ByteCode providers. Example: <property name='proxyfactory.factory_class'>NHibernate.ByteCode.LinFu.ProxyFactoryFactory, NHibernate.ByteCode.LinFu</property> Example: <property name='proxyfactory.factory_class'>NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle</property>

Pretty helpful message, no? (if only everyone would actually read the content of exception messages)

NHibernate used to default to use Castle's DynamicProxy to generate runtime proxies, but you now have to explicitly state which proxy factory should be used.

For instance, if you want to use Castle's DynamixProxy, add a reference to NHibernate.ByteCode.Castle.dll to your project and add the following line to your hibernate.cfg.xml file:

    <property name="proxyfactory.factory_class">NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle</property>

If you want to use another proxy factory, add a reference to the correct one (for instance, NHibernate.ByteCode.LinFu.dll) and modify the property in the config file. A proxy factory which uses Spring will also be included soon.

« Older EntriesNewer Entries »

Meta

Recent Posts

Categories

Archives