Enterprise security policy

I received an email reminder from the client recently.

"Please don't plug external/personal laptops into the corporate network, this is against the enterprise security policy".

This blog is not a criticism of this security policy.  In fact, I tend to agree with the gist of this security policy.  It is always better to tell your less-computer-savvy users to avoid plugging in potential trouble into the network.

However, this does reminds me of a few things I wanted to rant about:

1. What about things like: External Hard Drives, USB sticks (and by extension, iPods or digital cameras)? 

They can transfer viruses too.  There was a news just this January where the USB digital picture frames many people got for $50 from Best Buy for their grand dad for Chrismas, and it was infecting their PCs.

http://www.news.com/8301-10789_3-9843574-57.html

Personally I think the network must be smart enough to detect virus troubles and drops the device from the network automatically, in a corporate environment, this goes for both "internal" as well as "external" machines.

Enterprise Security Policy by limiting who can or can't plug into the network is extremely naive, and possibly only give a false sense of security.  I sincerely hope there's a second line of defense on the network beyond just this policy.

2. Licences on development machines

For many years, I do work on a laptop with all the tools already installed, licensed and configured correctly.  So when I showed up at a new client/project I'm ready to go on day one.  Trouble is, many clients have a similar requirement in not allowing external machines to be used on the network - usually that's a set back for development time with lots of "develop on laptop", "copy over on USB stick", "test on client network"...  rinse and repeat.  This is a workable solution, but it is time consuming and still requires a basic setup on the client's development computer (at least VS.NET)

I thought there are a lot of parallels between a consultant vs say a plumber.

Plumbers shows up at the project with their own hammer.  The client doesn't have to buy a hammer for the plumber.

If a consultant shows up at the project with their own laptops.  The client shouldn't have to buy a new laptop (or the tools on it) for the consultant. 

What happens though, when the client won't let the plumber use the plumber's own hammers on his sink?  How can the plumber do his work?

Oh by the way we're still waiting for a few more licences for Resharper.

Ad-hoc data structuring with anonymous types

I've been experimenting with the anonymous types we have in C# 3.0, here's my latest creation:

var actions = new[]
{
new { Name = ActionSave, Type = KnownActionType.Save },
new { Name = ActionCopy, Type = KnownActionType.Copy },
new { Name = ActionNew, Type = KnownActionType.New },
    // snipped another 10 actions...
};
foreach (var action in actions)
{
Actions.Add(new Action(action.Name, action.Type));
}

C# happily compiled this for me, to my surprise.  And it works just as I expected it to.

Even intellisense picked it up properly.  See, strongly typed goodness.

The most amazing part I wasn't expecting is the C# compiler knowing that all the array items are the same anonymous type.  So it must have worked that bit out somewhere.

---

Prior to the amazing var variable, you would to do this with nasty looking nested object[] setup.  Like so:

(warning, untested code)

object actions = new object[]
{
new object[] { ActionSave, KnownActionType.Save },
new object[] { ActionCopy, KnownActionType.Copy },
new object[] { ActionNew, KnownActionType.New },
// snipped another 10 actions...
};
foreach (object action in actions)
{
// reall awful looking line next
    Actions.Add(new Action((string)action[0], (KnownActionType)action[1]));
}

There are heaps of things wrong with this old way:

• No type safety - do your own casting


• No array-size safety - index 0 or 1 may not exist


• Boxing with KnownActionType

Yes.  I think I'm going to do nested anonymous types next.

jliu

IE, appendChild, setAttribute, CSS Class

I want to add a star to the end of a label for mandatory fields in the DOM.

.mandatoryIndicator { font-color: red; }

var star = document.createElement("span");
star.setAttribute("class","mandatoryIndicator");
star.innerHTML = " *";
label.appendChild( star );

The above code doesn't work in IE, the star is added, but it remains the default text colour.

I did a bit of hunting around and found out the problem is actually with setAttribute.  It doesn't work with half a dozen properties on the element.

The fix is actually quite easy, use this:

var star = document.createElement("span");
star.className = "mandatoryIndicator";
star.innerHTML = " *";
label.appendChild( star );

Anonymous Type of an existing type

I find the .NET anonymous type a bit weak in terms of a few more features:

1. Can't inherit/implement an existing type
   var x = new : IMyInterface {
      Number = 1,
      Name = "Hi",
   };
   
2. Can't add methods
   var x = new {
      Number = 1,
      Name = "Hi",
      Action = delegate(object o){ return true; },
   }

I guess anonymous types are purely for quick throw-away data constructs.  I might just as well write a class directly with all the stuff I wanted.

Embedded WebResource

The job of a framework library is to provide a basic package of necessary services and components.

In ASP.NET, being a web application, the UI portion of the framework has to provide not only server side code, but also CSS, JavaScript and image files.

ASP.NET 2.0 made it easy with the WebResourceAttribute.  And I was hunting for a bug today:

Page.ClientScript.RegisterClientScriptResource(GetType(),
"My.Framework.Web.UI.Pages.Collapse.js");

We have this bit of code on the masterpage in the framework, as soon as we use this in applications it stops working.

We get a 404, "invalid webresource request".

The issue actually was quite easy to fix once we what the Type argument was for.  It's for ASP.NET to work out which assembly to look for the resource.

Page.ClientScript.RegisterClientScriptResource(typeof(ATypeInTheFrameworkAssembly), "My.Framework.Web.UI.Pages.Collapse.js");

Which fixed the problem.