IDE sale.

[Robert Clark]

JetBrains is apparently having a one-day 75% off sale on their various IDE, which includes one for Ruby.

I am a newbie, and have nothing good or bad to say about JetBrain's products. I just like 75% off sales, and thought I'd pass the info on.

Thanks,
[RC]

[William Hertling]

My company uses RubyMine. I was initially opposed to an IDE, preferring TextMate, but I've grown to like RubyMine. The debugger is effective, it's convenient to run specs within a GUI, and I like the shortcuts to go to definitions and usages, even dynamic ones. -- Will

[Robb Shecter]

It's so slow and wonky — general usability issues because it's not a native app, and they haven't fully compensated for it. It doesn't bug the hell out of you?

(Currently switching from TextMate to Sublime Text.)

[Phillip Kerman]

Have used inteliJ and webStorm (in fact, took advantage of this 75% off for an upgrade).  Sure, they’re way more bloated than something like Sublime Text.  Like any editor you invest a bit of time just learning it.  I will say the debugger integrated in webstorm is pretty decent.  But the in-browser tools are getting pretty good too. 

 

For me the biggest advantage I found in these tools is the refactoring features.  The closest I’ve seen in Sublime text is multi-cursors.  Not really the same thing.

 

Thanks,
Phillip

--
You received this message because you are subscribed to the Google Groups "pdxruby" group.
To post to this group, send email to pdx...@googlegroups.com.
To unsubscribe from this group, send email to pdxruby+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Wilger]

On 12/20, Phillip Kerman wrote:
> For me the biggest advantage I found in these tools is the refactoring
> features. The closest I've seen in Sublime text is multi-cursors. Not
> really the same thing.

That is a nice advantage of RubyMine. I prefer to do 99% of my editing
in vim running inside tmux in a full-screen terminal. I tried RubyMine
a while back and found it was nice for a few tasks and can be helpful to
navigate your way around a (too) large project that you aren't familiar
with. But there was no way I was going to spend $70 on it, since it
wasn't something I was going to use very often at all. I decided to go
ahead and buy a license with the current sale, though; $20 was a little
easier to justify for something I might occasionally reach for.

--
Regards,
John Wilger

http://johnwilger.com
971-678-0999

[FredO]

I have been using RubyMine for about 18months now.  It's been really great for:

finding my way around around other people's code
finding my way around code I haven't seen in a couple of years
refactoring code
debugging code
integrating with git and Hg
automatic code formatting and indenting makes the code easier to read

Beyond that I have been pleasantly surprised by the 3 upgrade of the IDE over the last year.  For example, when I first purchased it, I was a bit dubious about using coffescript and  haml because the debugger couldn't map to your haml statements, and there was no integrated support for haml and coffeescript in the editors.  Those issues have been addressed in the past 12 months, (along a bunch of other features that I haven't even begun to touch).  And let's face it, if you are going to use languages that depend on indentation to indicate scope, it's a blessing to have an IDE that continuously checks for indentation errors as you work.

The git integration has been fantastic. In the project panel, you get a visual cue on which files have been changed since the last commit and (on the directory level) which directories contain files that have been changed.  And it's so easy to generate 3 or 4 a side-by-side visual diffs in new windows with any past version of a one or more files.  And selectively overriding changes in the newer files can be done with a button click.

And the on-the-fly syntax checking (which uses a lot of CPU) is a blessing as you get older, and your fine motor skills start to degrade and your fingers don't always type out exactly what your brain tells them to.

Having said that, it be a bit of a process getting it to work in a shared RVM environment where the gems are installed under /usr/local/rvm with ownership by root.  The IDE detects when when there are missing gems and offers to install them for you, and since you are generally not root while you are editing code, it doesn't work.  ( You also have to start up the IDE from the command line to get your GEM_PATH set correctly in the IDE.) However in a private RVM set-up this works well.

Also note you will need Java 1.6, since they haven't finished porting it to Java 7

[William Hertling]

I haven't found it to be slow, but I have found that it can get wonky in its ability to parse big/complex files. It'll suddenly get confused, and then syntax highlighting and helpers suddenly stop working. That does bug me.

Also, the refactoring never seems to work right for me. It always tries to change unrelated method calls. I don't know why, and it doesn't seem like it is a problem for other people in this topic.

[Kerri Miller]

On Thu, Dec 20, 2012 at 11:45 AM, Robb Shecter <ro...@weblaws.org> wrote:
> It's so slow and wonky — general usability issues because it's not a native
> app, and they haven't fully compensated for it. It doesn't bug the hell out
> of you?

