detecting that you're in an IFrame

9 April, 2009 //
2

I hit a JavaScript issue recently that stumped me. I’m trying to detect if the code I’m running is in an IFrame or not. It seems like the safest way to determine this would be the following comparison:

if(window !== top) {
   var mode = "frame";
}

‘window’ of course is the global object in which your code is running. If you’re running in a frame, your window object is actually a child in a window hierarchy. ‘top’ refers the to the top-most window in the hierarchy. Therefore if window and top are the same, then you are in a top level page; conversely if they are different, then you are in a frame (or iframe).

This works great on Firefox but on IE, the window !== top expression never evaluates to true. That is, even if you’re the top window, ‘top’ and ‘window’ aren’t considered equal. I’m not sure why this is. My current fallback code is this:

try {
    if (top.location.href !== window.location.href) {
        var mode = "frame";
    }
} catch (e) {    
    // if you're in an iframe in a different domain, the top.location check
    // results in a security exception
    mode = "frame";
}

This code has two problems:

  1. There’s a small possibility that you could have the a frame with the same URL as the outer page. This is very unlikely because there’s no scenario I know of where you want to nest a page, but it’s still a latent bug.
  2. You have to deal with the exception in the cross domain case. Not a big deal but unclean.

I’m curious if anyone has a better solution for detecting whether or not you’re in an IFrame.

Categories ajax

frameworks and building blocks

10 October, 2008 //
9

Between early 2006 and early this year, my team at IBM Rational and I built a framework for component-based Ajax development for use in the Rational Jazz platform. The framework’s capabilities aren’t the focus of this entry, so I’ll just list some of them briefly:

  • A nice component model based on OSGi bundles and the Dojo module system
  • Request-time “building” of many fine-grained JavaScript files into monolithic files for faster download based on the introspected relationships between the files – i.e. no developer effort required for fast code loading other than writing good application code
  • Making a subset of the Eclipse extension registry available in the web page and queryable via JavaScript APIs modeled off of the org.eclipse.core.runtime extension registry Java APIs, allowing for open-ended extensibility using the Eclipse extensibility model
  • A simple framework for demarcating UI states that made the back button, history, and page titles work seamlessly within the Ajax page, even when a user gesture resulted in crossing a component boundary (e.g. loading and displaying a new virtual “page” from a different component) [1]
  • Dynamic, transparent loading of missing code in response to a user gesture that required it

We did a fairly good job of keeping our Ajax framework decoupled from the rest of the Jazz Platform both for the purpose of design cohesiveness but also to allow for possible future use by teams who weren’t building full-blown application lifecycle management applications like Jazz SCM or Iteration Planning.

Over time, other IBM teams heard about some of our capabilities and saw the positive results in our Rational Team Concert web UIs [2] and contacted us to explore whether they could make use of our code in their products. Each conversation went like this:

  1. We gave a demo and talk about the capabilities and architecture of the framework
  2. The other team said “that’s really nice, that’s really useful, that would be great to have”
  3. The other team said “we’re not sure we want to live within your framework, we’ll get back to you”
  4. The other team didn’t get back to us

Initially this didn’t really bother me – after all my job was to deliver the foundation for our Jazz web user interfaces, not to create a general purpose Ajax framework for IBM, but as I’ve thought about it more over time and seen this anti-pattern from other teams and other frameworks, I’ve decided that we should make a conscious effort to make our useful functionality available as simple building blocks (in the form of libraries) and then provide frameworks that layer on top of these building blocks.

Let me take a step back and explain what I mean.

A library is a set of reusable functionality where your application uses parts of the library as necessary. For instance, most programming languages have a library for creating and manipulating dates. Frameworks also provide functionality to the application programmer, but instead of the application programmer making simple function calls, the framework runs the show and calls into the application at well defined hook points. For example, GUI frameworks provide ways to wire up code to run in response to users clicking on buttons.

