What's hot ? (and I mean really ...) - scroll down for more
1).  Code Templating - advanced usage of delegates & generics: my slides & demos are available for download! CodeProject article is also available.

2).  My series "TDD in the eyes of a simpleminded" is in progress(including code!): preface, part1, part2, Q&A 1, Manual Stub .vs. Mock Stub

3).  TDD Workshop: SeeCompass v0.1 and v0.2 are out.
# Wednesday, April 04, 2007

One of my favorite C# 3.0 features is Extension Methods. In short, it ables you to extend an existing type with additional behaviors. For example, you can consider to extend the type System.Int32 (aka "int") with a new method named IsEven.

The syntax is quite trivial:

namespace Lnbogen.Extensions
{
    public static class Extentions
    {
        public static bool IsEven(this int i)
        {
            return ((i%2)==0);
        }
    }
}

Notice the "this int" which means "I want to extend the type int".
Now I can write the following code (fully IntelliSense-d and compile time checking):

using Lnbogen.Extensions; //<- this will load the extensions, it won't compile without it!

... void TestIsEven()
{
   int num = 5;
   Console.WriteLine(num.IsEven());
}

What's going on behind the scenes is quite simple, the compiler got a little "smarter" and now knows to look for Extension Methods in the imported namespaces. I don't want to elaborate too much about the syntax and requirements as Anders Hejlsberg makes it all clear in his MSDN video: C# 3.0: Future Directions in Language Innovation.


Let me direct you to the  real  meat:


Extension Methods is going to change the way we enhance "already used" code. Up to now, looking at that need (for backward compatibility), Microsoft suggested to create an interface and an abstract class that implement this interface. This allows us to extend the abstract class simply by providing new virtual members without breaking the code. The problem in this solution is that things were getting out of sync really fast leaving our interfaces shy & dry(=out of date), just to avoid breaking changes. Even worse, due to the fact that multi-inheritance is forbidden, inheriting from the abstract class pretty much slammed the door on most of our design choices. 

Let's face it; Interfaces were programmer's nightmare(before you hack my blog and delete this post, bare with me). On one hand, we're reluctant to implement an interface with 10 members as we prefer to finish our tasks in this century but on the other hand, we want our interface to expose as much API as it can to allow easy usage for its customers(=programmers) and to avoid casting it(the interface) to "specialist" interfaces.

Well, Extension Methods allows us to extend any type. Do you get my drift here?
You can now enhance any interface you've ever exposed thus making old interfaces incredibly strong. You can define a lightweight interface(easy for the implementor of the interface) and extend its abilities without breaking any existing code(enrich the customers of the interface). This is exactly what Microsoft did with LINQ. They have extended IEnumerable<T> with many Query methods such as "Select", "From", "Where", "GroupBy", "Join" (and much more...) to enhance it with a great set of new methods while still keeping the original interface untouched. All we have to do is simply import System.Query namespace.


Brilliant.

.NET | C# 3.0
Posted by Oren Ellenbogen 
04/04/2007 07:01, Israel time UTC+03:00,     Comments [2]  | 
# Sunday, March 04, 2007

 15417-23PY.jpg

We've just received an email describing the agenda for Purim day here at Mercury.
It goes something like:

" Register for Purim disguise competition(M1 building)
(You can be painted for free ; -)

... [ some more text goes here ] ... "

The first thing that came up to my mind was "Oh shit, it won't compile, she forgot to close the second )".

 

Happy holiday everybody!

 

Posted by Oren Ellenbogen 
04/03/2007 01:59, Israel time UTC+02:00,     Comments [1]  | 
# Wednesday, February 21, 2007

Assuming that you're running it from the same directory the .csproj file exists in (using Visual Studio 2005 Command Prompt):

msbuild wapProjectName.csproj /p:Configuration=Release

msbuild wapProjectName.csproj /target:_CopyWebApplication /property:OutDir=c:\SomePath\
  /property:WebProjectOutputDir=c:\SomePath\ /p:Configuration=Release

copy bin\*.* c:\SomePath\bin\

Enjoy.

Posted by Oren Ellenbogen 
21/02/2007 11:26, Israel time UTC+02:00,     Comments [1]  | 
# Thursday, February 15, 2007

If you write a blog and love to talk about code\architecture\funny customers\funny programmers\funny [you name it], you've got a chance to talk the talk and chop the chops.

Date: 21/02/2007
Time: 21:00
More details here.

I'll be there.

Posted by Oren Ellenbogen 
15/02/2007 09:46, Israel time UTC+02:00,     Comments [0]  | 
# Monday, February 12, 2007

In one of our screens, we have a list of items on the left pane and "details" screen on the right pane. The details pane appears only when one of the items is selected. If no item is selected - we show some sort of empty pane that describes the usability of the screen and ask the user to select an item in order to continue.

