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
on 2006-03-08 04:46
on 2006-03-08 04:55
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
on 2006-03-08 05:42
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
on 2006-03-08 06:21
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 2006-03-08 12:17
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.] 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
on 2006-03-08 17:25
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
on 2006-03-08 17:37
> 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
on 2006-03-08 18:00
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
on 2006-03-08 18:27
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 ;-) 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
on 2006-03-08 18:46
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
on 2006-03-08 22:51
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.
on 2006-03-08 23:15
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 2006-03-08 23:18
svn doesn't necessarily supplant a good backup plan Craig
on 2006-03-08 23:21
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.
on 2006-03-08 23:49
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
on 2006-03-08 23:52
On 3/8/06, David M. <email@example.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
on 2006-03-08 23:55
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.
on 2006-03-09 05:05
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.
on 2006-03-09 11:36
> 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
on 2006-03-09 17:56
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
on 2006-03-09 18:40
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 M.
on 2006-03-10 05:19
Tom M. wrote: ... > > > As far as rebooting goes, unless you upgrade the kernel I'd be > surprised if you ever rebooted it. > > -- > -- Tom M. 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
on 2006-03-10 07:12
On Mar 9, 2006, at 7:19 PM, Jeff P. wrote: > Thanks Tom! > > 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