BBedit or TextMate?

[William Hertling]

I am just making the switch from Windows to Mac. (Yay. Ruby on Windows
sucks as a development platform.)

I am going to plunk down a bit of cash for either BBedit or TextMate.
90% of what I will be Ruby and Rails work. Any strong reasons to go
with one versus the other? It seems like there are Ruby developers in
both camps.

Thanks,
Will

[Jerry Hilts]

There are users who swear by both, so it's probably going to depend on your personal preferences.

I'm definitely in the TextMate camp. It integrates well with the command line and various *nix tools & commands. It also is amazingly configurable/extensible via its 'bundles' interface. I like to think of TextMate as a sane, Mac-like, version of emacs that I can tweak using Ruby instead of Lisp.

j.

> --
>
> 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 this group at http://groups.google.com/group/pdxruby?hl=en.
>
>

[Christopher Bailey]

They both have demo/trials I think, so probably best to try both out and see which you like.  For me it's no contest: TextMate.  I actually don't know any Ruby devs (i.e. that I know personally) that are using BBEdit these days.  I used it a lot "back in the day", but haven't for quite some time, just seems not-up-to-date UI wise and TextMate has worked really well for me.  Oh, and of course TextMate 2 will be here any day now ;-)

--

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 this group at http://groups.google.com/group/pdxruby?hl=en.

--
Christopher Bailey
Cobalt Edge LLC
http://cobaltedge.com

[Sam Livingston-Gray]

First off, this could be seen as a classic flamewar troll: geeks are
passionate about their editor of choice. I'm hoping we can avoid that.

Really, people. Let's avoid that, mmkay? (=

That being said...

On Dec 2, 2009, at 12:07 PM, William Hertling wrote:
> I am going to plunk down a bit of cash for either BBedit or TextMate.
> 90% of what I will be Ruby and Rails work. Any strong reasons to go
> with one versus the other? It seems like there are Ruby developers in
> both camps.

Personally, I get a lot of mileage out of TextMate -- its snippets are
easily one of the most powerful features I've ever seen in an editor
that wasn't an IDE, and I also use regex find/replace and column-edit
mode quite regularly. Being able to pass a highlighted chunk of text
out to a shell script (and bind that action to a keystroke) is also
incredibly useful.

Ultimately, the choice of one editor vs. another is probably not that
big a deal (at least, not within a given class of editor: obviously,
Notepad vs. Emacs is not a fair comparison). Whichever one you pick,
just take the time to learn enough of its features that you'd complain
bitterly if someone forced you to use something else.

Put another way: if changing editors doesn't seem like that big a
deal to you, either you're not using a good enough editor or you don't
know your editor well enough.

Hope this helps,
-Sam

[Duncan Beevers]

I think you'll find lots of arguments for various editors.  The decision kind of comes down to how you program and what features you need.

Be aware that there are many powerful, free editors available.
vim: http://macvim.org/OSX/index.php
emacs: http://emacsformacosx.com/
Aptana radrails: http://aptana.com/
jEdit: http://jedit.org/

In the for-pay camp there are a number of powerful options:
JetBrains RubyMine: http://www.jetbrains.com/ruby/
Komodo: http://www.activestate.com/komodo/

That said, I use TextMate and only curse it out once or twice a day.

[Brent Miller]

I'm partial to TextMate, except for one case: it's horrible at dealing
with large files. If, for example, you wanted to open and edit a 28
meg file, BBEdit has infinitely better performance. I keep around a
copy of the free low-weight version of BBEdit (TextWrangler) for just
those situations. Otherwise I like how the TextMate interface steps
out of the way and lets me code.

=======================================================
Brent Miller
http://www.foliosus.com/

"The problem is that once you have done away with the
ability to make judgments as to right and wrong, true
and false, etc., there's no real culture left. All
that remains is clog dancing and macrame."
-- Neal Stephenson
=======================================================

[Sam Livingston-Gray]

On Dec 2, 2009, at 12:22 PM, Brent Miller wrote:
> I'm partial to TextMate, except for one case: it's horrible at dealing
> with large files.

Excellent point. Just today, I had to resort to some command-line
trickery to slice out a small piece of a 60MB log file because I knew
it would choke TextMate.