Both the library and the framework provide useful functionality intended to make the application developer more productive. Though it’s dangerous to make a general statement, it feels to me that the big difference between the two is that frameworks generally provide more power, but require you to make a bigger commitment to the framework’s way of working, while libraries provide generally less power, but make few (if any) demands about how you structure your application.

What’s unfortunate is when you’ve got some useful bit of functionality that could be made available as a simple library but it’s only available in the context of a framework. This is where we were with our Ajax framework. This stuff is too abstract, so here’s an analogy: Imagine that you heard about a new refrigerator which provided every feature and characteristic you ever dreamed about having in a refrigerator. The catch however was that you couldn’t just buy the refrigerator – you had to move into a house on the other side of town that included the new refrigerator. After about 10 seconds of thought you realize that even though it’s the fridge of your dreams, you’re sure as hell not going to move into a new house across town in order to get it. This situation (switching back to software from refrigerators) is shown in the diagram below.

Useful building blocks locked inside a framework

Useful building blocks locked inside a framework

My recent realization (which seems obvious in hindsight) is that the useful functionality provided by frameworks and libraries need not be mutually exclusive. For instance, in our Ajax framework’s dynamic build system, rather than requiring applications to run within our framework to enjoy this capability, we could have created a simple callable library to perform dynamic optimization on a set of files, and then created a framework that simply used this same library. This approach is shown in the diagram below:

Useful building blocks used by a framework but also available independently of the framework

Useful building blocks used by a framework but also available independently of the framework

Over the past month or so we’ve been refactoring our Ajax framework to extract the useful building blocks into simple callable libraries and making the framework proper smaller by delegating to these libraries. We’ve done this in the hopes that our code will be useful to other IBM teams but as a result of the exercise, we’ve gained a deeper knowledge of our software and the software’s quality has improved as we’ve decoupled the framework aspects from the building blocks aspects.

Going forward, it’s my intention that our team will generally start with building blocks first and then consider if we should provide some higher-level framework that uses these building blocks. I only wish we had taken this approach from the beginning but you know, live and learn.

Footnotes

  1. This UI state management framework evolved into dojo.hash
  2. You can see our Jazz web UIs built on top of this framework in the development section of Jazz.net if you register.

Updates

Changed “other than writing good code” to “other than writing good application code”

Tags
Categories ajax, design, jazz

the awkward url-uri terminology dance

9 July, 2008 //
4

As my dear colleagues Simon Johnston and James Branigan have mentioned in various blog posts, on the Jazz project that I work on, we’ve (finally) fallen in love with the web/REST story. Because of this, we spend a lot of time in technical conversations using the standard REST alphabet soup vocabulary you’d expect – HTTP, XML, JSON, REST, URL, URI, etc.

One funny thing I’ve noticed is that there’s a certain conversational dance that goes on when the topic of URLs/URIs come up. For 99.9% of the web developers out there the distinction between “URL” and “URI” doesn’t matter, as the Wikipedia entry on URL points out:

In popular usage and many technical documents, [URL] is a synonym for Uniform Resource Identifier (URI).

However, some people who are a bit more pedantic than others care about the distinction (not me!) and tend to use “URI” in favor of “URL” when talking about REST stuff. People who are a bit new to the REST stuff on the other hand tend to use “URL”, since this term’s a bit older and a bit better known.

I’ve observed that when a REST newbie talks with one of the REST pedants, the newbie says “URL” while the REST dude uses “URI”. But as the conversation continues the REST n00b eventually uses “URI” – essentially deferring to and adopting the more knowledgeable person’s terminology.

I’ve also observed that when I talk with one of our REST dudes, if I continuously say “URL” (usually out of spite – I’m KIDDING!), they usually eventually start saying “URL”, I think just to bring more harmony to the conversation and because they realize that the distinction isn’t that important – probably simple mirroring at play.

I think in a future experiment, I will use the opposite term of whatever the other person (newbie or pedant) uses and as soon as they adopt my terminology I’ll switch back to the other term, and see what happens.

Should be fun.

