Some of the topics for CFUnited 2009 were announced yesterday. I (Marc) am happy that my Automation session was accepted, though I'm more jazzed up about the "how to learn...." session that's currently languishing in the "maybe" column. Automation Session A quick note on the Automation session: I had an unbelievably fun time delivering the ANT presentation at CFUnited 2008 last year, but I'm not the kind of guy who can recycle a presentation every year. It ain't me. And thus the Automation session will NOT be a 60-minute session on ANT. It'll cover all kinds of nooks and crannies related to automation, from super duper braindead simple to code generation to who knows what. It's a Smorgasboard presentation. Disappointed... The one session I think should be a "must see" is Adam Haskell's "Red Green Refactor" presentation. I reviewed his slidedeck for this presentation, which saw its first iteration at BFlex/BFusion, and I have it on good authority that the presentation was outstanding. Adam is top notch and he knows his TDD stuff. I'm putting a campaign sign in my virtual Lawn right here: RedGreenRefactor CFUnited 2009. The other topic I'm quite interested in is the Mate Flex framework session. This isn't because I'm some framework whore. In fact, I won't touch a framework until I feel the pain that a framework purports to mitigate. This is why I haven't simply downloaded Mate myself and started playing. I don't know enough about Flex yet to know how it -- or any other framework -- can help me. But I want to know what solutions are out there when I do need them. I'm looking forward to seeing what Swiz has to offer, and I want to see how Mate compares or complements it. Lawn sign: Mate CFUnited 2009 Yet another is the Groovy/Flex presentation by Joe Rinehart and Barney Boisvert. I was fortunate enough to see Joe's Groovy/CF presentation at the BACFUG after MAX this year... it was kick ass! I now want to see how these dudes tie it into flex. But I wanna see some code man! Code code code code code. (and config config config config). I want to walk away from this session, go back to my room, download whatever sample code they provide, and be able to start knocking some stuff out. Tall order, gents. Lawn Sign: Groovy/Flex CFUnited 2009. With Code. And Lots of it. And another is the Facebook & CF session. All the hip kids are building apps on top of the facebook platform; and it seems like it'd be fun to spend a rainy Sunday dreaming up ways to make enough money building a facebook app such that I could a) buy a Maserati or b) afford Wharton for both my daughters. Lawn sign: Facebook and CF @ CFUnited 2009. Go vote! Excited about... It looks to me like Liz and crew have made a good effort this year to get rid of some of the presentation recycling that (in my lowly, 'umble, far-distant opinion) seems to have crept in. So there's lots of good new stuff. After a quick run through of the accepted topics, here's what caught my eye right away. This is "gut" stuff, without reading the session descriptions. CFMythBusters. I love watching Charlie Arehart speak. He knows his stuff inside and out, and he's a very engaging presenter. Swiz. At least one session related to BlazeDS At least one session that answers the question, "Why should you spend a gazillion dollars on this LCDS thingamajiggie?" Skinning Components in Gumbo Hacking your own website. (I want to see this so that I can go hack other people's websites and crash the interwebs). Actually, I want to see this b/c my company is currently seeking a particular ISO certification that requires internal security auditing, and I want to know the tips and tricks for busting our sites so that we can be prepared. Why no TDD presentations from us? The incomparable Sam Larbi mentioned on the twitters that he was surprised one of us MXUnit hombres wasn't presenting on unit testing at CFUnited this year. I don't want to speak for Bill on this matter, but I will say that I know Bill's interests of late are veering toward security testing, code coverage, and other higher-minded, less gruntish aspects of testing than unit testing. As for me, my reasoning goes something like this: I hate to suck. I mean, I really, really hate to suck. Now, 7 months after my complete clusterf**k of a presentation at webmaniacs, I still harbor regret and guilt. And here's one thing I know: a sizable part of my "success" as a presenter comes from my passion for the topic. And for me to be passionate about presenting something, it's got to teach me something. If I'm not learning anything during the creation of a presentation -- the slides, the concepts, the code, materials, etc -- then I'm bored with it. And I won't do that to people in the audience. If I'm bored, they'll be bored. And I'm getting too old to fake it. I can do it, but it requires more energy to phone it in than it would be to come up with something new. I was super stoked about Bill and my presentation at MAX this year b/c it was relatively new stuff for us. We hadn't presented on it before. And Bill's BACFUG presentation, while an "intro" presentation, took a completely different angle on the topic. But for me, I've lost passion for "introduction to unit testing". It's time to let other people who have the passion for the topic share their discoveries. To that end, I do hope that Tim Farrar's unit testing presentation gets accepted this year. Another Lawn Sign: Tim Farrar, Unit Testing, CFUnited 2009. Bottom line for me: if I'm giving a presentation, I have to learn something too. It's quite selfish, I'll grant that. But a man's gotta know what lights the fire, and I know that much about me. Fear not, gentle reader. MXUnit will be on the scene at cf.Objective this year with a brand new, code-and-what-am-i-thinking-as-i'm-doing-TDD-intensive presentation. It's a new one for me, a sort of "meta" presentation to try to get into the head of someone designing code for testability. Merry Christmas!

