Yet Another Coding Blog : programming

Useful C# method for unit testing

Avi Pilosof — Thu, 16 Jul 2009 06:37:17 GMT

I’m unit testing a UI that needs to show some lists in various sorted orders, and I wanted to ensure that my tests would cover that. I found this method to come in handy:

   1:  public static bool IsOrderedBy<T>(this IEnumerable<T> coll,

   2:                     Func<T, IComparable> val)

   3:  {

   4:      if (coll == null || coll.Count() == 0)

   5:          return true;

6:

   7:      var curVal = val(coll.ElementAt(0));

   8:      for (int i = 0; i < coll.Count(); i++)

   9:      {

  10:          if (val(coll.ElementAt(i)).CompareTo(curVal) < 0)

  11:              return false;

12:

  13:          curVal = val(coll.ElementAt(i));

  14:      }

15:

  16:      return true;

  17:  }

Here’s how to determine if a simple array is in order:

var arr = new int[] { 1, 2, 3, 5 };
bool ordered = arr.IsOrderedBy(i => i);

Here’s how you’d call it on a more complex object:

var arr = Enumerable.Range(1, 10)
    .Select(e => new
    {
        Name = "bob",
        Salary = 10 * e
    });
bool ordered = arr.IsOrderedBy(i => i.Salary);

Avi

Live Mesh Applications – whoah.

Avi Pilosof — Tue, 17 Feb 2009 01:52:02 GMT

I’ve been playing with Live Mesh for a long time now, and have been loving it. During this time I’d been hearing about applications for Live Mesh, and while it sounded interesting in theory I didn’t really get what the point would be.

Then I watched this video:

http://briangorbett.com/mesh/mesh-video-player/

The video walks you through the development process of a Live Mesh app. The “whoah” moment is when I realized that the one codebase - without any special code - created an application that ran identically on the web and on the desktop. Money shot starts at about 25:30; but it helps to watch the whole vid.

This is fascinating; this is a “Web OS” (I hate that term).

Avi

Be Paranoid. Be Very Paranoid.

Avi Pilosof — Wed, 03 Dec 2008 06:29:33 GMT

Do you maintain an application with a backend database? Does that application ever write to the database? Be afraid.

The worst situation to be in with respect to the above is when a customer mails you and says: “Why is my data gone?”

99% of the time, it’s because they clicked on the “Delete” button; but sometimes you need proof – this is what I want to discuss.

Log every interesting write to the database. There are various levels at which you can do this:

Application logic level: This gives you the most context, the most usable logs, and in fact gives you data which can generally be exposed directly to the customer, preventing lots of questions. The problem is that it’s not reliable: The app could succeed in writing then fail in logging. Alternatively, a dev on the app might forget to add logging to a new feature.
Application object model level: A little less context/readability than above, a little more reliability.
Data-Access-Layer level: Less context than above, more reliability.
Sproc level: Same tradeoff.
Table level (triggers): And same again.

As you can see, the lower you go, the less chance for error and the less value a log entry gives you. You can increase the value of a “deep” log entry by forcing a set of arguments up the stack. For example, you can force every sproc which writes data to require username/machine/reason arguments – but this can become costly to maintain.

So which is right? Depends on your app, your level of paranoia, your customer’s needs, etc. Generally I stay away from triggers and try to add logging at the sproc level for critical sprocs, and at the app/OM level for extra context; better to have too much logging than too little.

Here’s a nice trick for creating a footprint log table that your sprocs (or triggers) can use quite easily - Create a simple table with the following columns (at least):

Name	Default value	Comment
LogEntry		The text you want to log.
TimeStamp	getdate()	Automatically fills in the current datetime.
User	system_user	Automatically inserts the logged in user’s ID.
Machine	host_name()	Automatically inserts the user’s client machine name.
Application	app_name()	Automatically inserts the name of the application running this code (provided you set it in the connection string, which you should!)

Inserting into this table requires only the one column, but you capture lots of extra data for free. If this is done from a trigger, then you’ll even catch slackers with access to the DB who are updating it manually.

Oh, don’t forget to age off old entries before the table ends up at 50GB ;)

Avi

Trivial but useful extension method

Avi Pilosof — Tue, 30 Sep 2008 08:34:45 GMT

Don’t know why I didn’t write this before; it makes code very readable. Often when you write anything graphics related, you want to constrain coordinates to window edges (for example).

So a simple method:

   1: /// <summary>

   2: /// Ensure that the given number falls within the

   3: /// given min/max constraints.

   4: /// </summary>

   5: public static double Constrain( this double num,

   6:                         double min, double max )

   7: {

   8:     if (num < min)

   9:         return min;

  10:     else if (num > max)

  11:         return max;

  12:     else

  13:         return num;

  14: }

It’s just a Floor combined with a Ceiling, but it reads nicely:

   1: xform.X = dx.Constrain(-this.ActualWidth, 0 );

   2: xform.Y = dy.Constrain(-this.ActualHeight, 0 );

Avi

On using Arrays

Avi Pilosof — Tue, 23 Sep 2008 03:52:32 GMT

Eric Lippert has a great article on arrays:

http://blogs.msdn.com/ericlippert/archive/2008/09/22/arrays-considered-somewhat-harmful.aspx

