Rubynuby == I'm a'scared to set it all up

Rails
1

I’ve been mostly lurking here with an occasional nuby question for a few
weeks now. It seems like Ruby and Rails and the many libraries and
tools growing up around it are a remarkable toolset. Unfortunately I’m
finding the whole enchilada a bit daunting.

It seems that if one is to truly tap into the power of this thing and do
a significant amount of developing, one needs to start with Ruby and/or
RoR (in my case on a Mac with TextMate). One also needs to figure out
how to use subversion to track code changes. One also needs to figure
out switchtower in order to eventually deploy his creation on his
quietly waiting web host account.

I would appreciate some words of wisdom for somebody who is starting
from scratch on all of it, with nothing but simple html websites and
years of completely unrelated development experience (embedded C on cell
phones and C and C++ app development on Macintosh and PalmOS) behind him
and a rather daunting combination of complex tools in front of him.

Should I just brute force my way into the whole lot at once? Should I
develop a complete app or two with the intention of throwing them away
because they are not lodged in a version control setup and were not
developed with an educated eye towards deployment on the real webserver?

To be honest, given the simplicity of at least starting a rails app, I’m
tempted to do my first development “in place” on my virtual dedicated
server and work “against the grain” to get my first rails app up and
running “in the real world”. It’s not financial or “lives at risk” kind
of stuff anyway, just bloggy forumish stuff.

What have others in a similar boat found to be the best way to
eventually use the wide spectrum of tools available when you are
starting from a state of awe and “deer in the headlights” with a dozen
different pdf files piling up on your desktop, each to supposedly teach
you some particular part of the whole enchilada?

Are there perhaps some integrated tutorials that will help me get svn
and switchtower setup and show me how to use them easily enough that
they don’t substantially add to the difficulty of learning Ruby and
Rails (and postgres and unix sys-admin etc. etc.)

Or maybe somebody will suggest a good order in which to tackle all these
many beasts one at a time. Any help will be appreciated.

thanks,
jp

2

On Wed, 2006-03-08 at 03:46 +0100, Jeff P. wrote:

quietly waiting web host account.
developed with an educated eye towards deployment on the real webserver?
different pdf files piling up on your desktop, each to supposedly teach
you some particular part of the whole enchilada?

Are there perhaps some integrated tutorials that will help me get svn
and switchtower setup and show me how to use them easily enough that
they don’t substantially add to the difficulty of learning Ruby and
Rails (and postgres and unix sys-admin etc. etc.)

Or maybe somebody will suggest a good order in which to tackle all these
many beasts one at a time. Any help will be appreciated.

ain’t nothing to it but to do it.

I would have loved to quit right there.

Just start hacking away…use webrick as your web server, pick your sql
db and start plunking at a project.

As the project grows and things get clearer, it’s easy enough to migrate
the setup into things like svn/apache w/fcgi etc. but there’s no need to
bite off everything at once and in fact, it’s likely to be counter
productive since each element adds another piece of complexity that all
at once would be too much. A 400 meter hurdle is a series of running and
jumping.

Craig

3

Jeff,

I think Craig pretty much nailed it. I am the newest of noobs, basically
still playing around with ‘scaffold’ :slight_smile:

Play around. Worry about ‘real’ issues later.

One of the key things I see lurking around here is that you shouldn’t
let
worry about traditional ‘gotchas’ slow you down. Play, make something
happen
and worry about the ‘real’ problems when those problems arise, if they
even
do.

I think that this is one of the most profound and liberating aspects of
this
whole approach, coming from a longtime corporate developer.

Dave

4

As someone who is only about two weeks into RoR,
I second Craig’s suggestion. I would only add that I
“jumped in” with a copy of Agile Web Dev. with Rails
on my lap.

I, also, have seen lots of posts that reference stuff I have
no idea about, but by deferring all the questions about real-live
deployment I have gotten far enough to show a demo RoR application to
a prospective client tomorrow.

That said, there are plenty of pdfs piled up that I have to
read if the client bites!

Rob

5

Jeff
Not much further ahead of the curve than you are, but would echo what
Craig said. My $0.02:

As a newbie you go through prob four stages (I’m at stage 2, bordering
on 3)

  1. The scaffold stage – wow, this is amazing. There are plenty of good
    tutorials out there (Curt H.’ OnLamp ones, the new Apple one). I’d
    recommend reading them all, then coming up with a simple application to
    try your own out (i.e. as simple as the cookbook type thing). While
    you’re doing this order yourself a copy of DT’s Agile w/Rails book and
    also the Pickaxe, i.e. Programming Ruby (will really help get you
    through stage 2).

  2. The WTF stage – when you just can’t get the hang of the syntax at
    all, and keep getting hit with one gotcha after another. This hit me
    particularly hard, never having used Ruby before, and never having used
    an Object Oriented-Language before(I suspect a lot of the rails newbies
    will like me be coming from PHP). I’ve survived this, by reading the
    Agile book (quickly, to be honest) and then re-reading parts VERY
    CAREFULLY. It’s made a big difference that I am working on a real-world
    app, albeit a personal one, so could hit real problems and then have to
    solve them. When I got to a problem I would search for an answer, try a
    few different bits of syntax, search again, try more variations, and
    then post here. Sometimes I didn’t get an answer – which was really
    frustrating, but good for the soul, as it forced me to work it out
    myself using either the Agile book, the Pickaxe, or the Rdoc resource
    (finally starting to make sense to me now).

[For what it’s worth, I think a newbie forum would definitely be a good
idea – would be lot more searchable than the mailing list, it would
stop the mailing list getting clogged up with the same basic questions,
and would stop unanswered questions disappearing of the radar after a
day.]

  1. The Return of Wow – as you become more familiar with the syntax and
    construction, you extend the app and become so productive it’s almost
    frightening

  2. The End of Newbiedom – I’m guessing there’s another bump in the
    learning curve here as you start to push against the framework, come up
    against issues such as scaling, performance and deployment.

NEWBIE REQUIREMENTS

  1. Agile w/Rails book – though please update it, not just for 1.1 but
    also to remove the deprecated syntax.

  2. An environment you feel comfortable with – for me it’s an old Linux
    box sitting in the corner, running webrick, connected to from a Windows
    XP and using jEdit. Lots of people work wholly locally with Instant
    Rails on their Windows box – it’s a matter of what’s comfortable for
    you, so you can concentrate on learning rails (Locomotive may be a good
    choice for you as you’re on a Mac). I’m not sure I would go down the
    dedicated virtual server (assuming you mean a hosted one) unless that’s
    what you feel comfortable with. having a local environment allows you
    screw up in the privacy of your home.

I’ve just added subversion to my server but that more to get to grips
with it than because the project required it yet. On the other hand, I’m
not even looking at Switchtower/Capistrino yet, nor Lighttppd/fcgi –
there’s enough else to think about without that. I also – embarrassed
pause – haven’t started testing yet. I will need to soon, and it will
prob make life easier, but as I said, there’s been enough to think
about.

  1. Programming Ruby. Has already been useful, even though I’ve used it
    more as a reference rather than actually reading it.

  2. Time. Time to read the mailing list. Time to play around. And time to
    bang my head against a brick wall when I can’t figure out the problem

Good luck.
Chris T

6

I’m also somewhere in stage 2, have lots of background in C and PHP, but
am quite overwhelmed with all the conventions and stuff. It does make
sense, mind you, but when you’re used to getting to know a codebase
through slowly working out its internal “conventions” it’s very hard to
shift yourself to learning somebody else’s, and an entire framework of
conventions at that.

Since you mentioned testing: can somebody comment on whether there’s
actually a value in testing for people like me who are trying to build a
real-life app but am overthrowing things twice a day? Like, on Sunday I
made an app/views/application/_list.mab for all my models/views to use
instead of the “list” thing being duplicated all over the place. BUT,
having not had enough experience with RoR I’ve no idea if this approach
will work out a bit more down the road, so I’m prepared for yet another
refactoring iteration. Under these circumstances, how sensible is the
implementation of tests?

– Raphael

7

Or maybe somebody will suggest a good order in which to tackle all these
many beasts one at a time. Any help will be appreciated.

Heres mine

To date…