Slooooooooooooow

So your Eclipse is sluggish, and you've tried the usual suspects: increase the heap and permgen, run -clean, close projects. You've found all the places where Aptana strangles your install and tried, to the degree possible, to tame its virus-like behavior. But something still feels off. Maybe startup is slow. Maybe, as happened to me, shutdown takes minutes. In my case, my eclipse install got to the point where shutdown was taking 2-3 minutes, and this is on a fairly performant machine. Finally, I had a Popeye moment: "That's all I can stands, I can't stands no more!". I opened up sysinternals excellent Process Monitor utility and watched what was happening. Bottom line: on shutdown eclipse was touching a gazillion different directories in my workspace, even directories on projects that were supposed to be closed. I do not know what it was doing (I suspect Mylyn, though, for what it's worth. But you'd have to rip Mylyn out of my cold, dead hands before I gave it up). So I decided to finally bite the bullet and adopt a practice suggested by many other people over the years (my buddy Mike used to yap at me all the time about this). It's a practice, however, that I tried before but couldn't commit to.

Separate Workspaces

What solved my problems: Separate workspaces. I know, you're thinking, "uh, duh, dumbass. that's what workspaces are for". But hear me out. When you start out with eclipse, you might have 5 or 10 projects in your workspace. A handful of java projects, some CF, some other play-around stuff... whatever. You wanna mess around with AIR, so you have some AIR projects. You have a handful of Flex projects. You decide one day to monkey with CFEclipse b/c you're so keen on giving back to the community, so you check out the 6 or so projects from SVN. You create a couple eclipse plugins yourself. Soon enough, you end up with 50 projects in your workspace. But you keep most of them closed, so technically they should be closed, right? "Yer dead to me", right? Apparently not. So I got my act together and finally separated out my different types of work into different workspaces, and the difference is dramatic. My primary workspace -- whittled down to a mere 31 projects -- starts up and shuts down in seconds. All the other workspaces, ranging from maybe 6 projects to 20 projects, load just as quickly. Nice thing is that now that I've got projects separated out, I don't need to keep projects closed all the time -- at least, not the ones in my "secondary" workspaces.

How to move projects from one workspace to another

But this post isn't just about my dummy AHA! moment. It's about a tip for a really fast way to move projects out of one workspace and into another. Here's what to do: To create a new workspace: Simply go to File -- Switch Workspaces and then type in a new Location. For example, for a workspace containing my Flex stuff, I just typed in c:\documents.....\mesher\EclipseWorkspaces\MyFlexWorkspace. Eclipse will then create a new, empty workspace. To get some of your existing projects into the new workspace:

1. File -- Import
2. General -- Existing Projects into Workspace
3. Click "next"

Here's where it might get a bit tricky, so I'm going to go into all the detail for my own personal setup. I have projects scattered throughout my system, but largely they fall into two places: 1) my webroot where I keep all my cf projects, and 2) my actual workspace, where I keep most of my java projects. I'll start with my CF projects. Let's say I have 50 different projects underneath my webroot, and I wanted to break them into roughly a third. In the "Select Root Directory" dialog that comes up, I went to c:\inetpub\wwwroot. This brought up a ton of projects, only a third of which I wanted to move into my new workspace. It then scans for all projects and loads them into the window at the bottom of the panel. I clicked "deselect all", then selected just the projects I wanted to import. Then, I clicked Finish. That brought all the projects I wanted to import into my new workspace. NOTE: I did NOT click to "copy projects into workspace!". I repeated that step for the other projects I wanted to move into separate workspaces. Finally, I went into my primary workspace selected the projects that I had moved into separate workspaces, and deleted them. I did not select "remove from file system"! Remember... by moving projects to another workspace, you're not physically moving the location on the file system.

Preferences

One thing to note when creating new workspaces is that each workspace gets its own separate Preferences. This is a good thing! But it does create a bit of extra work if you simply want to replicate your preferences among the various workspaces. For me, the quickest way to move my preferences from the primary workspace from the secondary workspaces was this:

