Develop with Pleasure: The Next Big Thing

I can imagine that creating a WYSIWYG-HTML will take a really long time

AFAIK Jetbrains already has such a WYSIWYG editor (recycled from the
dead project Fabrique) and it was for a few EAP builds in the distribution.

Ahmed.

Hello Erik,

I'd much rather see integrated profiling, better code coverage
support, and Java framework support
(Terracotta/Gigaspaces/Guice/Wicket) than things like this.

I prefer my profiler non-bundled. The profiler-formerly-known-as-JFluid has
become a sucky integrated affair which requires a 100MB download. That's
a shame, since the basic tool was quite decent and has a couple of smart
guys working on it. Fortunately there's still YourKit, which now seems to
have a permanent personal license offer :)

Or were you perhaps talking about a tighter integration between profiler
and IDE? If so, I'm interested in more details.

Also, what's bad about the current coverage support? I'm not a hard-code
coverage addict, but I know of two complaints about the current coverage
provided by IDEA:
-EMMA has bugs which don't get fixed (or only very slowly) - some prefer
Cobertura for that reason
-It's limited to line coverage because of its bytecode transformation nature

Are there any other downsides w.r.t. code coverage?

Out of curiosity, what kind of support would you like to see for Terracotta
and Gigaspaces.

Regards,
-tt

When I have to do (minor) HTML editing, I mostly do it by hand. This is fine, because editing HTML by hand is pretty easy with IDEA, due to completion, navigation, error highlighting, and the godlike HTML Preview. I'm not a graphic designer, have long since realized both that I will never become a graphic designer, and further that graphical design done by non-graphical designers tends to have large negative value, no matter how kick-ass the tools they use. Fortunately, I work in an environment (news and entertainment) where no-one has to be convinced of the value of graphic design, so I never have to hear my boss say "Can't you just hack up some JSPs?".

--Dave Griffith

And another:

JMX support. Basically, some way of opening up a JMX console automatically connected to a run or debug process. Think of it as either the next step beyond attaching a log reader to a run/debug process, or alternatively as a different sort of profiler launch plugin. Toss in some Spring support for creating/configuring MBeans (probably just a template bean or two), just for completeness.

--Dave Griffith

I agree with Erik about WYSIWYG HTML editing.

The concept is likely an exercise in tremendous frustration for the developers who will likely not be able to satisfy any significant subset of those who'd want to use it.

Really, WYSIWYG HTML editing borders on being oxymoronic.


Randall Schulz

Yes, I had something like that in mind. God safe the good old Fabrique!

Well, something like WYSIWYLG (...LikelyGet) would be sufficient for me.

+Out of curiosity, what kind of support would you like to see for Terracotta
and Gigaspaces.+

The last time I looked 'em over, I thought that they could seriously use the same sort of configuration/deployment tooling as J2EE containers have, but that they probably don't have enough market share to get it for a while yet. The configuration part might become somewhat moot if the products move to annotation-based configuration, as it seems like they should in a just universe.

Terracotta seems to have an Eclipse plugin, FWIW.

--Dave Griffith

Ahmed Mohombe wrote:
>> I can imagine that creating a WYSIWYG-HTML will take a really long time

AFAIK Jetbrains already has such a WYSIWYG editor (recycled from the
dead project Fabrique) and it was for a few EAP builds in the distribution.

I'd love to see that come back as well. It showed alot of promise..

>>> I can imagine that creating a WYSIWYG-HTML will take a really long time
>> AFAIK Jetbrains already has such a WYSIWYG editor (recycled from the
>> dead project Fabrique) and it was for a few EAP builds in the
>> distribution.

I'd love to see that come back as well. It showed alot of promise..

+1 .
It was shortly introduced at the start of the Selena EAP and in Fabrique
it was not bad at all (Fabrique had a Release Candidate 1 before it was killed).

Such feature(WYSIWYG) would be the target of many webframework extensions so IMHO
the best way would be to publish the source of that plug-in to let the developers freely
extend it, cause making open-API for it would take too much time, and I doubt it would be documented
soon.

Ahmed.

What exactly would you like to see improved?

Well, I think it could be improved in a couple of ways.

To start with, currently you can only see if a method is covered, or not. There are no numbers on how well the code is covered. I also cannot see which part of the code is very well covered, and which part isn't, since there's not an overview page of the coverage. Maybe it would also be nice to see a history log, to see an increase/decrease in coverage, but that's more a nice to have.

Currently, I don't use the code coverage, since I don't build with IntelliJ. I use Maven (1), with Clover, and sometimes Cobertura. As far as I know, Emma doesn't support Maven 2 (or the other way around), so it would be great if the Maven's code coverage could be integrated with IntelliJ. There was a Clover plugin for IntelliJ, which worked really well, and could (if I recall correctly) use Maven's coverage.db. Also, Emma supports partial coverag, but I don't see this in IntelliJ.