Tags , , ,
Categories Uncategorized

from Windows to Ubuntu

29 June, 2008 //
3

Well, as we mentioned over on the Jazz Team Blog, my Jazz teammates and I just shipped Rational Team Concert 1.0, the first GA product built on the Jazz Platform. More on that later.

Since I’ve been working on what became Rational Team Concert for the last three years, I’ve gotten into quite a groove with regards to the technologies that I use and how I use them. But there were a couple of things I didn’t like and I promised myself that I’d fix them once we shipped and I could spare a few days of being less than 100%.

Chief among these “things I’d like to change when I have the time” was my use of Windows XP as my operating system. For quite a while I was happy to use WinXP – mainly because I knew how to use it and IBM’s internal set of applications are optimized for Windows XP users. And when I say “optimized” here I mean in the sense of lack of barriers – available, tested, and supported.

But after the past couple of years as I got more into web development, I started to experience some pain as a WinXP user because it seems like most of the interesting web technologies are optimized for Linux or Mac users, and for Windows users there’s usually a short appendix in the doc that says “If you are unfortunate enough to use Windows, the following has been said to work…”

So the day after we declared bit freeze on Team Concert, I downloaded a Ubuntu ISO CD image, burned that, backed up my data, then formatted my hard drive and installed Linux.

The remainder of this entry I’ll write in Steve O’Grady Q&A format so I don’t have to think in full paragraphs 🙂

Q: How did the installation go?
A: It was truly easy. Just insert the CD, restart my Thinkpad, and let the Ubuntu installer do its thing. The last time I tried to install Linux was probably about 5 years ago and I remember it asking me all kinds of questions for which I didn’t know the answer. I don’t even recall Ubuntu asking me any questions, and if they did they must have been trivial because I don’t remember them.

Q: What was your first impression of the user experience?
A: I was really impressed. After installing just rebooted, logged in, and I was in a windowing system which was very easy to understand. The top panel has three simple, logical menus (Applications, Places, System), shortcuts to key programs, then the right side of the top menu has iconographic shortcuts to some important system applications (networking, sound, date time, system control). The bottom panel just lists the open programs and has some other miscellaneous controls related to desktop management (minimize all windows, switch between desktop, etc.)

My biggest takeaway on the window manager user experience is that it seems like they’ve taken care to strip out as much low-value cruft and redundancy as possible, so that you’re left with a small set of orthogonal, useful controls.

Q: Any problems?
A: There were two sets of problems: 1) Finding and learning the Linux equivalent for simple Windows programs like Notepad and Paint. 2) Getting IBM stuff to work that was mainly developed and tested for Windows and/or Internet Explorer web browser. To get over these humps I bought a license for VMWare and spent much of my first week within a Windows XP virtual machine. Luckily VMWare’s networking worked much better than I remember it working, so between VMWare and the Windows XP image with VPN and Lotus Notes, I could get basic things done like work email from home.

Luckily my Jazz colleague Matt Lavin has been using Ubuntu for over a year, so he was able to help me learn how to do some basic but important things like connect my system to the internal Debian package server.

I’m still having problems using Open Office vs. Microsoft Office. When I modified a Powerpoint file in Open Office, it ended up getting mangled back in Powerpoint. I’m not sure who’s fault it was, but it sure was frustrating. I may look into running emulated MS Office on Linux.

Q: Why Linux instead of a Mac?
A: Because I already have an iMac that I use a lot at home and also I have a very nice laptop from work (Thinkpad T60p) so I didn’t see the point of junking it and spending $3,000 for a new PowerBook.

Update: Added an additional question and answer below

