Summary
Isn't it wonderful to complain about something minor? Something so nit picky<Ctrl-S> that most people wouldn't care about it? Well, here's something in that vein.<Ctrl-S>
Advertisement
I recently downloaded Google Desktop and I really like it. It gives you
a sidebar with some very useful features. You
can have a continual weather feed, news, a rotating set of
photographs.. the list goes on, but the thing I love the most
is the Scratch Pad. It's just a simple pane of text that is always
up. I constantly write notes to myself and this pane just hovers
there ready for inspection. I can read it, I can type into it, and
I never have to save!<Ctrl-S>
There. I said it. I'm tired of saving. Yes, we all have our story..
our story about how we first learned that we need to save frequently.
Mine involves losing a whole afternoon's worth of work in a school computer lab
because of a vacuum cleaner.. Yes! Someone vacuuming in a computer lab
when people were working! I can't imagine anyone vacuuming in while people are reading in a library but then there would be no power cords for the vacuum to knock out in
a library, would there? Better to vacuum in a computer lab while people are working, right? So, I lost an entire afternoon's work because
of a vacuum cleaner, and because.. I didn't save. It's a lesson that
we all learn early<Ctrl-S>. But still... I resent it a little, moreso
now because I've seen alternatives.<Ctrl-S>
Jonathan Edwards has a very forward thinking programming environment
called Subtext that he demoed at OOPSLA 2005. It has more interesting
ideas than I can get into here, but one of them <Ctrl-S>is that the
environment is active. As you change a program it's constantly
executing and showing you the results on example values<Ctrl-S> you
specify.<Ctrl-S>
For anyone who has been doing Test Driven Development for a while,<Ctrl-S>
the connection should be clear. <Ctrl-S>Running our tests gives us immediate
feedback. It makes the feedback cycle very small and very tight. When
your editing actually triggers computation, you don't have to do anything
special to get feedback, it's right there.<Ctrl-S>
Personally, I think that this is the way things are going to go. The trend is already there in most IDEs. Nearly every IDE worth its download is active
to some degree. When you type, your IDE parses and colors keywords; it
prompts you with suggestions when you type a dot after an identifier. So,
why not do other things? Why not save automatically? Some IDEs will save
automatically when you compile but why not continuously?
I guess there are a couple of reasons why manual save has persisted. One reason
is because having a sandbox gives us a feeling of security. And then, there's the
question of undo.. Undoing character by character is tedious. Manual save
is like a single breadcrumb that we can leave behind us, it helps us get back to a known
point. But how often do we really use it? Maybe we'd program better if we typed every keystroke like we meant it? :-)
Fortunately, in programming environments we have something else
we can use as breadcrumbs: successful test runs. This is an idea quite a few
people have investigated, but I want an environment like that in front of me. I want an IDE with a switch that puts it into continuous save mode and triggers test execution on each keystroke.<Ctrl-S> If we want to undo, we can undo to each previous successful test execution. That would be an undo that really means something.
David Saff has been doing research in an area he
calls Continuous Testing for the past few years. He's built an Eclipse
plugin which runs your tests continuously in the background but the tool still preserves a bi-modal environment. You type in one mode and the
tests run in another. You have to save.<Ctrl-S> He did some research with an earlier tool, one that tried to trigger execution on each keystroke but found that many users didn't want that much feedback, but I wonder.. is there more to this? Is the idea of an active environment flawed or do we need to find another way?
Triggering tests on every keystroke would be great, but at this point, I wonder whether the ability to save manually really is useful. Maybe it is just an evolutionary artifact.. an appendix we can just discard.
Do you think you would ever give up saving if an environment allowed you to?<Ctrl-S>
Thanks for the note, Carl. I should download that and play with it a bit. I remember when it was being discussed on the lists. I also need to talk to David some more about why the feedback seemed to be too much for users when he went zero-button. It would be great to find out more about that.
I go on vacation for a couple days away from my blog reader, and look what happens. :) Thanks for the thoughtful post.
The first continuous testing tool we built was for a controlled experiment: it was a plug-in for Emacs. It ran tests not on every keystroke, but after a small number of keystrokes, or a relatively short pause in typing. There was a single buffer for displaying test results. Experimental subjects loved the tool overall (http://pag.csail.mit.edu/pubs/ct-user-study-issta2004-abstract.html), but the single test result buffer posed a problem, as follows.
Imagine that you have just run your tests, and you unexpectedly discover a failure. The results buffer displays more than a single bit of information: there's information on which tests failed, the expected values that were being compared against, and likely some stack traces full of juicy tidbits. Aha--should just be a two-line fix. You start typing the first line of the fix, and the tests start running after the first keystroke--or perhaps the first keystroke that happens to leave the code in a compilable state. The new results may well be utterly uninformative--they indicate that you are in the middle of an incomplete thought, which you already knew. But the old results are now gone.
In the Eclipse plug-in (http://pag.csail.mit.edu/continuoustesting), we solved this problem in two ways. First, you can always manually trigger a test run, and the results are saved in a different result display than the automatic tests. Second, even the automatic tests only run on saves. This seemed to be the easiest way to get the feeling of "I'm done with a thought", similar to periods in English. There's no technical reason we couldn't include an option to run on every keystroke as well. Our first priority recently has been in a different direction: submitting patches to generalize Eclipse's testing support (https://bugs.eclipse.org/bugs/show_bug.cgi?id=102632), so that add-on tools like continuous testing will be able to breathe a little easier and feel less like hacks. Clear, insistent user demand might shift those priorities.
In particular, I'm interested in what the user feedback for this should look like. Should there be a kind of test result "stack"? Eclipse allows you to shrink the JUnit result view into a small 16x16 (or so) icon. There could be a stack of these icons, indicating the results of:
Last keypress Last save Last test pass Last manual execution Last source-control check-in
I'm very interested to see other ideas here.
I think that there's a fair amount of thinking and writing that could be done about the idea of development "registers". The two registers that many people have become comfortable with are "I'm changing my code" and "I'm refactoring". Most teams also seem to have registers of "This is ready to be checked into source control", and "This isn't." But is there also "I know that this isn't going to work yet", and "This should work?". I've seriously considered installing a piano pedal that I can push down while in the middle of a thought (similar to a phrase in a piano performance), and let up when I'm interested in the test results. That would make the low-energy state continuous testing, rather than no-saving-no-testing.
> Imagine that you have just run your tests, and you > unexpectedly discover a failure. The results buffer > displays more than a single bit of information: there's > information on which tests failed, the expected values > that were being compared against, and likely some stack > traces full of juicy tidbits. Aha--should just be a > two-line fix. You start typing the first line of the fix, > and the tests start running after the first keystroke--or > perhaps the first keystroke that happens to leave the code > in a compilable state. The new results may well be > utterly uninformative--they indicate that you are in the > middle of an incomplete thought, which you already knew. > But the old results are now gone.
David, hi. Thanks for replying.
Yes. I wonder how much of it is a UI issue and how much is intrinsic. Even active environments like Excel give us that little buffer when typing in cell values or formulae. Did you all see the results being uninformative often? I was imagining test failures staying on the screen between compilable states. It seems that something like what Carl has, where the errors are close to the code and unintrusive would be interesting. It seems like have a model for that with IDEs that show compile errors. Maybe a list view of test cases could have highlights on the names of tests that fail or something?
I don't think I have ever hit Save in IntelliJ. In fact, when I use Eclipse, I get annoyed by the dialog that tells me I have unsaved files. Why is it telling me that ?
Cooper's About Face has a long section about how "Save" breaks the files and folders metaphor and is therefore confusing to newbies. Many consumer apps no longer have a notion of "save" but try making a tool for developers without it !
> I was imagining test failures staying on the screen > between compilable states.
In continuous testing, they do. (Both in the JUnit results view, and as Problems in the Problems view). But if you hit a state that happens to be compilable, but isn't sensible, then these results are replaced one at a time with the new results. As I said, it would be interesting to do more experimentation: there are many improvements in the Eclipse UI over that in Emacs, which would probably mitigate confusion.
> It seems that something like > what Carl has, where the errors are close to the code and > unintrusive would be interesting. It seems like have a > model for that with IDEs that show compile errors. Maybe > a list view of test cases could have highlights on the > names of tests that fail or something?
You should be able to get that in the JUnit results view, and the method names of failing tests have wavy underlines. One definite advantage of Carl's language is that there's not much question of "where" a failure is. With Java/JUnit, it's tougher. We started off highlighting the top "interesting" line in the stack trace. However, imagine you're a beginning Java developer, and you see this highlighted:
if (input < 0)
thrownew IllegalArgumentException("Negative input");
What looks like the easiest way to "fix" this failure? :(
Given this, we currently highlight the names of failing methods. I've talked with the JDT UI team about the idea of selecting a whole stack trace as the current "location", with the mouse wheel moving up and down through it--that would probably come closest to the right idea.
> You should be able to get that in the JUnit results view, > and the method names of failing tests have wavy > underlines. One definite advantage of Carl's language is > that there's not much question of "where" a failure is. > With Java/JUnit, it's tougher. We started off > f highlighting the top "interesting" line in the stack > trace. However, imagine you're a beginning Java > developer, and you see this highlighted: > >
> if (input < 0)
> thrownew IllegalArgumentException("Negative input");
>
> > What looks like the easiest way to "fix" this failure? > :( > > Given this, we currently highlight the names of failing > methods. I've talked with the JDT UI team about the idea > of selecting a whole stack trace as the current > "location", with the mouse wheel moving up and down > through it--that would probably come closest to the right > idea.
Yes, one thing I wonder about though.. maybe the primary indication doesn't have to point to the most specific piece of information needed to correct a problem as much as it needs to just indicate that there is some sort of a problem. I know when I type in Eclipse or Intellij, I get balloons or wavy red lines. I suppose that even the name of a method could be highlighted in red or marked in the same way if a tool is able to establish a linkage between the method being edited and tests that should be exercised when it is edited. Once a programmer sees that there is a problem, they can click over and see what it is.
I guess I'm looking at the UI model used for detecting errors while editing, rather than the model used for detecting errors at build.
Just in case, such a wonderful IDE as IntelliJ IDEA has transparent saving for ages. Information can be saved on frame deactivation (default), by timeout or manually. And there are undo and Local VCS if you want to return to some point in the past.
if there is going to be and "intelligent save", why not also making "intelligent undo". <Ctrl+S> and <Ctrl+Z> it's like a pair, u shouldn't split them. :)
my idea of intelligent undo is, u still can undo your work, even after u closed the application. ItÂ’s and automatic save to the repository system, and when u press <Ctrl+Z> it no longer search in the clipboard, but in your repository.
soo, the intelligent save, should be automatic save, automatic test and automatic versioning, plus inteligent undo.
The Oberon System [0] as well as the BlackBox IDE [1] allows you to develop, compile and run code without saving. In Oberon (as well as Component Pascal) the unit of compilation is a module. However, to run a newly compiled version of a module you have to unload the currently loaded module version.
that seems good to you. i got it too. but the problem is: sometime, i cant connect to google. that where my indignation goes. now i shut down my searching, just wait for a better improvement.
I'm fairly fond of the eclipse save model, where it auto-compiles on save. It allows me to
(1) quickly force a compilation whenever I want and (2) prompts me to save regularly while (3) allowing me to make edits that leave the code temporarily invalid without red lines making me blind.
Sean
Flat View: This topic has 15 replies
on 2 pages
[
12
|
»
]
Previous Topic
