Warning: This post isn’t meant to be an exhaustive exploration of Mylyn for ColdFusion developers; rather, it’s a quick dive into why I love it and would not want to work without it.

What is Mylyn

Mylyn is an Eclipse plugin that works with both ColdFusion Builder and CFEclipse.

From the Mylyn home page:

“Mylyn is a task-focused interface for Eclipse that reduces information overload and makes multi-tasking easy. It does this by making tasks a first class part of Eclipse, and integrating rich and offline editing for repositories such as Bugzilla, Trac, and JIRA. Once your tasks are integrated, Mylyn monitors your work activity to identify relevant information, and uses this task context to focus the user interface on the task-at-hand. This puts the information you need at your fingertips and improves productivity by reducing searching, scrolling, and navigation. By making task context explicit Mylyn also facilitates multitasking, planning, reusing past efforts, and sharing expertise.”

For me, this means:

• Noise reduction
• Easy context switching and context reconstitution
• Easy “context sharing”

All of this happens in the context of “tasks”. This might be a bug, a new feature, etc. It’s great when you can hook it into an issue tracker like Jira or Trac, but Mylyn can work just as well without a formal issue tracker.

Let’s look at what that actually means.

How Mylyn benefits me as a CFML developer

Part 1: Noise Reduction through “context”

My main Eclipse workspace contains dozens of projects. I keep all projects closed except active projects. Even with only a single open project, the workspace contains hundreds if not thousands of files. Here’s a screenshot of the Project Explorer with me working on an MXUnit issue, with just that project active in my workspace:

As I’m developing, I probably only care about a few files at a time. But the project explorer doesn’t help me keep “just those files” in view.

This is the first problem Mylyn solves: it helps you keep all the files you care about in sight and hides the rest.

Here’s what that same screen looks like when I create a task for what I’m working on:

Notice how the project explorer now contains just the files I want to see. This is the context of the issue I am working on. As I open more files, they get added to the context. If I want, files can drop off of the context as I close them. Removing files from the context manually is a keyboard shortcut away (ctrl-alt-shift-downarrow).

Part 2: Context Switching and Context Reconstitution

I have no proof of this, but I’d bet that most developers – at least developers in a corporate environment – work on more than one issue at any one time. Perhaps you’re developing a feature, and you get an emergency bug that just has to be fixed right this second or oh my God we’re all gonna die. Perhaps you’re fixing a bug in some system and as you’re doing so, you stumble on a bug in another system that you need to fix first because it’s blocking your ability to fix the immediate bug you’re working on. Regardless of details, this “multi-tasking” appears to be common.

But I don’t think brains work that way. Brains can’t spawn threads that think about 5 things at once. You can’t be fixing one bug while simultaneously fixing the bug that’s blocking you from your immediate bug fix. We have not acquired such higher consciousness yet.  So no… we don’t multi-task.

We context-switch. Very very fast, in some cases.

The inevitable problem with context switching is that as soon as you stop working on Thing 1, and move on to Thing 2, the process begins whereby you forget stuff about Thing 1. You forget what code you were working on. You forget what you were thinking. You forget what other files were associated. The mental bonds you had constructed around that Thing begin to decay.

When you return to working on Thing 1, loading all of that data back into memory takes time. This is why programmers are always complaining to managers about “Stop/Start Time”. It’s why, when a PM fails to fully spec a problem, and the developer ends up working on the same thing 5 different times till it’s done right, that developer gets grumpy.

Imagine, though, if moving from one issue to another, and back again, was a simple matter of a menu selection.

Imagine:

1. You’re working on Thing 1. You have 8 files associated with it. Your PM comes running down the hall, crying and blathering about how “The client is going to leave us right this very second if we don’t fix (insert dumbass unimportant thing here)!”.
2. She enters a bug for Thing 2: “If website font isn’t shrunken by .0003 Pixels, Client will Leave and we’ll all foreclose on our houses”.
3. You close all the files you’re working on, you open up the appropriate files for this new bug. You save the day and the houses of your colleagues
4. You close those files, hit a button, and presto, you’re back into your original bug… at the same file, perhaps even at the same mouse location.

That’s context switching. You’ve moved from Thing 1 to Thing 2. When finished with Thing 2, you moved back to Thing 1… right where you left off. You’ve reconstituted your original context.

This is the second problem mylyn solves: it helps you move from task to task and back again.

I recently wrote about how I do this context switching with my favorite Mylyn toolbar item, and I invite you to read that.

Part 3: Context Sharing

