This is probably one of the most useful ‘custom’ tweaks I’ve added to my mac since I got it – I use it constantly.

Add a Keyboard Shortcut to Maximize the Current Window using Quicksilver

I use Command-Shift-M.

Our applications frequently need to convert XML documents between systems. While straight XSL does a great job at mapping System A’s enumerations to System B’s, I’ve found it’s very handy to include an <xsl:otherwise> to make sure mismatches are mapped to an obvious error value instead of just being quietly lost in translation.

Let’s say my homegrown candy inventory system uses numeric enumerations to indicate different types of candy, but our vendor-made candy production system uses text codes. The following XSL snippet will translate MyCandyType to VendorCandyType:

      <xsl:element name="VendorCandyType">
<xsl:choose>
<xsl:when test="MyCandyType = 100">MILKCHOC</xsl:when>
<xsl:when test="MyCandyType = 200">DARKCHOC</xsl:when>
</xsl:choose>
</xsl:element>

This works great as long as MyCandyType is 100 or 200, but if I pass in 300, VendorCandyType will be blank. Is 300 a valid enumeration? Maybe it indicates white chocolate (yuck), and I need to add that
enumeration to my XSL, or maybe my source data is just wrong. The point is, I’m trying to map between values, and throwing the source value away makes it very difficult to diagnose the problem. It’s even worse if that field is optional, because the target system will accept the input and give no indication the data was lost.

By including an <xsl:otherwise> clause that maps the unknown value 300 to the string UNKNOWN VALUE(300),
I can rest assured that schema validation in the target system will reject this value. However, I’ll still be able to see what the source value was and determine that it was the XSL that didn’t know how to deal with it. Take a look:

      <xsl:element name="VendorCandyType">
<xsl:choose>
<xsl:when test="MyCandyType = 100">MILKCHOC</xsl:when>
<xsl:when test="MyCandyType = 200">DARKCHOC</xsl:when>
<xsl:otherwise>
<xsl:value-of select="concat('UNKNOWN VALUE (', MyCandyType, ')')"/>
</xsl:otherwise>
</xsl:choose>
</xsl:element>

My vendor system is expecting MILKCHOC or DARKCHOC. It’s not expecting UNKNOWN VALUE(300).
It will reject the input, immediately and clearly showing me the nature of the mismatch between the two systems. It might hurt, but blowing yourself up makes your bugs much easier to catch, and thus to fix.

Recently, I was working on my first Flex project where I was consuming XML via a service. Whenever I wanted to make data changes with the service, I was required to send in an XML packet. Since AS3 has native support for XML literals, I wanted to create my small XML packet inline. For example:

var changeSet:XML =
ACTIVEQUOTE
;

Continue reading»

Lets go straight to the HTML:

item 1
item 2
item 3



My title

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
My title

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
My title

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

and its corresponding style:

* { margin: 0; padding: 0; }
body { text-align: center; /*Hello IE*/ }
p { padding-bottom: 1em; line-height: 1.4; }
#canvas { width: 49em; margin: 0 auto; text-align: left; background-color: #F0F0F0; }
#right { float: right; width: 25%; }
#right ul { margin-left: 2em; }
#left { margin-right: 25%;background-color: #FFF; }

Explanation:
Use the id “canvas” to assign the right column color. Then give id “left” a background color of white.
Click here to view an example.

To set a drop shadow on say a VBox or HBox component you simply set the boolean property dropShadowEnabled to “true” — but this is not enough to make the drop shadow appear. An example:

  1. 

To have the drop shadow appear (with its default shadow color) you need to specify a value for borderStyle since the default is none. Setting the borderStyle property doesn’t necessarily mean you have to display a border, but it is needed for the drop shadow to appear. So if the border is not desired, simply set the style property borderThickness to 0. An example:

   1. 

The above sample will display a drop shadow for the HBox component without a visible border.

In this Quick Tip, I show you how to make a method that deals with System.Object parameters more type-safe by converting it to use generics. Last year I had written a wrapper class to talk to the ASP.NET caching system for me. It returned cached objects as System.Object for maximum flexibility. The client would cast to the desired type, but it always bugged me, because it wasn’t very type-safe. Consider the following chunk of code:

Cache.Set("WhenDidIDoThis", DateTime.Now);
...
int numberOfTicks = (int) Cache.Get("WhenDidIDoThis");

It will compile just fine, but it will blow up when I run it, because silly me, WhenDidIDoThis contains a DateTime, not an integer. It’s far safer to rewrite my code to use generics:

Cache.Set<datetime>("WhenDidIDoThis", DateTime.Now);
...
int numberOfTicks = Cache.Get<int>("WhenDidIDoThis");

Hmm. Actually, that same logic error still compiles just fine, but hey, at least my code now signals its intent more clearly. The bigger problem is now I’m getting a compiler error elsewhere. Let’s see why.

Continue reading»