Q: IBM provides a standard Linux distribution (Client for eBusiness, or C4eB) based on Redhat Linux. Why did you instead use a custom Ubuntu install?
A: Several reasons:

  1. I didn’t know such a distribution existed. Though I had been meaning to switch to Linux for quite a while, I never seriously researched it, and the final decision to switch and the actual switch happened over the course of about 3 hours on a random Saturday afternoon. As mentioned before, it was incredibly easy to find, get, and install the latest Ubuntu.
  2. I was influenced by some friends and colleagues in the development community (particularly the web development community) who strongly recommended Ubuntu.
  3. One of my goals is to learn more about Linux, so I don’t mind some of the pain of making things work.
  4. Even if I had known about it, I probably wouldn’t have used it, because in my experience, internal IBM standard distributions install way more software than I actually need, which is understandable since they need to provide a generally useful package for lots of people. I’d rather just install the stuff I need for development and then non-optional “I work at IBM” software such as Notes and the AT&T Network Client.
Tags ,
Categories personal

RIA weekly podcast and errata

18 February, 2008 //
1

Last Friday I did an RIA weekly podcast (mp3) with Michael Coté of Redmonk and Ryan Stewart of Adobe. This was a fun and interesting experience. Fun because I like Coté and Ryan a great deal and enjoy talking to them and interesting because of the subject matter and also because it was the first podcast I’ve ever done.

There were a few things I said in the podcast for which I’d like to provide a bit of extra context, because it’s difficult in the podcast format to provide a great deal of context.

Network Transparency and Latency

At one point in the podcast, I talk about Jazz‘s early RPC-style web services and say something along the lines of “This is great for the Java client developers because they essentially get network transparency, which is awesome except for the latency.” This is sort of like saying “Not paying income tax is great, except for the eventual fines and imprisonment.” RPC-style interfaces that strive to provide network transparency have the unusual problem that they make remote connectivity too easy for developers. The result, which is almost a cliché, is that developers design applications which are way too chatty and which work fine on local area networks (the environment in which they are developed) but fall apart in wide area networks (the environments in which they are deployed). Later, in the clichéd scenario, the developers learn about explicitly designing the “stuff” that travels over the wire to provide a good balance between the needs of the application and the realities of the network.

Sometimes you just shouldn’t make things too easy. Like you shouldn’t put the car’s ejector seat button where the toddlers can reach it 🙂

Why We Didn’t Consider Flash as the Basis for the Jazz Web UI Infrastructure

At another point, Ryan asked me if we ever considered Flash and I said something along the lines of “Well we didn’t select Flash because it wasn’t as ubiquitous as the standalone browser” but after saying this I remember Pat Mueller telling me recently that Flash is the most widely deployed web client technology when you compare it against particular browsers (i.e. browsers in general are more widely deployed than Flash, but Flash is more widely deployed than any particular browser like Internet Explorer or Firefox). So though my memory is a little fuzzy, I believe the reason was that just as a general principle, we didn’t want any core Web UI application functionality depedning on a particular plug-in; for instance, the user shouldn’t require Flash to create a bug report. Another factor was that this was early 2006 so Flash was probably not as ubiquitous as it is today. Yet another factor was our later principle that “look like a normal web page” and some examples of Flash violate this (i.e. the big box of Flash in the middle of the page, or overly ambitious site welcome screens). But I have to say, my thoughts on Flash have really changed over the past two years, because I’ve seen some incredibly useful, subtle applications of it. I can’t think of a particular example, but I know a couple of times some page on Amazon.com had a really cool little visual effect and sure enough when I right-clicked it turned out to be a little Flash app seamlessly embedded in the page. So using Flash in tactical ways where it can provide a powerful but non-jarring user experience is something I would like to explore in the future.

Meeting with the WebSphere Application Server Folks

At one point early in the interview Coté mentions that we hung out and got drinks in Austin one night and I mentioned that I was down for a meeting with some WebSphere Application Server folks and it was also a good opportunity to meet with Coté which is why I accepted the meeting. Listening to the podcast, I feel bad about how this came out because in reality the WebSphere App Server folks were doing us a favor by taking a day off to review the security architecture of Jazz.net and indeed they pointed out both important security and scalability issues. The missing context is that I hate work travel (I repeat hate) because I have two toddlers and they just grow too much and we miss each other too much when I travel without them. So the only time I travel for work is if I really need to be there in person (like if I’m speaking at a conference) or if I can accomplish more than one goal with a single trip. If not for the chance to both do the Jazz.net review and meet Coté, who in my opinion (don’t blush Coté) is both a cool guy and important industry analyst, I would have probably called in.