At work in particular, I often work on something and then sometime down the road, I need to work on something similar. If it hasn’t been too long, I’m likely to remember that thing I worked on. I’ll search Jira and find the issue number.  Wouldn’t it be nice if I could take that “context” (remember… for us, Context means basically  “a collection of files”) and copy it to my new Jira issue? With Mylyn, you can do that:

From the “task” editor for the original task, I go to the Context tab and click “Copy Context to…”. It pops up a task finder, I select or search for the new task, hit a button, and bam, done.

Now, I deactivate that old task, activate the new one, and this is what it looks like:

That’s right… just like the “source” task, except in a new task. My original task remains untouched, and anything I add or remove from this new one is unique to just this task.

This is the third problem mylyn solves: It literally takes seconds to transfer the “mindset” of a previous task to a new task.

Summary

As developers, we are expected to be more and more productive. By default, constant stop/start – constant context switching – is anathema to productivity. Mylyn helps mitigate the pains associated with this kind of chaotic working style, and that’s why it has become one of my most valued and loved tools.

Where I work, a kind of schizophrenia is the norm. It’s rare that I can work on any single Jira issue, from start to finish, without being pulled off of that issue and onto another. It’s also rare for me to have fully defined requirements backing any single issue, and so even when I think I’m finished, I usually need to revisit. What I’m trying to say is that there’s a whole lot of start/stop/resume. It’s not ideal, but it’s how we roll.

Prior to Mylyn, this was maddening. Mylyn, though, makes it easy to get into, out of, and back into issues at the point where I left off. In earlier versions (I’m thinking around the Eclipse 3.3 timeframe), Mylyn would contribute a toolbar item that made it braindead simple to navigate previous tasks. It is a little purple arrow which looks like this:

When you want to work on a previously worked-on issue, you simply hit the arrow, pick your previous issue from the list, and you’re back in the context of that issue. It is, no question, my most frequently used toolbar item.

Around the 3.4 timeframe, it went missing from a fresh Eclipse install. Here’s how to get it back:

1. Window – Customize Perspective
2. Select the “Command Groups Availability” tab
3. In the “Available Command Groups” pane, scroll down toward the bottom and find the “Task Navigation Extras” checkbox. Toggle it. Save your windows
4. Exult!

Here’s what the Command Groups tab should look like:

While you’re poking around the Command Groups, note that you can also deselect stuff that you don’t use, which can aid in noise reduction. Enjoy.

--marc

It doesn’t happen much that I think about HTML. In a weird convergence of events, though, I find myself reflecting on SELECT boxes, aka “dropdowns”. Specifically, how they are my own personal bane, and how application developers can redress the scourge they have put upon us.

This is my story.

Consider

This is a screenshot from Mint.com’s account setup screen, wherein you can enter your username, password, and answer security questions for the account which match the security questions from your bank. The typical workflow goes:

1. You answer your security questions at your bank’s website
2. You go to Mint, you set up the account (account numbers, usernames, blah blah), and you fill in the security questions
3. You hit a submit button, magic happens, and all your data gets pulled into Mint.
4. Glory ensues

Except: Step number 2 isn’t really step number 2. It’s like step 2 through 108. With the 106 steps being “read every $*%!ing option in the “security question” dropdown list 5 times, maybe 10, to try to find a match to the questions that you answered on your bank’s site. Oh: they’re not sorted; they’re not worded exactly; they’re in no way thematically related. It. takes. for. ever.

To wit, pain:

Notice the size of the thumb on that dropdown. Notice how the questions are ordered in no sensible manner. Imagine using this for real.

I dare you to guess how many choices there are in that one option list. Now multiply it by 3, because that’s how many questions you have. By the way, Intuit now owns Mint.

And you thought that was bad

You will not be able to read the content of this image. You will, however, see that it is an HTML dropdown, based on the fact that there is a scrollbar on the right side. The thumb is a few millimeters tall, indicating that the list is very long.

This is part of a time-keeping application that folk in my company must use. This dropdown contains a list of projects. You go to this screen, you pick your project, you pick options from other dropdown lists, you enter how many minutes you worked on that application for the day. Repeat as needed.

Now, I figure that most developers work on at most 5 projects at any one time. Do you know how many projects are in the list in this screenshot? Can you guess? Now, in your head, do the math… 

5 / NumAvailableProjects = % of shit that is relevant

or something like that. It doesn’t matter. Math doesn’t matter. The size of that thumb in the dropdown is all that matters.

Your job as a user

