EMF: It's A Beautiful Thing

At the moment, there are at least 11 different ways to get EMF, topped just the way you like it:

• 9 zips: 3 SDKs (EMF-SDO-XSD, EMF-SDO, XSD SDK), 3 runtimes (EMF-SDO, XSD & Standalone), examples, tests, and models [1]
• 2 different Update Manager methods (install EMF-SDO-XSD SDK or install individual features) [2]

Is this sufficient? Some say it's already overkill, but others say no, and with the lofty goal of pleasing most of the people, most of the time, we're now exploring creating a whole new set of features in EMF [3].

This new set of features [4] is intended to add more options via Update Manager, as that's the most commonly used mechanism (80% of all requests tracked by eclipse.org last year) for downloading EMF. The old features remain -- they're just being chopped up more finely.

Those who want fries with that can order a combo meal and drive forward to the second window to pick up their zips; those who want EMF à la carte will now be able to order off the Update Manager menu, so they can pick and choose the toppings, er, features, they want for their special-needs diet.

Please comment or vote for bug 106804 if you have concerns or kudos.

Only 34 shopping days left!

Well, TV Turn Off Week is almost over, and as the weekend draws near and part two of Doctor Who (2005) "The Daleks Take Manhattan" readies itself to be ripped and shared across the internet (thank you, TPB!), it's time once again to remind all ya'll to get out and vote for the Java Developer's Journal 2007 Reader's Choice Awards. Yes, I said 'all ya'll'. I've been taking some online classes in Southern as a Second Language at the Hacker T. Tech Public School.

EMF sits firmly as the #3 Java Modeling Tool, and though it briefly enjoyed the #1 Java Component spot, it's now down by a mere 9 votes. C'mon, people, we can win this!

Will the real EMF please stand up?

Thanks to the wonder of Google Alerts, I discovered tonight that there's yet another entity/concept going by the moniker EMF. The list now contains software, music, physics... and at least one consulting company that writes about MDD (or is it MDD?) and embedded systems:

• Eclipse Modeling Framework
• Enhanced Metafile
• That 'Unbelievable' UK band from the late 80s
• Electronic Music Foundation
• Electromotive force
• Electromagnetic field
• Embedded Market Forecasters

... to name but a few.

embeddedforecast.com's whitepaper, entitled What Do You Do When the Horse You’re Riding Drops Dead: Why Model Driven Design is Emerging as a Preferred Best Practice, has some very nice things to say about the world of MDD. While it doesn't actually mention Eclipse or EMF -- presumably to avoid confusing the reader with ambiguous TLAs, it does mention Telelogic's Rhapsody which is built on Eclipse, and speaks highly of UML, stating that organizations using modeling are seven times more likely to make or beat schedules. It also suggests some Dilbert-like solutions to the problem faced when riding a dead horse. Worth a look.

TrackPoint no more?

For shame! I was comparing Thinkpads the other night when I noticed that the new Lenovo systems seemed to be missing the much-beloved and very useful TrackPoint from their 3000 Family of laptops.

A little more digging tonight through Lenovo's Design Matters blog, and I discovered that not only is it conspicuously absent from all 3000 laptops, but it's an intentional design/marketing choice, not some accidental oversight!

We intentionally did not include a TrackPoint because notebooks within this price category tend to use pads. If you really want a TrackPoint I suggest you buy a ThinkPad. [1]

If you've never used a TrackPoint, it can be a bit odd to first get used to it, but once you're accustomed to using the rubber-tipped, 3-button "keyboard nipple", it's much more efficient than a run-of-the-mill grease-prone two-button touchpad, because unlike a touchpad, it responds to directional pressure like a mouse or trackball rather than making you pretend your finger is a stylus to 'draw' your cursor around the screen.

Luckily, you can still get a TrackPoint on Lenovo's Thinkpads. I wonder how much longer they'll be available?

One final note: this poll suggests I'm not the only vocal TrackPoint fan out there, and also that my cap of choice is the most popular. Woohoo! Maybe there's hope for the future of the TrackPoint.

