The EclipseCon programme selection process is an open and transparent process. It is. Really. It says so on the website:

The selection is done in an open and transparent way using the Eclipse open source project rules. Specifically, all submission is done through a modified Bugzilla system (hereafter known as Eclipsezilla). Anyone in the community (including you) is welcome to review the submissions, ask for more information, provide comments and critiques - just as anyone in community is invited and encouraged to do for Eclipse bugs and features.

As a member of the Technology PMC, it’s my job—along with the rest of the PMC—to select the talks, panels, etc. that will be presented in the "Technology and Scripting" track. In theory, the "open and transparent" part means that we use the input provided by the community in our selection process. I say "in theory" because community input has been scant (at least in the technology track). Without community input, we have to pick the talks that we believe are most appropriate for the conference.

So this is a call for help. We need your input. Proposals are entered in a bugzilla instance (EclipseZilla). Existing "Technology and Scripting" panel and short talk proposals are here. Please add your comments and votes. To be totally frank, your comments are far more valuable to us. Even just +1/-1 comments. Also, feel free to make recommendations for changes to talks if you think it’s appropriate. It’s getting a little late for panels, but it’s a good time to get involved with the short talks (there’s a few entered already).

Of course, there’s other tracks that will benefit from your input as well…

Short talk proposals are due January 15th. If you’re thinking about submitting a proposal, time’s getting short…

Since Ian brought it up…

---

Hey, I’m not a salesman, or a consultant…
I’m not egotistical, or vain, or arrogant…
and I don’t know Jimmy, Sally or Suzy from HP,
although I’m certain they’re really really nice.

I have an Executive Director, not a CEO.
I can develop using PHP, Ruby, and C/C++, not just Java
And I can do it all in a task-oriented way using Mylar

I can proudly sew the Eclipse logo on my backpack.
I believe in building solid APIs, and exemplary products,
diversity, not assimilation,
and that the you can build pretty much anything using EMF.
Equinox is a component framework, Higgins does security,
and it is written as ‘plug-in’ not ‘plugin’, ‘plug-in’ !!!!

Eclipse has the largest user base!
The first and best extensible platform!
and the best Java IDE in existence

My name is Wayne!!
And I am Eclipse!!!

Today is the last day to get your talks in for Eclipse Forum Europe. Do it. Do it now.

If you haven’t had your fill of Mylar yet (I know I haven’t), check out this interview with Mylar Project Lead, Mik Kersten.

Mylar facilitates communication with other team members through the task repository. There’s a handy “Attach context” feature that appears on the task editor that lets you package up your task context and attach it to the task (bug) in the repository. The task context contains the information about the elements that are made visible in your workspace views. In essence, by attaching your context, you are allowing other developers to share the trimmed list of elements that you were working with at the time you saved the context. Other developers who might also be interested in the task can retrieve it by selecting “Retrieve Context” from the pop-up menu for the task.

Personally, I think that facilitating communication between developers is great all by itself and a worthy place to end my “five reasons”. However, since I started this series, I’ve developed another great reason to love Mylar: it has a really slick look and feel, and it integrates very naturally with the workbench (okay, that’s two other great reasons). Mylar just plain old looks good. And it behaves in a predictable way. The creators of Mylar have taken the “less is more” mantra to heart and have refined the user interface to be intuitive and powerful, but without excessive complexity.

I love the pop-ups that appear unobtrusively in the bottom right hand corner of the screen to let you know that changes have been made to tasks you have included on your task list (that is, when another developer makes a change in bugzilla, Mylar tells you about it). Mylar also marks the task on the task list. I also really like the hover help tips Mylar provides (including fancy graphics).

Mylar is a powerful tool with a refined look and intuitive user interface.

Mylar hooks to external task repositories. The Mylar download site offers support for integrating with Bugzilla, JIRA, and Trac. There is a long talk proposal for EclipseCon that intends to discuss (among other topics) integration with XPlanner. I’ve been using the Bugzilla integration to triage Eclipse Corner Article submissions and Phoenix bugs. I’ve just started using the JIRA integration to keep tabs on the Apache Harmony bugs.

Adding entries to the task list is a matter of building a query on a repository. The query pulls the matching tasks (bugs) into the workspace where they can be manipulated (offline manipulation is supported). Creating repository queries is very easy using first class tools that resemble the corresponding web user interfaces (but feel far more elegant in the case of Bugzilla). I find the JIRA web interface a little clumbsy (likely due to my inexperience with it), but the query wizards provided for Mylar are intuitive and easy to use.