1. in primary workspace, go to File -- Export
2. filter on "preferences"
3. Export all preferences to a file somewhere... I put mine on my desktop

Then, switch to another workspace.

1. in this secondary workspace, go to File -- Import
2. Filter on "preferences"
3. Navigate to the file you created
4. Click Finish

That's it! Do that for the other workspaces, and now your preferences are consistent. Got any other tips for speeding up Eclipse?

This is going to come across like bullshit hype, but I've never liked the fact that the hardware I buy (desktop, laptop, and phone, especially.) is effectively owned by the underlying operating system and carrier. Chances are I will never rebuild the OS or even write a killer-app, but it's getting old waiting and waiting and waiting until something gets fixed or a new version released or just trying to find a workaround to some feature I need. But with an open operating system for mobile devices (Google Android), developers and enterprising folks can provide products and services to otherwise enslaved users. Viva la revolución!

Computers suck a lot of energy, as do the peripherals connected to them. Even when turned off, all devices draw at least some current. It's a trickle, but it adds up. First, the setup: I have a HP running Vista 64bit with two 19 inch monitors, a printer, speakers with subwoofer, cable modem, vonage router, and wireless router. The goal: When the PC shuts off, keep the cable modem, vonage, and wireless router still juiced, and completely kill the other peripherals... I don't want them drawing any power at all. Even better goal: not have to turn the PC off at all to make this happen (because PC startup takes a while). Even better: only a few minutes after I finish using the PC, have it shut down such that all peripherals are invisible to the grid, and with a mouse click, have everything back up within 10 seconds. No data loss, either, obviously. At home, here's how I contribute some treehuggin granola and lovin' to Mother Earth. Some time back, I heard of the Smart Strip power strip, a strip that enables a "controller" outlet to effectively cut off power to all other plugged-in devices when that controller itself is turned off. Seemed like a reasonable idea, so I bought two: one for my TV/devices and one for my computer. I'll focus on the computer with this post. I have the computer plugged into the control outlet. Monitors, printer, and speakers are plugged into the "controlled" outlets. Cable modem, vonage, and wireless router are plugged into the "always hot" outlets. Thus, when the PC is "off", the big-energy-sucking devices go dead while the ones I need to have on stay active. That's part 1. Some pics

This is all well and good... turn the PC off, and save some money and some trees. But that's not good enough. I want it to be brainless... I don't want to have to turn off anything, and I don't want to have to wait a few minutes for everything to boot back up. I want it to happen automatically, and have my entire "state" retained when it comes back up. So, on to Part II of how I'm saving the world. "Sleep" to the rescue. Now, back in the XP days, I remember sleep flat out sucked. It took forever to come back up, often longer than it would've taken to shut down and restart the PC. With Vista -- at least in my experience with this particular PC, sleep is quite good. I have my power options set to turn off the monitors after 5 minutes of inactivity and Sleep the computer after 10 minutes. Thus, 10 minutes after I walk away from the thing, my state is retained and everything "shuts down". All earth-melting peripherals are off the grid. Angels weep at my magnanimousness. Babes swooooon. Now, some latte-sipping hypermiler choad is saying "But that's 10 minutes! What about the Northern endangered spotted Newt! You're killing the Newt you paint-drinking techno-earthkiller!". OK, I'll grant that in those 10 minutes, multiplied by say 10 times a day or whatever, I'm not winning any Al Gore Humanitarian awards. So, on to Part III, for the Prius set. In Vista, you can control what the "power" button does. That's the little round thing with the bar up the middle. I have it set so that when I hit the power button, the computer goes to "sleep". This is not windows XP sleep. This is Vista sleep (again, at least on my PC). And it shuts down within about 5 seconds, and when I wake it back up with a single mouse click, it's ready to roll in about 5 seconds. Full network connectivity takes somewhere between 15 and 30 seconds to reestablish. I know it's back up when TweetDeck chirps. Now, I did hit a snag initially with keeping the router Hot. The PC would sleep, but then it'd come back to life a second or two later. I had to go into device manager, find the network controller, right click and select "Properties", go to the "Power Management" tab, and Deselect "Allow this device to wake the computer". Bottom line: for me, the Smart Strip + Vista + Power Options + Sleep-on-Power-Button combination has been a win.

