Rails - Jul 2005 - RE: Newbie: Anything like [ www.php.net/manual/ ] for Ruby &RoR ?

> I am not a CS guy, but I managed to pick up PHP because it 
> was easy to learn and had good easy to digest information, 
> and I''m hoping for the same here with RoR & Ruby.
Correct me if I''m wrong here, folks, but although there''s tons
of
tutorials and Wiki-type info out there, I kind of think your best bet is
to RTFB.  Kind of like you, I''m not a CS guy and I''m coming
from
experience with a procedural language, too (ColdFusion, in my case).
Because Rails is a *framework* and an object-oriented, MVC one at that,
it''s been really helpful for me getting my head wrapped around these
totally different concepts by following the RoR shopping cart
"tutorial"
in the book.

My take is that with PHP or ColdFusion, you can quickly look up
functions and syntax in an online manual and hack together bits and
pieces of an app pretty easily but I don''t think this is really the
case
with Rails because it''s a entire development framework... it helps to
really understand how the entire thing works and fits together.

Really, the book is good and easily to follow along.

One strength of the PHP docs, though, is how they''re just so damned
granular. Yeah, a poor software architect can use them to just hack
together an app using the predefined functions, but lately I''m using
them mostly to search for a concept (''php.net/functions'') or
to check
my knowledge before I start coding something that won''t work.
(It''s
amazing how often I think I can do something in PHP that''s not
possible, just because I''ve gotten used to doing it in Ruby or even
JavaScript...I mean PHP doesn''t even have try/catch/throw...)

Basically it comes down to finding out: will this statement do what I
need it to do?


One other thing the PHP docs do right: _examples_. Lots of examples,
organized by statement, so that if you think you might need to use
method_exists it''s very easy to see how to implement it. Some of the
nerdier RoR list peeps might think examples are for people who are too
dumb to understand how to use a framework, but I would point out a few
things about a lot of PHP programmers:


* A lot of us are artists/designers who picked up some PHP because
they needed something they couldn''t get from purely client-side
technologies, and either couldn''t afford to hire a programmer or
didn''t know one _could_ hire a programmer.

* A lot of us, while not down with the whole framework thing, are
wicked smart about structure. I know/work with a number of PHP coders
who may not have been computer science majors but have a solid sense
of architecture from having studied music, design, (yes) architecture
or (in my case) cinema studies. Us artist-programmers are also
aesthetes who _love_ clean code. You CS guys may love Rails, but we
are the people who _need_ Rails.

* A lot of us are visual learners. It''s one thing to read an
explanation of the functionality of has_and_belongs_to_many, or to see
a flowchart of the table relationships. But sometimes what''s needed is
some example code that basically tells you "if you put a :join_table
=> ''blah'', :foreign_key => ''foo'' here,
it will do something cool". It
overcomes a lot of learning barriers quickly.


RailDock looks good, but it''s still a little arcane -- it''s
got the
level of detail, but the organization isn''t the same. The API docs
have the organization, but in most places lacks the right level of
detail. More can be done, I think, to make sure the best web apps
framework out there has the best documentation out there.


On 7/14/05, Dean Matsueda <dmatsueda-1n2u0cAa2q8@public.gmane.org>
wrote:
> > I am not a CS guy, but I managed to pick up PHP because it
> > was easy to learn and had good easy to digest information,
> > and I''m hoping for the same here with RoR & Ruby.
> 
> Correct me if I''m wrong here, folks, but although there''s
tons of
> tutorials and Wiki-type info out there, I kind of think your best bet is
> to RTFB.  Kind of like you, I''m not a CS guy and I''m
coming from
> experience with a procedural language, too (ColdFusion, in my case).
> Because Rails is a *framework* and an object-oriented, MVC one at that,
> it''s been really helpful for me getting my head wrapped around
these
> totally different concepts by following the RoR shopping cart
"tutorial"
> in the book.
> 
> My take is that with PHP or ColdFusion, you can quickly look up
> functions and syntax in an online manual and hack together bits and
> pieces of an app pretty easily but I don''t think this is really
the case
> with Rails because it''s a entire development framework... it helps
to
> really understand how the entire thing works and fits together.
> 
> Really, the book is good and easily to follow along.
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 

=== === === === === === === === === === ===
==ddemaree-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org  
http://practicalmadness.com/

PHP5 fully supports exception handling now.
They do lack a ''finally'' clause, which is a shame.
PHP5 is a lot better than 4. Pick up my book on PHP5 to learn more. :)



