Perimeter Sweep:            An Assortment of Stuff from Gary Horton

It's late on a Friday and I've just solved a JSF headache, so I'm going to quickly write this up while it's still fresh in my mind (the solution, not the headache).

You may have stumbled onto this message if you're developing in JSF or just vanilla JSP:

#{..} is not allowed in template text

When you Google this phrase, you'll find various chunks of advice around versions of JSP, deferred expressions and the Unified Expression Language that comes with JSP 2.1. In particular, this reference appeared to have the definitive fix for my problem: either change the "#{" to "${", or backslash-escape the "#{" sequence, or change a setting to allow deferred syntax as literal. Now, any or all of these solutions might work for you, depending on your context; but I write this up because none of them worked for me.

What I have is a web application developed with JSF 1.1 that had used JSTL 1.1, but that then got deployed into a Java EE 5 environment which provides JSF 1.2 and JSTL 1.2. Many of you already know where this is going. But for my own future reference and possibly your amusement, I'm going to write it up anyway.

I changed all occurrences of #{ to ${, and knowing that Java EE 5 servers already supply the correct JSTL 1.2 version, I removed my webapp's private copies of jstl.jar and standard.jar (vestiges from when they were needed, with J2EE 1.4 servers), but now I get this error message:

According to TLD or attribute directive in tag file, attribute rendered does not accept any expressions

So the syntax change was a head-fake, at least in my case; I can't explain why. You are invited to chime in if you understand it. I was referred to one useful discussion that contains various suggested solutions and references various other threads, and it got me on the right track. Here's what I ended up doing: first, change the ${ back to #{, since really getting the incorrect JSTL version out of the way is the true fix. There is also an EL expression factory workaround discussed in that thread which was applied to my deployment descriptor.

But, here's where it gets interesting (as if it isn't already drop-dead compelling, right?) -- although removing the JSTL 1.1 stuff, applying the DD workaround and reverting back to #{ syntax should have cured all my problems, now I get an EL parsing error concerning this particular attribute construction:

text="#{dds.value.enabled?isnsMsg.deactivate_action:isnsMsg.activate_action}"

This is a boolean expression managing a text value that must change depending on the state of a given backing bean property; this had worked just fine in my JSF 1.1 deployment, but now it's no good. The error reads something like this:

Was expecting one of:
    "(" ...
    <IDENTIFIER> ...
    <NAMESPACE> <IDENTIFIER> "(" ...

Without belaboring the point - since I have a headache from all the different things I tried - I'll just admit it: I took the inelegant way out and used two panel-grouping blocks, each with its own rendered-if attribute, to fix this problem:

<ui:panelGroup rendered="#{dds.value.enabled}">
    <ui:hyperlink text="#{isnsMsg.deactivate_action}"/>
</ui:panelGroup>
                                               
<ui:panelGroup rendered="#{!dds.value.enabled}">
    <ui:hyperlink text="#{isnsMsg.activate_action}"/>
</ui:panelGroup>

Using JSTL IF and WHEN testing is just as ugly, but at least it fails to work. The JSTL expressions get evaluated too soon relative to the JSF lifecycle, i.e. the IF and WHEN always yield false since they're evaluated before the backing bean property gets its value set as needed.

I didn't do any research to understand why the inline boolean expression in JSF 1.1 caused a parsing error in JSF 1.2 (or maybe it's a JSP 1.2 vs JSP 2.0 thing...hey, probably it's JSTL 1.1 vs 1.2...isn't web-tier fun?). So while I've solved the immediate problem, I've left plenty of room for colleagues to elaborate and, frankly, to correct me where I'm misleading. Like I say, it's late on a Friday and sometimes I do as little as necessary to get from A to Z. If anyone has additional insights around what's discussed here, you are invited to share.

Just a quick announcement about the first release of our iSNS BUI. The download is binary only - source to follow "soon" - supporting the x86 and SPARC platforms with a minimum Nevada release of snv_78. If you're already iSNS-savvy, that might be all you need to hear; else, here's some elaboration:

First, when would you care about iSNS? Only if you are managing an IP SAN...I touch on this briefly in a previous entry; here's that elevator pitch plus some more detail:

iSNS is a value-add technology supporting management of IP SANs, in particular providing centralized access control between iSCSI initiators and targets. This becomes an increasingly compelling mechanism as the number of iSCSI nodes grows: no more sneaker-net to connect storage consumers and providers.