Innovation vs. Standardization

At another point in the podcast, I mention a blog post by Alex Russell of Dojo where he talks about standards not saving us and encourages browser vendors to provide non-standard innovative features. I think in the podcast I may have come across as “standards don’t matter”. In fact I think standardization is important to build the applications of today but agree with Alex and that the future won’t be invented by standards bodies.

Finally…

Otherwise I agree with everything I said 🙂

Categories ajax, design, meta

Jazz Team Blog

17 January, 2008 //
0

On Monday there were two notable changes at the Jazz.net web site I manage:

  • We opened up registration to everyone (previously it had only been to Rational customers and business partners)
  • We made the Jazz Team Blog public

I wrote the first entry on the Jazz team blog, and it outlines the sorts of things we’re going to write about over there.

Also, I created a video that provides a tour of Jazz.net in case you’re ambivalent about registering but curious about what’s behind the curtain.

Finally, I’m guessing that I’ll probably write many, if not most, of my work-related blog entries (Jazz, Ajax, etc.) over on the Jazz Team Blog, so you may want to subscribe to that if you’re into my writing on those topics. I’m currently working on an entry over there that explains how some of the early lessons learned developing the Jazz Web UI technology led to my UI design opinions that I captured in my “Uncanny Valley of UI design” post.

Categories jazz

measures of progress

2 January, 2008 //
1

I had an insight a few weeks ago that I thought was worth sharing. First some context.

On the Jazz project, one of my jobs is leading the software development for our platform-level web UI stuff [1]. Erich Gamma is the overall Jazz technology lead. Twice a month we have a sync up meeting where we discuss platform-level web UI progress.

In our last chat in mid-December, one of the things we chatted about was the status of the Jazz Server’s Admin Web UI. We began bootstrapping the Admin Web UI in September and I thought we’d made good progress in such a short amount of time. Erich didn’t seem so impressed with what he saw. I was a bit frustrated by this because I thought Erich was being unreasonable – we’d made good progress for the short amount of time we’d been working on it. But after a few more minutes of chatting, I realized that there was simply a mismatch in what we were evaluating. I was evaluating the state of the Admin Web UI vs. the resources (time and people) we’d had to work on it; Erich was evaluating the state of the Admin Web UI vs. his vision of what an awesome Admin Web UI should look like. Put more tersely, I was measuring “current vs. previous” while Erich was measuring “current vs. ideal”.

I found this difference in approach fascinating and insightful. I’m a very methodical person; when someone gives me a job I very methodically list its goals and measures of success, then I work backwards given the time and people I have to reach the goals and then over the course of weeks or month work towards the goals. But during my conversation with Erich I realized that a risk of my methodical approach is that I can become too bogged-down on the blocking and tackling of day-to-day software development and become overly focused on incremental progress and lose sight of the big vision of what you’re trying to build. I found that when I adopted Erich’s point of view and thought about the current state of the Admin Web UI vs. what it could become in the very long-term, I became very dissatisfied with its current state and highly motivated to be more ambitious with the next iteration plan.

It’s ironic because most of the iterative software development literature talks about the converse problem – you’re too focused on the big picture that you don’t make day-to-day progress. Indeed it’s become a cliché over the past several years to make fun of architects who are too far removed from day-to-day coding, testing, and building.

So the insight I gained was that I need to think in terms of both “current vs. previous” and “current vs. ideal”. Fortunately our iterative development process supports finding this balance. At the beginning of iterations it’s fine to dream big dreams about what you’re trying to achieve but then to become very pragmatic about how to make incremental progress towards realizing those dreams in the course of a four week iteration. Then over the four weeks you can be extremely methodical about making progress. Then at the end of the iteration you can reflect on what you’ve accomplished and feel some short satisfaction that the software is significantly better now than it was four weeks ago. Then you can reflect that the software’s not nearly as good as you ideally want it to be which provides the motivation to start the cycle again.