1/ Google ‘Database normalisation explained’
2/ Getting Started with Rails Tutorial
3/ 4 Days on Rails Tutorial
4/ Agile Book
5/ Really Getting Started with Rails Tutorial
6 Pt1/ Ruby Pickaxe Book
6 Pt2/ Ruby Forums & Sitepoint
7/ Create Sourceforge project to share and learn (had to read a bit
about Subversion but SVN for OSX works out the box

To come…

8 Pt1/ Ruby For Rails
8 Pt2/ Rails Recipes

_tony

8

On Wed, 2006-03-08 at 17:00 +0100, Jeff P. wrote:

Probably the best way to learn about switchtower is to learn how painful
it is to deploy without it. (or maybe it isn’t, in which case I won’t
need to bother with it).

things are happening so fast that it isn’t even called switchtower any
more :wink:

no reason at this stage anyway, to start killing yourself to embed
technologies that you aren’t ready for yet…I use this analogy, sit up,
crawl on hands and knees, stand up, walk, run, do hurdles.

I’m trying to get upright from hands and knees right now.

Craig

9

Thanks guys. Glad to hear that I’m not the only one who found it
daunting.

I think I’m going to just jump in the frying pan with rails and get my
first very simple app running. No SVN or Switchtower or “test first”
for the moment. Just hop in the shallow end of the pool and make
swimming motions.

Once I get one working, then I’ll read some more and then add SVN to my
tool belt and proceed from there.

Probably the best way to learn about switchtower is to learn how painful
it is to deploy without it. (or maybe it isn’t, in which case I won’t
need to bother with it).

I really appreciate all the input.

best,
jp

10

Jeff P. wrote:

Thanks guys. Glad to hear that I’m not the only one who found it
daunting.

I think I’m going to just jump in the frying pan with rails and get my
first very simple app running. No SVN or Switchtower or “test first”
for the moment. Just hop in the shallow end of the pool and make
swimming motions.

Once I get one working, then I’ll read some more and then add SVN to my
tool belt and proceed from there.

I found that the major tasks in learning the Agile/Rails/MVC paradigm
was read, read, and read, then create something small and conceptually
well understood. In my case I took a small bash script used to move
files around the file system, extended it to do all of the stuff a
utility program would do (get options off of the command line, do error
checking, guard against invalid values, and so forth) and programmed it
in Ruby using the usual procedural style found in scripts.

Then, with that script functionality firmly established in my mind, I
then went about converting this to a Ruby script using the 2ed. of the
Pickaxe book (Programming Ruby: The Pragmatic Programmers’ Guide, 2.ed)
as a guide and employing (my rather primitive ideas of) object
programming techniques. Posting my efforts on the Ruby List provided
much useful feedback and provided guided discovery of Ruby (and object)
principals, conventions, and idioms. Eventually I transitioned to test
based programming for the later stages of the exercise. This exercise
provided so sufficent a grounding in Ruby that, when I again took up the
Rails tutorial, much previously obscure was now clear.

I think that you should get Subversion and install it first however.
While anything new is always confusing and requires even more work and
emotion (does anything ever go right the first time?), setting up
Subversion is not terribly difficult and, in my experience, it proved
surprisingly useful even during the exploratory exercises above. I
strongly recommend that you obtain the book Pragmatic Version Control
from the PP guys. This slim volume is an excellent quick study for
getting Subversion installed, configured, and running. It also provides
a useful set of conventions that avoid common repository limitations
caused by poor setup choices.

If you throughly explore Euby first and then Rails, all under the
umbrella of a working version control system, then transitioning to a
real development project takes very little effort (however difficult the
project itself proves).

Later you will want to look at project management software like Trac
(http://trac.edgewall.com) or Collaboa (http://www.collaboa.org). These
web tools interface directly with subversion and provide a wiki based
application that is extreme useful for project design and development.
You can run these locally on your laptop or move them onto a server
somewhere as your needs dictate. They both support RBAC and I find Trac
truly remarkable. Collaboa is promoted as a (future) Ruby version of
Trac (Python).

Switchtower/Capistrano is of interest when you approach the point of
deploying an application across servers. In some cases this point is
never reached. In my opinion the principal of YAGNI applies to
switchtower right up to the point that it turns out you actually do need
it.

I hope that you find this useful. Good luck.

Regards,
Jim

11

Agree completely - Subversion is simple to use (on Windows, check out
the TortoiseSVN client), there’s free hosts out there (so you don’t
need to set up a server just to learn how to use it), and version
control is absolutely a requirement for software development.

You’ll realise this approx 1.5 seconds after you’ve just overwritten
or accidentally deleted a key file that you didn’t have backed up. Or
2.5 seconds after you’ve been collaborating with someone else on
development, then find both of you have spent a whole lot of time
updating the same file and now you can’t merge your changes.

If you use a free SVN server, it’ll take you about 1-2 hours of
reading the (online) SVN manual and playing around for you to become
comfortable using it. You’ll be ahead the first time you have to
reproduce an accidentally-deleted file.

Regards

Dave M.

12

svn doesn’t necessarily supplant a good backup plan

Craig

13

On Mar 8, 2006, at 8:00 AM, Jeff P. wrote:

I think I’m going to just jump in the frying pan with rails and get my
first very simple app running. No SVN or Switchtower or “test first”
for the moment. Just hop in the shallow end of the pool and make
swimming motions.

I’ll slightly disagree and suggest you delve into Subversion
immediately.

In this day and age, anybody who writes code should be using version
control.

Don’t consider it part of Ruby on Rails, but a general resumé upgrade.

–
– Tom M.

14

On Wed, 2006-03-08 at 13:20 -0800, Tom M. wrote:

On Mar 8, 2006, at 1:17 PM, Craig W. wrote:

svn doesn’t necessarily supplant a good backup plan

Did anybody suggest it did?

yeah - Dave did - that was why I said it - with direct reference and
inclusion of his comments

Craig

15

On Mar 8, 2006, at 1:17 PM, Craig W. wrote:

svn doesn’t necessarily supplant a good backup plan

Did anybody suggest it did?

–
– Tom M.

16

On 3/8/06, David M. [email protected] wrote:

Agree completely - Subversion is simple to use (on Windows, check out
the TortoiseSVN client), there’s free hosts out there (so you don’t
need to set up a server just to learn how to use it), and version
control is absolutely a requirement for software development.

TortoiseSVN, makes it easy to work locally without a server. You can
right-click on any folder and select “Create SVN Repository Here”.

Curt

17

OK, I see your point. I’ve been using version control software of one
kind or another at work for upwards of 15 years now. I’ve never used it
for projects at home, since they are always done by “a team of one”.
That leaves one of the main reasons for source control out of the
equation, but certainly there is also great value in keeping track of
previous versions and never losing any work. I’m sure it also makes it
easier to dig up something to copy and paste when you are working on
your third or fourth project and realize you’re about to write something
all over again that you did a year ago.

OK, I can probably stomach SVN first. Thanks for the input.

jp

Tom M. wrote:

On Mar 8, 2006, at 8:00 AM, Jeff P. wrote:

I think I’m going to just jump in the frying pan with rails and get my
first very simple app running. No SVN or Switchtower or “test first”
for the moment. Just hop in the shallow end of the pool and make
swimming motions.

I’ll slightly disagree and suggest you delve into Subversion
immediately.

In this day and age, anybody who writes code should be using version
control.

Don’t consider it part of Ruby on Rails, but a general resum� upgrade.

–
– Tom M.

18

Yeah, so he did.

My bad, sorry for suggesting otherwise.

That said, I don’t think Dave’s comment was meant
to suggest that you don’t need to backup, just that
version control can help you out in similar ways.

–
– Tom M.

19

OK, I can probably stomach SVN first. Thanks for the input.

jp

I have to say as a beginner that putting my personal project in SVN made
a HUGE
difference. Since I am still playing around and learning I often break
my code and being able to quickly revert to the old (Working) version
without resorting to ninja Cut&Paste-fu meant I spent a lot more time
coding and less time backing up / copying directories. Especially since
my IDE of choice (Radrails) integrates with SVN and makes it all very
simple.

I would recommend learning SVN from the beginning, it took me 3 or so
hours to understand, download, install and get running with SVN, now I
don’t know how I did it before.

Jeff

20

Original poster here again…

So assuming that it makes sense to start from the beginning with SVN,
and since I already have a virtual dedicated server box at an ISP with
several domain names on it (some of which can be used for practice right
now), and already have rails running there, is there some fundamental
reason why the following is a "really bad idea"TM?

What if I were to run the SVN server on my virtual dedicated server box
(which BTW, gets backed up daily). I could then use the apache version
of connectivity for clients in various places like my mac laptop and my
Mac home machine and my windows machine at work.

Further, I could use the Rails environment I already have working on the
dedicated server and actually do my development in place on that server
with one of the “practice” domains. Then the act of deployment would
simply be to check out the same project files to the “real” domain’s
disk area on the server.

As I understand it right now, the only downside would be a few seconds
to do a “check-in” to the remote server every time I want to tweak
something and re-run the app. The plus side is that I would be checking
in every little thing, and would have a very “high resolution” revision
history where I would never have to wonder, “did I save that before or
after that one change that broke everything?”.

Another upside to having the server out there on my remote box would be
very easy collaboration with other coders, if I ever do a group project
or hire somebody to do some development I don’t have time for.

This would also still allow me to do some development locally without
connectivity (just couldn’t check anything in until connectivity
resumes).

This seems like a really slick solution to me. What are the downsides I
haven’t thought of? Is SVN relatively quick for little bits and pieces
like I’ve described here? I use Perforce at work right now, which
appears to be a similar versioning system, and it would be fast enough
to keep me happy working in this way. Is SVN comparable in speed?

I guess one question I should ask is how often would one find it
necessary to reboot a unix machine that is being used for this type of
development work? I’m assuming that would not be very often. Don’t
want to tick off people using my other sites too often when it
inexplicably goes down for a minute or two.

thanks,
jp