Ezekiel - Sent into an impossible situation

As part of my effort to get to know God again I've started reading the book of Ezekiel. I didn't pick it for any particular reason except that I needed to start somewhere.

This is the story of a man who had recently been exiled from Babylon and, by all accounts, was an average Joe until God singled him out for a very dangerous task: He was to go to Israel and inform the people that God was about to destroy their city and most of the people in it. You see, Israel had fallen into sin and was as evil as it gets. It's uncanny to read about how angry God was that they had turned on him, and to hear his plan for unleashing his wrath on their lives.

But if he's so angry, why did he bother to send an ordinary man to Israel to warn them? Because God is compassionate and wanted to give them one last chance to redeem themselves and save their lives:

Ezekiel 18v21-23 - "If an evil man stops sinning and keeps my laws, if he does what is right and good he will not die; he will certainly live. All his sins will be forgiven, and he will live, because he did what is right. Do you think I enjoy seeing an evil man die?" asks the Sovereign Lord. "No, I would rather see him repent and live."

For all his anger at the people of Israel, God still wishes for them to come right with him and leave their evil ways. If God had no compassion he would simply destroy Israel without warning.

Have a good day,
Cheers,
Luke.

Discovering God without Bells and Whistles

For a long time I've been neglecting my relationship with God. So, the other day I decided to pick up my bible and start reading what he has to say. Something struck me while reading The Laws of Prosperity by Kenneth Copeland regarding God's covenant to his people:

Before the world was created, the Word already existed; he was with God, and he was the same as God. From the very beginning the Word was with God. Through him God made all things; not one thing in all creation was made without him. The Word was the source of life, and this life brought light to mankind. The light shines in the darkness, and the darkness has never put it out. (John 1, v1-5)

I'd always thought that if God was really serious about using me as his servant that he'd reveal himself to me in a way that would confront my comfort zone. I'm talking about an apparition or some wierd, cooked event that I wouldn't be able to avoid. Was I ever off the mark.

What I'm beginning to realise is that God's Word is his revelation to us and is much a message to me as it is to you and everyone else. It's a contract founded on 100% truth and purity. I've always had a huge problem determining how deep to go when reading the bible. I'm a quantitative person - if you ask me to ride a bike I'll start outlining limits for peddling speed, seat height, brake application - everything gets measured and tuned. So, when I'm told to "read the bible" I start freaking out about how much to read, how deep to go, whether I should focus on a single verse at a time. As I'm reading I start worrying about whether I've missed something crucial that is required for the next verse. It's probably what I love about programming so much: it's deterministic and predictable.

Ahhh, but what a relief to realise that the Holy Spirit is with me when I'm reading. He helps me grok the verses and keeps those parts that are required for the next verses in memory. In other words, I get a wholesome understanding instead of panicking about what meaning to take and what to leave. With the Holy Spirit walking me through the passages I don't feel like I'm missing out on God's message.

And so, Dear Reader, I will share my journey with you as I read God's Word. I've started reading Ezekiel and all I can say is that he's one willing servant of God.

A prayer asking the Holy Spirit to open your heart and mind to the Word:

Dear God,

I ask that your Holy Spirit guide me through your Word. Help me unlock the meaning and understand what it is you're telling me. Your Word is your covenant to me and I want to learn more about you. I pray for an open mind so that I can hear the message you have for me.

I ask this in Jesus' name,
Amen.

System.Uri.Segments : String[] - wierd logic and no caching

I'm busy writing a URL parser that will take URLs such as these:

• http://example.org/Home/Blog
  
• http://example.org/Home/Blog/id,1204/

And extract information on what controller I need to invoke. I'm using System.Uri to extract the Path information by grabbing the Segments : string[] property. I iterate over the loop twice per web request, so obviously I don't want System.Uri to recreate the segments each time.

So, I fired up Lutz Roeder's Reflector and inspected System.Uri. First off I find this gem at the top of the method:

string[] strArray = null;
if (strArray != null)
{
return strArray;
}

Hehehehe, I wonder when that return statement will be executed? I also see IndexOf's and Substrings being used. Would regular expressions be faster in this instance?

