Skip to content

Debugging Google Maps with an Offset Center

September 29, 2009 has an embedded Google Map showing each park’s location. On the park-screen, this embedded map is hidden until the visitor clicks on a tab. To eliminate any momentary display of this map during the drawing of the page, the entire DOM element is created with javascript (jQuery).

A strange thing happened when I first built this functionality. When the map was displayed through the visitor clicking the tab, the map’s center was offset (south and east), and the south-most and east-most map-tiles were blank. After significant debugging, I found this only happened when the map was drawn within a hidden element. To solve the problem, I just adjusted the order of the javascript so that Google’s initialization code occurred immediately before the code that hides the container.

Incidentally, since embedded Google Maps don’t work so well with javascript disabled, the embedded map’s dynamically created container/placeholder, replaces a <noscript>…</noscript> container that holds a link to the full map on This way, if no script runs, the visitor still has access to the map, and the page continues to be readable. And, if javascript is enabled, the noscript-link does not display momentarily, or flicker, before the javascript completes.


Generating a Universal Unique Identifier

September 28, 2009

A Universally Unique Identifier (UUID) is a formatted string used to identify something with reasonable confidence that the identifier will never be unintentionally repeated by anyone for anything else. This is useful for example in creating table-entries with unique IDs, which you might need to merge with another table and not have conflicting ID’s or need to generate new ID’s.

B_UUID is the second installment in my B-Suite of custom types, and is a pure-Lasso method of generating a version 4 (random) Universally Unique Identifier (UUID). The usage is very simple, you simply call the prototype, and the call is replaced by a new UUID.


=> 12c9ca38-ef23-42f2-951b-f6dad1ced320

For the most up-to-date version of this code, I recommend checking the source out from my Google Code account linked to above. As an alternate, you can also view/copy the source from

Other methods of creating a UUID in Lasso

  1. On most operating systems, using Jason Huck’s Shell tag, or the built in OS_Process tag, the `uuidgen` command can be used to return a version 4 UUID.
  2. Steffan Cline has recently posted a cross-platform LJAPI module, GetUUID, that is most likely faster than any solution written in Lasso Script, or certainly any solution that needs to open a shell.
  3. My understanding is that when LassoSoft releases Lasso 9 (most likely October, 2009) that the built in Lasso_UniqueID will generate a version 4 UUID, similar to B_UUID.

Making a page too dynamic

September 25, 2009 has a feature where a visitor can choose to jump to a randomly selected park. The way this initially worked was the “random”-link simply selected a park at random, and build the park-screen. The “random”-link’s URL looked like this:

The problem with this design was that if the visitor navigated to another screen, and then used their browser’s back-button, they were presented with an entirely new park each time they returned. This effectively broke the browser’s back-button, and my focus group displayed quite a bit of confusion (yes I did, and continue to, use a focus group. They’re a small group of friends and family who agreed to help unpaid, and to whom I am very grateful).

In any case, I knew we had to change this functionality, and did so first thing. The change was simple, the code now does an HTTP-redirect to the actual park-screen of the randomly selected park. That URL looks like something this:

I did worry over this change before implementation. Redirects, especially temporary redirects, are considered bad form by some pundits of “good web design”. But I finally decided that this was a proper use of the functionality.

My focus group appreciated the change. They’re happy, I’m happy, and now I just hope the general public will be happy.

Celebrating a Launch:

September 24, 2009

I’ve been quiet recently, I know. I spent the last 4-weeks working on a personal project; a small tech. start-up named As businesses go, it’s not huge. But, I believe it has some potential for traffic.

The genesis of the website was a morning in which my wife asked me to find a park to take our two-year-old to that evening. On her way out the door to work, she said she wanted the park to have a great play area, and not be one he had been to before. This should have been easy to find on the web, but surprisingly wasn’t. The easiest to find content, off of the various city-websites local to us, showed a single small picture of each park’s sign, and an anemic blurb of little help. If you dug enough, you could find user reviews, which are always helpful, but they were on third-party websites not specializing in parks, and had no pictures.

My wife and I actually love the Amazon shopping experience. Mostly it’s the user reviews, unbiased reviews of any product from a multitude of sources. So the idea behind is to pair the Amazon-like user experience, with a catalog of parks. Of course, Amazon isn’t the only website out their with a great user experience, so they’re not our sole inspiration.

Being a web developer, of course I’m using this project to try out some new ideas of my own. I’ll be blogging about these experiences as I encounter them, and hopefully you’ll benefit from this as much as I’m sure I will.

