Photoquarium Blog

Awesome, Aw … wait for it … wait for it …. SOME

I don’t think I could do justice to this post by summarizing it so I won’t.

If you have a few minutes to read this post I really encourage you to do so. Also post your comments here about the article, I would love to hear everyones take on this.

I’m off to read a bit on “complex adaptive systems theory” and “Evolutionary Stable Strategies”.

http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html

During one of my many discussions with James, he brought up the question “What makes a good developer?” I didn’t have any really good answers but, as most things, someone else had encountered a similar question that has given me a bit of insight. Davey Brion wrote a post on his blog ElegantCode on Ethics In Software Development:Pragmatism Over Dogmatism where he describes what he thinks is the primary goal of a developer and how writing crappy code (or maintainingcrappy code over fixing it) is counterintuitive to the goals of a developer.

A software developer’s primary goal should be to create value for the users of a system. Value can mean a lot of things here. First and foremost, it should be about things that users actually experience. Features, ease of use, performance, etc. You can get all of those with crappy code, but that leads to a situation where you won’t be able to sustain that value in the long term. A system can be very useful to its users, but if the code is in such bad shape that it can’t easily be maintained and extended with new features over time, the value of the system will slowly reduce. New features will introduce new bugs. Bug fixes will introduce new bugs. Eventually, the system starts to collapse under its own rot and the dreaded rewrite commences. Nobody really wants this, do they? If you write good, clean code from the beginning, you can usually avoid these problems.

Read the rest of this entry »

Sometimes you encounter things at just the right time. This article is one of those things at the right time. Please read this article if you have ever had to deal with legacy code and muttered under you breath, “Can’t we just scrap this crap and start over”, when trying to fix an issue. Below is my spin on it for the situation I am in.

Read the rest of this entry »

At my day job we are in the midst of a pretty big change in the way we are interacting internally within out systems. To date we have been interacting with a really ad-hock method which has caused a lot of dependencey issues and headache, especially when trying to upgrade anything.

So on our path toward SMWDA or Stable Modular Well Documented API’s, I have some across this article on the MSDN site. Now don’t let the fact that it is in MSDN Magazine and written by someone that develops on Microsoft’s platform deter you from reading it, it is a good read. It will also give you a little bit of an insight on the direction our code bases should be going.

Open Closed Principle

I was going to give a quick summary but the article isn’t that long and it does a better job than I can.

For all of you out there that need or want to read up on software engineering or just want to pad their geek library with books that will get noticed, check out this list of The Top 100 best Software Engineering Books, Ever. 

This is a huge list and maybe you don’t agree with all these books as a “best ever” but it will give you some books to keep in mind as a start to increase you knowledge. Also he posted a follow up to this post here. Enjoy.

 photo credit: blu_blue

Lately there have been a few blog posts that I have read about whether to relay the benefits or features of a product to the user in an attempt to give them the best tools to choose your product. Some circles believe that you should list the benefits that a product produces instead of features since benefits can be understood easier by clients instead of a list of features (which can and most times are a technical list and confusing to the end user).

Read the rest of this entry »

I love how the internet just let you stumble onto new and great things. Be it the latest “Funniest Home Video” on youtube or another great blog writer. Just today I was going through my rss feeds and Max Pool had a quick little post on a new blogger he has been reading.

Now Max’s article isn’t much more than “I like his posts here are a few of my favs“. Short simple and piqued my interest.

So I went over to Jurgan Appelo’s blog and took a look at the arctiles and low and behold I think I agree with Max. Jurgan you have some great posts and I am going to add you to my feeds that I use to help better myself as a developer and aspiring Project Manager.

I could make a few posts on what I have taken away from each of the articles I have read on his blog but I don’t really have the time so here is a recap of the posts I read:

• Make It Simple vs Do It Simple
• Complex versus Complicated
• MoSCow Priorities
• The Single Above-Average Programmer

Plus I think if I read these posts again in a few months even I would get something different from them.

Thanks Max and Jurgen

I ran into a little issue with trying to update a UI from a working thread. I was working on refactoring some code which I took from .Net 1.1 and upgraded it to .Net 2.0 as well as refactoring some of my earlier work. Code that I now look at at slap myself trying to figure out why I had put all the business logic directly into the UI class. Dumb me. But that is all part of the learning process and I don’t know anyone that writes code they are satisfied with when looking back on it a few days, months or years down the road.

Alright, enough of a side track back to the threading issue. Basically in the .Net 1.1 land you had to declare a a delegate and then create a instance of that delegate and then use that instance in your thread to do the actual updating. It can get quite messy. At least from my perspective. Here is a small example:

     public class UI
     {
        public delegate void UpdateProgressBarDelegate(int percent);
        public UpdateProgressBarDelegate updateProgress;

        public UI()
       {
           updateProgress = new UpdateProgressBarDelegate(incrementProgressbar);
       }
    }

Now in a function somewhere on the working thread you would have this:

     private class doingTheUpdate(int percent)
     {
         mainUI = updateProgress.Invoke(new object() { percent });
     }

With .Net 2.0 it gets a bit simplified and you can use the EventHandler class to create an event and you don’t have to declare the delegate and then create an instance. Below is an example:

    public class MyUI
    {
       public event EventHandler UpdateProgressEvent;

       public void InvokeUpdateEvent(int percent)
       {
          InvokeUpdateEvent(UpdateProgressEvent, percent)
       }

       [MethodImpl(MethodImplOptions.NoInlining)]
       private void InvokeUpdateEvent(EventHandler handler, int percent)
       {
          if( handler != null )
          {
             MyEventArgs e = new MyEventArgs(percent);
             handler.BeginInvoke(this, e, null, null);
          }
       }
   }

Now doesn’t that seem a bit more concise. I admit I am doing some other things there to help make this thread safe and I got most of this from Dave Brook’s at Aliens ate my GUI. So I will try to summarize what it is doing.
First where it looks like I am declaring the method InvokeUpdateEvent twice, once as public and once as private, I am. The reason this is done is because you can get a race condition if you just check for null and then call the event. A way to fix this potential race conditions Dave explains it very well so I won’t try.

“One counter measure is to make a copy of the delegate. Delegates are immutable so by copying it to a temporary variable you keep a copy of the original state of the delegate, irrespective of any thread context switches. Making any change to the state of the delegate creates a new one on the heap and updates the reference to which the delegate point.”

As well on the private InvokeUpdateEvent declaration there is a attribute added. This is added because the JIT compiler might optimize the code above and basically get you back to the state before where the race condition can occur. So the [MethodImpl(MethodImplOptions.NoInlining)] attribute is used to tell the JIT not to optimize this function.

The only other item in there is MyEventArgs class. This would just be a class that inherits from the EventArgs class and adds any info that needs to be sent with the event. In this example it was just the percent to update a progressbar.

Hope this helps. I know it helped me.

 Edit:

Well I have jumped the gun a bit on this one and it looks like I needed to add one more thing to this to make it work on threads. when I call the event in the last function I still will need a BeginInvoke to make sure that it is run on the correct thread or else I get a cross threaded exception thrown. I have edited the code above to reflect this.

Also if you have any suggestions to improve this please post a comment. I am not perfect even though I tell myself I am.