On Jul 14, 2005, at 5:30 PM, David Demaree wrote:
> One strength of the PHP docs, though, is how they''re just so
damned
> granular. Yeah, a poor software architect can use them to just hack
> together an app using the predefined functions, but lately I''m
using
> them mostly to search for a concept (''php.net/functions'')
or to check
> my knowledge before I start coding something that won''t work.
(It''s
> amazing how often I think I can do something in PHP that''s not
> possible, just because I''ve gotten used to doing it in Ruby or
even
> JavaScript...I mean PHP doesn''t even have try/catch/throw...)
>
> Basically it comes down to finding out: will this statement do what I
> need it to do?
>
>
> One other thing the PHP docs do right: _examples_. Lots of examples,
> organized by statement, so that if you think you might need to use
> method_exists it''s very easy to see how to implement it. Some of
the
> nerdier RoR list peeps might think examples are for people who are too
> dumb to understand how to use a framework, but I would point out a few
> things about a lot of PHP programmers:
>
>
> * A lot of us are artists/designers who picked up some PHP because
> they needed something they couldn''t get from purely client-side
> technologies, and either couldn''t afford to hire a programmer or
> didn''t know one _could_ hire a programmer.
>
> * A lot of us, while not down with the whole framework thing, are
> wicked smart about structure. I know/work with a number of PHP coders
> who may not have been computer science majors but have a solid sense
> of architecture from having studied music, design, (yes) architecture
> or (in my case) cinema studies. Us artist-programmers are also
> aesthetes who _love_ clean code. You CS guys may love Rails, but we
> are the people who _need_ Rails.
>
> * A lot of us are visual learners. It''s one thing to read an
> explanation of the functionality of has_and_belongs_to_many, or to see
> a flowchart of the table relationships. But sometimes what''s
needed is
> some example code that basically tells you "if you put a :join_table
> => ''blah'', :foreign_key => ''foo''
here, it will do something cool". It
> overcomes a lot of learning barriers quickly.
>
>
> RailDock looks good, but it''s still a little arcane --
it''s got the
> level of detail, but the organization isn''t the same. The API docs
> have the organization, but in most places lacks the right level of
> detail. More can be done, I think, to make sure the best web apps
> framework out there has the best documentation out there.
>
>
> On 7/14/05, Dean Matsueda <dmatsueda-1n2u0cAa2q8@public.gmane.org>
wrote:
>
>>> I am not a CS guy, but I managed to pick up PHP because it
>>> was easy to learn and had good easy to digest information,
>>> and I''m hoping for the same here with RoR & Ruby.
>>>
>>
>> Correct me if I''m wrong here, folks, but although
there''s tons of
>> tutorials and Wiki-type info out there, I kind of think your best  
>> bet is
>> to RTFB.  Kind of like you, I''m not a CS guy and I''m
coming from
>> experience with a procedural language, too (ColdFusion, in my case).
>> Because Rails is a *framework* and an object-oriented, MVC one at  
>> that,
>> it''s been really helpful for me getting my head wrapped around
these
>> totally different concepts by following the RoR shopping cart  
>> "tutorial"
>> in the book.
>>
>> My take is that with PHP or ColdFusion, you can quickly look up
>> functions and syntax in an online manual and hack together bits and
>> pieces of an app pretty easily but I don''t think this is
really
>> the case
>> with Rails because it''s a entire development framework... it
helps to
>> really understand how the entire thing works and fits together.
>>
>> Really, the book is good and easily to follow along.
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>
>
> -- 
>
> === === === === === === === === === === === ==>
ddemaree-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org   http://practicalmadness.com/
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 7/14/05, David Demaree
<ddemaree-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I mean PHP doesn''t even have try/catch/throw...)
Sure it does:
http://php.net/manual/en/language.exceptions.php


-- 
Greg Donald
Zend Certified Engineer
MySQL Core Certification
http://destiney.com/

As one of the just plain stupid guys on the block, I agree here.  
Examples are good, and there is a need for all the documentation we can 
find/create/scrape together.  Perhaps we can start from Raildock and go 
from there when the source is released, but we need some sort of 
comprehensive resource where this poor RoR developer can go for all his 
documentation needs :-)
>
>RailDock looks good, but it''s still a little arcane --
it''s got the
>level of detail, but the organization isn''t the same. The API docs
>have the organization, but in most places lacks the right level of
>detail. More can be done, I think, to make sure the best web apps
>framework out there has the best documentation out there.
>  
>
Ben Robison


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.15/49 - Release Date: 7/14/2005