DRM Packaging for Linux

In order to put .mp3s on my new SE W810i phone as ringtunes, I have to convert them first to .dm files. This is a pain, but it could be worse. So, I found SonyEricsson's DRM Packager, installed it, and it works great. Unfortunately, they only provide this tool for Windows and Mac.

So, naturally, it was time to write a Linux implementation. ;-)

---

Setting up the DRM Packager for use with Linux is easy. Packaging is faster on a native Windows system (seconds instead of milliseconds), but then you have to actually boot Windows, so overall it's still faster.

I'm currently using the following tools for converting MP3s to ringtunes:

1. mp3 slicing: kwave sound editor, part of KDE (save as uncompressed .wav files)
2. mpeg compression: lame or sneetchalizer (.mp3 or .mp4)
3. DRM packaging: Sony Ericsson's DRM Packager tool -- details below (.dm)
4. copying files to device: Konqueror, part of KDE (drag and drop from hard drive to usb device)

---

DRM packaging

1. Download 'DRM Packager 1.35 - Windows' from Sony Ericsson's site.
2. Install from Executable (using WINE) to default location, eg: ~/.wine/drive_c/Program Files/Sony Ericsson/DRM Packager/.

  wine ~/DRMPackager-1.35-Windows.exe

3. If your WINE instance doesn't use z: as the drive for the filesystem root (/), edit drmpack.sh and change to s: or whatever your WINE wants.

  rootDir="z:"; # wine directory mapping

4. Run drmpack.sh to convert a single file or recurse through a directory of .mp3 & .mp4 files, in order to generate .dm files. For syntax help, run w/o commandline options or read the source.

  nickb@nickbdesk:~/ringtunes $ ./drmpack.sh tunes

  Processing directory /home/nickb/ringtunes/tunes ...
  Creating /home/nickb/ringtunes/tunes/neuroticfish_shortcommercial.dm ...
  Creating /home/nickb/ringtunes/tunes/neuroticfish_theyrecomingtotakemeaway.dm ...
  Creating /home/nickb/ringtunes/tunes/placebo_runningupthathill.dm ...
  Creating /home/nickb/ringtunes/tunes/placebo_postblue.dm ...

5. If you prefer a GUI, use DRM Packager.desktop to launch the GUI tool using WINE, then browse for files to add to the GUI, and click 'Create DRM Content'. For Sony Ericsson W810i, DO NOT CHANGE THE DEFAULT SETTINGS! You can launch the GUI from the commandline with:

  wine "c:\Program Files\Sony Ericsson\DRM Packager\DRMPackagerGUI.exe"

6. If the GUI won't open, try copying MSVCP60.DLL into the DRM Packager install folder. If you don't have a Windows machine handy to grab this file from, Google for a site like http://www.dll-files.com/dllindex/dll-files.shtml?msvcp60 you trust and download it from there.

---

Tested with:

• Sony Ericsson W810i phone
• Sony Ericsson DRMPackager-1.35-Windows.exe
• WINE 0.9.9-0ubuntu2
• MEPIS Linux 6.0 (based on Kubuntu 6.06LTS)
• Windows XP Pro SP2
• Thinkpad T60p

We're sorry, the Gmail you have reached is not in service.

My new toy

Decided to make the switch from my crazy-old cellphone to a new one this week, and it arrived yesterday to the usual chorus of barking at the front door.

I'm now the proud owner of a Sony Ericsson W810i, complete w/ 1G of storage for MP3s. Very cool phone; better than my nearly-dead 256M K-BYTE MP3 player. I've only made one actual call on it so far, and the fact that it doesn't come with an actual audio-in jack (2.5 or 3.5mm) is a bit of a turn-off, but it works great for games and music, and sports a 2MP still and video camera.

