03.12.12
Posted in Eclipse, programmer productivity at 9:57 pm by ducky
Several years ago, I found that differential code coverage was extremely powerful as a debugging tool and made a prototype using EclEmma. I also had some communications with the EclEmma team, and put in a feature request for differential code coverage. Actually, I thought that incremental code coverage would be easier for people to understand and use.
Well, EclEmma 2.1 just came out, and it has incremental code coverage in it! I am really excited by this, and wrote a blog post at my workplace. I have given motivation on this blog before, but I give some more on the Tasktop blog posting, as well as some instructions for which buttons to push to effectively use EclEmma to do incremental code coverage.
Permalink
10.20.08
Posted in Canadian life, Eclipse, Hacking, programmer productivity at 3:28 pm by ducky
I am looking for a job. If you know anybody in the Vancouver area who is looking for a really good hire, point them at this blog posting or send them to my resume.
Ideally, I’d like a intermediate (possibly junior, let’s talk) Java software development position, preferably where I could become an expert in Java-based web applications. (Java because I think it has the best long-term prospects. My second choice would be a Ruby position, as it looks like Ruby has long-term staying power as well.) I believe that I would advance quickly, as I have very broad experience with many languages and environments.
Development is only partially about coding, and I am very, very strong in the secondary skills. While studying programmer productivity for my MSCS. I uncovered a few unknown or poorly known, broadlly applicable, teachable skills that will improve programmer productivity. Hire me, and not only will you get a good coder, I make the coders around me better.
I am particularly good at seeing how to solve users’ problems, sometimes problems that they themselves do not see. I am good both at interaction design, at seeing the possibilities in a new technology, and seeing how to combine the two. I have won a few awards for web sites I developed.
I also have really good communication skills. I’ve written books, I blog, and I’ve written a number of articles. I even have significant on-camera television experience.
If you want a really low-stress way of checking me out, invite me to give a talk on programmer productivity. (I like giving the talk, and am happy to give it to basically any group of developers, basically any time, any where in the BC Lower Mainland. Outside of the Lower Mainland, you have to pay me for the travel time.)
Do you know of any developer opportunities that I should check out? Let me know at ducky at webfoot dot com.
Permalink
09.10.08
Posted in Eclipse, Hacking, programmer productivity at 6:41 pm by ducky
In the observations of professional programmers that I did for my thesis, I frequently saw them get sidetracked because they didn’t have good information about whether the code they were looking at was executed as part of the feature they were exploring. I theorized that being able to look at the differences in code coverage between two runs — one where they exercised the feature and one where they didn’t — would be useful. Being able to see which methods executed in the first but not the second would hopefully help developers focus in quickly on the methods that were important to their task.
In my last month at UBC, I whipped up a prototype, an Eclipse plug-in called Tripoli, and ran a quickie user study. The differential code coverage information really does make a big difference. You can read a detailed account in UBC Technical Report TR-2008-14, but basically graduate students using Tripoli were frequently more successful than professional programmers who didn’t use Tripoli.
As an example, in the Size task, the subject needed to find where a pane was resized. That was hard. There is no menu item or key stroke invocation for developers to use a starting point. They also didn’t know what the pane was called: was it a canvas, a pane, a panel, a frame, a drawing, or a view? Between pilot subjects and actual subjects, at least eleven people tried and failed to find a method that was always called when a pane was resized and never called when it wasn’t. I even spent a few hours trying to figure out where the pane was resized and couldn’t.
As soon as I got Tripoli working, I tried the Size task, and in my first diff, I saw ten methods, including one named endResizingFrame(). And yes, it turned out to be the right spot. I realized that most of the methods came from not hovering over the corner of the frame such that the cursor changed into the grab handle, and reran. This time I got exactly one method: endResizingFrame(). Wow. The graduate students in my second study were also all able to find endResizingFrame() by using Tripoli.
Tripoli does take some getting used to. Even as the author, it took me a while before I consistently remembered right away that I could use Tripoli on my problems. I’ve also clearly gotten better over time at figuring out what to do in my second run to ensure that the “diff” has very few methods in it.
If you want to try Tripoli out, I’ve posted it online. Just remember it’s a prototype.
Permalink
05.14.08
Posted in Eclipse, programmer productivity at 12:51 pm by ducky
Andrew Ko, whose papers I have mentioned before, observed in An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks that
When investigating [navigations back to previously-seen code fragments], nearly all seemed to be for the purpose of juxtaposing a set of code fragments while editing many dependent fragments. … Although Eclipse supports viewing multiple files side by side, placing any more than two files side by side would have incurred the interactive overhead of horizontal scrolling within each of the views.
Meanwhile, from my user study, I believe that the Package Explorer is usually not worth its screen real estate and the Outline View is probably harmful (which I will explain below). If I close the Package Explorer and the Outline View, on my 24″ monitor, I have oodles of room for two source files side-by-side. I think that is probably the way to go.
Package Explorer
Developers used the Package Explorer to find classes that had interesting strings in them. For example, in the Arrow task, they would do a “visual grep” to find classes that had the word “Arrow” or “Line” in them. Generally, however, they would explore the first class they found with “Arrow” or “Line” in it. While that happened to be okay in the Arrow task, it is easy to imagine situations where the first class could be uninteresting or even deceptive. I have come to the opinion that it is better in most cases to use Control-Shift-T to open the “Open Type” dialog, where you can enter in the string you are interested in. (Note that you can use wildcards, e.g. “*arrow” to find all Types that have the text “arrow” anywhere in their names.)
If you use the Open Type dialog, you will immediately (because it immediately displays matching type names as you type) have a very good idea of which / how many classes have that text in them. You are not going to miss one, and you are less likely to get distracted by the first one you see.
Now, I saw a very small number of cases where the Package Explorer was useful. For example, in the Output task, one guy looked at package names and guessed (successfully) that “proguard.io” might have something to do with IO. So I don’t think you should do away with the Package Explorer, but minimize it most of the time.
Outline View
As for the Outline View, you can search for strings in the method/field names using Control-O. Just like with the Open Type dialog, you can search for strings (including wildcards). Even better, with Control-O,Control-O, you can see what methods are inherited.
I don’t think I ever saw anyone wandering aimlessly (i.e. not doing a visual grep for a specific string) around the Outline View and having any good come of it. So I don’t think the Outline View is worth the screen real estate.
Permalink
05.06.08
Posted in Eclipse, programmer productivity at 4:06 pm by ducky
In previous posts, I talked about wanting a code-coverage tool to use while debugging, and how EclEmma did most of what I wanted. After my user study, where I dissected in detail how seven professional programmers did four twenty-minute programming tasks, I am even more convinced that a wonder tool would be highly, highly useful to people. I want the wonder tool to colour and present source based on whether code was executed between a user-defined start and stop point.
- As I mentioned in the first post, I’d like to be able to start and stop collecting code coverage information. It would be nice if I could set START LOGGING and STOP LOGGING breakpoints, so that lines of source would be coloured based on whether they were executed inside the “active” regions. Being able to do this would mean that I could greatly narrow down what code was involved in a particular feature, and not have all the code touched by initialization routines touched.
- I’d like the number of times that a method gets executed to influence the Mylyn degree of interest. I’d like Mylyn to restrict what classes/methods Eclipse showed me (initially) to only those which were executed between the START LOGGING and STOP LOGGING breakpoints.
For example, I could bring up a GUI application, hit the Suspend button, set a START LOGGING breakpoint, hit resume, and resize a window, and hit the STOP LOGGING button. The PackageExplorer would then only show me the methods involved in event handling and resizing a window. Most of the event-handling code would probably be done by .class files, so it probably would only be the code related to event handling.
I believe that this would have helped my user study subjects enormously. They overwhelmingly used static tracing (i.e. jumping to references or declarations of selected methods) to find where things happened in the code, but they frequently got caught by differences between what static tracing told them and what actually happened. Examples:
- All seven subjects searched for an unusual string related to the given task in a GUI, which seemed perfectly reasonable. However, that string appeared in a superclass of the object that was actually instantiated. Jumping to declarations (via F4 or hyperlinks) took them preferentially to methods in the superclass. Four of the seven subjects never noticed that there were interesting subclasses. If, however, they had been using my wonder tool, the first time they jumped to a method that the subclass overrode, they would have seen from the source code colouring that that method never got hit.
- In one task, important code was not broken, but flat-out missing. Subjects usually found the right method pretty quickly, but then assumed that — because that method didn’t have the needed code — that it didn’t get executed. “Oh, here’s where the start-of-line decoration code is, now I just have to figure out where the end-of-line decoration code is.” Had they seen that that method got executed, they might have realized faster that the end-of-line decoration code was simply missing.
- In another task related to incorrect output, to statically trace through to bug’s location meant going through six methods whose names and comments made it look like they were related only to input. Setting a START LOGGING breakpoint where it wrote “Writing output…” to stdout and a STOP LOGGING breakpoint at the next stdout status message, then the subjects would have been able to see that the “input” methods were involved in writing the output, so they might have been willing to push through them.
- One task that asked the subjects to do something when a pane got resized was so difficult that nobody solved it. In addition to problems with language (Is that pane a Window, a View, a Drawing, a Pane, or a Panel?), it can be tricky to get from the place where a GUI widget gets set up to where the event gets handled. (In this case, they needed to find what methods were executed when a pane was resized.)
With my wonder tool, subjects would be able to get a list of all the classes and methods that were involved in the resize. By browsing that list, they would have a better shot at finding a method that they could use.
I think it wouldn’t be too difficult to implement this — EclEmma has already done the lion’s share of the work — but I doubt it’s compatible with finishing my thesis. 🙁
Permalink
04.17.08
Posted in Eclipse, robobait at 1:43 pm by ducky
Eclipse has incremental find!
Control-J will let you start typing to find the next occurrence of what you’re looking for; Shift-Control-J will do incremental find backwards. See Erik’s nice writeup on incremental find…
Permalink
04.16.08
Posted in Eclipse, Hacking, Technology trends at 5:42 pm by ducky
There are a zillion graphical IDEs out there, and I really don’t want to download and try each one. I don’t even want to try twenty of them. So, dear readers, care to help me?
All the IDEs that I’ve seen have a main center panel with the source of the file you’re looking at. Above that, they seem to all have a row of tabs, one per file that you’ve opened. (Does anybody have anything different?)
Here is a link to a screenshot of Eclipse. (Sorry, it was too wide for my blog.) Eclipse puts a little “>>” to show that there are more files (as pointed to by the ugly black arrow), with the number of hidden tabs next to it (“4” in this case). Clicking on the “>>4” gives a drop-down menu (shown here in yellow).
What happens in other IDEs when you have more tabs than will fit across the horizontal width of the source file? How does your IDE handle it? Or does your IDE have a different tabbing model altogether, e.g. it opens one window per file? I would greatly appreciate hearing from you.
You can either email me ducky at webfoot dot com or post in the comments; I’ll wait a few days and then summarize in another blog posting. Remember to tell me the name of your IDE.
Permalink
03.17.08
Posted in Eclipse, robobait at 2:34 pm by ducky
I’ve got two cool tricks for you today. Control-O opens up a “quick” view of the Outline View. Instead of looking in a separate pane, you can do it right inline. Furthermore, it has incremental search built in, so you can type a few letters to find methods that start with those letters. If you type in the normal Outline View, it will find the first method that starts with those letters but will continue to show you all the methods.
In the Quick Outline View, it will show only the methods that start with what you typed, so if you type “set”, the quick outline view will only show you setFoo(), setBar(), etc.
But wait, it gets cooler: you can use wildcards in the Quick Outline View and you can’t in the Outline View. For example, in the Quick Outline View, you can type “*Foo” to find getFoo(), setFoo(), etc.
But wait! It gets even cooler! If you have the Quick Outline View up and type control-O again, then it will show you the inherited methods as well as the ones in this class. Totally sweet.
Permalink
03.14.08
Posted in Eclipse, robobait at 9:35 pm by ducky
Several of the users in my study have complained about “tab spam” in Eclipse — having so many files open (at one tab per file) that they can’t keep track of them all.
If you want to limit the number of tabs in Eclipse that you have open at any one time, you can do this:
- go to Window->Preferences->General->Editors,
- put a check in the Close Editors automatically
- and select the number of editors (tabs) that you want open at once.
If you don’t want a tab to be reused, you can “pin” it. (On my toolbar, the “pin this” icon is at the far right, just to the right of the forward arrow, and has a little white-window-with-blue-taskbar underneath a green pushpin.)
This still cycles through editors, eliminating the least-recently-used, but at least you won’t get tab spam.
If you reuse editors, it is handy to use the Auto-Pin Editor Tabs Tweaklet. With that tweaklet installed, Eclipse will not reuse an editor (i.e. a tab) if the file within is dirty. (This will save you a bunch of annoying messages about needing to save files.) If all of the tabs are pinned, it will open a new one.
Permalink
03.13.08
Posted in Eclipse, robobait at 4:27 pm by ducky
One of my user study subjects pulled out a keyboard shortcut that I had never seen before: control-shift-u.
I didn’t get to talk to him about it much, but it pops up a menu with Identifier, Implementing Methods, and Throwing Exception options.
The Identifier seems to find occurrences of that Java element in this file. I guess you could do almost the same thing if you do a FileSearch for a element’s name in one particular file, but that would be a lot more work.
For the Implementing Methods selection, it appears to tell you which methods in this file override/implement methods in the type you had selected. (Note that the type needs to be something right after the keywords “extends” or “implements”. If not, you will get an error message “Cannot search for current selection. Please select a type behind ‘implements’ or ‘extends’.”
You can select an exception (e.g. IOException), press control-shift-u, and select Throwing Exception in order to see which lines of source cause that exception to be thrown. Maybe you knew that read() threw an IOException, but if you didn’t realize that skip() also throws an IOException; this would show you not just that skip() was what was throwing the exception, but the exact line where it was doing so.
Permalink
« Previous entries Next Page » Next Page »