I'm happy to announce another update to the MXUnit Eclipse plugin. This started out as an attempt to correct a deficiency that was a deal-breaker for some people, but turned into a few additional features as well. Here are the goodies. Any-resource-level CFC Path Property Several people who've tried to use the plugin have been stopped at the gates because the plugin could not correctly determine the dot-notation (CFC) path to a component. This was due to the way the plugin expected eclipse projects to be set up. When I first wrote the plugin, I knew there was one condition that would cause the plugin to not work for people... but I thought "Why the hell would anyone set up their environment that way?" I should've known... The proper fix is now in place: you can set the component root property at any resource level. This should eliminate any problems with the plugin determining the component root for a directory of tests since you can now specify that root on any folder, not just the project. In addition, there's a nifty feature contributed by a user named Alanyst that provides the "I don't want to use the webroot, but I want an 'empty' component root" behavior that some people have asked for. Method Timeouts Bob Silverberg, a dude I hold in high esteem, emailed me one day with this bugger of a problem in the plugin: it'd hang and hang and not return anything. The problem turned out to be trying to call debug() on a component instance, and it was taking forever to serialize the data across the wire from CF to Eclipse (or something like that). My response was "if it hurts to do that, quit doing that". Bob's persistent, though, and was having none of my attitude. From our conversation, the need for method timeouts was born. There's now a global preference for timeouts. Now that this feature is in there, I like it a lot. I've set my preference down real low... to 5 seconds. This keeps batches of tests flying and lets me know what tests are taking too damn long. When I want to actually run those long tests, I change the preference (quick and easy from within the View itself.. no window/preferences hooey). Admittedly, this timeout behavior is an initial stab. It's a big old sledgehammer approach (single setting controlling everything). In the future, this timeout behavior will likely be controllable at a more granular level. This was put on the radar a while ago when Bill and I started talking about what's coming up in MXUnit 2.0. Run multiple directories or components in the Navigator You should know by now that you can right click on any directory or Test component in the navigator view, right click, and select "Run MXUnit Tests". However, until now this was limited to a single directory (and its children, obviously) or component. And you couldn't select projects. This was modeled after the JUnit way of doing things. Turns out, the addition of the folder-level component path property was the key to enabling this "multiple select" feature. I won't get into the details, but the bottom line is that you can now select multiple directories, tests, and even projects. No more View "Chatter" When running a large number of tests, the top panel of the view scrolls to the bottom as the tests are run. In addition, all of the tests are selected so that the bottom panel will have any stack trace details immediately available. This visual cue that your tests are running is a holdover from when the plugin was first written, prior to using a progress bar. This was fine in normal day-to-day unit testing, but when running a lot of tests the constant updating of both panels created "chatter". On a fast machine, it was downright epileptic. With this update, the top panel no longer scrolls, and the bottom panel isn't updated until all tests are run. This creates a much quieter test run. If you mainly use the plugin for TDD, small-batch runs, etc, then the difference will not be very noticeable. If you run a lot of larger batches, you'll see the difference right away. Small stylesheet enhancements This is a small change, mostly for the bored and picky. When viewing the output of tests in the browser view, the styling was extremely basic. I'm no pixel pusher. So I made the styles customizable, with a bit of work. This will get easier down the road, but for now, simply navigate to your eclipse plugins directory, find the org.mxunit.eclipseplugin.... directory, and then drill down into the "style" directory. You'll find a stylesheet. Do as you please. Just don't delete the file. As I said, this is a silly little change for folk more visually inclined than I. So how do you learn more about all this stuff? You might not know it, but the plugin comes with integrated help. It's the QuestionMark icon to the right of the View. Click that thing, and then from there you can go to "Configure global preferences" to learn more about method timeouts and "Configure project properties" to learn more about the improvements to setting the CFC path property at any resource level, including the "empty path" indicator. The plugin's been working fine for me. Will this break things? It shouldn't... though I haven't tested on Mac or Linux. If the plugin behaves differently -- in bad ways -- email me on the MXUnit mailing list and I'll do my best to get things fixed up toot sweet. 'Cause toot sweet is how we roll. A Plea, from me to you, About Coding Faster This is completely unrelated to the plugin but is directly related to "working smarter, not harder". The MXUnit framework download comes with a directory named "cfeclipse". Inside are two directories: snippets and dictionary. Please, read the readme.txt files in there and spend 5 minutes installing the dictionary and snippets. Use the copysnippets.xml ant task to copy the snippets and the keyboard shortcuts to your snippets directory. And start using the snippets! You can crank out lots of boilerplate code with the snippets and focus your energies on writing just the code you need to write. Done. Test and Be Happy!