The first app I had to install was of course Gmail. Being a linux geek, the second was MidpSSH which worked fantastically within a couple minutes (except when I wanted to use an ssh key instead of user/password login, and discovered that OpenSSH doesn't appear to support DSS.) Actually, it was user error. I had MidpSSH configured to use SSH1, not SSH2, so it wasn't even trying to send the key. Anyway, re-RTFM a few hours later solved the problem. I can now ssh to my home machine from my phone! Config steps:

1. Configure SSH settings to prefer SSH2 and to use Public Keys
2. Create a session, configured to use your Public Key
3. Copy your phone's public key to your destination host's ~/.ssh/authorized_hosts file
4. If necessary, enable debug mode on the destination host's sshd instance by editing /etc/ssh/sshd_config and setting LogLevel DEBUG, then restarting the daemon with /etc/init.d/ssh restart
5. Connect!

Blogger Label Cloud

Found a cool way to present Blogger labels in a cloud (see "Categories" at right). Thanks to phydeaux3 for the code and configuration walkthru.

Desperately Seeking Status (Of My Bugs)

Since being syndicated at PlanetEclipse a few short hours ago, I've already incurred my first response from Alex Blewitt, of bug 178923 fame. Thanks Alex! I feel like I'm finally part of the Eclipse blogosphere. [Incidentally, PlanetEclipse (since its facelift at EclipseCon) doesn't render in Konqueror. I'd open a bug about that, but then I'd have to close it myself as WONTFIX or WORKSFORME because it works just fine as a Google homepage widget in Konqueror. But I digress...]

Kidding aside, I'd like to address your comments here in a fresh entry. Note that much of what I'm saying below is in reference to the general J. Disgruntled-Eclipse-Commmunity-Member, not Alex Blewitt personally. ;-)

It's not about 'never fixing bugs' or for that matter 'not able to reproduce' bugs. It's about hiding bugs so that you can't search for them by virtue of them being in the RESOLVED bucket.

Since there's a lot of different ways to manage a project using Bugzilla, and many different ways to mark status of bugs (other than simply their state being NEW, ASSIGNED, or FIXED)... perhaps the underlying problem is that we as committers need to better educate the community on how to find bugs and track their progress, plus how we use Bugzilla to track our own progress.

For the sake of leading by example, here's what *I* do:

1. Configure Bugzilla to send me emails for almost everything that happens in bugs I care about. Bugs I care about include: ones I've opened, ones assigned to me, ones for which I'm cc'd, and ones that depend or block any of the above.
2. Since I work for IBM, I use my IBM email address as my Bugzilla address; however, I've received the nod from On High that it's okay (since it's all in the public domain anyway) to have this mail forwarded to my Gmail address.
3. Because Gmail rocks for sorting, searching, and filtering, I have it configured to automatically label all Bugzilla emails with a special label, and skip my inbox.
4. This keeps my inbox clutter-free, but also lets me watch the left side of my Gmail screen for when there's bugs I need to read (that is, unless I've read them in Eclipse thx to Mylar!)
5. To be notified when there's something new in a bug I'm watching, I've installed the .deb package 'gmail-notify'. If you're on Windows, there's Gmail Notifier instead.
6. Regardless of a bug's status, I can now query Gmail to find the bug I care about, including posted comments and links to attachments. I don't even need bugzilla itself (though I still use that for other searches).
7. To track a subset of bugs I care about (my immediate TODOs), I have set up canned queries (do a query and then save it for future reuse) which work both in a browser and in Mylar, too. If you love Mylar like I do, you probably already know this; if you don't just add a Task List view > New > Query... using the "Create query from existing URL" option, like https://bugs.eclipse.org/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=My%20TODOs and you'll see what Bugzilla sees, in Eclipse. Just make sure you Task Repositories View > Add Task Repository with your committer id/password or you won't be able to retrieve the canned query from your Bugzilla profile. pserver:anonymous is faster, but not as powerful. If you're not signed up as a Bugzilla user, do it today, so you can tweak your email settings and configure canned queries!
8. There's no special magic for finding bugs you care about. It's just a matter of playing with Bugzilla's Advanced Search until you get what you want. I find more often than not, the best approach is to use only a few simple restrictions - too many and you'll get the ever-annoying (but amusing) Zarro Boogs.

On the topic of how I use Bugzilla to track my own progress, I admit this is a bit of a hack... but it works. In EMF-land (and those (un)fortunate? enough to have been assimilated into our workflow), we use, generally, three bug states:

1. NEW: bug is open and/or being worked. Comments will appear in the bug as it progresses. Note that not all bugs are bugs - many are enhancements, feature requests, or plan items / placeholders. Some are duplicate markers so that we can close the same bug in multiple streams and generate accurate releaes notes from those changes.
2. ASSIGNED - fix is in CVS, awaiting the next build to be released. Sometimes ASSIGNED also means we're playing 'pass the bug around' because there's parts that need to be worked by multiple people. Release Engineering bugs are notorious for this because I tend to open single bugs for umpteen work items, and because my works depends on others' and vice versa, so we can assign bugs back and forth as needed. I like this feature too because when I assign a bug I'm working to someone else, it disappears from my "TODOs" query until it's bounce back to me.
3. FIXED - fix is availabe in the latest build. Thanks to a bit of code written by Neil Skrypuch, my fantastic co-op student from this past summer/fall, we have a tool (and it's in org.eclipse.releng.basebuilder!) which you can use to automatically move ASSIGNED bugs to FIXED when releasing a new build.

Also, it's not LATER and WONTFIX as your blog post suggests -- it's LATER and REMIND. I don't think anyone has an issue with WONTFIX or WORKSFORME if they're valid resolutions.

On occasion, these states are used too, skipping from NEW to FIXED. I agree it's a bit of a misnomer to say a bug you opened that will never be fixed (WONTFIX) or that might be fixed some day in the far-flung future (LATER) is "FIXED", but that's the way the tool works. If you distance yourself from the dictionary definition of the word and instead use it in the context of Bugzilla, it really just means 'not being worked anymore' - for various reasons. I'd like to see a COMMITTED and a RELEASED state be added, but we can't all get what we want, and so we work around these sorts of situations the best we can with the time, tools, and resources we have.

I'm not going to get into the religious war about bugs states that bug 178923 has become. Let me just conclude this diatribe by suggesting that Bugzilla is a database. With a lot of data. Managed by a lot of diverse groups, in diverse places, with diverse work styles, on diverse teams, from diverse companies, universities and parents' basements. Despite all that diversity, we have a system in place that can cope with the 100s of requests logged every week. And it's in ONE common language, all focused aroung ONE community. So what if we use that language a little differently?

I welcome your comments & thoughts.

Blog the Vote!

If you're an Eclipse, EMF, or Java geek, please vote in the Java Developer's Journal 2007 Reader's Choice Awards! There's a whole bunch of your favourite Eclipse projects and Eclipse-based products in there. Oh, and if you register FIRST, your vote counts double (no, really):

As part of our 2007 Readers' Choice Awards Voting Process - the votes of ACTIVE subscribers, of JDJ will qualify as 2 points in our voting tally. New subscribers votes will count as 1 point. Subscription records are verified as of the start of voting. Voting continues through midnight, MAY 31, 2007.

EMF is listed in two categories, and as of this writing sits in the top 2 or 3 in both of them:

• Best Java Component
• Best Java Modeling Tool

Vote early, vote often!

Focus Follows Mouse

Thanks to Deepak Bhagat for the idea of this, and Wayne Beaton for most of the code.

Here's a quick & dirty eclipse plugin to make focus follow your mouse, with a toggle button to turn it on and off (because it can get rather annoying in wizards). EPL, of course.

org.eclipse.xmouse plugin, project w/ source

If you make this better, let me know, thanks!

LATER & WONTFIX Bugs (The Saga Continues)

This was orginally going to be a post in bug 178923, but seeing as Ed and Aaron have decided to duke it out themselves, I'll just move it here.

--

Reading through the later comments on bug 178923, I would like to clarify a few things, just in terms of the my experience working on and with the EMF team.

I felt your treatment of my bugs (= what I cared about) on the verge of abuse.

That's unfortunate, but FWIW, we've all been there. I've opened bugs against sourceforge projects and had them sit for ages, untended & ignored. (You might argue that's not as bad as being closed WONTFIX or LATER, but IMHO, it amounts to the same thing - my complaint is unresolved.)

I've also seen the backlog of bugs sitting queued against some projects (like Azureus, for example) and thought, my god, there's no point opening a bug, it'll never be triaged up the queue. (And yet I haven't sworn off using Azureus every day just because the bug backlog was long.) I've spend time watching the traffic around the OpenEmbedded/OpenZaurus teams and decided that opening bugs wasn't worthwhile either, because again, they're swamped. I've consistently had things crash while using KDE but never even thought I should open a bug because, frankly, I don't know enough about the way the platform works to open a bug which would be useful to the developers. Besides, where there's a will, there's a workaround.