On 14 Jul 2005, at 21:46, Dean Matsueda wrote:
> Correct me if I''m wrong here, folks, but although there''s
tons of
> tutorials and Wiki-type info out there, I kind of think your best  
> bet is to RTFB.
As I said, I''ve got both books and is reading them, but the PickAxe  
II book is so poorly structured and dry to read that I fall asleep  
within seconds. Yesterday I tried to look up the =begin ... =end  
commenting syntax that I vaguely remembered reading about somewhere.  
5 min''s of looking through the book provided NO help. (might just be  
me and my eyes though)

The RoR book is better, but written by very much the same guys - even  
though DHH et al has improved it I''m sure -, so is not exact and  
direct to the point all the times, and introduces new things like  <%  
for product in @products -%>  where the -%> was not explained until  
much later. Even a look into the PickAxe II didn''t answer my  
question, nor did google. Only the IRC channel of RoR did, but that  
was after roughly 10 min''s of looking.

In other words, all the productivity boost from RoR can be lost  
through bad documentation and information access.
> Because Rails is a *framework* and an object-oriented, MVC one at  
> that, it''s been really helpful for me getting my head wrapped  
> around these totally different concepts by following the RoR  
> shopping cart "tutorial" in the book.
Yes the Depot tutorial is good, and I''ve been following it, but it is  
not the end all be all. Besides it''s written by people that know this  
stuff and therefore naturally take things for granted that newbies  
like me - and others - don''t know.
> Really, the book is good and easily to follow along.
Yes, probably it is, but it''s NOT a source that I could easily  
reference like I can with the PHP.net manual is it, and that''s what I  
was asking for.

Kind regards,

Mats

----
"TextMate, coding with an incredible sense of joy and ease"
- www.macromates.com -

On 14 Jul 2005, at 22:30, David Demaree wrote:
> One strength of the PHP docs, though, is how they''re just so
damned
> granular. Yeah, a poor software architect can use them to just hack  
> together an app using the predefined functions, but lately I''m  
> using them mostly to search for a concept
(''php.net/functions'') or
> to check my knowledge before I start coding something that won''t
work.
> Basically it comes down to finding out: will this statement do what  
> I need it to do?
Exactly ! The PHP doc''s (offline/online) are not my favourite bedtime  
reading, but they help me when I need it and they do so FAST and  
concisely !

> One other thing the PHP docs do right: _examples_. Lots of  
> examples, organized by statement, so that if you think you might  
> need to use method_exists it''s very easy to see how to implement
it.
AMEN!

> Some of the nerdier RoR list peeps might think examples are for  
> people who are too dumb to understand how to use a framework, but I  
> would point out a few things about a lot of PHP programmers:
>
> * A lot of us are artists/designers who picked up some PHP because  
> they needed something they couldn''t get from purely client-side
> technologies, and either couldn''t afford to hire a programmer or  
> didn''t know one _could_ hire a programmer.
Or just wanted to do stuff ourselves without depending on programmers  
that were not necessarily on the same planet as us ;)

> * A lot of us, while not down with the whole framework thing, are  
> wicked smart about structure. I know/work with a number of PHP  
> coders who may not have been computer science majors but have a  
> solid sense of architecture from having studied music, design,  
> (yes) architecture or (in my case) cinema studies.
AMEN again !  I''m a (ex-)? photographer, and began working on my own  
PHP ''frameworks'' similar to MVC long long before I even knew
of
programming Design patterns, RoR or anything else that CS/programmers  
take for granted. MVC is not something supremely smart, it''s just a  
simple common sense approach to tackling a common problem.

> Us artist-programmers are also aesthetes who _love_ clean code. You  
> CS guys may love Rails, but we are the people who _need_ Rails.
Damn, I have to say AMEN yet again !! :)

> * A lot of us are visual learners. It''s one thing to read an  
> explanation of the functionality of has_and_belongs_to_many, or to see
> a flowchart of the table relationships. But sometimes what''s
needed
> is some example code that basically tells you "if you put  
> a :join_table => ''blah'', :foreign_key =>
''foo'' here, it will do
> something cool". It overcomes a lot of learning barriers quickly.
Exactly !!  I''m a visual person and it was the "RoR movie Take
2"
that finally made me buy the book and pursue this further as I saw  
something in 15 min''s that would have taken me hours/days to grep  
while reading.