My experience with RubyMine as well. :(

> (Currently switching from TextMate to Sublime Text.)

Did that a few months back, never been happier. (Would love to see
your prefs file, if you feel like sharing.)

-k-

[markus]

> Also, the refactoring never seems to work right for me. It always

> tries to change unrelated method calls. I don't know why, ...

You don't suppose the fact that static identification of the method
called by any given line of ruby is equivalent to the halting problem
and thus provably impossible has anything to do with it, do you?

> and it doesn't seem like it is a problem for other people in this
> topic.

This is an amazing (but easily demonstrable) bug in how our brains deal
with consensus around tool use. If enough of us believe that the
majority of us believe that something works, we'll all act as if it
works "for other people" even if it regularly fails for all of us. This
applies to everything from prayers to the stone statue of Yedophanpo to
cool features of the iPhone. Instead of blaming the tool, people will
adamantly, persistently blame themselves.

-- Markus

[Matthew Boeh]

On Fri, Dec 21, 2012 at 7:54 PM, markus <mar...@reality.com> wrote:

> Also, the refactoring never seems to work right for me. It always

> tries to change unrelated method calls. I don't know why, ...

You don't suppose the fact that static identification of the method
called by any given line of ruby is equivalent to the halting problem
and thus provably impossible has anything to do with it, do you?

 If RubyMine is trying to solve that problem, it's both impressive and foolish. I wouldn't surprise if it's sometimes confounded even without trying to do so, though. If what it changes is confusing to an experienced Ruby developer, I suspect it's either far too clever or not nearly clever enough.

Smalltalk users have profitably used refactoring browsers for decades, and the problem isn't that much less difficult in Smalltalk, right?

[Monty Williams]

It's much less difficult in Smalltalk. All the code lives in a coherent image, not in separate files. You always know the senders and implementors of any method. You can take advantage of true object identity.

We really learned how much more difficult Ruby is to implement than Smalltalk when developing MagLev.

-- Monty

[markus]

> Smalltalk users have profitably used refactoring browsers for decades,
> and the problem isn't that much less difficult in Smalltalk, right?

I see that Monty already responded, but I have to second what he said.
The problem is far, far easier in Smalltalk. Or, to put it the other
way, the range if things you can say with certainty about a piece of
Smalltalk at development time is much greater than what you could say
about a similar piece of Ruby.

-- Markus

[Ian Goodrich]

Given how useful it's been to me, I feel obliged to chime in here and defend the honor of poor RubyMine, including its refactoring support.

I've used vim, emacs, and textmate for extended periods of time, and poked around with SublimeText2 a bunch, and RubyMine is what I've settled on for every day rails project work.  I think its ugliness and clunkiness are what understandably turns folks off.  You can configure your way out of this unfortunate largesse to some extent, but it's never going to feel as light and nimble as, say, vim.

If I were working on small projects, I might not use RubyMine at all.  For large projects, it's a godsend, particularly for researching how features work or how you might go about implementing something.  The code navigation plus the find features are fantastic and seamlessly include not only your project files but also your libraries.  In my experience, RubyMine is way faster than ack for searching through files; I think this is because it indexes everything in a slightly better than text only way. Again, not such a big deal on small projects where ack is pretty quick; larger projects, it can matter a lot.  It's also very natural to root a search in a particular directory, something I've find surprisingly awkward, though achievable, with some other tools.  RubyMine has become particularly good at navigating to the definitions of methods and classes.  Yes, I've used tags; my experience has been that they are awkward, inaccurate, and a pain to keep up to date.

Now on to the refactorings.  In my experience, the refactorings that are local to a file work pretty much flawlessly.  I use extract method, rename variable, extract variable, and inline variable as natural extensions of editing.  I know the keyboard shortcuts and toss them around several times a day.  Extract method can be particularly handy if you're working with a long, gnarly method.  I've really missed the support for these refactorings when on occasion I've been tempted back to vim or SublimeText2.

Rename method in ruby is a tricky beast, as you can imagine.  I pity the poor jetbrains soul who has to implement it, tbh.  The IDE respects the difficulty though and treats it like a slightly more intelligent find/replace, presenting you with all the places it thinks it needs to change and let's you exclude/include them. For methods with distinctive names, it's spot on -- just like you would be with find/replace except it's faster and easier to do.  For methods with names like #run I don't really bother and fall back to the excellent cross file find/replace like I would with a purely text based tool.  I don't really blame the IDE for not being able to deal with Ruby for this kind of thing.

I use the research parts of the git integration, but use gitx and the command line to commit and do various other kinds of research.  RubyMine is excellent at keeping in synch with the file system, so that's not a problem.  In general, one can switch back and forth between the command line or other tools and not pay a synchronization penalty.  RubyMine also keeps its own local history of any changes, which has saved me big time a few times.

The debugger is easy to use and very reliable.  I generally just run my rails server in debug mode and then set breakpoints when it strikes my fancy.

It's got excellent support for the panoply of languages and file formats you experience on a rails project.

RubyMine takes a while to get used to and configure.  I don't think the learning curve is really much less steep than vim or emacs.  Well, than vim anyway :).  This can be confusing because at first its doing a poor imitation of being friendly and easy to use, and it's really neither.

Oh -- one last thing -- you basically need an SSD and a lot of memory.  It's a total pig and if you let it get hungry, it might well try to eat your toes. Now that I'm fortunate enough to have a screaming fast machine, I put this mostly in the aesthetically displeasing category.  Worth noting though and probably another cause for peoples very mixed reactions.

Dear RubyMine, pelase consider your honor defended.  I did my best, anyway :)

Ian

[Ward Cunningham]

Monty points out that everything is simpler when your world is within your reach. Everything.

This raises the question: are there limits on the size of an agile project? Perhaps the limits of your reach?

I think agile could scale larger but it would take some new thinking about refactoring. Would it be possible, for example, to refactor an API used by millions? How would that work? We're talking about computers here so think big? How could we change an API used by millions?

Here is my scheme: Let's say 1/10 of one percent of your users write test cases against your API and share them with you. Perhaps you promise to run them whenever considering breaking changes and bring them into your decision loop when you feel the need to go ahead and break things.

Consider also that you have a refactoring engine that can record every change you make as a refactoring script. Eclipse has (had) this feature but it has not been applied as I am describing in spite of my enthusiasm.

Now, suppose that your refactoring script shows that when applied to your contributed test cases that the refactored cases continue to pass? Would you then feel justified publishing those refactoring scripts as you deprecate an API used by millions?

Surely this will create grief for someone. But most people I know say that you can never break an API and that makes its own kind of grief.