I've been going through some good (seeming) resources for Rails tutorials, and will dutifully follow the steps until halfway through I realize a helper has been dropped or something else has changed. Aside from the 1.0->2.0 change (which I imagine was significant, given typical versioning), are there other updates that have fundamentally changed how rails works, and before which I shouldn't try to "translate" older resources? Thanks!
(please don't just say "read the changelog". I don't know how Rails works; it doesn't mean much to me yet)
I wouldn't say there have been any really big fundamental changes since Rails 2 where it was like, "OK, throw out the old tutorials." There have been some useful features added that might not be in older 2.x tutorials (named_scope is the biggest thing that immediately springs to mind), but it's just another useful tool you can learn, not something that makes everything you've learned before useless.
There has been a list of changes to 'Edge Rails', http://ryandaigle.com/tags/Edge%20Rails
Hopefully that'll give you a better idea.
Related
I have a large ruby on rails 2.3 which was now a disaster because of the slowness and many bugs. I'm the only programmer and every day I've done debugging and tearing my hair off because of this. The users are already using the product but so many bugs and data are scattered.
I was employed without prior knowledge of project development and management. Now I'm suffering of having more overtime and a crisis on my codes to be fixed.
And also I've created this app while learning rails so there are codes there that became stranger to me.
What should I do?
What are your suggestions?
What books do I need to read about more?
Please I need some help.
Thanks.
I would love to recommend you upgrade to Rails 3. Especially since there are many newer features and some things are simplified, and it would ease future maintainability.
However, unfortunately, I am hesitant to (or rather simply cannot) actually recommend that given that you already have much more on your hands.
In this case, the best thing you can do is to start writing tests. If there are so many bugs, I have to assume that either you have no tests or your have an incomplete test suite. Tests will help to give you confidence that you do not break anything when you try to fix something else.
The default rails test framework can be found at the Ruby on Rails Guides. Having said that, many people prefer the RSpec testing framework. There are indeed shortcomings of the default Rails testing framework (notably the fragility of fixtures - try get a factory gem, and other features such as mocks and expectations, and nested contexts).
You should read up on the testing frameworks, and maybe try it a bit. Pick one testing framework early on however, and start testing everything!
Perhaps when you become more confident in your test suite and have fixed the most important bugs, you should think more about a path to upgrading Rails - because all the gems will march on, and gradually drop support for Rails 2.3, which means you will be using increasingly old gems which may no be well supported anymore.
From what I understood, you are asking for project managment tips and tools how to get a rails project under control.
I believe first thing you need to is stabilize the project. To do this, you will need to minimize the bugs and chart the required work.
I see two complementary approaches for this:
use a task/bug tracking tool
start using cucumber for testing
Task/bug tracking
This is very important, because you will need some kind of list that itemizes all bugs.
Sometimes users discover a bug, and suddenly you have to drop everything, because at that moment, that single bug is the most important bug ever, and needs to be solved immediately.
However, if you would ask them outright if this means the bugs you are fixing are more or less important, the answer could be different.
So it is in your advantage if there is a clear way to let the user participate in that decision process. If there is a shared bug-list, users can also follow the current state (what you are working on), they can indicate/choose which bugs are more important for them.
Secondly: having a list of items(work/tasks/outstanding bugs/...) will also help you planning the work.
There are a lot of options to some kind of bug-tracking, but some easy/pragmatic/free suggestions are
checkout trello
use the issues from github
Tracking the bugs/tasks will give you the feeling you gain control of your project, and furthermore: it will make this also more visible to your client.
Cucumber
When fixing bugs there is always the danger to introduce new bugs, definitely in a project that is originally not your own.
In a project where there are next to no tests, I always propose to start with cucumber. Cucumber has a few advantages:
it tests your application/website from the outside in: no need to understand the code fully, you just need to know what the application should do. If I click this link, it should take me to that page.
it is really easy to write tests in cucumber, and you get test-coverage really quickly
as a bonus, your test-code is readable, which you could show your clients/users, and they would actually understand what is covered by the tests (and could correct/improve it).
Upgrading or not?
I personally believe your first step should be stabilizing the project and minimize/remove all bugs. Whilst upgrading to rails 3 would be a huge improvement, it is not a straightforward process. There are good guidelines, but if you do it now, you will have no idea if a bug was introduced during the upgrade, or existed before. First get your code quality in order, and then do the upgrade.
Hope this helps.
Actually the thing you are asking is completely depending on how much refactoring you need to clean up the whole project. If you have enough time in your hand to clean it up completely. I would suggest following steps:
Getting Ready
Get the visualization of the whole project. What is required and what is not required.
Define your resources and relation between them properly.
Use proper RESTful routing.
Decide the test tools and frameworks like cucumber, rspec, factory girl etc.
Plan of Action
Decide (if possible, as a team) that what are the minimum or necessary changes required.
Isolate all the components in different groups so that each group can be refactored individually. Smaller groups are preferred.
Decide test cases.
Break down tasks into as much as small size possible.
Make sure to keep your test coverage more than 90%.
This process will take around 4-5 months for a medium scale project for a team of 4 members.
Let us know if you have any specific confusion.
What to read: http://guides.rubyonrails.org/v2.3.11/ Start with chapters about debugging and performance testing.
Forget about upgrading to Rails 3 for now, at this moment it would only introduce many more bugs and probably lots of problems with legacy gems and plugins. And don't forget that you need ruby 1.9 in order to upgrade to rails 3 - yet another batch of problems.
Adding tests is a good idea, as ronalchn suggested. I'd recommend to start with unit tests. You might have to rewrite code a lot in order for it to be testable. (In other words, instead of trying tests to fit current legacy code, it's usually better to refactor the code to make it testable.)
Unfortunately there is no quick fix in your current solution. If you seriously consider an upgrade, it will take time to fill in the missing tests if you haven't been writing them, pick up the testing frameworks on top of Rails 3, and work out the necessary data migration once you are ready to flip the switch.
The other option is to continue with Rails 2.x, which isn't completely unfathomable although the support avenues will be much more limited. You still need to work in the tests as a first priority and understand the various nuances that are present in the existing application.
For your scenario (one-man racket with little to no prior experience), I feel that sticking with what you have and improving the testability up to the point where you would feel an upgrade is worthwhile, would be the prudent action. No matter which course of action you would take, be prepared to put in quite a bit of work in the short-to-middle term (but such is the case of accumulating technical debt).
I am using Ruby on Rails 3.2.2. and I would like to know if the following thought (born from my previous question) is correct:
I tend not to use third-party gems (at least when it is possible and reasonable) because they might be abandoned at any time. Also, if the Ruby on Rails framework changes, I might have to wait for those gems to be updated before updating my application to the latest RoR version.
In a perfect world where you're immortal, have infinite time, are the world's best programmer, and it makes no difference whether you launch your product in 1 hour or 10 years so you can code everything yourself from scratch, then maybe it makes more sense to avoid the code of other people.
But in the real world, people have solved problems for you already. And gems allow you to plug in those solutions.
A good rule of thumb is to prefer the community's favorite/popular gems for a given solution when you can. The more people using a gem, the more people have an interest in keeping it updated and the more eyeballs are scrutinizing it and sending pull requests. Chances are that a gem that's battle-tested by a bunch of people in production environments is better than what you'd come up with on your first attempt, right?
Gems that depend on one hobbyist maintainer that's not even using it in a self-itch-scratching production application are where you tend to find some risk. But even in those situations, if you end up having to fork his gem one day, you're still ahead of where you'd be if you started from scratch.
A better tendency is to avoid writing everything from scratch and instead leverage the brains of other people with similar needs.
Well, it's the risk you're taking in exchange for saved development time/budget and shorter time-to-market.
If you find yourself in a situation when one of your gems is abandoned, then you could look at similar gems or fork and improve that one. Either way, it's still better than developing everything by yourself.
Abandon this philosophy! A lot of websites/companies tend to do this -- it's better known at the "Not invented here" syndrome. Twitter, in particular, is a big offender. Open source is great -- use it.
A work is perfectly finished only when nothing can be added to it and nothing taken away.
– Joseph Joubert
That's the same philosophy we follow with our Rails projects at work. If you want to add a gem to the Gemfile, you basically have to argue it in. If you can't find a good reason why it should be in there, it will get kicked out. We are definitely not trying to reinvent the wheel, but keeping the number of potentially badly maintained moveable parts down is IMHO a good choice. So say yes to well-maintained and established Rails plugins, but be wary about stuff that looks like a quickly thrown together solution. More often that not you end up maintaining your own patches of it or forking the repo, so you might have as well reinvented that particular wheel...
Try, for example,devise gem, and then implement its functionality yourself. So you can define your own vision of the problem.
I prefer to use all gems, which I found useful. If after update any gem doesn't work, you can always fork and upgrade it.
I am looking to start developing a relatively simple web application that will pull data from various sources and normalizing it. A user can also enter the data directly into the site. I anticipate hitting scale, if successful. Is it worth putting in the time now to use scalable or distributed technologies or just start with a LAMP stack? Framework or not? Any thoughts, suggestions, or comments would help.
Disregard my vague description of the idea, I'd love to share once I get further along.
Later. I can't remember who said it (might have been SO's Jeff Atwood) but it rings true: your first problem is getting other people to care about your work. Worry about scale when they do.
Definitely go with a well structured framework for your own sanity though. Even if it doesn't end up with thousands of users, you'll want to add features as time goes on. Maintaining an expanding codebase without good structure quickly becomes fairly horrible (been there, done that, lost the client).
btw, if you're tempted to write your own framework, be aware that it is a lot of work. My company has an in-house one we're quite proud of, but it's taken 3-4 years to mature.
Is it worth putting in the time now to use scalable or distributed technologies or just start with a LAMP stack?
A LAMP stack is scalable. Apache provides many, many alternatives.
Framework or not?
Always use the highest-powered framework you can find. Write as little code as possible. Get something in front of people as soon as you can.
Focus on what's important: Get something to work.
If you don't have something that works, scalability doesn't matter, does it?
Then read up on optimization. http://c2.com/cgi/wiki?RulesOfOptimization is very helpful.
Rule 1. Don't.
Rule 2. Don't yet.
Rule 3. Profile before Optimizing.
Until you have a working application, you don't know what -- specific -- thing limits your scalability.
Don't assume. Measure.
That means build something that people actually use. Scale comes later.
Absolutely do it later. Scaling pains is a good problem to have, it means people like your project enough to stress the hardware it's running on.
The last company I worked at started fairly small with PHP and the very very first versions of CakePHP that came out (when it was still in beta). Some of the code was dirty, the admin tool was a mess (code-wise), and sure it could have been done better from the start. But do you know what? They got it out the door before their competitors did, and became extremely successful.
When I came on board they were starting to hit the limits of their current potential scalability, and that is when they decided to start looking at CDN's, lighttpd caching techniques, and other ways to clean up the code and make things run smoother when under heavy load. I don't work for them anymore but it was a good experience in growing an architecture beyond what it was originally scoped at.
I can tell you right now if they had tried to do the scalability and optimizations before selling content and getting a website live - they would never have grown to the size they are now. The company is www.beatport.com if you're interested in who I'm talking about (To re-iterate, I'm not trying to advertise them as I am no longer affiliated with them, but it stands as a good case study and it's easier for people to understand what I'm talking about when they see their website).
Personally, after working with Ruby and Rails (and understanding the separation!) for a couple of years, and having experience with PHP at Beatport - I can confidently say that I never want to work with PHP code again =p
Funny to ask "scale now or later?" and label it "ruby on rails".
Actually, Ruby on Rails was created by David Heinemeier Hansson, who has a whole chapter in his book labeled "Scale later" :))
http://gettingreal.37signals.com/ch04_Scale_Later.php
I agree with the earlier respondents -- make it useful, make it work and get people motivated to use it first. I also agree that you should pick off-the shelf components (of which there are many) rather than roll your own, as much as possible. At the same time, make sure that you choose components for your infrastructure that you know to be scalable so that you can go there when you need to, without having to re-write major chunks of your application.
As the Product Manager for Berkeley DB, I've seen countess cases of developers who decided "Oh, we'll just write that to a flat file" or "I can write my own simple B-tree function" or "Database XYZ is 'good enough', I don't have to worry about concurrency or scalability until later". The problem with that approach is that a) you're re-inventing the wheel (and forgoing what others have learned the hard way already) and b) you're ignoring the fact that you'll have to deal with scalability at some point and going with a 'good enough' solution.
Good luck in your implementation.
This question already has answers here:
Closed 12 years ago.
I've read several other questions about material in order to learn RoR. But my question is can I start learning RoR without Ruby?
It's clear that the other way around is better, but I would rather try this way if it makes sense (somehow). Or learn both in parallel...
Well, given that Ruby on Rails is just Ruby written in a particular fashion (read: framework) yes you will need to learn Ruby.
You will need to learn these things about Ruby (amongst other things):
Everything Is An Object. Everything. Yes, even 2 and "foo"
Class Inheritance and What It Does(tm)
How to tell the difference between class and instance methods
Modules and how to use them correctly (class_eval Is Your Friend)
People write gems. Use them. Re-inventing the wheel is fine and dandy for learning but re-inventing it because you think your method is better is not.
And these things about Rails:
Do not fight conventions.
Do not fight conventions.
Model code goes in the model.
Controller code goes in the controller.
View code goes in the view.
Helper code goes in the helper.
Ask yourself "Does Rails have a helper for it?". If the answer is "No" ask somebody else. The answer is likely to be "Yes".
And these things in general about learning:
Google it.
Google it again.
If the answer you seek is not within Googling distance, formulate it in a way that is kind to those who may know the answer (such as you've done with this question!)
Appeal to people's greater motives. How can helping you, help them?
Try not to be too much of a help vampire.
If asking in an IRC channel, use a pastebin service such as http://pastebin.com, http://pastie.org or http://gist.github.com
Second rule about asking in IRC: Don't ask "any ideas?" after your question. Your question should already ask this by itself.
And finally: Love what you do.
People used to say that you could learn RoR without knowing Ruby (including DHH, if I am not wrong).
But in my opinion, if you also know Ruby, you can do a lot more stuff than without knowing it. And the knowledge would be very helpful when you debug or troubleshoot your programs.
So my suggestion is learn both in parallel.
You can. RoR is in a way a domain specific language, since a lot is defined for you and putting a simple application together can be like following a straightforward recipe. It would of course be better to learn the language properly, but many people don't.
The Ruby For Rails book tries to teach you both at the same time, so you might want to look into getting that one. I haven't read it but I hear it's pretty good.
Obviously :) ... if you really want to develop good web apps ...
But it will also be interesting to first get your hands wet with some RoR sample applications using inbuilt features that RoR provides... and then learn the details(which will require knowledge of Ruby)
If you avoid learning Ruby, (that many of the RoR developers do)... then you will find yourself stuck at position and going through an alien code. And eventually you might leave RoR out of frustration. I have seen many of such cases.
The question you ask is slightly ambiguous. Specifically, you could be asking "Can I learn Rails without first knowing Ruby?", or "Can I learn Rails without having to learn Ruby too?".
The answer to the later question is probably no, if you want to be particularly functional with it. Without knowing Ruby, it would be hard to take advantage of much of Rails' power.
The answer to the first question is most certainly yes. While knowing Ruby first would make learning Rails faster/easier, you can easily learn both at the same time. That's actually how I learned Ruby/Rails, by taking a site I had to implement first in Java and re-implementing it using Rails.
You need to know both, The RoR framework is an organizational and convenience system if you will, what it organizes is your ruby code.
If you have programmed before then here are most of your answers:
http://www.ruby-doc.org/core/
http://railsapi.com
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I love working with Rails but I keep tripping up against my own inefficiency: I'll spend time implementing some "useful" function only to discover subsequently that it was already in the framework, had I but known it!
Particular areas of wheel reinvention for me are
helpers and built-in class extensions
recently-released features that may not yet have lodged in my brain
plugins (a taxonomy of Rails plugins, if such a thing makes sense, would be a boon)
migration options
less-frequently used rake tasks
the options hash on just about everything
Obviously (?) we can't all remember all this stuff all the time. There are "cheat sheets", but unless they're up-to-date they can potentially compound the problem by appearing authoritative when they're really targeted at older versions.
What do you do to minimize this excise? Can anything be done?
I wondered if a set of Big Visible Charts might help, although goodness knows where I'd stick them in an open-plan office.
One thing here is to know about the existence of particular feature (plugin, gem, etc) in the first place. That's why
I try to keep up to date with the information about the edge Rails.
I follow many blogs and try to if nothing else then run over the titles every day, just to have it leave at least some tiny footprint in my memory.
That's for the passive part. Now for the active:
As I fly through the new features/plugins I try to imagine at least some use case in which it might be helpful in what am I working on right now - this exercise helps me to remember the thing, since I connect it to my actual conceptual system.
In my less serious projects I really try experiment with new things.
On SO I often answer questions I'm not sure about or I don't really know anything about but they seem interesting to me - then I do some research and extend my knowledge on that particular topic.
I don't think that "big visible charts" can help in the long run. I only use cheat sheets when learning new things and it's really only a short term thing. Exellence is a habit, as Aristotle said.
This isn't just a problem with Rails, but with any framework. Programmers I know who have worked for years with Delphi still are shocked to find simple standard functions that they'd replicated.
WRT Rails, Mike Gunderloy recently wrote about highlighting text, and ended with this wise tidbit:
It’s worth taking a dip into ActionView::Helpers occasionally to see what other bits of functionality are lurking that you’ve forgotten about.
Any time I need to do something I think should be easier than it is, I do a quick check there, as well as Google, to make sure I'm not about to waste a ton of time.
I face this problem as well- and it was a lot worse when I first started with RoR. Now after over 1.5 years, I know what's available pretty well.
Basically what I do is if I am using parts of the framework I know... no big deal. If I need to do something I will likely have to create myself, I first google it or search the Rails API. Lately I have also begun searching github and some of the plugin sites like railslodge.com.
While this does not completely solve the problem, it has helped dramatically.
I surf over the rails blogs in my RSS feed reading the headlines and just enough to figure out what the article is about. This gives me a good breadth of knowledge but pretty shallow. Still it lets me know what is out there. Like yesterday when I saw a blog post about a highlight helper (I had no idea it existed. Now I do and if I ever need it I know to look for it - even without reading the post in depth). I also open the posts I want read in depth in another tab for later (I used to use ReadItLater but it got out of hand) and as i read them i write notes in a post on my own blog more for my own benefit than for others - to get into memory and to ensure I can find it later.
The other thing I do when I am entering uncharted or forgotten territory is to I ask a question here about best practices or specific details even if I think I know the answer. For example I couldn't remember the names of the popular plugins for tracking edit histories of records (acts_as_audited and acts_as_versioned). I had the answer in 15 minutes.
It turns solo programming into programming in one of those cool noisy dev shops with a foosball table and lots of other people who know stuff i don't.
I tend to assume that most types of basic problems I'm solving have already been solved by someone else; by starting with the assumption my thoughts aren't along the lines of "how do I build this" but "where do I find it" and of course google, the wikis and the plugin and gems lists all play a part in that. I have written very little code that isn't directly related to my business domain.
I write tests first. Then code. Sometimes the framework does it for me and I don't have to write code. :)
I don't think Rails is any different than other frameworks... it takes a while to know where things are. The best you can do is read the API docs and see what's there. You don't need to learn how to use it, just what is there and get an idea of how to look for it when you need it.
Also, it's not a bad thing to write code that someone else already has. You learn from it. Later you just swap in the framework mojo and see if your tests still pass. If so, you're good and you know how the internals of one part of the framework probably work.
I believe the key to eliminate the time wasted on reinventing the wheel is to have a very handful tool to search inside the Rails helpers/capabilities.
On one hand a good choice of IDE could help a lot. On the other hand - a very good online (offline) edge documentation with an ability to quick search through it. These days one of our russian Rails programmers made one: http://railsapi.com/. The search is done in a very MacOS style, making it a very good choice for a fast diggin'.