Today Joe Gregorio pointed the Ape at his “apptestsite” and found some problems. And the Ape found some problems with his stuff too. So we both fixed ’em and the Ape’s much happier. This is fun!
There are still grumbles
about Joe dropping foreign markup (a dc:subject) and not
accepting an input category, but his code is within its rights.
Doesn’t mean I’ll take the complaints out, they’re useful information about
the quirks of one particular implementation.
I bet there’ll pretty quickly be market pressure for APP server implementations to preserve at least some foreign markup. Those guys pushed back pretty hard in the WG about writing that requirement into the spec, which is fair enough, but shooting ad-hoc extension markup around is just going to be too useful, I bet.
Hey, Joe’s server actually has paged collections with
<link rel="next" />, the first I’ve seen; but the Ape’s not
seeing them for some reason, that’s a job for tomorrow.
My logfiles say there were a couple of dozen different computers out there exercising the Ape today, and Ben Lund sent along a couple of good patches; thanks!
Q: Are Globals Ever OK? ·
When I was learning Ruby, I found out it had global variables a
la Perl, with a $ in front. Ewww, I thought.
But then in the Ape code there are some manifest constants, in particular the
namespace names for Atom and APP and XHTML, as well as well-known MIME types.
They need to be centralized and have symbolic names because they change,
albeit rarely.
I was thinking of having a Constants class or module so I could say
Constants::AtomNamespace or some such. But then I thought
“simpler is better” and just used $atomNamespace,
$appNamespace, and so on.
Should I feel unclean?
[Update: OK, the commenters convinced me, that was unclean. There’s now
names.rb and I can say things like
Names::XmlNamespaces and
Names::AtomMediaType.]
(Oh, and Ruby needs an IDE. Because I want to change the names of these
things to make them more readable and I want to change the name of the file
that defines them from namespaces.rb to constants.rb
because I want to add media-types. Without an IDE, this will involve several
minutes of tedious error-prone editing. With one, it’s a fail-safe point and
click.
Sigh.)
Contributions
Comment feed for ongoing:
From: Thijs van der Vossen (Mar 13 2007, at 01:03)
Why not use Ruby constants? Just define ATOM_NAME_SPACE and APP_NAME_SPACE in your top level module.
(Oh, and Ruby does not need an IDE, you dear Sir need TextMate. Ok, you'll still have to change the filename yourself, but with the very nice 'Find in Project' [1] there's no need for several minutes of tedious error-prone editing at all.)
[1] http://macromates.com/textmate/manual/working_with_multiple_files#find_and_replace_in_projects
[link]
From: Noah Slater (Mar 13 2007, at 01:33)
We don't need ANOTHER editor Tim.
http://diveintomark.org/archives/2007/01/21/wrongroom
Oh, and yes - I think you should feel, perhaps, a little guilty for using global variables.
[link]
From: Dominic Mitchell (Mar 13 2007, at 01:48)
In Ruby, it's more common to have constants as ALL_CAPS, in a namespace. In fact, the language assures this for by not letting you change the value of anything which starts with a capital.
As an aside, that's how classes / modules are implemented. "class Foo" creates a constant with class object for Foo in it.
[link]
From: Peter Wilkinson (Mar 13 2007, at 04:13)
How about using "sed -i s/\$atomNamespace/whateveryouwanttochangeitto/ *.c"?
[link]
From: Bruce Walker (Mar 13 2007, at 05:22)
Re "Ruby needs an IDE else error-prone editing": two words, "run glimpse".
[link]
From: James Yopp (Mar 13 2007, at 05:46)
If you're using TextMate, try the "Replace in Project..." option. You can use Perl Regular Expressions if necessary -- not for the faint of heart, but quite useful -- and just replace your constants lock, stock, and barrel throughout the whole project.
TextMate will present you with all the matches first in a list, and you can command-click a subset of them to replace, if that is your fancy.
[link]
From: Dave Brondsema (Mar 13 2007, at 07:14)
Is an IDE that provides refactoring support, content-assist, etc, even possible with a dynamically typed language?
[link]
From: Geoffrey Wiseman (Mar 13 2007, at 08:22)
Well, given that many of the significant Java IDEs are making headway on Ruby support (Netbeans betas, IDEA plugin, RDT significant update due shortly, Aptana taking up the RadRails development), you may have a fair amount of choice in Ruby IDEs soon (not to disparage the existing Ruby IDEs/Editors; I haven't used them enough to compare).
[link]
From: anders pearson (Mar 13 2007, at 09:07)
M-x find-dired [Enter]
(make sure it's in the right directory) [Enter]
-name '*.rb' [Enter]
% m rb$ [Enter] (or just mark individual ones with 'm')
M-x dired-do-query-replace-regexp [Enter]
regexp-to-search-for [Enter]
string-to-replace-with [Enter]
Then don't forget to save.
Or there's M-x tags-query-replace if you have TAGS set up. If you use speedbar (I don't), I think it provides a way to do it with more of a notion of a "project" than just a directory.
[link]
From: assaf (Mar 13 2007, at 10:14)
Is integreated debugger, source control, test tool, and an army of wizards -- are these all necessary for the task you're trying to do, which is essentially a smarter search & replace?
[link]
From: assaf (Mar 13 2007, at 10:33)
Re: globals
They're a pain. When you pull one library from here, another library from there, and they both use the same globals in conflicting ways, not to mention problems you'll get with concurrency, and code using shared variables doesn't scale as easily.
But I guess you're doing none of that.
How can anything used properly not be OK?
[link]
From: Bob Haugen (Mar 13 2007, at 18:01)
Re "Is an IDE that provides refactoring support, content-assist, etc, even possible with a dynamically typed language?"
The original IDE and refactoring browser were in Smalltalk.
[link]
From: Dan Davies Brackett (Mar 13 2007, at 21:39)
Ah, Good Old Editor Flamewars. At least ongoing is efficient -- in 14 comments, we've gone through the entire ritualistic war: a bunch of descriptions of different editors and how to achieve what the originator wanted, at least one reference to a *different* flamewar on the same topic, and a vaguely humorous attempt to summarize the war and thereby blunt it a little.
[link]
From: John Cowan (Mar 13 2007, at 22:49)
'ed' is the standard editor. (I personally use 'ex', being willing to trade a little minimalism for a little clarity.)
[link]