"RESTful Web Services"

[Rich Morin]

I've been reading

RESTful Web Services
Leonard Richardson & Sam Ruby
O'Reilly, 2007

Aside from being an interesting and well-written book on
the topic, I was pleased to find that it uses Ruby for
all of its code examples.

-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume (e-mail address removed)
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development

 

[dblack]

Hi --

I've been reading

RESTful Web Services
Leonard Richardson & Sam Ruby
O'Reilly, 2007

Aside from being an interesting and well-written book on
the topic, I was pleased to find that it uses Ruby for
all of its code examples.

That is indeed cool. I remember when Jack Herrington's book on code
generation came out in 2003, also using Ruby for its examples --
definitely a nice way to raise Ruby awareness and demonstrate the
language's strengths.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Mark Volkmann]

I've been reading

RESTful Web Services
Leonard Richardson & Sam Ruby
O'Reilly, 2007

Aside from being an interesting and well-written book on
the topic, I was pleased to find that it uses Ruby for
all of its code examples.

I picked that up recently too and agree that it's a really well
written book ... at least what I've read so far.

 

[Giles Bowkett]

That is indeed cool. I remember when Jack Herrington's book on code

generation came out in 2003, also using Ruby for its examples --
definitely a nice way to raise Ruby awareness and demonstrate the
language's strengths.

Can I just say that this is an absurdly under-rated book? Admittedly I
skipped a lot of its parts, especially the Java stuff, which I think
he only threw in because he had to, but it very much turned my brain
sideways. My new theory, based on this book, is that Unix is Lisp with
a compilation phase. Think about it - how many times have you written
shell scripts to generate new shell scripts, or to generate new lists
of shell commands? How many shell commands do you invoke with a list
of files? Unix is all code generation and lists. It's Lisp in a
different form.

Anyway, long story short, "Code Generation in Action," awesome.

 

[M. Edward (Ed) Borasky]

Can I just say that this is an absurdly under-rated book? Admittedly I
skipped a lot of its parts, especially the Java stuff, which I think
he only threw in because he had to, but it very much turned my brain
sideways. My new theory, based on this book, is that Unix is Lisp with
a compilation phase. Think about it - how many times have you written
shell scripts to generate new shell scripts, or to generate new lists
of shell commands? How many shell commands do you invoke with a list
of files? Unix is all code generation and lists. It's Lisp in a
different form.

Anyway, long story short, "Code Generation in Action," awesome.

Hmmm ... well ... I came to Unix fairly late in its evolution, having
spent most of the previous time as an assembly language and FORTRAN
programmer and having used a range of operating systems dating back to
such primitive beasts as the IBM 7090 without disks to "modern" systems
like Xerox CP-V and VAX/VMS.

My first encounters with Unix were, coming from VAX/VMS, quite
unpleasant. The editors didn't make sense, the whole notion of shell
scripting rather than command files didn't seem useful, etc. I
essentially used FORTRAN as a scripting language.

What changed that was that the company I was working for, Floating Point
Systems, merged with another company, Celerity Computing, that was
making a Unix (4.3 BSD) product. Instantly I had colleagues who knew all
this fancy Unix stuff, could write C code as well as I could write
FORTRAN, etc. It was sink or swim so I learned to swim.

But I don't think Unix is as much about code generation and lists as it
is, at least initially, about text processing. The whole philosophy at
the time, before GUIs, etc., was that developers spent a lot of time
dealing with text files, whether they be code, numeric data, documents
or something else, so Unix should make that easy to automate.

IIRC spell checking was built into the very first versions of Unix, for
example. And I think the core idea of the Unix user interface is not
Lisp, lambda calculus, and AI so much as it is the notion of regular
expressions and the compiler-compiler. Again IIRC, lex and yacc were
also built into the first versions of Unix.

I guess I should get the book.

 

[Giles Bowkett]

[code generation in action tangent]

But I don't think Unix is as much about code generation and lists as it
is, at least initially, about text processing. The whole philosophy at
the time, before GUIs, etc., was that developers spent a lot of time
dealing with text files, whether they be code, numeric data, documents
or something else, so Unix should make that easy to automate.

IIRC spell checking was built into the very first versions of Unix, for
example. And I think the core idea of the Unix user interface is not
Lisp, lambda calculus, and AI so much as it is the notion of regular
expressions and the compiler-compiler. Again IIRC, lex and yacc were
also built into the first versions of Unix.

I guess I should get the book.

Well, it's kind of my own theory based off the book, but it is an
excellent book. I say it that way because of the Paul Graham thing,
praise for Lisp macros, where you have a language sufficiently
malleable to adapt it to the program you're building in it. Being able
to write programs which generate Unix commands is kind of the same
experience - the "compilation phase" comes when you save a shell
script to a text file, or especially when you save a list of files to
a text file, save a Perl script which writes a shell script for you to
a Perl file, run that Perl file to generate that shell script, and
pass it that text file containing a list of files. In Lisp you'd do it
all with macros; in Unix you're saving it to the drive. But it's
still, in either case, code which generates code and handles lists.

Might even be more a metaphor than a theory, but the whole idea of
creating code which creates code, so that you can program at a very
high level, that is actually totally available to anybody who writes
code which runs on Unix. It's not just a Lisp thing.