As iSCSI initiators and targets are added to an IP SAN, maintaining access control becomes an increasingly demanding chore. Engaging an iSNS server as the “authorization clearinghouse” can effectively centralize the management of initiator-target communications and lower these management costs - an attractive alternative to the manual administration required without iSNS.

iSNS provides a containership hierarchy that is analogous to the Fiber Channel zone and zone set idiom.  To enable intra-node communication, the storage administrator creates one or more discovery domains that group the appropriate nodes together; initiators can contact only those targets that co-exist in the same discovery domain. However, the communications can only take place within discovery domains that are contained in an “activated” discovery domain set. Discovery domain sets serve as a coarse-grained on-off switch – for instance, the administrator may wish to disable activity while network backups are in progress, and grouping nodes and discovery domains accordingly will facilitate this.

As you might know, recent releases of Solaris 11 now provide an integrated iSNS service, and as a complement to the command-line interface supporting iSNS operations, this BUI provides web-based management. The BUI has been designed with a task-oriented focus to provide an intuitive front-end for iSNS management operations, with basic operations to include the following:

• Create a Discovery Domain or Domain Set
• Manage the Members of a Discovery Domain (Set)
• Delete or Rename a Discovery Domain (Set)
• Activate/Deactivate a Discovery Domain Set
  

Convenience operations are additionally provided, to include:

• Manage the node’s assignments to domains
• Identify all nodes that are not assigned to any domain
• Identify all nodes that are members of a given domain
• Quickly find a node among a long list using AJAX-powered search-as-you-type
• Tree-based view of the overall IP SAN
• View “connectivity count” – # of nodes contained in each domain
• View node members in a given domain by type (target and initiator)
  

Your feedback is invited to help guide our ongoing design decisions; if you'd like to participate in the BUI evolution, please offer suggestions, point out bugs, and etc. via the isns-discuss at sun.com alias. In particular, if you do download and install, please send us comments around how well that went for you.

Visit http://opensolaris.org/os/project/isns/BUI for an overview of the project, including updates on current activity, screen shots and a brief discussion of the application architecture.

The last year has been one of intense learning around JSF for me. Some of my teammates have asked me to share my so-called wisdom, and I'll be using this blog as one part of that effort. It's been said that to really learn something, one should teach it...so I look forward to giving this a shot.

A modesty disclaimer is in order: it's only "so-called" wisdom because I've got a great deal more to learn about JSF (and web development in general), so everyone's feedback, critiques and corrections are invited.

For starters, it's useful to gain some historical insights...so I start with a quick look at the prehistory and subsequent evolution of web development. With this and all subsequent posts around this topic, I'll be generalizing quite a bit, in the interest of publishing quickly; if you feel something has been omitted or misrepresented, you are invited to add to the discussion.

So, for my first generalization: the topic here is "presentation technology". My second generalization is that there are two types of presentation: web-based and not web-based. Concerning the forces at play motivating the evolution of these technologies, I'll do a broad-brush to capture what has struck me as essential. This includes the aspects of user experience, deployment and standards, with brief discussion around the tradeoffs that web-based vs. non-web-based approaches bring to each.

In the early days (defined as "long ago when my career was young"), graphics-powered desktop systems enabled the beginning of the "rich user experience". Various systems and toolkits emerged supporting both local and remote GUIs, and there is today an abundance of applications still using these approaches (X Windows, Motif, Swing, Visual Basic, etc.). Let's start with these and elaborate a bit on the user experience, deployment and standards aspects:

On the plus side, user experience is typically quite good: these GUIs provide interactive, dynamic content, with good responsiveness - especially when deployed locally. X Windows is an example of what I mean by a remote deployment (display information is transported over the network), and responsiveness in this setting is not always good. No surprise here; shipping bits over-the-wire is almost always the bottleneck in the responsiveness pipe. While delays might also be seen with a "local" GUI (display logic is installed on the user machine) that gathers its content from a remote data source, the impact here can easily be mitigated since the GUI can still be responsive if, e.g., the content retrieval is done asynchronously, i.e. in a separate thread. As it turns out, this arrangement can be exploited to provide constant, predictable response times on the display client independent of server activity with a "database in the middle" architecture; but that's a digression I'll look forward to writing about later. My main point here is that responsiveness can most easily be optimized with a locally installed GUI.

