I’m pleased to announce that I’ve released my first open source project!
The Selenium Toolkit for .NET contains a bundled installer for Selenium libraries (Selenium-RC, Selenium IDE and Selenium client library for .NET) and an NUnit Addin that makes getting started with Selenium easy.
More information can be found here: http://seleniumtoolkit.codeplex.com/
It's been a few months since I wrote my article Creating a better wrapper using AOP, and I haven't thought much of it, but a recent comment left by Krzysztof has motivated me to re-open the project. Krzysztof has an interesting optimization that I want to try, and perhaps I will delve into that in another post, but today I want to expand on my intentions of improving both performance and memory management as mentioned in the caveats of my article. In truth, most of this article is inspired by the work of Jeffrey Richter's C# via CLR and Vance Morrison's blog, and I've been itching to test out the concept of using runtime type handles for a while.
Most developers are led to believe that Reflection is a performance hit, but few understand why. Here's my attempt to explain it in a nutshell. I’m neither a Microsoft employee nor expert in this matter, I’m simply paraphrasing and I encourage you to pick up Jeff’s book. If I’m paraphrasing incorrectly, please let me know.
When your code is executed for the first time, the CLR finds all references to Types in the MSIL in order to JIT compile them. As part of this process, Assemblies are loaded and Type information is read from the meta-data and put into the AppDomain’s heap using internal structures – mainly pointers and method tables. The first time a Type’s method is called, it is JIT compiled into native instructions and a pointer refers to these compiled bits. Nice, light and fast.
Reflection however is different. By calling the Type’s built-in GetType method, we are forcing the runtime to read the meta-data and potentially construct dozens of managed objects (MethodInfo, FieldInfo, PropertyInfo, etc) and collectively these can be somewhat large data structures. Often as most reflection methods use strings to identify methods, we’re performing a case-insensitive scan of the meta-data. When we call those methods our parameters have to be pushed onto the stack as an array of objects. When compared to compiled native code with pointers, you can see why this is slower. (Roughly 200x slower)
Clearly, the .NET runtime doesn’t need these large data-structures to execute our code. Instead we can leverage the same pointers that the CLR uses through their managed equivalents: RuntimeTypeHandle, RuntimeMethodHandle and RuntimeFieldHandle. At their most basic level, they are the pointers (IntPtr objects) to our Types, without all the additional reflection performance overhead. Since an IntPtr is basically just a numerical value (a ValueType nonetheless), they use considerably less memory.
An interesting point: an example from Vance’s blog demonstrates that typeof(Foo) is considerably slower than typeof(Foo).TypeHandle because the JIT recognizes you need the pointer and not the Type.
Even more surprising, anObj.GetType() == typeof(string) is faster than (anObj is string) for the exact same JIT optimization. Amazing.
If your application holds onto Type data for extended periods, it may be worth your while to use handles. Here’s a few examples of using them.
[Test] public void CanGetHandleFromType() { RuntimeTypeHandle handle = typeof(string).TypeHandle; Type type = Type.GetTypeFromHandle(handle); Assert.AreEqual("A String".GetType(), type); }
[Test] public void CanGetHandleFromMethod() { MethodInfo m1 = typeof(Foo).GetMethod("Do"); RuntimeMethodHandle handle = m1.MethodHandle; MethodInfo m2 = MethodBase.GetMethodFromHandle(handle) as MethodInfo; Assert.IsNotNull(m2); Assert.AreEqual(m1, m2); }
Getting back to my AOP example, I can now create a really simple mapping table for my AOP wrapper that’s lean(er) on memory and will cut down on needless calls to the Reflection API, thus speeding things up considerably. Note that I’m doing all the Reflection work upfront and then storing only pointers.
Update: After some initial profiling, I wasn’t surprised to discover that loading the MethodInfo by the handle is as expensive as the original GetMethod call. As such, I’ve opted to store my mapping table as Dictionary<RuntimeMethodInfo,MethodInfo> instead of Dictionary<RuntimeMethodInfo,RuntimeMethodInfo>.
public class InvocationMapping { public InvocationMapping(object instance) { _table = new Dictionary<RuntimeMethodHandle, MethodInfo>(); _instance = instance; } public static InvocationMapping CreateMapping<TWrapper>(object target) { InvocationMapping mapping = new InvocationMapping(target); Type wrapperType = typeof(TWrapper); var wrapperProperties = wrapperType.GetProperties(); Type targetType = target.GetType(); foreach (var property in wrapperProperties) { MappedFieldAttribute attribute = property.GetCustomAttributes(typeof(MappedFieldAttribute),true) .OfType<MappedFieldAttribute>() .SingleOrDefault(mf => mf.TargetType == targetType); if (attribute != null) { PropertyInfo targetProperty = targetType.GetProperty(attribute.FieldName); mapping.Add(property, targetProperty); } } return mapping; } public Dictionary<RuntimeMethodHandle, MethodInfo> MappingTable { get { return _table; } } public void Add(PropertyInfo property, PropertyInfo targetProperty) { if (property.CanRead && targetProperty.CanRead) { _table.Add(property.GetGetMethod().MethodHandle, targetProperty.GetGetMethod()); } if (property.CanWrite && targetProperty.CanWrite) { _table.Add(property.GetSetMethod().MethodHandle, targetProperty.GetSetMethod()); } } public bool Supports(RuntimeMethodInfo handle) { return _table.ContainsKey(handle); } public object Invoke(RuntimeMethodInfo handle, params object[] args) { MethodInfo method = _table[handle]; return method.Invoke(_instance, args); } private Dictionary<RuntimeMethodHandle, MethodInfo> _table; private object _instance; }
My next post will look at combining this approach with a IProxyBuilderHook and/or ISelectorType.
Our team was working late the other night and got tripped up on how "Any CPU" works with 64-bit operating systems. I had developed a simple command-line utility that used some third-party assemblies that were installed in the GAC. Everything worked great on my local machine until I deployed it into the build environment, where the app simply blew up and reported an awkward "FileNotFoundException".
At a quick glance, it seemed obvious: the 3rd party assemblies weren't in the GAC. My head snapped back a bit when C:\Windows\Assembly showed that the exact versions I needed were in fact installed. I double checked my project references and painfully grudged through security policies, FusionLog files and web.config settings and with each attempt I became increasingly aggravated and annoyed. When I copied the 3rd party assemblies out of the GAC and into my utility's folder and got a BadFormatException, I realized that the only difference between my machine and the build environment was the 64bit operating system.
On a hunch, I recompiled my utility to target "x86" and suddenly everything worked. The team was baffled -- why didn't "Any CPU" work?
The .NET Framework inspects the meta data of your dll or exe to determine how to load it. By default, "Any CPU" creates a native process to that OS. In other words, 32 bit process for 32bit OS and 64 bit process for 64bit OS. When a 32bit application (x86) runs on a 64bit OS, it runs as a WoW64 emulated 32bit process (Windows on Windows).
The following table outlines how the Visual Studio Build Configuration is interpreted between 32bit and 64bit OS.
| Any CPU | x86 | x64 | |
| 32 bit OS | Native (32 bit) | 32 bit process | N/A |
| 64 bit OS | Native (64 bit) | WoW64 process (emulated 32 bit) | 64 bit process |
The real gotcha is that your referenced assemblies must match the process space of the application they're being loaded into. Any assembly that is compiled as "Any CPU" is considered "neutral" and can be loaded into either a 32bit or 64bit process.
There are a few ways to determine if your assembly is Any CPU, 32bit or 64bit:
Global Assembly Cache
If your assembly is in the GAC, you can find this information in the Processor Architecture column.
Corflags
The corflags.exe tool that ships with the .NET SDK is a very powerful and dangerous tool. Just supplying the name of your exe or assembly to corflags shows some vital PE meta information. More great information can be found here: http://blogs.msdn.com/joshwil/archive/2005/05/06/415191.aspx
Incidentally, instead of recompiling the application with the “x86” target, I could simply have hacked the header using corflags:
corflags myapp.exe /32bit+
However, hacking the header of the assembly using corflags will invalidate the digital signature. Although you can always re-sign the assembly using the strong-name (sn) utility, it’s easier to just recompile and deploy.
Cheers.
The other day while working on a SharePoint project, we needed a simple utility to show us the current build and version numbers of deployed assemblies. Rather than going through the hassle of creating a custom web-part or compiled assembly, I decide to opt for a simple ASPX page with inline code.
The approach worked well. I had IntelliSense and I wasn’t limited to any language features until I added a few simple Linq statements. I then ran into this fun error:
error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)
at System.Web.Compilation.AssemblyBuilder.Compile()
Despite the fact that .NET 3.5 was installed and other compiled assemblies worked fine on this machine, the ASP.NET process was having problems compiling the Linq features on its own. It just needed some additional guidance on where to locate those assemblies…
First, the compiler needs a hint on how to resolve the Linq assembly, located in System.Core:
<compilation batch="false" debug="true"> <assemblies> <!-- add –> <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" /> </assemblies> </compilation>
Then, the module that compiles our code needs a hint to build using 3.5:
<system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"> <providerOption name="CompilerVersion" value="v3.5" /> <providerOption name="WarnAsError" value="false" /> </compiler> </compilers> </system.codedom>
It's an abuse of Moore's Law: as computers get faster, software will get slower. And while there are many reasons why software feeds on additional resources, whether it's providing a more intuitive user interface, coding for security or simple feature bloat – it’s largely the fault of software developer's assumption that disk, memory and CPU will continue to increase in capacity and power while the cost decreases.
With the advent of multi-core processors, it's evident that software cannot afford to assume that execution will occur on a single thread. We need to embrace multi-threaded techniques to allow our software to scale with the platform. Developing for multi-threaded applications requires special consideration.
I want to share a simple code snippet that I've frequently used to block individual threads from executing the same code twice. It's especially handy in dealing with process intensive or time-sensitive requests where race-conditions can occur. For example, a recent project needed to dynamically generate an image and cache as a file – if requests were allowed to overwrite the file as it was being served by another thread, the results would be disastrous.
The concept uses the "double-checked locking" pattern, which is commonly used for synchronized lazy-initialization, such as creating singletons. Unlike the singleton pattern, this example assumes there are multiple requests for different objects, so the technique is modified slightly.
For those that aren't familiar with the "double-checked locking" pattern, I'll outline here using a Singleton example. In short, double-checked locking is "Check twice before doing any work, with a lock in the middle."
Note: Some may claim that the thread-safety of the double-checked lock pattern simply cannot be guaranteed. This is true for environments where the processor or application runtime model can vary (Java, C++, etc). However the CLR does guarantee thread synchronization.
This example outlines the double-checked lock being used to guarantee that only one singleton is created:
public class MySingleton { private static volatile MySingleton _instance; private static readonly _lock = new object();
public static MySingleton Instance { get { // 1: first check if (_instance == null) { // 2: lock a common object // all other threads must wait until the lock is released lock(_lock) { // 3: second check if (_instance == null) { // 4: thread-sensitive work _instance = new MySingleton(); } } // 5: release the lock } return _instance; } } // other methods }
If you've never seen this type of pattern before, it may at first seem awkward (“why are you checking for null so much?”). Here's a quick run down of how this plays out in a multi-threaded environment:
As mentioned previously, the pattern above ensures that only a single instance of our object is created. However, this technique doesn't work well for methods that vary their response based on input because we're locking a single object to create sensitive regions. By locking only a single object, we create a nasty side-effect that synchronizes all requests to a single thread.
To solve this problem, we need to put our lock on a different object so that we are only blocking similar requests. We need a key that is synchronized for requests with the same input.
This is where the “SyncKey” comes in:
public sealed class SyncKey : IDisposable { private static Dictionary<string,SyncKey> _inner = new Dictionary<string,SyncKey>(); public static SyncKey Get(string key) { // lock the table to ensure that only one thread can access // the dictionary at a time lock(_inner) { // if this is the first request for this key, it will not be present // in the dictionary. create and store it. if (!_inner.ContainsKey(key)) { SyncKey item = new SyncKey(key); _inner.Add(key, item); } // return the synchronized key return _inner[key]; } } private static void Remove(SyncKey item) { // lock the table to ensure that only one thread can access // the dictionary at a time lock(_inner) { // for the request that first instantiated the key, // the sensitive work is complete and the key can be safely // removed from the dictionary // for subsequent requests, although the key was used to prevent // a duplicate request, it no longer exists in the table // and can be safely ignored. if (_inner.ContainsKey(item.Key)) { _inner.Remove(item.Key); } } } private string _key; SyncKey(string key) { _key = key; } public string Key { get { return _key; } } public void Dispose() { Remove(this); } }
An example using this strategy:
public class MyObject { public string SensitiveMethod(string inputParameter) { string key = GetKey(inputParameter); // 1: first check string result = GetItemFromCache(key); if (result == null) { // create a sync key for this request using(SyncKey sync = SyncKey.Get(key)) { // 2: lock request-specific object lock(sync.Key) { // 3: second check result = GetItemFromCache(key); if (result == null) { // 4: thread sensitive work result = BuildResult(key); CacheResult(key,result); } } // 5: release lock } // dispose sync key } return result; } }
I built a small contrived example that pushes 1000 threads through a fixed set of input using the following three strategies:
Some notes on the findings:
When I read Rob Conery's post about I suppose I'll just say it: You should learn ASP.NET MVC, it resonated strongly with me: the bloated abstraction of WebForms has placated developers into thinking they don't need to know HTML to build web applications. We've spent the better half of this decade blissfully ignorant using server-side technology to "shoehorn" client-side concepts, and we (the asp.net developer) have been negligent on staying on top of the revolution that has been quietly happening client-side.
Thankfully, Microsoft's recent formal inclusion of jQuery for the ASP.NET MVC project has got developers discovering how powerful jQuery and client-side development can be, and that excitement is changing the way developers think about developing for the web. I believe there's a new renaissance coming, one that isn't based on the bloated server-centric model of WebForms, but rather a new breed of sites with lean, semantic markup and rich client-side interactivity using JavaScript fuelled AJAX. Or at least, one can hope.
With all the attention client-side scripting is getting, there's never been a better time to learn CSS. (If you're going to develop for the web, why not go all in?) Until recently, I never did much user-interface development, but after a few short UI-centric projects I'm personally climbing onto the soapbox to challenge backend developers to drop their "I don't do pretty" attitude and learn this important skill.
So if you’ve secretly wanted to learn CSS but didn’t have a good reference point, this is my attempt at providing a crash course:
If you’re generally familiar with the basic concepts behind CSS, you can skip ahead, but no harm will come to you read it.
As developers, we love to think of the browser’s Document Object Model (DOM) as an object graph with pretty collections of childNodes and attributes that we can programmatically manipulate using imperative code instructions. While this concept translates really well into technologies like XPath, it doesn’t fit CSS selectors so literally. The syntax (is exactly the same syntax jQuery uses) is actually very straight-forward, and focuses primarily on all nodes of a specific criteria rather than targeting specific child nodes.
Styles can be applied to all elements of a particular Type (or TagName):
/* single type (all h1 tags) */
h1 {
color: blue;
}
/* multiple types (all h1, h2, and h3 tags) */
h1, h2, h3 {
color: blue;
}
The hash/pound/number symbol (#) is used as a selector to elements with a specific “id” attribute. Note: This approach should only be applied to controls without the “runat=server” attribute since ASP.NET server-controls dynamically generate their IDs.
<style> #title { color: blue; } </style> <h1 id="title">Foo Heading</h1>
Obviously, the more appropriate technique would be to assign the element a “class”, which in ASP.NET translates to our CssClass for most WebControls (otherwise you have to access this value through the Attribute collection under the appropriately named “class” key). Note that the “class” is not tied to a specific type, and can be reused on other elements:
<style> .title { color: blue; } </style> <h1 class="title">Blue Heading</h1> <p class="title">Blue paragraph</p>
You can also get specific and limit the scope of a selector to a particular tag, by prefacing the selector with the tag name. Note there is no space between the tag and class:
<style> h1.title { color: blue; } p#description { color: green; } </style> <h1 class="title">Blue Heading</h1> <p id="description">Green Paragraph</p>
You can also refer to child elements, which affords us the ability to provide additional formatting without having to modify our markup.
<style> // all li elements under a ul with a "menu" class ul.menu li { list-style-type: none; display: inline; } </style> <ul class="menu"> <li>inline 1</li> <li>inline 2</li> <li>inline 3</li> </ul>
Another important (and not well known) thing to point out is that you can have multiple class names for a single element, which can reduce duplication:
<style>
a.navLink {
text-decoration: underline;
color: red;
}
.selected {
font-weight: bold;
}
</style>
<ul>
<li><a class="navLink" href="#">one</a></li>
<li><a class="navLink selected" href="#">two</a></li>
<li><a class="navLink href="#">three</a></li>
</ul>
There are a few more selectors I haven’t covered here, but you can more details and tutorials here:
From a pure developer perspective, inheritance in CSS is similar to inheriting classes:
However, CSS inheritance deviates from this analogy as properties are merged in combination from multiple sources (wildcard, class, id and type selectors), somewhat like multiple inheritance:
While this sounds complicated and difficult to troubleshoot, tools like FireBug and Internet Explorer Developer Toolbar have made this a trivial task. My deepest respect goes to the user-interface developers who painfully slugged this stuff out manually only a few years ago.
A simple inheritance example:
<style> body { background: #fefef2; /* eggshell */ } h1 { text-decoration: underline; background: #ffffff; /* white */ } .title { color: #0000ff; /* blue */ } </style> <!-- titleeffective style applied after inheritance: { text-decoration: underline; /* from h1 */ background: #ffffff; /* from h1 */ color: #0000ff; /* from .title */ } --> <h1 class="title">Underlined blue title with white background</h1>
Note that the only way to prevent inheriting settings from a parent node is to explicitly supply a value for the property.
<style> body { background: #fefef2; } h1 { text-decoration: underline; background: #ffffff; } .title { text-decoration: none; background: #fef2f2; color: #0000ff; } </style> <!-- effective style applied after inheritance: { text-decoration: none; /* back to the default */ background: #fef2f2; /* back to the default */ color: #0000ff; /* new value */ } --> <h1 class="title">Blue title with eggshell color</h1>
Much like setting the content-type of a Response in ASP.NET so that the browser will understand what the content is, the DocType is a crude processing instruction at the top of the document that instructs the browser how they should process the markup. Without this instruction, most browsers will assume the content is ancient and they will use the oldest rendering engine available.
As to which doctype you should use, it largely depends on the markup you have, but you should strive for the most compliant possible.
A List Apart has one of the best references on this topic.
The Box Model is another core concept of CSS. All elements are contained in their own box and have margins, borders and padding.
Commit to memory: Margin, Border, Padding, Content.
Commit to memory: Top, Right, Bottom, Left
When specifying values for padding, margins or border widths CSS provides two approaches. Either declare each value separately (border-top: 0px; border-right: 0px; border-bottom: 0px; border-left: 0px) or inline as one statement in clockwise order starting at top (border: 0px 0px 0px 0px;). This comes up frequently, so memorize now and thank me later.
Also note that there’s a shortcut for the shorthand, where top & bottom and left & right are the same values (border: 0px 0px;).
Fonts can be tricky, and I tend to lean on the graphic designer to pick the typography for the site. From a development perspective, although you can choose any font it must be available on the user’s machine, and only a few fonts are truly available across operating systems. A great reference of browser surveys can be found here: http://www.codestyle.org/css/font-family/index.shtml
From a CSS perspective, you can supply a number of different fonts in comma-delimited format, and the browser will apply the first match from left to right. Outside of actual Fonts, there are five generic fonts which all browsers implement.
Keep in mind that there is much debate on whether you should specify fonts in “em”, “pt”, “px” or “%” for font-sizes. I won’t settle that debate here.
Congrats on reading thus far, if you skipped ahead, no cookie for you.
While pseudo selectors are bordering on advanced topics, a crash course in CSS would be incomplete without mention of some pretty important CSS selectors: a:link, a:visited, a:active, a:hover. These are special selectors that can be applied to anchor tags for their various states. The first two (“:link” and “:visited”) allow you to specify the style of the anchor tag based on the user’s history; the latter refer to user actions with the hyperlinks. The “:active” selector is applied the user is clicking on the hyperlink; the “:hover” selector is applied when the user moves the mouse over the anchor.
Astute developers pick up that “:hover” allows you to define styles that would normally be applied using “onmouseover” and “onmouseout” events using JavaScript. One of my favorite applications of the “:hover” tag is to change the background image of an element when the user hovers over it. With some extra effort, you can change the relative position of the background image to achieve a “sprite” effect.
Some trivia: there is no equivalent of these selectors as an inline style attribute, they can only be defined in a style block or style sheet. Also, the “:hover” tag can be applied to other tags, but only anchor tags are supported in IE 6.
CSS provides the ability to set the background property of an element to point to an image, which is major shift from standard HTML. By moving our images from the markup into the CSS, we not only reduce the amount of markup required, but we separate presentation from content. This technique is essential for creating impressive effects, such as drop shadows and nifty borders.
The syntax:
/*
element {
background: color url(path) repeat attachment position
} */
div {
background: transparent url(../images/bg.png) repeat-y fixed 0 0
}
By specifying the repeat value of an image, your image only needs to be a few pixels in size. In addition, you can specify an offset in pixels to have the image indented.
Few key takeaways:
The div tag is one of the most popular tags in XHTML/CSS as it's used to create logical sections for your layout. While divs are preferred over tables, using divs exclusively to represent content isn't necessarily a good thing. If you've fallen into this trap or have trouble knowing when you should use a div versus a span, I'm going to break you out of a bad habit by demystifying what the div tag is by looking at the how it's described by most browser's default style sheet:
div {
display: block;
}
That's it! So maybe it would help us to understand what "display" does?
There are a bunch of settings for "display", but the short list is: "none", "block", and "inline". Setting display to "none" basically means that the content won't take up any layout space and is thus invisible. Elements with display set to "block" are considered a chunk of content that has a line break before and after, whereas "inline" means it's part of the content. It's best described by looking at the default's for some tags:
| Tag | Display Default |
| body | block |
| h1,h2,h3,h4 | block |
| p | block |
| div | block |
| ul, li | block |
| bold, strong | inline |
| italic, em | inline |
| a | inline |
| span | inline |
A great breakdown of “display” and how it’s used, including support for all modern browsers, is available here.
If what you really need is a container for some content, P and UL are great substitutes. You’ll be surprised at how quickly your content begins to look less like div-soup and more like xml.
<!-- before --> <div id="contacts"> <div class="person"> <div class="details"> <b>Person Name</b><br/> <i>555-1234</i> </div> </div> </div> <!-- after --> <ul id="contacts"> <li class="person"> <h3>Person Name</h3> <ul class="details"> <li class="phone">555-1234</li> </ul> </li> </ul>
Working with CSS can get tricky, especially managing the complexity of your style sheets to support multiple browsers. One of the best approaches to minimize this complexity is to override the default settings for all elements to a minimalist state, and then slowly build up your styles to suit your needs. This approach reduces duplication and helps ensure that your settings aren't inconsistent between browsers.
Here's a quick example that removes the padding and margin for all elements, and turns off the legacy blue-border around the image tag:
// remove all margins and padding from all elements * { margin: 0; padding: 0; } // remove legacy border around images img { border: none; }
Here are a few great starting points for a clean slate:
Using "floating" to position elements can be tricky, and there are certainly a few tricks to make it work for all browsers (I'm looking at you Internet Explorer 6), but mastering it means you'll never need to use tables to layout your content again. Or at least, only use tables when representing data.
At a very high level, when an element has a float applied to it, it is no longer part of the normal flow of the document. An element with a “float:left;” will float to the left until it meets the left edge of it’s containing block; likewise a “float:right;” implies the element will nestle up to the right of it’s container. Floating can be turned off by setting a “float:none;” to the next element.
The secret to getting floating to work is ensuring that the element being floated has a width explicitly defined. Likewise, setting a width to the parent element that contains the floating element solves many problems.
Still, as developers, we know from experience that this is a major cross-browser problem and it’s likely the principle reason why we leave CSS to the experts. Truth is, every browser except Internet Explorer got the Box Model right, and the fix is shockingly simple: floating problems in Internet Explorer 6 are generally solved by ensuring that the floated element (in IE’s terms) “has a layout specified”. In most cases, specifying “display:inline;” works:
.container
{
float: left;
display: inline;
}
A great reference on float theory can be found here: http://www.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/
A close relative to floating is the concept of “absolute and relative positioning”. Personally, I’ve always felt that absolute position was a last resort when compared to using floats, but in concept may be easier to understand.
Since “static” is the default behavior for content, the real work is understanding that “absolute” and “relative” provide meaning to the css properties “top”, “left”, “right” and “bottom”.
When an element uses “absolute” for it’s positioning, the “top” and “left” properties can be used to position the element anywhere in the document, where (0,0) represents the top, left-hand corner of the document.
When an element uses “relative” positioning, the “top” and “left” properties indicate where the element appears in relation to the element that came before it.
And here’s the magic: if an element inside a “relative” positioned element specifies an “absolute” position, the “top” and “left” properties can be used to position the element anywhere within the containing element where (0,0) represents the top, left-hand corner of the relatively positioned element.
A great tutorial on positioning can be found here: http://www.barelyfitz.com/screencast/html-training/css/positioning/
While the Internet Explorer 8 Developer Toolbar is considerably better than previous versions, FireBug, the popular addin for FireFox, is still the king. Aside from being able to hack the CSS values in real time, one of the most useful features that FireBug provides is that it can highlight the contents of an element as you move your mouse over them. The highlighted area, which uses different colours to represent padding versus margins, shows how the browser has reserved space for the visual element. I've discovered there are times where FireFox renders the content correctly, but the overlaid highlight for margins and padding doesn't exactly match the visual appearance. From my own experience, I've discovered that these discrepancies are often more apparent in other browsers. If you can get FireBug's visual overlay to match the desired visual, you're less likely to have issues in other browsers.
The following example shows how FireBug highlights a paragraph with a width greater than it’s parent.
<style> div { float: left; width: 300px; } p { width: 350px; /* bigger than parent! */ } </style>
Lastly, while not a CSS tip, it would be an injustice to think that you as the developer are not capable of cutting and resizing images. Let the graphic designer be responsible for producing the content, but as a developer you need to learn be independent and cut up the image yourself if needed.
Paint.NET is awesome, and when compared to Photoshop or GIMP, it's as easy to use as ms paint. There are lots of tutorials online that hold your hand from start to finish on creating some impressive graphics.
Thanks for reading. If you’re a backend developer who’s never spent any time in the user-interface, I hope this has help shine a light for you, please send me some feedback. If you’re a front-end developer and I’m completely off my rocker, feedback is also appreciated.
Cheers.
Recently, I was working on a system that had to use several third-party data sources with different object models. Since changing their code was out of the question, the obvious workaround was to wrap the third-party objects into a common interface in my codebase. The resulting code was dead simple, but the monotonous repetition of creating property accessors for several dozen fields left me with a sinking feeling that there ought to be a better way.
public class PersonWrapper : IPerson // REPEAT for each 3rd party object... { public PersonWrapper(CompanyA.Person person) { _person = person; } public string EmailAddress { get { return _person.Email; } set { _person.Email = value; } } // REPEAT for each Property we want to expose... CompanyA.Person _person; }
The better way snuck into my head when a colleague found an interface in the third-party library that was similar to our needs. We only needed a small handful of properties of their interface, so he asked, "Can we inherit only half of an interface, somehow?" This odd question with a seemingly obvious answer (there isn't a CLR keyword to break interface definitions) pushed me to think about the problem differently. We can't choose what parts of an interface we want to inherit, but we can choose a different interface and inherit from it dynamically. Not a trivial task but certainly possible as many frameworks have been dynamically generating classes from interfaces for years. This technique only solved half of the problem, so I discarded the notion.
Later that night, the solution to the other half seemed obvious: decorate the interface with attributes that describe the relationship to the the third-party types, and use an aspect oriented concept known as call-interception to forward calls on the interface to the mapped fields of the third-party type. If it sounds complicated, it is -- but fortunately, the tools make it easy to do, and I'll try my best to walk you through it.
For starters, it helps to understand that typically AOP is used to augment the behavior of existing classes by creating a special proxy around objects at runtime. For the existing code that will use those augmented types, the proxy is identical to the original -- the key difference is that each call to your object passes through a special middleman (known as an interceptor) that can perform additional operations before and after each call. The most commonly used example is logging the parameters that were passed in or the time that the method took to execute. This diagram attempts to describe what's happening:
However, a dynamic proxy for an interface is different because there's no existing class, so our interceptor is responsible for doing all the work:
So rather than creating a concrete wrapper for each vendor's type, we annotate our interface with the mapping information. The advantage is that we can manage our interface definition and mappings in a single place, making it easy to extend to new fields and other vendors without incurring class explosion.
public interface IPerson { [MappedField("First", typeof(CompanyA.Person))] [MappedField("FName", typeof(CompanyB.Contact))] string FirstName { get; set; } [MappedField("Last", typeof(CompanyA.Person))] [MappedField("LName", typeof(CompanyB.Contact))] string LastName { get; set; } } [AttributeUsage(AttributeTargets.Property, AllowMultiple=true, Inherited=true)] public sealed class MappedFieldAttribute : Attribute { public MappedFieldAttribute(string fieldName, Type targetType) { FieldName = fieldName; TargetType = targetType; } public string FieldName { get; private set; } public Type TargetType { get; private set; } }
Now that our interface contains the information to map to properties in our third-party class, we need to dynamically generate a derived class that implements this interface. I'm using Castle projects' DynamicProxy, though there are several other ways to do this. We'll configure the derived class (Proxy) with a custom interceptor that will read information about the method being called, and using some Reflection goodness, it will redirect the incoming call to the third-party object.
DynamicProxy's interceptor interface is simple. The IInvocation object contains all the information about the incoming call:
public interface IInterceptor { void Intercept(IInvocation invocation); }
If we were creating a proxy for a concrete Type, we'd likely want to pass the call from the proxy onto the target object using the invocation.Proceed() method, but because we're using an interface with no target implementation, we'll have to write the implementation within the Interceptor. We can implement anything we want though the only constraint is that we must set the invocation.ReturnValue if the method has a return value.
The details of the method being called are represented in the invocation.Method. When the call is for a property, the Method is the actual accessor method, ie get_<PropertyName> and set_<PropertyName>. This represents a bit of a gotcha because our attribute definition isn't on the accessor Method, it's on the PropertyInfo, so we have a bit of work to get our custom attributes.
The FieldMapperInterceptor implementation looks like this:
public class FieldMapperInterceptor : IInterceptor { public FieldMapperInterceptor(object target) { _targetObject = target; _targetType = target.GetType(); } public void Intercept(IInvocation invocation) { if (!InterceptProperty(invocation)) { throw new NotSupportedException("This method/property is not mapped."); } } protected bool InterceptProperty(IInvocation invocation) { MethodInfo method = invocation.Method; string methodName = method.Name; if (!IsPropertyAccessor(method)) return false; string propertyName = methodName.Substring(4); bool writeOperation = methodName.StartsWith("set_"); // get attribute from the Property (not the get_/set_ method) PropertyInfo property = method.DeclaringType.GetProperty(propertyName); MappedFieldAttribute attribute = property.GetCustomAttributes(typeof(MappedFieldAttribute), true) .OfType<MappedFieldAttribute> .SingleOrDefault(mf => mf.TargetType == _targetType); if (attribute == null) return false; // locate the property on the target object PropertyInfo targetProperty = _targetType.GetProperty(attribute.FieldName); if (targetProperty == null) { throw new NotSupportedException("Field not found on the target Type."); } if (writeOperation) { object propertyValue = invocation.Arguments.Last(); object[] index = invocation.Arguments.Take(invocation.Arguments.Length -1 ).ToArray(); targetProperty.SetValue(_targetObject, propertyValue, index); } else { invocation.ReturnValue = targetProperty.GetValue(_targetObject, invocation.Arguments); } return true; } public bool IsPropertyAccessor(MethodInfo method) { string methodName = method.Name; return (methodName.StartsWith("get_") | methodName.StartsWith("set_")); } private object _targetObject; private Type _targetType; }
The FieldMapperInterceptor will work with any interface using the MappedFieldAttribute and any third-party object, but there are a few caveats:
With this in place, dynamically graphing our custom interface to our third-party types is a snap:
[Test] public void Demo() { ProxyGenerator generator = new ProxyGenerator(); CompanyA.Person actualObject = new CompanyA.Person(); FieldMapperInterceptor interceptor = new FieldMapperInterceptor(actualObject); IPerson person = proxyGenerator.CreateInterfaceWithoutTarget<IPerson>(interceptor); person.FirstName = "Bryan"; Assert.AreEqual(actualObject.FName,person.FirstName); }
Comments welcome.
So I'm sitting on a very long flight (when I wrote this, watching 'Flight of the Conchords'), wishing I had wifi as my current project involves distributed WCF services between virtual PCs. Without network access, I'm dead in the water (probably not the best thing to say while in a plane). After banging it out, here's a quick tip on how to set up networking for your virtual PCs when you don't have any network.
The irony here is this post is really only useful after you connect to the network. Still, this may be good reference material for me at some point later on, if you benefit from it, that's good too.
On the host operating system, install a Loopback adapter.
Configure the VPC to use the Loopback Adapter.
To test it out, on the host OS "ping 10.0.1.11". Voila! Network without Network. Now, where's that drink cart?
I was pretty sure by the end of 2008, I wasn't going to succumb to peer-pressure and write a Top 10 posts of 2008 post, but there may be some value in this retrospective thing. After all, 2008 was a huge year for me, not only did I have my second child, but I also changed jobs and bought a new car. On a much smaller scale, but very relevant here, I also changed the focus of this blog from day-to-day diary to a technical focus: .NET, TDD, Software Development Process, ALT.NET -- it's been an experiment of tinkering and hacking blogger templates and plugins, blog writing software and analytics.
Though it hasn't been a runaway hit, it's been successful in my books: blog posts, traffic and readership are up. There's been a few kicks and some comments, which are not only encouraged but greatly appreciated: thanks.
Since I have only 35 posts for 2008, a top ten list seemed unlikely, so I thought I'd post a handful of the popular ones. I ended up with ten anyway...
Test Driven Development:
Log4Net
Windows Services
The Odd Bucket
I thought I'd round out the top-ten with a few weird posts that were very popular:
Plans for 2009
2009 is shaping up to have a huge focus on testing in new and odd ways. Expect to see lots about parameterized tests, Office automation using White, and hopefully, more Surface and WPF work.
Happy New Year, and may all your tests be green.
My last few projects have leveraged both Selenium-RC and Selenium-Core. Here's a few notes from the field:
FireFox 3 doesn't work with Selenium 1.0.0 beta 1
When working with Selenium RC out of the box, Selenium stalls when trying to launch an instance of FireFox 3. The Selenium-RC application works as a browser extension that is marked to only certain versions of the browser, this patch fixes the meta-data for the firefox plugin.
Instructions on how to fix the issue yourself can be found here, and within the comments there's a downloadable selenium-server.jar with the patch already applied.
Use Selenium-RC Judiciously
When you're working with Selenium Remote Control, every selenese command is sent over the network to the java application (even when working locally), so beware of redundant calls. For example, I wrote several helper methods in my NUnit tests to group common selenese functions together:
public void SetText(string locator, string value) { selenium.Click(locator); selenium.Type(locator,value); }
Since the "Click" event is only needed for a few commands, trimming down the selenese can improve execution speed:
public void SetText(string locator, string value) { SetText(locator, value, false) } public void SetText(string locator, string value, bool clickBeforeType) { if (clickBeforeType) { selenium.Click(locator,value); } selenium.Type(locator,value); }
Avoid XPath when possible
Using XPath as a location strategy for your elements can be dangerous for long term maintenance for your tests as changes to the markup will undoubtedly break your tests. Likewise, certain browsers (cough cough IE) have poor XPath engines and are considerably slower (IE is about 16x slower).
Strangely enough, following accessibility guidelines also makes for better functional UI testing. So instead of XPath locators, consider:
<a id="close" href="#" onclick="javascript:foo();"><img src="close.gif"/></a>
selenium.Click("close");
<img src="close.gif" alt="close window" onclick="javascript:foo();" />
selenium.Click("alt=close window");
<a href="/">Home</a>
selenium.Click("link=Home");
Avoid timing code
When working with AJAX or Postback events, page load speed can vary per machine or request. Rather than putting timing code in your NUnit code (ie Thread.Sleep), take advantage of one of the selenium built-in WaitFor... selenese commands.
To use, you place javascript code in the condition where the last statement is treated as a return value.
// wait 30 seconds until an element is in the DOM selenium.WaitForCondition("var element = document.getElementById('element'); element;", "3000");
This approach allows your code to be as fast as the browser rather than set to a fixed speed.
Use Experimental Browsers
When testing, I found several cases where I hit security limits, such as uploading a file. In those cases, you have to use *chrome for Firefox and *iehta for Internet Explorer. These browser profiles are just like *firefox and *iexplore, except that they run with elevated privileges.
Got a tip? Leave a comment
As a follow up to log4net configuration made easy, a common question people ask is what tool to use for reading log4net output.
Unless you're using an AdoNetAppender, there aren't many popular choices for combing through log4net file output. This really should be as simple as setting fixed width columns or column delimiters into our FileAppender's layout pattern, but unfortunately it isn't that simple: log4net's base appender (AppenderSkeleton) outputs Exceptions over multiple lines making it unsuitable for delimited output.
Here are a few options for producing friendly log4net output that can be easily imported or understood by common tools, such as Excel, LogParser, etc.
log4net is just so darn extensible! Object renderers are one of those great hidden gems in log4net that allow you to log an object and leave the formatting to log4net configuration. Any object reference pushed through log4net (including derived classes) will use the supplied object render to customize the output.
public class ExceptionRenderer : IObjectRenderer { public void RenderObject(RendererMap rendererMap, object obj, TextWriter writer) { Exception ex = obj as Exception; if (ex != null) { // format exception to taste writer.Write(ex.StackTrace); } } }
The object renderer appears in your config thusly:
<log4net> <!-- appenders --> <appender ... /> <root ... /> <renderer renderingClass="MyNamespace.ExceptionRenderer,MyAssembly" renderedClass= "System.Exception" /> </log4net>
This option can be combined with the other approaches defined below, or on it's own.
try { // perform work } catch(Exception ex) { // format using IObjectRenderer log.Warn(ex); }
By logging just the Exception object, the IObjectRenderer will do its formatting. Coincidentally, because the exception is the message it isn't subject to the same delimited friendly problems, though this may not be a suitable solution for you if it means having to rewrite all of your exception blocks.
As previously mentioned, the culprit behind our messy exceptions is the AppenderSkeleton. Technically, it's how the RollingFileAppender leverages the AppenderSkeleton RenderLoggingEvent method: it appends content to the log based on our LayoutPattern, and then dumps the Exception stack trace as its own line. We can correct this behaviour by creating a new appender that handles our exception details before it gets rendered into the logger as an exception.
public class CustomRollingFileAppender : RollingFileAppender { public override Append(LoggingEvent loggingEvent) { string exceptionString = loggingEvent.GetExceptionString(); if (String.IsNullOrEmpty(exceptionString)) { // business as usual base.Append(loggingEvent); } else { // move our formatted exception details into the message LoggingEventData data = loggingEvent.GetLoggingEventData(FixFlags.All); data.ExceptionString = null; data.Message = String.Format("{0}:{1}", data.Message, exceptionString); LoggingEvent newLoggingEvent = new LoggingEvent(data); base.Append(newLoggingEvent); } } }
The key advantage to this approach is that you won't have to change your existing logging code.
Though the previous approach solves our problem, we're coupling our message to our exception. There may be some cases where you would want to separate exception details, such as importing into a database where the message is limited and the stack trace is a blob. To accommodate, we can write our exceptionString to a custom property, which can be further customized using our layout configuration.
This code example shows the exception being logged to a custom property:
LoggingEventData data = loggingEvent.GetLoggingEventData(FixFlags.All); data.ExceptionString = null; data.Properties["exception"] = exceptionString;
And our configuration:
<appender name="RollingLogFileAppender" type="log4net.Appender.CustomAppender"> <file value="..\logs\log.txt" /> <layout type="log4net.Layout.PatternLayout"> <conversionPattern value="%date %-5level [%t] - %message %property{exception} %newline" /> </layout> </appender>
The final piece is defining our layout of file so that it can be consumed by Excel or Log Parser. In the example below, I've customized my Header and Conversion pattern to use a pipe-delimited format, perfect for importing into Excel or a database table.
<log4net> <appender type="Example.CustomAppender,Example" name="CustomAppender"> <!-- derived from Rolling File Appender --> <file value="..\logs\log.txt" /> <appendtofile value="false" /> <layout type="log4net.Layout.PatternLayout"> <header value="Date|Level|Thread|Logger|Message|Exception " /> <conversionpattern value="%date|%-5level|%t|%logger|%message|%property{exception}%newline" /> </layout> </appender> <renderer renderedclass="System.Exception" renderingclass="Example.ExceptionRenderer,Example" /> </appender> <root> <level value="DEBUG" /> <appender-ref ref="CustomAppender" /> </root> </log4net>
Here's a Log Parser query that uses pipe-delimited format (we use a Tab delimited format with a pipe as the delimiter):
logparser.exe -i:TSV -iSeparator:"|" "select Level, count(*) as Count from log.txt group by Level"