Rails - Mar 2006 - rubynuby == I''m a''scared to set it all up...

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

-- 
Posted via http://www.ruby-forum.com/.

On Wed, 2006-03-08 at 03:46 +0100, Jeff Pritchard wrote:
> 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.
----
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

Jeff,

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

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

-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Craig White
Sent: Tuesday, March 07, 2006 9:54 PM
To: rails@lists.rubyonrails.org
Subject: Re: [Rails] rubynuby == I''m a''scared to set it all
up...

On Wed, 2006-03-08 at 03:46 +0100, Jeff Pritchard wrote:
> 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.
----
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

_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails

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
> On Wed, 2006-03-08 at 03:46 +0100, Jeff Pritchard wrote:
>> 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.
> ----
> 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
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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 Hibbs'' 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.]

3) 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

4) 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.

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

4) 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

Craig White wrote:
> On Wed, 2006-03-08 at 03:46 +0100, Jeff Pritchard wrote:
>   
>> 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.
>>
>>
>>     
> ----
> 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
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>

You know what? Not true.  Learn the language, write some programs first.
When you need to learn how to use ActionMailer to send messages, learn
it then.  When it comes time to work on your program from both your
laptop and your desktop machine, then learn how SubVersion works.  When
you have the coolest application in the world and you want to deploy it,
then learn that.

Don''t learn it until you *need* it. Sure there''s a lot there,
but to
learn PHP you have to set up the webserver too, and Rails has one of
those built in, so you can jump right in and develop.

Who knows... You may not like Rails (blasphemy!) so why learn EVERYTHING
at once? 

I''ve used a lot of languages and Ruby and the Rails framework was the
easiest for me to learn and the most fun I''ve had, but I took it one
step at a time.

Do the "Depot" app in the Agile book. They don''t use anything
but MySQL
and WEBrick for that. :)

Good luck to you!

-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Jeff Pritchard
Sent: Tuesday, March 07, 2006 8:46 PM
To: rails@lists.rubyonrails.org
Subject: [Rails] rubynuby == I''m a''scared to set it all up...


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

-- 
Posted via http://www.ruby-forum.com/.
_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails

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

-- 
Posted via http://www.ruby-forum.com/.

> 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

-- 
Posted via http://www.ruby-forum.com/.

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

-- 
Posted via http://www.ruby-forum.com/.

On Wed, 2006-03-08 at 17:00 +0100, Jeff Pritchard 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.
> 
> 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  ;-)

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

Jeff Pritchard 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

-- 
Posted via http://www.ruby-forum.com/.

On Mar 8, 2006, at 8:00 AM, Jeff Pritchard 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 Mornini

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.

On 09/03/06, Tom Mornini <tmornini@infomania.com>
wrote:
> On Mar 8, 2006, at 8:00 AM, Jeff Pritchard 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 Mornini
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

svn doesn''t necessarily supplant a good backup plan

Craig

On Thu, 2006-03-09 at 08:13 +1100, David Mitchell 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.
> 
> 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.
> 
> On 09/03/06, Tom Mornini <tmornini@infomania.com> wrote:
> > On Mar 8, 2006, at 8:00 AM, Jeff Pritchard 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 Mornini
> >
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

On Mar 8, 2006, at 1:17 PM, Craig White wrote:
> svn doesn''t necessarily supplant a good backup plan
Did anybody suggest it did?

-- 
-- Tom Mornini

On Wed, 2006-03-08 at 13:20 -0800, Tom Mornini wrote:
> On Mar 8, 2006, at 1:17 PM, Craig White 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

On 3/8/06, David Mitchell <monch1962@gmail.com>
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

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 Mornini

On Mar 8, 2006, at 1:46 PM, Craig White wrote:
> On Wed, 2006-03-08 at 13:20 -0800, Tom Mornini wrote:
>> On Mar 8, 2006, at 1:17 PM, Craig White 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

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 Mornini wrote:
> On Mar 8, 2006, at 8:00 AM, Jeff Pritchard 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 Mornini

-- 
Posted via http://www.ruby-forum.com/.

> 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

-- 
Posted via http://www.ruby-forum.com/.

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

-- 
Posted via http://www.ruby-forum.com/.

I would rather cut off one of my arms than go back to a time where
I could not develop without internet connectivity.

Working on your own box is fantastically useful!

So much so that I use SVK (don''t worry about it for now) so that
I can commit changes locally and then later push them up to the
Subversion repository when I''m connected.

Since you''re using several computers for development, when
switching from one to another just do a commit of your project
with an appropriate comment about why you committed it, then
go to the other box and update your working copy. This is another
huge advantage of working with version control, even if you''re
a single person team. :-)

To be clear, there''s nothing wrong with what you''re suggesting
from a technical standpoint, and I think it complete improves
on the edit-ftp-test experience, but I''m recommending local
development environments on each machine because I find I''m more
productive that way.

As far as where the repository should be, YES, by all means,
put it where it''s most easily accessible to you and to others
in the future, i.e. on your VPS (particularly since it''s backed
up!)

As far as rebooting goes, unless you upgrade the kernel I''d be
surprised if you ever rebooted it.

--  
-- Tom Mornini

On Mar 9, 2006, at 7:56 AM, Jeff Pritchard wrote:
> 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
>
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Tom Mornini wrote:
...
> 
> 
> As far as rebooting goes, unless you upgrade the kernel I''d be
> surprised if you ever rebooted it.
> 
> --
> -- Tom Mornini
Thanks Tom!

Regarding rebooting, what about restarting the web server.  It seems 
like I vaguely remember from one of the tutorials I read that you have 
to restart the web server at certain points in the development.  Don''t 
remember if it had to do with making a new table in the database or 
after generating a new project or what it was.  Perhaps this would 
another reason to develop locally, to minimize restarting of the 
"production" web server  (even though there is nothing particularly
hot
on it just yet).

I''m just dreading the day when I get an app working locally on OSX and 
then wind up frustrated by differences between local and server when 
trying to get it deployed.  That''s really the only reason I like the 
idea of developing in the same environment as the VPS.  Perhaps that is 
a molehill that I''m mountainizing.

jp

-- 
Posted via http://www.ruby-forum.com/.

On Mar 9, 2006, at 7:19 PM, Jeff Pritchard wrote:
> Tom Mornini wrote:
> ...
>>
>>
>> As far as rebooting goes, unless you upgrade the kernel I''d be
>> surprised if you ever rebooted it.
>>
>> --
>> -- Tom Mornini
>
> Thanks Tom!
>
> Regarding rebooting, what about restarting the web server.  It seems
> like I vaguely remember from one of the tutorials I read that you have
> to restart the web server at certain points in the development. 
Don''t
> remember if it had to do with making a new table in the database or
> after generating a new project or what it was.  Perhaps this would
> another reason to develop locally, to minimize restarting of the
> "production" web server  (even though there is nothing
particularly
> hot
> on it just yet).
>
> I''m just dreading the day when I get an app working locally on OSX
and
> then wind up frustrated by differences between local and server when
> trying to get it deployed.  That''s really the only reason I like
the
> idea of developing in the same environment as the VPS.  Perhaps  
> that is
> a molehill that I''m mountainizing.
>
> jp

Jeff-

	Yeah you are mountanizing. Rails makes it pretty easy to develop  
locally and deploy to another OS. I do all my development locally on  
osx and then deploy on linux without changing anything more then  
database.yml settings. Don''t worry about moving from local to remote.  
You will find out thats not going to be that difficult.

Cheers-
-Ezra