Aside from that, though, I'm basically stuck on the Mac for the
foreseeable future because of TextMate. (=

-Sam

[Craig McClanahan]

On Wed, Dec 2, 2009 at 12:19 PM, Duncan Beevers <duncan...@gmail.com> wrote:
> I think you'll find lots of arguments for various editors.  The decision
> kind of comes down to how you program and what features you need.
>
> Be aware that there are many powerful, free editors available.
> vim: http://macvim.org/OSX/index.php
> emacs: http://emacsformacosx.com/
> Aptana radrails: http://aptana.com/
> jEdit: http://jedit.org/
>

NetBeans (http://netbeans.org) is worth considering as well ... quite
nice support for Ruby, Rails, debugging, and it even supports all the
TextMate snippets, plus letting you define your own :-)

Craig McClanahan

[Markus]

All --

Here's something that's frustrating me. I can write a test like:

[1,2,3].should_not be_include(0)

but if want to write something like:

[1,2,3].should_not be_any { |x| x < 0 }

the test always fails.

Grr.

-- Markus

[Bill Burcham]

I feel your pain brother.

[Reid Beels]

You could, of course, write it another way, but that's hardly the point.

[1,2,3].any?{ |x| x < 0 }.should_not be_true

This would seem to be the ticket of interest:
https://rspec.lighthouseapp.com/projects/5645/tickets/905-predicate-matchers-ignore-block-arguments

Reid

[Bill Burcham]

Speaking of F/OSS I recommend TECO-6 a.k.a. "Real Time" TECO. Here's a good TECO download page.

[Bill Burcham]

Shouldn't that be:

[1,2,3].any?{ |x| x < 0 }.should_not == true

[Ben Bleything]

On Wed, Dec 2, 2009 at 5:27 PM, Bill Burcham <bill.b...@gmail.com> wrote:
> Shouldn't that be:
> [1,2,3].any?{ |x| x < 0 }.should_not == true

Either will work. should_not be_true reads better to me.

Ben

[Markus]

> You could, of course, write it another way, but that's hardly the point.
>
> [1,2,3].any?{ |x| x < 0 }.should_not be_true
>
> This would seem to be the ticket of interest:
> https://rspec.lighthouseapp.com/projects/5645/tickets/905-predicate-matchers-ignore-block-arguments

Exactly. It should even be easy enough to patch around. But, as you
say, that's hardly the point.

The real issue isn't that you can't do it, it's that there's no
indication that you can't do it. To put a finer point on it, the
corresponding test:

[1,2,3].should be_all { |x| x < 0 }

will always pass.

I do not like it, Sam I am.

-- Markus

[Bill Burcham]

Is be_true a special case?

[Ben Munat]

Markus, a thread-jumper? Never would have thunk it.

b

(top-posted, of course...)

[Bill Burcham]

I've run into precisely that issue before (spec succeeding for the
wrong reason). And specifically, w the all/any methods. Ended up
rearranging it to work (will dig up the result in a while). But I'm
sure that necessitated a big ole ugly comment in the code. A comment I
am sure I did not repeat in every instance.

[Markus]

On Wed, 2009-12-02 at 18:40 -0800, Ben Munat wrote:
> Markus, a thread-jumper? Never would have thunk it.

I started to reply indignantly that I'd started this thread, but I
decided to see if I could see what made you think that I was a cad. On
evolution (on my linux desktop) and on my blackberry this is its own
thread. But on "Mail" (the generic mail reader on my MacBook) it shows
up merged with the "BBEdit or TextMate" thread. And on GMail it isn't
showing up at all (*sigh*). No idea how it looks to MS Windows, if
anyone is still using that.

>From this I deduce that you're probably using a Mac.

-- Markus

P.S. I am sorry about jumping threads in the Mac-version of reality, and
if I knew how it happened I'd promise not to do it again.

[Ben Munat]

Fair enough. (Yes, on a Mac, but reading in the horrid Thunderbird.)
That's weird that you didn't hit reply to the the bbedit/tm thread.

I didn't really care that much, but was in a punchy mood. And glad to
see you care. :-)

b

[Ben Bleything]

On Wed, Dec 2, 2009 at 6:36 PM, Bill Burcham <bill.b...@gmail.com> wrote:
> Is be_true a special case?