So in short:

• More numbers

• A better overview of the coverage

• Integration with Maven (/Clover/Cobertura)

• Partial coverage

Btw, the biggest reason I'm currently not using code coverage integration (which I really think is a shame!) is because I'm on a project which is currently stuck to Java 1.4, and I don't think you can use the IDE integration than.

As an extra nice to have, it would be nice to see the level of coverage on a statement. I.e: the difference between decision and condition coverage. If I have a method like:

And it turns up green, what does it tell me? Currently, it tells me it has been hit at least once, but I'd rather have me tell that it was once called with true or false result.

Btw: this plugin I really like: http://www.cenqua.com/clover/doc/idea5/index.html.
(It has a counter, some metrics , etc)

and Java framework support
(Terracotta/Gigaspaces/Guice/Wicket) than things

like this.

Have you tried the existing plugins for Guice and
Wicket? If yes, do they
suit your needs?

I haven't tried them. In fact, I was unaware of the Guice plugin untill you mentioned it, because I couldn't find it in the list of plugins. If I have feedback about the Wicket plugin, I'll let you know.

The idea about my post was to focus more on developing software (with pleasure!). So I'd rather see framework support and other handy developer tools (like the profiler integration, since I agree with Taras: it doesn't need to be bundled, but maybe some support for integration, or something) instead of focussing on things like Drag and Drop support for HTML stuff.

Erik

Hello Erik,

Any specifics on what kind of support for Terracotta/GigaSpaces you're missing?

-tt

Hi Taras,

Sorry for not replying to you before on your other post (I also have some work to do ;)). Some support for e.g. Terracotta could consist of file templates, like processors and polling containers.

The Terracotta/GigaSpaces thing was just an example. I'm not very experienced on that level, but the point I tried to make was that IntelliJ is a Java IDE. That's why I use it, and that's why (or, at least I think so) IntelliJ should focus it's attention on (JEE?) Java things, like framework support. I do consider it great that IntelliJ has XML support, but I'm not in favor of creating the same functionalities XMLSpy has.

So I'd rather have the best Java IDE in my hands than the best XMLSpy/Frontpage/Eclipse/Photoshop combination... well, I hope you catch my drift :)

Please ignore it, read too fast

I've already posted this on EAP thread, but let me summarize
a couple different ideas for evolving/leveraging the inspections:

1. Code->Quickfix/Cleanup Code
http://www.jetbrains.net/jira/browse/IDEADEV-17781

This would allow you to select an Inspection profile and scope (current file, package, etc.),
and IDEA would automatically inspect the files and apply all quickfixes in one shot.

I have a 'Normalize' profile I use which contains only inspections which have quickfixes which help clean up code like 'missorted modifiers', 'for loop to for each', etc. Right now, I have to Inspect->AnalyzeCode, and then click through the results and apply the quickfixes which takes minutes sometimes.

2. SRRS (Sixth and Red River Software) Inspector General.

This Inspector General plugin has a feature called 'Rationalize Control Flow that
it is an integrated one pass rewriting of the code, and so it avoids the hurdle faced
by this Code->Quickfix/Cleanup action which has to try to apply many independent
(and possible contradicting or overlapping) quickfixes which could be error prone.
It replaces a large subset of the piecemeal inspections in IDEA, and even does some
things IDEA can't do like 'use continue statements to flatten loop structures',
and 'prefer early returns'

I posted more about it in this thread along with some other ideas I had;
http://www.intellij.net/forums/thread.jspa?messageID=5197138

I think SRRS is really onto something which could be very useful by allowing you
to normalize your code in one shot just you can normalize your code in one shot with
Code->Reformat.

In the future, if I had to adopt some code and needed to clean it up, I would like
to be able to follow these steps:

1. Code->Reformat
2. Code->Generify... (if it was pre JDK 1.5 code)
3. Code->Quickfix/Cleanup Code
or
Code->Normalize Code which would do a one-shot normalization using
SRRS's "Rationalize Control Flow" and "Normalize References and Declarations"

Doesn't the Emma integration show you the percentage cover of package/class/line in the project view?

Improvements to code coverage for me would be:

- Ability to export the data into some csv/xml/html format, without having to cobble together some Emma/Ant task.