I think this is especially useful to consider if you’re writing an API. Consider not just arrays, but any time you’re returning any collection: Are you returning values or a variables? Did you mean to?

Avi

Code commenting? Try Business Commenting.

Avi Pilosof — Fri, 25 Jul 2008 06:12:15 GMT

Jeff has a good post here about code comments and that they shouldn't be used as crutches:

Coding Horror: Coding Without Comments

I agree with the article, but one thing I rarely hear mentioned is that it's often more interesting to comment the business justification than it is to comment the code. Jeff goes some way towards suggesting this when he says to comment the "why", but for many people that translates to "Why did I write the code this way?".

I often find that code I'm maintaining is missing comments regarding the business logic. Rather than "Why is the code designed like this?", something like "Why is the business process designed like this?"

This becomes most useful when you look at unfamiliar code (your own, probably) and decide that the easily-digestible code is nevertheless doing something you are sure is silly, and you change it. Big mistake.

Example of a code architecture comment:

   1: // We cache these values because they only change once per

   2: // week or so.

Or:

   1: // We lazy-load these properties because they're rarely used

   2: // and they chew up a decent amount of RAM.

Example of a business architecture comment:

   1: // We copy the lab owner on this mail because even though

   2: // they don't own this resource, they wanted to be aware

   3: // of changes. See bug 54321 for request and history.

Or:

   1: // This used to delete items older than 30 days, but

   2: // bug #65432 requested that an exception be made for

   3: // items that are of type X.

All are useful, but I find the second type are rarely used. They become more valuable as the code ages.

Avi

Australia is going to France!

Avi Pilosof — Tue, 08 Jul 2008 03:59:00 GMT

(Bonus points for misleading title)

The Australian Team SOAK just made it into the finals of the Imagine Cup. They were one of the 6 teams chosen in the Software Design Category.

This year's theme was "The Environment", and Team SOAK has written software to monitor/control water usage on farms.

Well done guys! I'll even forgive the fact you're from Melbourne ;)

UPDATE: They won!!!!

Avi

It's all just a clock measuring contest...

Avi Pilosof — Fri, 04 Jul 2008 01:13:00 GMT

Did you know that SBCL is now faster than Java, as fast as Ocaml, and getting better?! What does this mean for you? Most likely, nothing.

They have various benchmarks that are used to measure the speed of a language implementation; and I think it's a good thing - it keeps the implementers honest, and I'm not crazy about wasting CPU cycles just because they're there.

However, these numbers remind me very strongly of the local CompuMart selling the 2.4GHz machine for 1.5x the price of the 2.0GHz machine and relying on the fact that customers have no idea that this will make exactly zero difference for most uses.

Why? Because pretty much all programs nowadays depend on more than just the CPU. They're competing for RAM, disk access and maybe even network. None of those are nearly as fast as the CPU, hence most often create a bottleneck.

Aside from this, it's very likely that the code you're writing will be more dramatically improved by tweaking your algorithms than it would by changing the language.

Couple that with the unfortunate fact that most jobs won't allow you to just grab SBCL or OCaml because it happens to be at the top of the list today, and you're left with a measurement that has little real-world value.

What these measurements are good for is preventing those who write the language implementations from getting too lazy. While I think that application programmers should generally be spending CPU cycles to save lines of code, I don't necessarily believe the same for platform/language programmers.

Just don't look at this list and get too disheartened about your choice of language. Even if it is Ruby ;)

Avi

Can Software be Reliable?

Avi Pilosof — Fri, 27 Jun 2008 09:21:29 GMT

Just read a post (permalink is broken) regarding how software engineering is nowhere near the level of quality as traditional engineering, partially because we don't have standards, regulations, etc.

While I agree with some of the argument, people often give too much credit to meatspace engineering when compared to software.

You often get what you pay for, and this applies to both types of engineering. Look at NASA's software engineering team (awesome article). Two quotes from there:

"The last three versions of the program - each 420,000 lines long - had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors."

And:

"...the group's $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations."

Similarly, there's other very reliable software running very reliable systems (nuclear reactors, chemical factories, fighter jets, stock markets, whatever). Basically, when you're prepared to pay for software quality, you can get it.

Viewing things from the opposite direction; while it's true that none of my cars have ever spontaneously combusted on the highway, neither have any of them been bug free. There are always rattles, electrical problems, mechanical problems, and they all need constant maintenance - I can't treat my car recklessly and expect it to behave well forever. Just like with software, environmental changes can bring out defects in the original design. Bridges need constant maintenance, cracks form in buildings, roofs leak, gutters rust, foundations sink, water rises, dishwashers break (taking down my whole circuit) and light bulbs fry themselves.

Most of these things can be avoided with the judicious application of more resources (read: money [=time]). It just happens that most software companies get a better return on investment spending that money on new features/products than they do on aiming for five nines. Why? Because that's generally what customers respond to. What would you prefer - an iPhone with Safari occasionally crashing, or that small Ericsson from 1997 that never ever crashed?.

Sometimes it makes sense to spend a fortune to get that extra 1% (10%?) of quality, but each percent costs more than the last. I certainly want that last percent on bridges, airplanes and skyscrapers. But if I had to pay 3x the price for my video card (or phone, or DVD player) and wait 3x as long for new versions, I don't think it would be worth it.

Avi