I like the permanent nature of the tasks. They’re loaded into your workspace and they’re updated on a regular (configurable) interval. Tasks that change are marked in the task list, making them really easy to spot. Mylar lets you attach additional information to the tasks, including such things as schedule information (when are you going to work on task), how long you estimate the task will take to complete, how much of the task is complete, and more. It also keeps track of how long the task is active (on a side note, it might be cool to build a BIRT report that details some of the statistics).

I’ve done a little digging and I’m quite sure that it’d be easy to create a mapping to a custom database table or web service for storing regular (i.e. non-bug) tasks. I’ve been toying with the idea of sorting out how to create integration with Outlook (or possibly an Open-Xchange server)…

Mylar remembers what you were doing when you switch between tasks. This is pretty closely related to my second reason, but I think it deserves it’s own special spot.

Not only does Mylar keep track of what you’re doing, it keeps track of it on a task-by-task basis. Here, for example, is what my Eclipse workspace looks like when I’m working on a bug for an Eclipse Corner article (bug 138600).

This bug’s going to be open for a while, so it’s handy that Mylar keeps track of the file that the task is concerned with. When I switch to instead work on a Phoenix bug that’s assigned to me (bug 164658), the views change:

Very handy. Switching between tasks is a breeze. It’s easy enough to just click on the “activate” button for the task, but you can very easily flip between recent tasks by using the drop-down on the task list:

In case you missed it, Mylar 1.0 was released today.

Eclipse Forum Europe starts on April 23, 2007 at the Rhein-Main-Hallen in Wiesbaden, Germany. I really love this conference, so I’m going to be there.

The call for papers ends on December 18th. Be sure to get your submission in. I look forward to seeing you there!

A bunch of my friends and I get together on new year’s day for an annual tradition. This tradition involves using a chainsaw to cut a hole in the ice of the Rideau River (in beautiful, but somewhat chilly, Ottawa), clearing out the ice and then taking turns jumping into the water. Here’s a picture of me doing this last year:

There’s more pictures here. Why do we do this? Good question. The best answer is something along the lines of temporary insanity. However, we’re now onto year ten of this foolishness and I can’t wait. I love this event. It’s fun. Honestly.

Not only do I get to strut around half naked in subzero weather (after spending a good hour doing reasonably hard physical labour to set it all up), but I get to raise money for the local children’s hospital.

When we first started doing this craziness, we looked around for a suitable charity; the children’s hospital was an obvious choice. So now, we jump in the water every year to raise money for the kiddies. This year is no exception.

So I’m looking for sponsors. Donations of more than $10 are tax deductable (for Canadians anyway). Every little bit counts. It’s for the kiddies afterall.

Even better… if you’re in the Ottawa area on January 1st and want to participate, drop me a line.

Mylar focuses you on your task. I’m starting to think of this in terms of top down development. I’ve always done software development using a top-down or "needs driven" approach. That is, I’ve always started by building the tests, then the layer being tested, followed by subsequent underlying layers. I tend to do this in a fine-grained manner so that I’m never very far away from actually running the tests (a là eXtreme Programming).

Unfortunately, my role as evangelist doesn’t afford me the same kind of time I used to have to actually write software, so I’ve been getting a lot lazier. Maybe that’s not totally correct: it’s probably more accurate to say that I spend a lot more time exploring than I do developing. I still do start with tests, but not as often. But I digress…

I’ve found that Mylar is pushing me back to the top-down, test-first approach. Specifically, it encourages me to define tasks that define some portion of the work I do. At first, the tasks were quite coarse-grained ("Explore EMF 2.3"), but they are now getting more and more fine-grained ("Modify the generated editor into a view"). This realignment is encouraging me to write my unit tests first (as it should be).

Of course Mylar lets me work on several tasks concurrently. And it remembers the context for each task, so that when I switch between my tasks, it adjusts my views to show me the information pertinent to that task. I also like that it lets me store my task context in Bugzilla, but I haven’t had much opportunity to play with that yet.

So why is top-down programming good? Well, people who are smarter than I am have written volumes on this topic. For me it comes down to something very simple: when I write code from the top down, I tend to write exactly what I need. I find that when I write code bottom-up or using some hodge-podge combination of techniques, I end up with a lot of code that I really don’t need; or worse, that I’ve written a bunch of stuff that–while it conforms to the requirements–doesn’t quite do what I really need it to do. This kind of problem goes away when you build top-down. That’s been my experience anyway.