I'm not sure I would call it a special case as such... it is an
"assertion" (I can't remember the proper rspec term) that rspec
provides.

Ben

[Jacob Helwig]

Matchers, IIRC.

-Jacob

[Sam Goldstein]

I've wished for this matcher in rspec myself on occasion.

It is very easy to define your own custom matchers including ones that iterate arrays.

I'm suspecting that they may not be included in rspec by default since it's very hard to write good failure messages for these.

http://gist.github.com/248868

~sam

http://drasticcode.com

-------------

require 'rubygems'

require 'spec'

describe "all_be" do

  def all_be &block

    simple_matcher "all be" do |given, matcher|

      matcher.failure_message = "expected #{given.inspect} to all be something"

      given.all? &block

    end

  end

  def have_any &block

    simple_matcher "all be" do |given, matcher|

      matcher.failure_message = "expected #{given.inspect} to have at least one something"

      matcher.negative_failure_message = "expected #{given.inspect} to not have any something"

      given.any? &block

    end

  end

  it "positive numbers should all be greater than 0" do

     [1,2,3].should all_be { |x| x > 0 }

  end

  it "positive numbers should not have any less than 0" do

     [1,2,3].should_not have_any { |x| x < 0 }

  end

end

[Sam Goldstein]

One other way to write `[1,2,3].should_not be_any { |x| x < 0 }` that results in more descriptive output:

[1,2,3].each do |number|

  it "#{number} should not be less than 0" do

    (number < 0).should be_false

  end

end

Now my test output looks like:

  1 should not be less than 0

  2 should not be less than 0

  3 should not be less than 0

~s

[Markus]

> One other way to write `[1,2,3].should_not be_any { |x| x < 0 }` that
> results in more descriptive output:

> [1,2,3].each do |number|
> it "#{number} should not be less than 0" do
> (number < 0).should be_false
> end
> end

> Now my test output looks like:
> 1 should not be less than 0
> 2 should not be less than 0
> 3 should not be less than 0

More verbose, perhaps, but not really more descriptive. In the failure
case (which is when you really want the error message to make sense) you
will see something like this:

-1 should not be less than 0

which is patently absurd. -1 certainly should be less than zero, or
much of conventional mathematics shears off and slides into the sea.
The problem is, the original test was trying to make a statement about
the array, not about its elements.

> I'm suspecting that they may not be included in rspec by default since
> it's very hard to write good failure messages for these.

Eh. They allow

[1,2,3].any? { |x| x < 0 }.should be_false

Which is no easier to write a good descriptive test for.

>
> http://gist.github.com/248868
>

Yeah. I wound up doing a custom matcher that was more task specific.
The general case on yours could be tweaked to make it a little more
descriptive:

def all_be(desc='something') &block

simple_matcher "all be" do |given, matcher|
matcher.failure_message =

"expected #{given.inspect} to all be #{desc}"
matcher.negative_failure_message =
"expected #{given.inspect} to not all be #{desc}"
given.all? &block
end
end

Letting us write:

[1,2,3].should all_be('positive') {|x| x > 0 }

Still though, the real problem is a framework that has edge cases like
this in the first place. If the be_xxx matchers are going to ignore the
blocks they should raise an exception if given a block. Otherwise, it
is yet another way in which your tests can look like they are proving
something when in fact they are doing nothing of the sort.

-- Markus

[Sam Goldstein]

Still though, the real problem is a framework that has edge cases like
this in the first place.  If the be_xxx matchers are going to ignore the
blocks they should raise an exception if given a block.  Otherwise, it
is yet another way in which your tests can look like they are proving
something when in fact they are doing nothing of the sort.

This is why I always consider it important to see the test fail before you make it pass (even if this means breaking/commenting code you've already written).  If you assume that the test is testing what you think because it looks right you're bound to have cases where its passing for erroneous reasons. 

[Bill Burcham]

Great point Sam!

[Bryan]

I find this especially true when mocking/stubbing a lot.  I once found myself accidentally stubbing out a method that was being tested indirectly.  I think it was in a controller where I was testing that a user needed to be logged in.. but I had forgotten that I stubbed out the "logged_in?" method in the controller. Something like that.

[Markus]

That isn't really a guarantee of anything though (c.f. my most recent
hangman code). This is an age old problem (Quis custodiet ipsos
custodes anyone?) and adding another layer of technology or an
additional best practices ritual isn't going to solve it.

-- Markus