To me, a long bug queue can be seen to mean:

1. insufficient time & resources to do everything everyone would like
2. very large community being sourced by a very small team
3. lots of great ideas (enhancement requests) but few contributors to work them
4. lots of strange corner cases, or uses which were never expected, or unsupported combinations/platforms/environments for which the core team can't test (lacking hardware, for example)
5. there's probably excellent support in other ways (newsgroup, wiki) for where a fix isn't possible but a workaround or better approach is possible ... and not just for the "Doctor, it hurts when I do _this_." - "So don't do _that_." scenario. ;-)

Reporters of bugs can't see how stressed the Eclipse teams are, what their priorities are...

We do publish Project Plans on our websites... but perhaps this question should be asked when opening a bug? Something along the lines of:

This might be an odd corner case, but it's costing me $$$ and time, and so I'll volunteer to write a wiki doc in return or field some newsgroup questions so that the people who normally do that can be focused on my bug for a few minutes instead.

Give and take, not just take. Isn't that what open source is about? Collaborating, not demanding? Sharing, not taking?

A bug must hurt to some exten[t] before someone takes the time and effort to file it. So I'm in a bad mood when I write a bug report.

How do you think dev teams feel when they realize they have yet another TODO added to their already massive pile? ;-) In all seriousness, *I personally* am grateful for the fact that I can, ahem, rely on the community for the odd bug report here and there. It means the massive job of testing all cases can be shared, I can focus on new development sooner, and it also validates the fact that people are using the stuff we create. Being told I'm not perfect sucks, but being told someone uses my code certainly offsets the offput.