I''m afraid many within the core thrust of the Ruby/RoR movement are  
the wrong people to understand most of these things. I''m NOT saying  
they are stupid, it''s just that they know too much to about these  
things to be able to think that ''low'' down. What they and the
community needs are people like us asking questions and they  
answering them in co-operation with an ''in-house'' designer
person
that can translate geek-talk into human readable language and visuals.

Or as I often say to the geeks "Start with point 1 being ''Turn on
the
computer...'' and explain each step from there carefully and  
extensively with WHY being in the forefront of your mind".  ;)

> RailDock looks good, but it''s still a little arcane --
it''s got the
> level of detail, but the organization isn''t the same. The API docs
> have the organization, but in most places lacks the right level of  
> detail. More can be done, I think, to make sure the best web apps  
> framework out there has the best documentation out there.
Please see my other reply''s relating to RailDock for more thoughts,  
but RailDock if done right could be a great resource.

The point that the RoR community must take on board as well, is that  
for someone like me, RoR is our first introduction to Ruby. Normally  
it''s the other way around with the Language first and then the  
Solution.  As such, you/we as a community must put pressure on the  
Ruby side of things to sort out their stuff as well.


Kind regards,

Mats

----
"TextMate, coding with an incredible sense of joy and ease"
- www.macromates.com -

On Jul 15, 2005, at 5:57 AM, Mats Persson wrote:
> On 14 Jul 2005, at 21:46, Dean Matsueda wrote:
>
>> Correct me if I''m wrong here, folks, but although
there''s tons of
>> tutorials and Wiki-type info out there, I kind of think your best  
>> bet is to RTFB.
>>
>
> As I said, I''ve got both books and is reading them, but the
PickAxe
> II book is so poorly structured and dry to read that I fall asleep  
> within seconds. Yesterday I tried to look up the =begin ... =end  
> commenting syntax that I vaguely remembered reading about  
> somewhere. 5 min''s of looking through the book provided NO help.  
> (might just be me and my eyes though)
>
> The RoR book is better, but written by very much the same guys -  
> even though DHH et al has improved it I''m sure -, so is not exact
> and direct to the point all the times, and introduces new things  
> like  <% for product in @products -%>  where the -%> was not  
> explained until much later. Even a look into the PickAxe II didn''t
> answer my question, nor did google. Only the IRC channel of RoR  
> did, but that was after roughly 10 min''s of looking.
>
> In other words, all the productivity boost from RoR can be lost  
> through bad documentation and information access.
This is the first time I''ve ever heard a criticism of the Pragmatic  
books, so I''m curious to explore your thoughts on this some more.   
What technical books do you speak of highly, and why?

     Erik

On 15 Jul 2005, at 13:09, Erik Hatcher wrote:
> On Jul 15, 2005, at 5:57 AM, Mats Persson wrote:
>> As I said, I''ve got both books and is reading them, but the  
>> PickAxe II book is so poorly structured and dry to read that I  
>> fall asleep within seconds. Yesterday I tried to look up the  
>> =begin ... =end commenting syntax that I vaguely remembered  
>> reading about somewhere. 5 min''s of looking through the book  
>> provided NO help. (might just be me and my eyes though)
>>
>> The RoR book is better, but written by very much the same guys -  
>> even though DHH et al has improved it I''m sure -, so is not
exact
>> and direct to the point all the times, and introduces new things  
>> like  <% for product in @products -%>  where the -%> was not  
>> explained until much later. Even a look into the PickAxe II
didn''t
>> answer my question, nor did google. Only the IRC channel of RoR  
>> did, but that was after roughly 10 min''s of looking.
>>
>> In other words, all the productivity boost from RoR can be lost  
>> through bad documentation and information access.
>
> This is the first time I''ve ever heard a criticism of the
Pragmatic
> books, so I''m curious to explore your thoughts on this some more.
> What technical books do you speak of highly, and why?
OK, before I specifically address the PP book(s) I have to make this  
clear. I am a visually minded person that has learnt everything I  
know about computers and programming through the Web, a few books (15  
- 20 in 10+ years) and through analysing others code or experimenting  
myself.  Furthermore, I am not someone that can sit/lay down with any  
book like the PickAxe II and read it cover to cover.

"Programming Ruby" book::
Considering that I''ve had the book for about 1+ month or so, and have  
tried to read it at least twice every day, I''m still no further than  
page 83 in it. That speaks volumes in my life, as I can read 400+  
pages of fiction in less than 24 hours sometimes. Now would you or  
anyone else find it as dry as i have? Maybe maybe not,  that''s just  
my feeling from it.