[1] By “platform-level” I simply mean more of the infrastructure. That is, frameworks and APIs rather than tangible applications.

Categories culture, design

job news

28 October, 2007 //
0

As I mentioned on Twitter, as of this week I’ve got a new job of managing the Jazz.net community site. I’ll continue to lead the development on the framework-y pieces of the Jazz Platform web UI stack.

This is going to be a fun job since we’re trying something relatively new with the Jazz Project that we’re calling “Open Commercial Development“. On traditional commercial software projects, there’s a pretty high wall between the development team and everyone else. With the Jazz Platform and the products we’re building on top of it, we want to create a much higher bandwidth channel between the development team and people who use Jazz-based tools and people who build their own tools on top of the Jazz Platform.

So my job is to make it easier for the development team, users, and extenders to collaborate. This of course means good docs and good tools for collaboration, but more than anything, it means getting to know more folks who are interested in learning more about Jazz technology and influencing its direction.

So if you have questions or concerns about Jazz.net, feel free to drop me a line. My work email address is bhiggins@us.ibm.com and my cell phone number is 919-564-6862. Please don’t be shy 🙂

Categories jazz

if you're using Jazz, what other development tools do you need?

8 September, 2007 //
1

Update: Changed title; original one sounded too presumptuous (was “what development tools do you need besides Jazz?”)

Aaron Cohen of Rational asked an interesting question in the Jazz.net forum the other day. I’ve reprinted his question and my answer here verbatim, with permission from Aaron and the Jazz Project.

Question (Cohen):

Right now Jazz.net uses Wikis and newsgroups to supplement Jazz. If a team is deploying Jazz. What type of Wiki or other collaborative software should we use with Jazz?

Answer (Higgins):

Aaron, it really depends on the needs of your team. With Jazz, our goal is not to reinvent every known software and/or collaboration tool as a Jazz component. Basically we look for opportunities where deep integration with other Jazz components could produce a much more productive experience.

Just implementing a Wiki on top of the Jazz repository is not interesting; the world doesn’t need another Wiki implementation. But it is interesting to observe how we tend to use our own Wiki and then explore how we could provide new functionality in Jazz to replace Wikis for these needs. For example, every Jazz component lead used to create an iteration plan page in the Wiki. Observing this, the Agile Planning team provided an “Overview” page for each iteration plan, where a team can write semi-structured markup as well as linking forward to important work items. Now most component leads don’t feel the need to create a separate plan overview in the Wiki.

In the case of newsgroups, we needed a lightweight way to make announcements to a subset of the project, and newsgroups have been doing this for years so we used newsgroups. This continues to work really well, so… I don’t know why we’d ever change it.

But getting back to your question, I’d rephrase it as “What non-Jazz tools do I find my team using to support our software development?” And if you notice yourself using some non-Jazz tools for large chunks of your development, it’s worth asking “Could a Jazz-based component provide a richer, more productive, more integrated experience?” If the answer to the second question is “Yes”, then we encourage you to consider either building your own Jazz component to fulfill the need or to raise enhancement requests against us.

Thanks for your question and I hope this helps.

Categories jazz

upcoming Beijing talks

23 August, 2007 //
1

I’ll be in Beijing, China next week giving a couple of talks on the Jazz Platform and Rational Team Concert:

Rational Team Concert: Agile Team Development with Jazz

Inside the Jazz Technology Platform

  • When? Friday, 31 Aug 2007 (10AM – Noon, local time)
  • Where? IBM China Research Lab, Beijing
  • What? A technology-focused presentation on the Jazz Platform architecture and how to extend the Jazz Platform with custom components (charts courtesy of Scott Rich and Kai Maetzel)
Categories jazz
« Older Entries
Newer Entries »