Your job as a user of an HTML select is to pick an option from a list. Usually, you know exactly what you want. Or damn close. Probably you use this application every day. That means when you’re picking options from your Project list, you know 90% of the characters in the text string that makes up the OPTION. You’re not poking around, thinking “hmmmm, I wonder what options are available to me”. Most option lists you encounter aren’t a whimsical stroll through unknown possibilities (like, for example, “Which shipping method would you like?”).

Most of the dropdowns in your life contain XX% noise, and 1 thing you want. But you gotta get through the XX%, every single time.

When I was 15, I took a job as a meat room cleanup kid. I learned how to use a knife, how to clean a block, how to “bone meat”. Eventually, during college, I worked as a meat cutter. I “worked racks”, which meant taking racks of meat from the cooler to the case and back again. Meat rooms are designed for efficiency of meat movement. If it were still alive, a Delmonico could wheel itself from cooler to case… that’s how well most meat rooms are designed.

Imagine putting a 3-foot curb between the cooler to the meat room, then from the meat room to the supermarket floor. How, tell me, could you wheel that meat cart over a 3-foot curb?  HTML dropdowns like the one above do the same kind of disservice to a user: they significantly impede progress. If you’re a manager-type, you won’t understand anything I’ve written here, so let me put it into Manager-ese: It “has a negative effect on productivity”.

By the way, that dropdown is courtesy of QuickBase, a wondrous, extensible, powerful, enterprise-y application. Sadly, I know nothing of its wonder. All I know is that I have to pick a single project from that enormous dropdown list and I hate the application for it. By the way, QuickBase is an Intuit application.

You need to know

Take off your user hat, and put on your developer hat: You need to know that as the application developer, all those fancy things you do to get your enterprisey app to meet all the needs of all your big-dollar customers – to make your app behave as a JeeJaw for Customer1 and a Fahoozle for Customer2 AND a timekeeping application for Me – all the magic you have to work doesn’t mean a damn thing to people like me. What matters to me is the dropdown. I don’t want to marvel at your skill. I want to fill out my timesheet and do my real job. But I can’t do that quickly because I have to pick one option from a 523-and-growing list of projects.

I know, I know. “But that’s not how we designed it!”

Whatever. You wrote it. You own the Problem. Only you can fix it.

How to fix it

The current SELECT element in html is broken. Even 15 years ago, people knew it sucked. Every time you have to choose a date from an old-school date picker (month, day, year), you’re suffering from the failures of the HTML fathers to predict the grievous abuses that website developers would inflict. Every time you fill out your credit card details in an order form and have to scroll through an interminable list of expiration dates, you pay for their mistake. Perhaps you have some authority in your projects to suggest a correction.

I started with what is, frankly, the only awful part of the Mint.com experience. I’m going to end with the part of the application I interact with most frequently and which I consider the current best model for what SELECT lists should become. In other words, If I were in charge of the HTML spec, dropdown lists would have this functionality built in.

I’m making this image big b/c I want you to see it right away. Notice how the dropdown list itself is a type-in box. It is built for filtering. It’s built for action. Your job as account maintainer is to look at a line item and assign it to a category if Mint.com got it wrong. You know exactly what it needs to be. Or close enough. You know it’s a “coffee”. You know it’s “gas” for your car. You know it’s a tax of some sort. Mint’s category dropdown perfectly addresses this need. You start typing in the type-in box, and it filters down to whatever options might match what you’re searching for. You could have 300 categories and subcategories configured, or you could have 1000. It does not matter.

This is what that same dropdown looks like as soon as I start  typing the name of the category I want to put the expense in:

I do not need to know exactly how the category starts, either. This is critical: good searching lets you, the user, be “close enough”. For example, if I wanted to categorize something as “auto insurance”, but didn’t remember if the category was “car insurance or “auto insurance”, I’d just start typing “Insurance”. With a few characters of typing, it narrows down to the available options, and I can easily see that “Auto Insurance” is what I want. I arrow to the choice I want, hit “enter”, and I’m done.

The central concept is:

You know what you’re looking for

The standard HTML Select list is built around: “WE have no idea what you’re looking for. You choose”.

Let me break this down for you

Good

“You know”

Bad

“We don’t know”

As a developer, you should…

Find ways to anticipate odious dropdowns in your applications. When you find them, consider a Mint.com style dropdown.

If you have good suggestions for canned/pre-built/jquery plugin/whatever examples of this, please share them with the rest of us.