- For partial line coverage, show which part of the line has been hit (I don't know whether this is possible from the collected Emma data)

- The ability to merge two sets of code coverage results, at a later point in time.

In a word: webservices.

It appears that the current web services plugin is a third party plug in, and bluntly it shows. I have downloaded the current version and tried to get it working, its very difficult.

Points of note:
Little or no user feedback.
Causes errors on Idea V7 M2.
Does not seem to decode some wsdl's and gives no feedback to indicate what may be wrong.

If anyone else used this plugin in anger and found my comments unfounded, please comment.

There is JIRA for the plugin
(http://www.jetbrains.net/jira/browse/WSVC), please, provide feedback there.

Dave Cherry wrote:

In a word: webservices.

It appears that the current web services plugin is a third party plug in, and bluntly it shows. I have downloaded the current version and tried to get it working, its very difficult.

Points of note:
Little or no user feedback.
Causes errors on Idea V7 M2.
Does not seem to decode some wsdl's and gives no feedback to indicate what may be wrong.

If anyone else used this plugin in anger and found my comments unfounded, please comment.

--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Here's mine:

integrated js debugger.

Nothing too earth shattering, but basically something that does exactly what firebug does, using IDEA's UI and ease of use. This would also mean expanding the existing gecko html preview to allow abitrary urls to be loaded into it.

I'd like to get to the point where when I'm developing webapps, I never ever leave IDEA.

Did someone say Scala?

Evidently they were shouted down by the Groovy crowd. They're a raucous bunch...


RRS

A small part of my idea of heaven includes coding Scala in IDEA, but better since it would include not just object-oriented refactorings/inspections/intentions/code-assists, but also functional r/i/i/c-a, r/i/i/c-a to help you move between the two, and a whole bunch of functionality to help people learn the trickier bits of programming in type-inferenced languages. The end result would be the most amazing programming environment ever, and would significantly improve the chances of humanity making it through the next century without descending into barbarism due to cascading system failures.

I could make it happen if I just had a year, $1.5M, and Eugene Vigdorchik. Sadly no one is going to give me any of that. Sigh...

--Dave Griffith

With the usual caveats about Google Trends:

http://www.google.com/trends?q=Perforce%2CMercurial%2CSubversion%2CGit%2CClearCase%2CMKS&ctab=0&geo=all&date=all&sort=0

My guts says we're just finishing the first wave of early adopters for distributed VCSes, and they are primed for serious takeoff over the next 2-4 years. If I were you guys, I'd definitely be strongly considering Mercurial support in 8.0, as a strategic bet that could pay off big in the mid-term.

--Dave Griffith

I'm kicking myself for not accepting that position on the IPCC...


RRS

I think better management of multiple projects would be a pretty good line item.

I often have 3 projects open simultaneously. It would not be appropriate for them to be modules of a the same project. I've noticed the following problems:
- When a dialog box is grabbing control in one project window, that locks up all project windows. Why should opening the project settings window lock up other projects?
- When I exit idea entirely and then open up idea again, only one of the projects is opened up. Sometimes this is what I want and sometimes it is not. I would prefer to do it the way that Opera does it. When starting idea, pop up a window asking if all projects (which were open when idea was last closed) should be reopened. If not then have a checkbox list where I can select yes/no which ones to open.

Multiple clipboards would definitely be a good bullet point.

I can't tell you how many times I've wanted to get access to a history of the values in the clipboard. I suggest something like ctrl-alt-shift-v to pop up a clipboard history. Then I could click a selection or hit a number (if it's within the first 9) and have it paste the values from that clipboard.

You wouldn't need to include the latest clipboard in the history since ctrl-v would just paste the latest.

Once that's done, having keyboard bindings which directly paste entries from historical clipboards would be nice. I could bind ctrl-shift-1 (or whatever) to the second most recent clipboard entry.

I'd like to also control how many clipboards are in the clipboard history. You might also have a memory constraint so that the clipboard history won't keep more than one super-huge clipboard in memory at once.

Have you ever issued the Edit -> Paste... (CtrlShiftV) command?

Is this not sufficient?


Also, I know that for Linux users of KDE (and I'm sure there are counterparts for other desktops and other operating systems), there is "Klipper," which does something similar.


Randall Schulz

Huh. I clearly just didn't know where to look to find that feature.

I don't know about others, but I was searching online and in help files for "multiple clipboards". Perhaps you could put a line item in the help that was titled "multiple clipboards" to help others find this feature.

Thanks!

Geoff Fortytwo wrote:

Huh. I clearly just didn't know where to look to find that feature.

I don't know about others, but I was searching online and in help files for "multiple clipboards".

And how much faster and easier would it have been if you just had took a
look at the commands in the Edit menu.... :):):):):):)

Dave, if you by any chance happen to be at OOPSLA this year, you might come to PLIDE workshop we are organizing, see http://lamp.epfl.ch/~mcdirmid/PLIDE/doku.php
One of the organizers is Sean McDirmid, the author of Scala plugin for Eclipse. He is giving a talk on how Scala plugin is implemented on top of the compiler itself. While I see many problems with IDEA-level support this way, it requires far less work, and given the will for EPFL team to collaborate, this might be a solution for Scala plugin.

Eugene.