In order to switch between the details\empty panes, I draw two span elements and played with their visibility property. The controls are partially rendered which means that if the user did not select an item, no "details" controls or rendered and neither their validators. The problem is that ASP.NET register the validators only once (via ValidatorOnLoad() method) and on the first time the screen is rendered, the controls are not there yet (no item is selected by default).

The solution was pretty straight-forward, I think. I've downloaded a simple call to my javascript method so the validators will be re-attached again:

ScriptManager.RegisterStartupScript(this, this.GetType(), "HookupManuallyToValidators", "ReRegisterValidators();", true);

And the javascript method:

function ReRegisterValidators()
{
   if (typeof(Page_Validators) == "undefined")
      return;

   var i, val;
   for (i = 0; i < Page_Validators.length; i++) 
   {
        val = Page_Validators[i];
        ValidatorEnable(val, true);
   }
}

1-0 to lnbogen .vs. asp.net

Posted by Oren Ellenbogen 
12/02/2007 05:09, Israel time UTC+02:00,     Comments [1]  | 
# Saturday, February 10, 2007

There is a big set of posts about this issue lately. From Ayende's Can you learn to program better? and What can make a great programmer? to Phil Haack and his Better Programming By Programming Better to Jeff Atwood and his How To Become a Better Programmer by Not Programming and many others...
Well, they are all great developers and they all give us a great view for what is a great developer and how can you become one(or realize that you already are, for that matter). I like the way Jeff sums it up:
" You won't-- you cannot-- become a better programmer through sheer force of programming alone. You can only complement and enhance your existing programming skills by branching out. Learn about your users. Learn about the industry. Learn about your business. "

I agree with all of them about the HUGE leap each great developer should take from being a good developer into a great developer. Not many have done it, although I believe that many more can. I'm not sure if you heard about Ron Clark, his story is an amazing demostration of true passion to bring the best out of people. Ron managed to take a bunch of kids from Harlem, those that no one believe in them, and make them one of the best classes in the US. In his first lesson, he wrote on his board: "Dream Big! Take Risks!". He manged to direct his students with his 55 rules and teach them how to become a great human beings before everything else. It's a story about how to get everyone around you excited, driven to extract the very best out of themselves.

In my point of view, great developers are the one that really into code because they love it and because they want to make the rest of us guys better. They possess Ron's Passion to make everything better. The software they are building and the guys that are involved in doing it.

I tried to come up with my "rules" that helped me progress and influence others in the last 7 years:

  1. Be proud of your work - The most important rule I give others - Love your job, Enjoy code, Appreciate elegant solutions and let them be your inspiration.
  2. Be Eager to learn - In order to become one, you must learn the "55 rules", the foundation of your progression bar. Ayende says it best:
    " At any rate, what I am trying to say is that you need to act. Doesn't matter what you do, you need to keep pushing your knowledge until extra knowledge is easy to absorb. ". Always have a list of things you would like to know. Clear some time for you in order to progress. baby steps.
  3. Write it all down - It will take you years to understand why X is "better" than Y. Why writing logic inside a stored procedure is not always the smartest thing(or why SP is not the best way in common\simple scenarios), why it's important to unit-test your classes or why loose-coupling is that important. Following only ideas from others without suffering from your mistakes will keep you always a mediocre\good programmer at best. I have started my world with Data-Access-Layer written manually, then generated it and only then using some sort of ORM tool for this task. I've learned so much in the process that "spending" years at each phase made me understand better the way I work and the way I want to work. It was worth it. I don't encourage repeating others mistakes, I just want you to follow your heart. There are mistakes worth repeating, if it will improve you and make you releaize things about yourself.
  4. Seek for better ways to solve things - In time, you'll see a lot of recurrent patterns in your code. The way you write your application tiers, your data-access, your database, your sql, your security handling, your logging mechanism, how you integrate with other applications or how you create a solid framework. In time, you'll see a lot of recurrent thinking you were used to. Only in time you'll know how to solve code duplication in a proper manner, how to build a smart API and how to estimate your mission so you'll meet the deadline without staying at work for 14 hours a day.
  5. Don't be afraid to get credit for your work - remember, be proud of your work. You deserve it. Take ownership!
  6. Be proud of your people - Your people will make you progress or stay put. It is simple as that. 
  7. Share your knowledge - I remember that a good friend of mine talked with me about whether is should help others at the office on the expense of his time. He felt that writing code for others will make them progress on his expense. I could relate to his thoughts, but I strongly disagree with him and that's what I told him: Teaching others is the best way to take the next step. Make sure you educate others, it will make them easier to give you back. I believe that this ability and willingness to teach distinguish the great ones from the good ones. If you really want to progress from being a programmer to a Team Leader\Architect\Adviser\whatever, you would need your co-workers support, right?
  8. Find a mentor - find someone at work that will make you work harder just to so they would be proud of you. I call it the "work-daddy syndrome". It is much easier to motivate yourself if you know that someone expect greatness of you. My parents expected that I'll be great from the first day I could remember myself. They never pushed me too hard or made me stress. They were there for me when I needed them. Always with something good to say to calm me down. The reason I am so motivated to be the greatest programmer I can be is that I have great friends that expect it from me and I had the pleasure to work with my mentors and get their feedback to push me forward. I want to make them proud.
  9. Be a mentor for others - All my life I thought that I am blessed with great family, great friends and great co-workers because I manged to contribute to others. I allow myself to feel this as I know that I do my best to contribute others, to make my surrounding feel that we're heading for a better place. That we will actually be there soon. Look hard and find someone that you can see the potential in him, and if he\she let's you, help them to become better. There is no better feeling that getting a big Thank You. I'm hardly a religious guy, but I feel it easier to except good surprises in life due to good acts on my side. If something terrible happens, I know that I have a good place to fall into, that I'll bounce back.
  10. Enjoy life, it's yours - leave a funny comment in your code, don't be afraid of saying geeky comments, laugh about your\others old code. Laugh as much as you can. People will follow you if you'll know how to make them smile when things are hard. Coding can be a bitch, great programmers makes you forget it for a while.