When I report bugs, "LATER" screams "WE DON'T CARE!" and "GO AWAY!".

I would argue that it means "low on the pile" or "can we put out the 4-alarm fire before we get your cat out of the tree?" It's about prioritizing, not ignoring. I'm sure you've had the odious experience of waiting several hours in a hospital w/ a non-life-threatening problem. Sure, to you, that broken foot is super-painful, but to the staff, it's something that can wait a few hours, because the guy who came in just after you with the bullet holes needs immediate care first. Sorry to pull out the public sector metaphors, but let's be real here - there's some definite parallels between us open source workers and the overworked/underfunded public workers on which we depend.

For these reasons, I've stopped to report bugs against EMF because the responses to my bugs clearly showed that I was neither welcome nor would I ever get anywhere. And *that* shouldn't happen.

I agree - it should never happen. But look at it this way: bug fixing is a form of routine maintenance, like getting an oil change every few months, or a visit to the dentist for a cleaning. Would you be offended if you were told that the next available appointment was in 2 months' time? No, you'd think, "Damn, my dentist is popular. He must be such an expert he's got people beating down the door for his service." ;-) If you think I'm being flip, it's not intended - my point is that there's more than one way to perceive a situation.

The bottom line is this: if your bugs aren't being addresseda s prompty as you might like, ask yourself this: how many bugs have I opened w/ full Steps To Reproduce, screenshots, JUnits, or patches? If you meet the teams part way by contributing something to the bug fix effort (beyond just reporting it) it goes a LONG way towards its resolution and its ascent up through the priority pile.