In either deployment, there are distribution issues: local GUIs must be installed directly on the user's machine (a so-called "fat client"), and remote deployments require some level of installation on the user's machine to support the client-server idiom; e.g., an X11 server is needed in the X Windows case. Managing this distribution has non-trivial maintenance costs; the larger one's audience (e.g. intranet vs internet), the more of an impact this will have. To address the timely update and distribution of fat clients, we've seen solutions ranging from sneaker-net (here-and-now solution but very slow, very difficult to manage versioning, etc.) to things like self-updating applications (more sophisticated but, at first, lacking in standards and still requiring the initial installation). Deployment costs in this setting most likely limit one's audience to the intranet only.

Finally, there has been the issue of standards. With widespread adoption of Java, platform-independent GUI development has been largely realized; however, user-facing Java applications (applets, AWT, Swing) have, fairly or not, been regarded as slow and clunky. I've personally never thought of the presentation layer as Java's strength, but it was originally marketed with that as the focus, and unfortunately this has left an indelibly negative impression around Java in some camps. For this and/or whatever other reasons, desktop Java has made some inroads but is hardly what I would call "ubiquitous" or "compelling". Aside from this platform-independence issue (which is, arguably, a deployment topic), there is a need for standards around the presentation-layer programming model. When we standardize here, our investment in learning curve can be reapplied in subsequent projects, we provide for modular component-based programming that encourages reuse, we build communities of developers that share knowledge bases and design patterns, ... the list goes on, I'm sure. It's probably pretty safe to say that standardization here would be a good thing. However, desktop presentation developers use a wide variety of proprietary or at-best-de-facto-standard toolkits, with widely varying programming models and APIs; I'm unaware of any widely embraced standards in this area.

Now let's move on to web-based presentation. There are many excellent writeups on the history of the Internet and development of the World Wide Web (WWW) as an Internet application; for my purposes here, the main takeaway is that an entirely new basis for presentation was provided by (1) opening the Internet to commercial interests in 1988, (2) the invention of HTML, HTTP, and web browsers in the early 90's, and (3) resultant widespread public consumption.

With the WWW, internet-wide deployment can be realized (open up your audience to...the world); while web browsers still must be installed on the user machine, they are typically included in the desktop OS, reducing the deployment cost (and time) to zero. The ubiquitous web browser is now taken for granted.

Building on the WWW, benefits can be gained from use of standards - for a beginning, HTTP, TCP/IP and HTML lay the foundation, and further evolution has moved from there: the subsequent layers above this basis have standardized over time to bring us to JSF.

While not lost in the shuffle, the WWW user experience is something of a setback. Dynamic interactivity (e.g. drag-n-drop, automatic screen refreshes, etc.) is, until recently, lost altogether, and responsiveness is known to suffer. In fairness, this is as mentioned always a risk for remote deployments, which is usually what your web browser is part of - although this can be mitigated with asynchronous processing, database-in-the-middle, etc.. Overall, while the deployment and standardization advantage goes to web apps, non-web-based locally-deployed GUIs hold a strong edge with user experience. But, this is changing with emergence of AJAX and related technologies that leverage asynchronous behaviors. In fact, with these new approaches, the web-based experience has potential to evolve into a rich, responsive one.

You have my apology for such generalized content; I've omitted a great deal. My purpose here is to simply set the table for a TOI (uh, a general one) around JSF, and that series will continue "soon". Next up is a closer look at web-based technology per se to fashion a backdrop, moving into JSF and Sun's implementations of JSF in particular, and revisiting my current learning curve around AJAX to share still more so-called wisdom...

Just a quick summary on our Monday night adventure at the DMA Science Fair, where we set up a booth to demo our webapp for managing iSNS servers. Our goal was to spread awareness of this soon-to-be-released management tool among the Data Management Ambassadors, get some test drives from these folks to gain usability insights, and ideally set the stage for an ongoing dialogue. Overall, we succeeded: half-a-dozen-or-so DMAs expressed a desire to follow up, including downloading the product, demo'ing it to their customers, and in most cases staying in touch with us to help shape ongoing product evolution.

A secondary goal of consuming pizza and beer during big-screen Monday Night Football was also attained. Life is good.

To backup a bit: iSNS is a value-add technology supporting management of IP SANs, in particular providing centralized access control between iSCSI initiators and targets. This becomes an increasingly compelling mechanism as the number of iSCSI nodes grows: no more sneaker-net to connect storage consumers and providers. The handout we provided at the fair elaborates a bit, including a big-picture view of the tool's functionality.