In any case, was just launched yesterday as a beta. Please check it out. I’ve already made some changes to the UX since launch (more about that is another post). As developers, you might be especially interested in the Development Roadmap.

B_Template: Deep-sixing Includes

August 10, 2009

B_Template is the first installment in my B-Suite of custom types, and can be used to apply multiple consecutive changes by regular-expression to a text-file. The text-file is then sent to the client as the final content body. I built this to separate the front-end of my web applications, from my middleware code, and avoid an octopus-like tangle of included files. The current B-Suite source can be checked out from the Google Code.

Typically you’ll use the Include tag to dynamically patch together each webpage from a header, footer, sidebar, code libraries, etc. I’ve found this becomes difficult to manage as the size of the website, or number of participants, increase. Instead, I wanted to keep the front-end self contained, and then dynamically apply generated content.

For a very simple example, an HTML page can stand alone, and be easily managed with many available tools.

<html lang="en">
<meta charset="UTF-8">
<title>Insert Title Here</title>
<h1>Insert Header Here</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>

A script file can then pull together the data, and apply it to the above template.


Inline( -Database='db',
-SQL='SELECT `title`, `header` FROM `tb` LIMIT 1');

'Insert Title Here'=Field('title'),
'Insert Header Here'=Field('header'));



Of course, the above is an exceedingly simple example. You can also use regular expressions to specify changes, and structure your usage more programatically using member tags.


Local('mytemplate' = B_Template);
#mytemplate -> Location('/path/to/template.html');
#mytemplate -> Apply(RegExp(-Find='(?<=<title>).*(?=</title>)', -Replace='My Title'));
#mytemplate -> ServeAtEnd;


There’s control over when the current instance of the template is served to the client, what MIME type is used, and whether to apply the changes to the current instance or start again with the original template. Using B_Template, you can also extract sub-templates from the original, which allows example structures in the original template to be looped over and appended to with changes.

There’s more information in the project wiki — or will be shortly. I’d love any feedback, so please leave a comment with your thoughts.

Started B-Suite Project on Google Code

August 10, 2009

I’m working on several custom tags and types for release to the Lasso community. Collectively I’m refering to these as b-suite. I’ve created a new project up on Google Code, and as each new tag or type is released, I’ll add it to this project.

I’ve chosen to release this code under the MIT License, which seems to me to provide all the rights you could possibly want. If your organization requires anything more, please contact me.

At this time b-suite is coded for Lasso 8.5.5. I have several custom tags and types planned for inclusion, and have Lasso 9 versions in the works. Watch this blog for announcements when each tag or type is added to the public repository, and please leave me a comment, or email me directly, if you put any of my code to work in your projects.

A First Look at L-Unit™ 2.0

July 29, 2009

For anyone conversant with Test Driven Development, it’s enough to say that L-Unit™ is a unit testing environment for Lasso code. For the rest of us, L-Unit™ is a framework upon which you can setup, store, and run tests of your custom types. These tests are abstracted from your application as a whole, and only act upon an individual “unit“. The developers say this helps you avoid the “whack-a-mole” type debugging one inevitably engages in when revising a broad or complex code-base, and I can certainly see how L-Unit™ will help.

Setting up L-Unit™

I’ve heard about L-Unit™ for years, but I never paid much attention to it until last September’s Lasso Developers Conference. So, about a month ago I downloaded a zip-archive of the application from The developers recommend checking out the Subversion repository instead, which makes a lot of sense — the zip file I downloaded was created early October, while the repository was last updated a month later — but I was being lazy. Besides, while I use Subversion daily, some developers are not yet comfortable with SVN. I plan on publishing a second article on L-Unit™ after I’ve used it a bit more, and I’ll base that second article off of the code-base checked out from the repository.

I started by reading through the first 24 pages of the manual. The last 3 pages are reference material, and can be skipped until you start coding. The “Quick Setup Guide” is on page 24 of the manual, which seems an odd location. But, it being there guided me towards reading the manual before I started, which was perhaps the writer’s intention. The “Quick Setup Guide” is available as a separate download as well.

After reading the manual, it was pretty obvious I needed to rework many of my settings in Lasso’s ServerAdmin. I had about 15 websites already running on my development machine, but rather than create a separate Lasso site for each, I had only configured the default site. This wouldn’t do, since L-Unit™ should run in a default environment. So I moved everything in under a new Lasso site instance, and created a second new Lasso site just for L-Unit™.