Also, they declare an ArrayList to hold the segments when the number of segments is known:

ArrayList list = new ArrayList();
for (int i = 0; i<privateAbsolutePath.Length; i = index + 1)
{
index = privateAbsolutePath.IndexOf('/', i);

// ....

list.Add(privateAbsolutePath.Substring(i,(index-i) + 1)); }

The ArrayList is cast to a String array later on, but that call isn't necessary if a string[] segments was declared before the start of the loop. Collections are only necessary if the number of elements cannot be determined until it is fully populated.

In a nutshell, System.Uri.Segments does not cache the resulting path segments, so I'll need to save the output string array and iterate over it rather than on the Segments property.

As an aside, here is how a URI is structured:

  \_/   \______________/\_________/\__________/ \__/
|           |             |           |        |
scheme     authority       path        query   fragment
  foo://example.com:8042/over/there?name=ferret#nose

(thanks cambiaresearch.com)

Using DebuggerDisplay to make your types debugger-friendly

System.Diagnostics has an attribute called DebuggerDisplayAttribute which lets you specify additional documentation for your classes and properties.

The quick way to make your types more human-readable is to override the ToString() method and return a string telling the developer about your type's instantiation. However if you're using ToString for something else then you'll need to use the DebuggerDisplay attribute.

Let's say we've got a class called Cow:

public class Cow
{
public string Name { get; set; }
public bool HasBell { get; set; }
}

The quick way modify this class give some useful information about Cow in the debugger would look like this:

public class Cow
{
public string Name { get; set; }
public bool HasBell { get; set; }

public override ToString() {
return String.Format("Name = {0}, {1} a bell", this.Name, this.HasBell ? "has", "does not have");
}
}

Our debugger will show this line:

Name = "Bessie", Has a bell = true

But what if we were using ToString() to render Cow with some HTML tags? Then we'd need to add a DebuggerDisplay attribute, and end up with this:

using System.Diagnostics;

[DebuggerDisplay("Name = {Name}, Has a bell = {HasBell}")]
public class Cow
{
public string Name { get; set; }
public bool HasBell { get; set; }

public override ToString() {
return String.Format("Cow's name is {0}, and she {1} a bell.", this.Name, this.HasBell ? "has", "does not have");
}
}

Notice that the DebuggerDisplay constructor argument has the property names wrapped in a pair of curly brackets {}. These must match the properties that you've declared in your class.

In the debugger we'll get a line of text looking something like this:

Name = "Bessie", Has a bell = true

But what if we wanted to show the output HTML in this line too? We need to call ToString() from within our DebuggerDisplay constructor, and the class will look like this:

[DebuggerDisplay("Name = {Name}, Has a bell = {HasBell}, Output HTML = {this.ToString()}")]
public class Cow
{
public string Name { get; set; }
public bool HasBell { get; set; }

public override ToString() {
return String.Format("Cow's name is {0}, and she {1} a bell.", this.Name, this.HasBell ? "has", "does not have");
}
}

The debugger will now show this:

Name = "Bessie", Has a bell = true, Output HTML = "Cow's name is Bessie, and she has a bell."

Neat!

Read up more about DebuggerDisplay on MSDN:
http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggerdisplayattribute.aspx

For loops: caching the length of an array causes performance degradation

I picked this up on a video on the Rich Type System by Brad Adams.

This:

int length = a.length;
for(i = 0; i < length; i++){
a[i] = 0;
}

Is slower than this:

for(i = 0; i < a.length; i++){
a[i] = 0;
}

Because the JIT compiler will recognise a repetitive bounds check, and will also realise that the bounds of the array are fixed for the full duration of the loop. The CLR does bound checking, and so the JIT will remove a.Length and replace it with the actual integer value.

However, if the JIT cannot guarantee that the value won't change during the loop then it will not change the value for a constant and the array bounds check will be performed on every iteration.

Links that explain REST services

Here are some good links on REST that I came across recently:

Top 10 REST API Mistakes
http://www.prescod.net/rest/mistakes/

How to create a REST protocol
http://www.xml.com/pub/a/2004/12/01/restful-web.html