As our low-tech poster board (uh, flip-chart and magic marker...only because we couldn't find a typewriter) claimed at the fair, here are the Top 10 Reasons to Use the ISNS Web-based Management App:

1. Friendly wizards to guide tasks
   
2. Intuitive layout - no need to recall CLI syntax
   
3. Use the iSNS webapp, or the puppy gets hurt
4. Simple presentation for junior administrators
5. AJAX, baby! Check out the "quick-find" feature!
6. Agile: we'll adapt quickly to new feature requests
   
7. Co-exists in Lockhart console w/other mgmt apps
8. Point-n-click for mgmt nirvana ("Backspace? We don't need no steenkin' backspace key!")
9. Your input helps guide the evolution of the tool
10. A perfect complement to the iSNS CLI

Our key takeaways from discussions with the DMAs are these:

(1) There is lots of interest out there around iSCSI, and iSNS plays right into it. The DMAs were pleasantly surprised to see we even had such a thing. They feel their customers would use it.

(2) There are market opportunities in Windows shops that we've yet to exploit - but, we can only get in via appliances, because these shops do not want CLIs. We discussed getting iSNS in via the appliance OS as our on-ramp, and this is an approach favored by various DMAs.

(3) The iSNS BUI (Browser User Interface), as it stands, has some usability concerns - and this is exactly what we were hoping to uncover, so this is a half-full glass. In particular, while engaging some DMAs with typical task flows, we realized the need to expose a comprehensive node-centric view of the iSNS hierarchy ("what targets can this initiator see? what initiators can see this target? is this particular node in an active domain set? which domain sets do I need to activate to establish communication?"), we need a domain-centric parent view ("what domain sets does this domain belong to? which ones are active?"), and we need a network-entity child view ("what LUNs are part of this box?").

Adapting to provide this new functionality will, thankfully, not require any changes to the iSNS server data model or API: we've already transformed that XML-based data model into a web-tier-resident relational database to facilitate these unforeseen query needs (and likely many more to come). As an aside: the ability to fashion new queries on-the-fly, without having to restructure the backend to support this (aka ad-hoc query), is one of the big advantages of relational technology. And that's a whole other topic that I look forward to writing about. Meanwhile, here's an overview of the architecture for the web-tier.

Our 2007 Science Fair adventure is an example of Engage the Customer, which is the first of my various ease-of-use bullet points. Additionally, as per our ability to quickly provide new queries and views without undue pain, we've already benefited from Adjust your Process to Allow for Course Corrections...and with quick-and-easy-answers to the key questions listed above, we Design for Optimized User Experience. This quick-and-easy-answer ability demonstrates some of the value-add of a BUI/GUI that complements a CLI.

 Our team is talking about going agile, discussing ways to bring in an underlying iterative backdrop to what is largely a waterfall context. Though we live within the constraints of Sun's product lifecycle process, we believe that we can become more effective, flexible and productive by intentionally working in various aspects of an agile mindset. In fact, the way we're probably going to be able to accomplish this will itself be agile - a little bit at a time, course correcting as we go, getting feedback from our stakeholders.

So what we're really doing is something of a "meta-process" - figuring out what process to use to bring in a new process. Our "stakeholders" in this meta-process will be our managers, who will need to continue with their own existing processes but be able to integrate our progress reports, issues, bugs and so on without disruption. Ideally, we are able to demonstrate to our managers (and ourselves!), over time, the value-add of an agile approach.

One of the goals is to avoid the Big Bang Integration we've seen in the past. We also target getting "aspects" done as we go instead of waiting until the end (logging, I18N, diagnostics, persistence, ...). We're convinced that this will facilitate communication around all areas of the product - in particular acknowledging the realities of our Sun product lifecycle needs - early on, addressing any risks and unknowns upfront instead of bumping into unforeseen problems later in the cycle.

Since we have a new product spinning up as we speak, we think that now is the right opportunity to rethink our approach from the inside-out, simultaneously educating ourselves on agile process fundamentals and engaging with others here at Sun who are already on that road. Here's our first cut at how to proceed internally with our new product, which involves web-based management of iSCSI devices:

The first release is a thin vertical slice, focusing on "happy path" only, and addresses one user story only - as pretty much an "excuse" to get all infrastructure together upfront. The release might consist of something like this:

Hats off to Sang Shin. This energetic Sun employee puts together high-quality online coursework around various Java-related topics, on his own time, and rightfully attracts a good crowd for each one. Check it out if you haven't already done so. The current course is around AJAX programming, and it's my pleasure to be sitting in.

Now, when I start learning a new technology, I look for the Hello World lesson - i.e., what's the least I have to do before I can actually get an A-to-Z out of it. And, if I can retrofit it quickly to my current project, all the better! Sang's first AJAX lesson does not disappoint; I've moved from AJAX-ignoramus to actually productizing my own customized validation routine in the last 1½ days. I count that as successful time spent, especially since AJAX-enabled behaviors in our product were deferred until "next year" - because we thought the effort would be prohibitive. Not!

You're invited to gain some immediate benefit from my learning curve, as I provide a series of "Cliff's Notes" type posts that summarize what I'm learning and how I'm applying it. What I'll present will start out with a certain naivety - since, frankly I still have a great deal to learn - but will likely evolve into something more sophisticated as I proceed through Sang's class. You are also, of course, invited to join me in this class - it's never too late with Sang's Java Passion courses, since they are self-paced.

AJAX is surprisingly easy to get going on - there's no downloads needed; you already have all the tools you need. This of course is true since we're looking at AJAX 101 - bare-metal vanilla no-frills and no-framework AJAX, which as Sang points out is not the way you'll (probably) end up using it, but is useful for instructional purposes. The moving parts, for this particular exercise, include some JavaScript, some JSP and a servlet - nothing new or exotic. So, while one of the many available AJAX frameworks may give us more power, there is plenty of value in first understanding things at a basic level.

Here's the problem space: our product, a web-based management application for iSNS, provides wizards that create various user-named objects in an iSNS space, and provides forms that support renaming these objects. As per the iSNS spec, all objects of a given type must be uniquely named. This validation is, of course, done on the server to maintain its database integrity; we are also motivated to do it on the client so that the user can be notified as soon as possible that the name he is choosing will not be acceptable.

Now, this is one of those types of validation that must in fact call back to the server to determine the acceptability, and this is where AJAX fits in nicely. So we'll set up a mechanism that calls back to the iSNS server to confirm the user-entered name is unique, and we'll spice it up a bit by also detecting an empty (zero-length) name, which likewise would not be acceptable. The payoff, of course, is that the user is notified of non-uniqueness or zero-lengthiness as she types, vs. having to submit the form and wait for a server response. It's asynchronous. But you knew that.

The AJAX-centric strategy to provide the validation is to (1) track user text input as it happens, (2) sending that input back to the server to check for duplicates or zero-length, (3) responding to the browser client with an assessment of the text input value, and finally  (4) displaying a message and disabling submit-type buttons, or alternately removing the message and enabling the buttons, as needed.

I implement the strategy by lifting some of the code snippets presented in Sang's course materials, refactoring them into a generalized reusable set of JavaScript functions and one reusable servlet, and accessing these components from a JSP client. The JSP client will specify an event handler that tracks each character typed and invokes a JavaScript function to validate the input. This validate function is the on-ramp for clients, and is part of a collection that leverages the AJAX engine to provide something more of a "rich user experience". Finally, the servlet processes the GET generated from the validate function and does the validation, returning an XML-encoded response processed under the covers via the magic of AJAX. As usual, the servlet must not only be implemented, but it must be declared in the deployment descriptor.

BTW, there have been raised-eyebrow questions in class - and, before trying it, I had similar concerns myself - about round-trip performance when AJAX issues GETs with every character the user types. In this iSNS management webapp, with every character typed, the user-entered value goes across the wire using RMI to connect to a JMX module, which goes across a shared-memory interface, converting the query into XML (using JAXB) going over JNI to a C-based server. The C-based server looks things up in its database, replies back over JNI with XML, this data then goes back over the RMI connection to the webapp which converts the XML into Java objects (JAXB again). From there, the determination is made about uniqueness (i.e. if the object is not null, it is not unique).

Does this not sound like there'd be undesirable delay getting messages to the user? It did to me - but when I gave it a quick-and-dirty trial, the responsiveness was pretty much immediate at the user-facing level, even when the user continues typing. Our design, admittedly, has already been tuned for optimized round-trip performance; we took explicit steps to make things lean-and-mean, otherwise the responsiveness might not have been so good - but I wouldn't have known for sure in either event until I tried it.

From this, as an aside, I would offer two thoughts: (1) don't solve performance problems until you have one, and (2) don't assume you'll have a performance problem until you do a quick proof-of-concept. I'll "soon" be posting articles about our iSNS webapp, and I'll point you to it so you can try the validation processing for yourself.

See you in class. I'll continue posting more about what I learn there, as I work my way through it.

I'm not an HCI expert, but nonetheless I will blather on here about ease of use, in particular with software products and from a developer's perspective. This is a topic that our team wants to bring to the foreground, so I save my thoughts here as part of the discussion.

The first question, "what is it", requires no particular expertise to answer; it requires, I believe, only some experience as a so-called customer. Here, for instance, is a low-res photo of yours truly in one of my thirstier moments, having just purchased some beverage, albeit in an adult-proof container:  

No, it's not a recent photo, but thanks for asking. Anyway, I did finally get that plastic top unscrewed from what admittedly appears to be a tube of blue toothpaste, and clearly burned some calories getting it done. It was no mistake that I was dressed for breaking a sweat, since I knew what I was up against: a beverage in a squeezably-soft toothpaste container protected by an adult-proof screw top, but, hey, haven't we all been there?

My point is that we've all been customers of products, some of which we find easy to use, and others...not so much. So we're all qualified to define this ease-of-use thing; I offer a simple, general take on it: it does what I think it should with a minimum of fuss...alternately, I'm able to learn the thing quickly without reading the manual .... or, it helps me more than it annoys me ... this list can go on. But I defer to anyone who has an opinion: "what is it" is a subjective thing, defined by the customer, in the context of the particular product in question.

This customer thing lends immediate insight into the next question: who wants it? Well, of course, it's the customer - which includes you as a developer, if you are for example using components provided by your teammates. Assuming then that customer satisfaction is important, the notion of providing ease of use should matter immeasurably to developers, since it can be argued that customers are our raison d'être. This is French for (1) the reason we have marketing and sales departments and/or (2) why we stopped waterfalling and learned to love requirements changes.

So we assume a "customer-centric" approach....whatever that means. Well, I suggest it means more than just the look-n-feel of a product, and that getting to "ease of use" involves a comprehensive set of issues. Which brings us to our third question: how do we get some of this ease-of-use stuff? Sure, engage the customer...for starters. But from a developer's viewpoint, and in particular from my experience, there's a bit more needed than that. Here's my list:

1. Engage the customer

2. Engage an HCI expert

3. Requirements drive the What, developers address the How
   

4. Design from the top-down

5. Design for optimized user experience

6. Adjust your process to allow for course corrections

Now, I want to elaborate on each of these, but - in the spirit of ease of use - I end this post as a brief introduction. I will continue to blather about each of the above items in upcoming days and weeks, so please check back.

I close by repeating that ease of use is gained by addressing more than just the GUI or BUI presentation, and in fact applies to not only the process used to get to this user-facing end-game, but also to all layers of the software stack that support it, to include component interfaces, APIs and architecture. My definition of interface includes the "contract" defining that interface, and my definition of customer includes developers who act as consumers of APIs, contracts, etc. So, in future posts, I'll detail my six bullet points with a holistic view.

Our son's 1st birthday is today. This is difficult to believe. How is it that all of these children I know are growing up so fast, while I don't age at all? At least my friends tell me I look the same as I ever did. Hmmm...maybe it's like my Dad once said about his girlfriend-at-the-time (settle down - he was single-at-the-time), "She looks pretty good to me, but you know my vision just isn't that good anymore...".

Aimee is taking him to bed now (our son, not my Dad; puh-leeze settle down), and he's waving buh-bye to me as they go upstairs. I'm reasonably certain this is the cutest kid ever. Judge for yourself, here's a candid shot:

Our boy's name is Connor. Connor Michael. He sports a keen fashion sense, no?

Connor lives with two Huskies (he's part of a pack...). Now, as Connor knows, Huskies are the kind of dog where you have to be in the mood for adventure. So, for example, whenever we go to some new dog park, their first move is to check the boundaries - hoping, as it were, not to find any. There was this time we entered a dog park via a double-lock gate...which would seem to add a certain sense of security...I mean, once you enter through a double-lock gate, what's the worst that could happen? Moments later, my smug self-assurance turns to horror: they've noticed the dog park lacks a fence on one side. A dog park...entered by a double-lock gate...but enclosed on only three sides. Lending new meaning to the sign outside the park: "Boulder County Open Space".

On the plus side, it was an opportunity for heart rate zones 4 and 5, if you catch my meaning. Since then, I do a perimeter sweep before entering unfamiliar dog parks - just some insurance that I'll leave with the same number of Huskies I came with.

So, "perimeter sweeps". That's what Connor does, it's what the Huskies do, and now it's what I do. Check the boundaries, find a way to get outside the box, but first confirm there is a box. Balance is essential for everyone's best interests.

More on double-lock gates later. It's my son's first birthday. Wow.