Until you do so, realize that every dropdown that is populated by  a database query or some other external, non-hard-coded datasource has the potential to grow. Do not kid yourself thinking “it’ll only ever be a few elements”. It won’t. The thumb will get smaller and smaller, and some user will start to complain. And you know what:

They’re right.

I’ve been using ColdFusion builder extensively at work recently. It is beta software, so my intentions for using it are at least in part to help ferret out bugs so that when it launches, it’s a stable product that we can all trust. Currently, it’s not quite there yet, and so I want to show you a quick and easy tip for helping the CFBuilder team diagnose problems related to stability. This is in the spirit of “every little bit helps”.

I have posted this bug, which contains a description of what I experience every time CFBuilder freezes/hangs. In addition, I attached a java Stack Trace to the bug, hoping to give the CFB team some insight into what Eclipse is doing at the time of the freeze. I think that seeing the stack trace is about as close as we can get to showing what’s happening under the hood when CFB freezes.

This assumes you have a recent JDK installed and on your path. You’ll know you’re good if you can open a cmd and type “java –version” and get information. If you can do that, proceed. If not, download a JDK, install it, and continue.

To get a stack trace, you need to know one thing: the process ID of the javaw.exe process for CFBuilder. In Windows, this is as simple as opening up Task Manager (ctrl-alt-escape), finding javaw.exe, and noting the value in the “PID” Column. If you don’t have that, you can get it by choosing “View – Select Columns” and toggling the “PID” checkbox. It looks like this:

Now then, to get the stack trace into a file, open a cmd and type

jstack <pid> > CFBuilderStackTrace.txt

This will pipe the output of the jstack command into that file. From there, you can copy the stack. Feel Free to add it as a comment to this bug.

--marc

OK, OK, I know. I normally don’t truck with such dramatics, but the two topics I want to talk about merit it.

I’m talking, of course, about the two topics I submitted this year to CFUnited 2010. I’m asking for the chance to earn your vote. If you want to skip my stump speech, simply

Go here and Vote

You click that link, you search for “Esher”, you click the checkbox beside it, and you fill out a little more info and submit the form. I cannot emphasize enough how much good you will be doing for this world of ours (if you don’t, the terrorists have won. Do you want that on your conscience? Didn’t think so). Vote for change you can believe in!

My Pitch

Session #1: Debugging like a Rock Star

Last year at CFUnited, I presented on “Automating like a Rock Star”, wherein I spoke on batch processing, keyboard launchers, ANT, and JMeter. I covered a wide range of subjects, all with an eye towards helping make your development life less monotonous and more enjoyable.

This year, I’d like to present with that same goal in mind: helping bring more joy to your day job. I know: there sometimes is nothing more joy-less than debugging. I don’t pretend to have magic pixie dust that you can sprinkle on your apps to make all your nightmares vanish. But I do have a bunch of strategies that have served me well. We’ll cover the most basic CF debugging – how to read a stack trace / tagcontext, how to trace through an object graph, etc – and move on to tricks for what is potentially the hardest debugging: when your app manifests bugs in production that didn’t appear during development.

Rock Stars don’t fill arenas by growing long hair and putting on makeup and pursing their lips (except Poison, but they rocked, so…). Rather, they work hard, practice till their fingers  and noses bleed, and out-persist lesser musicians. This session aims to demonstrate how to out-persist your bugs.

Session #2: End-to-end Testing Roundtable

How many sessions have you been to at a conference where you sat in a chair, a dude like me walked up on stage, said who he is, and rattled on for 50 minutes?

The End-to-End testing roundtable is NOT that session.

This session will be “facilitated” by some of my best friends in the community. We have no idea whether this will work. It could be the most boring hour or two of your life. But man… it could be awesome! What we hope for is that we can harness the collective experience in the room to discuss wins, failures, challenges, ah-ha’s, and other manner of discoveries related to application testing. We’ll talk a little bit about the different kinds of testing (unit, integration, the blurry lines), and from there, it’s all about engaging the audience.

We have no slidedeck backup. We have no prepared demos. All we have is a hope that we can attract a room of people who want to teach and learn.

If this sounds interesting to you, we simply say, “Come”.

Sessions you can believe in

Look: if you have worked with people, or are one of those people, who struggle constantly with effective, productive debugging, then I’m asking  you to check the checkbox for Debugging like a Rock Star.

If you want to take part in – or at least give others this opportunity to participate in – a one-of-a-kind session on application testing, then please check the checkbox for the End to end testing roundtable.

Go here and Vote

Thank you. And God Bless America.