Starting with a clone of an example test case , I created a very simple test case for a custom type I had recently completed. This was putting the cart before the horse in the Test Driven Development methodology, but I thought I would learn a bit more this way.

Boom. I hit my first brick wall, if not a particularly high one. Belatedly realizing that L-Unit™ must parse through my class-files, custom type files in Lasso parlance, I ran a chmod command on the site’s root directory to allow write privileges for everyone.

chmod -R go+w unit

Changes to my code

I found that I needed to adjust my coding style to fully utilize L-Unit™. The custom type I had chosen had only three member tags. One of these member tags was fairly complex, but none of the enclosed-code was duplicated anywhere else. Also, the complex member tag had no return value — it simply set or modified a global variable. To test the code within the complex member tag granularly enough to make a difference, I needed to split it up into many smaller tags, and make each one return some value. While this might seen a bit intrusive on the part of L-Unit™, I think the end result is a better bit of coding on my part than what I started with.

When I finished with my a successful test case for that first custom type, I moved onto a second. This was actually a custom tag. The test setup for a custom tag was identical to that for a custom type. Again, granularity in my own code was a must. I ended up re-coding my tag into a custom type, but just get into the mindset of building a bunch of small constructs, instead of one big one. Intrusive? Yes, but again I liked what resulted from my re-coding. And, I didn’t actually change the usage for the resulting code.

Finally, when I created my first test for this second custom type, I was at first a bit confused. I code all of my custom types and tags for a given namespace within a single file. So, naturally I tried coding my second test case in the same file as my first. Since the two constructs I was testing are in the same file, this made perfect sense. Well, apparently not to L-Unit™. Oh well, once I stumbled upon the answer it wasn’t a huge paradigm shift to build one test case per file.

What I don’t like

The PDF manual I downloaded doesn’t allow copying and pasting. Any such attempt results in gibberish. Perhaps I’d have better luck with Acrobat Reader, rather than Apple’s Preview. The way around this annoyance is to use the Google Doc version of the manual. I had downloaded my copy of the manual from the “Downloads” page, rather than looking on the “Documentation” page where the Google Doc version is mentioned.

I found it difficult to debug errors shown by L-Unit™ during a test run. The information returned was fine, but since each test is run asynchronously there are few if any means of pulling out more information. I’d like to see some method of viewing the content_body from each run of a tag within L-Unit™. It’s possible a construct like Log(-Window) would help push debugging information out to the Lasso Service console, but I haven’t tried this yet.

Of course, I’d like to see L-Unit not rely on non-standard file suffixes, but I’ve already detailed my reasons for this in an earlier post. It is nice to see the numerous warnings against running L-Unit™ in a production environment. But, such a warning should be for performance reasons, not security.

What I do like

The application’s user experience is very polished, which is refreshing to see in an application intended for admins. And, while the documentation has some small errors and could use a bit more information, it’s rather polished as well.

Others might complain more about the need to adjust their own coding structure to maximize the usefulness of L-Unit™, but as I said before, I liked the results. I probably should have been coding more like this for years. Of course I really should have built my test cases first, and then written my code to satisfy those tests. So changes in my architecture would have seemed more natural from that perspective.


I probably could have had any questions answered pretty quickly by posing them on the LassoTalk mailing list, or emailing the current developer directly. But I think a number of developers hesitate before asking questions, not wanting to appear the “newb”. By sorting through the issues alone, I got a sense of what they would be going through. Either that, or I just didn’t want to appear the “newb” myself.

I’m looking forward to using L-Unit™ on several upcoming projects, this time coming at the code in the correct order, with the test-cases first and the application code after. I’ll need more time to fully form an opinion, but at this stage I’m optimistic that L-Unit™ will become a standard part of my work flow.

A fews more things

L-Unit™ was originally developed by Greg Willits, and has more recently been driven by Ke Carlton. Both should be commended for their respective efforts. Ke is the one who gave the L-Unit™ presentation at last year’s Lasso Developers Conference, and finally got me to take a look at the application.

Greg Willits also developed PageBlocks™, L-Revolver™, L-Migrator™, and L-Debug™ — which I speculate might satisfy my desire for more debugging capability within L-Unit™. It’s not my intent to write about any of these other offerings at this time. This posting is intended to reflect solely on L-Unit™ 2.0.

Do you have any experience with L-Unit™, past or present? Did I miss anything, or get something wrong? Make yourself heard in the comments.