Good luck, I know you can make it. 

Posted by Oren Ellenbogen 
10/02/2007 02:55, Israel time UTC+02:00,     Comments [4]  | 
# Wednesday, February 07, 2007

I'm doing one of the most complicated UI I've ever did(ASP.NET). In the process, I need to generate tabs(via MultiView control) pragmatically and for each tab render a tree-like checkboxes. All based on external xml. Yami.. ;-)

Reading a little about how to add dynamic View to MultiView control made me realize that I need to do my magic on the page's PreInit event. This one was quite easy, I've override the OnPreInit (I could register to the event in the page constructor, but this is easier) and called my dark voodoo "BuildTabs" method. All is good.

Now, Adding MasterPage to the blend made me puzzled for a few minutes. It seems that the page's controls are not initialized on the PreInit phase if the page has MasterPage. After I got my eyes back on the screen, stop nodding with disappointment and taking my head off the wall, I used my built-in behavioral program:

pre-think (short phase ~Thread.Sleep(1000*60));
while(no solution yet) { 
   try;
   think;
}.

2 minutes later I found the trick:

protected override void OnPreInit(EventArgs e)
{
   base.OnPreInit(e);
   base.Master.Init += new EventHandler(Master_Init);
}

void Master_Init(object sender, EventArgs e)
{
   BuildTabs(); //we must draw it from scratch on each post-back.
}

Now the controls are initialized and I can program in peace.

Posted by Oren Ellenbogen 
07/02/2007 11:47, Israel time UTC+02:00,     Comments [2]  | 
# Saturday, February 03, 2007

http://urikalish.blogspot.com/2007/02/beam-me-up-scotty-copy-and-paste-human.html

Talking about building solid, trustable enterprise applications...
gosh, this makes you think about real-time applications in a different perspective right?.

After you're done wiping, read *this dude's blog.
He is a good friend of mine and a teammate at Mercury, and by god, he knows how to write and he's never boring!

* I call him T-Bag(no physical similarity, just a private[for now] joke), but he's also known as Uri Kalish ("the man and the legend").

Posted by Oren Ellenbogen 
03/02/2007 09:06, Israel time UTC+02:00,     Comments [0]  | 
# Tuesday, January 16, 2007

After digging in into BitArray with Reflector, I saw that this class, in its current state, is simply unusable; Here is why:

1.  The class does not override Equals (and ==, !=, GetHashCode). We use BitArray because bitwise comparison is relatively very fast. I don't want to perform reference comparison on bitwise array. I use bitwise structure to perform bitwise operation and bitwise comparison.

2.  This class is sealed.  Reading the first section can give you the idea why this is a mistake built on top of another mistake.

3.  The exposed bitwise operations change the state of the object. Meaning doing bitArrayInstance.And(anotherBitArray) actually change the state of bitArrayInstance. I really don't understand why this was made by design. It is very common to perform several bitwise operations on a BitArray object and perform some comparison afterwords.

We decide to disassemble the code into a new class named BitArray2 and I refactored the code so it would fit the "normal"(in my book) usage of BitArray.
The code:

BitArray2.zip (4.19 KB)
Posted by Oren Ellenbogen 
16/01/2007 10:33, Israel time UTC+02:00,     Comments [1]  | 

I have to following code:

BitArray arr1 = new BitArray(200);
BitArray arr2 = new BitArray(200);

arr1[2] = true;
arr2[2] = true;

if (arr1.And(arr2) == arr2)
   Console.WriteLine("good");
else 
   Console.WriteLine("bad");

It returns "bad" for some unknown reason.
My guess is that Equals implemented a reference comparison and not bitwise comparison.
It seems like a strange behavior as BitArray is classic for bitwise operations on it.

Am I missing something?

update: I've refactored Microsoft orginal BitArray and named it BitArray2. You can find it here.

Posted by Oren Ellenbogen 
16/01/2007 12:11, Israel time UTC+02:00,     Comments [2]  |