Structure wise I think the book is quite weak.  Although I would  
never be able to do what the PP gang has done, I have to say that  
this is where they really need to rethink their approach. Two examples:

Ex 1:  Comments: (page 317+ in Chapter 22 "The Ruby Language")

     -- Instead of presenting the fundamental language structure/ 
grammar up front in the book, they bury it deep inside. What is the  
logic in that ?
     -- Secondly, compare their handling of the subject with the PHP  
manual''s handling of it [ http://www.php.net/manual/en/language.basic- 
syntax.comments.php ]
     -- Thirdly, the =begin ... =end syntax I looked for above (which  
I just found now)  is described in one paragraph at the top of the  
page like this:

     "Physical lines between a line starting with =begin and a line  
starting with =end are ignored by Ruby and may be used to comment out  
sections of code or to embed documentation."

This would be much more efficient:

     Comments are ignored by the Ruby parser, and there are two (?)  
types:
     --  Single line Comments like this
         # comment here until the end of the line

     -- Multi-line/Block Comments like this where the code within the  
block is ignored.
     =begin
         large code block ignored by the parser
     =end

Ex 2: eRuby ERB (page 242+ Chapter 18 "Ruby and the Web")
I still don''t know if the - (dash) in front of the closing %>  is  
part of ERB, RoR or just plain Ruby. I now know what it does, but I  
couldn''t find that information in the PickAxe II book when i looked  
for it.


The point here being that - although these two may be bad examples  
and just accidentally overlooked - the PickAxe II book did not help  
me with them in a succinct, efficient and clear way.


"Agile Web Development with Rails" book::
I already said it is better, albeit with some flaws. I actually found  
it''s introduction to Ruby much better for me than the Pickaxe book.  
And I have read roughly 200+ pages in less than a week, and done most  
of the Depot app.  I hope you can see the difference there.


Good books that I''ve read and retained:
-- "Advanced PHP Programming" by George Schlossnagle
     Easy to read, structurally sound and a logical layout.

-- "designing with web standards" by Jeffrey Zeldman
     Explains why very well and have good examples.

I''m well aware that these two books might not do all the things that  
the Pickaxe tries to do, but they are books that I''ve read cover to  
cover and retained the info from, and got on the shelf next to me. I  
therefore ''judge'' any other book against them.

I didn''t mean to stir up a debate about these books, but rather just  
expressed my view/feelings about them within the context of my point  
for having a good reference point where I could find the answers I  
was looking for.


Kind regards,

Mats

----
"TextMate, coding with an incredible sense of joy and ease"
- www.macromates.com -

On 16.7.2005, at 14:28, Mats Persson wrote:
>
> On 15 Jul 2005, at 13:09, Erik Hatcher wrote:
>> On Jul 15, 2005, at 5:57 AM, Mats Persson wrote:
>>> As I said, I''ve got both books and is reading them, but
the PickAxe
>>> II book is so poorly structured and dry to read that I fall asleep 
>>> within seconds.
>> This is the first time I''ve ever heard a criticism of the
Pragmatic
>> books, so I''m curious to explore your thoughts on this some
more.
Me too.
>>   What technical books do you speak of highly, and why?
>
> Good books that I''ve read and retained:
> -- "Advanced PHP Programming" by George Schlossnagle
>     Easy to read, structurally sound and a logical layout.
>
> -- "designing with web standards" by Jeffrey Zeldman
>     Explains why very well and have good examples.
I find it a bit curious that you consider PP books dry and boring but 
rave about DWWS. Agreed, Zeldman''s book was and still is an important 
landmark in the fight for standards-compliant web design. However, I 
find him filling 400+ pages with meat for about half of that (and am 
not the only one [1]). As opposed to that, PP books are always concise 
and to-the-point, and still not forgetting humor to keep the reader 
awake.

There''s a reason for techie books being funny, as taught (and shown) by
people like Spolsky [2]. However, it should support the main message, 
not distract from it like I find DWWS sometimes doing, and it 
definitely doesn''t justify filling half a book with meaningless 
chatter.

All this is of course IMNSHO :-)

//jarkko

[1] http://www.pinds.com/bookshelf/book-view?book_no=37
[2] http://www.joelonsoftware.com/


--
Jarkko Laine
http://jlaine.net
http://odesign.fi


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails