Hey so I realize this probably isn't good practice, but I was wondering if it's technically possible to combine the code from my various rails model files into one .rb file?
I have a lot of very short models, and when making changes to them it'd be quite helpful to be able to see them all in one place instead of having to open up numerous windows.
This goes against the rails philosophy of Convention over Configuration.
Ruby is a highly flexible language, so yes it would be possible to do that, but you would have to undo much of the auto-configuration that makes up the entire reason for using rails.
Related
Breaking a large rails app into smaller apps?
Modularizing Rails applications
Best practice for structuring a 'large' Rails app
I have a quick question on modularization in a large Ruby on Rails App.
Setup:
I am building a core app that stores information about people. I also have several 'modules' that use that information in very different ways. (e.g. one could display information about the people, another could figure out connections and commonalities between them, etc).
The question:
How do I modularize this app efficiently?
Potential Answers:
Since the modules share models and views with the core app (and eachother) it makes sense for me to combine them into one app. However, as the app grows this will obviously lead to problems. This to me suggests either Namespacing the controllers and models "How to organize controller in moderately large Rails application?" or using engines "Modularizing Rails applications".
Since the modules are in active development it is very helpful to use rails generators on them, which seems to make using Engines a pain in the butt. It also seems that while engines are fully supported from a Rails point of view, they still seem rather hacky with regard to lack of generator support and database migrations. Does anyone have experience with developing engines successfully? It seems like engines would be a great solution if you had a working app and wanted to port it into a plugin (i.e. copy paste code) but if you are actively developing it (changing models etc) it would be difficult.
The last thing I have seen around is using multiple apps and one database. This way seems like a royal pain with migrations and keeping models straight etc etc. But I thought I would get thoughts on that as well.
Rails engines seem to be the correct solution for you. I have used engines when I worked with Refinery CMS, which is built on top of Rails Engines.
The following are some nice links which talks about Rails Engines:
http://www.themodestrubyist.com/2010/03/01/rails-3-plugins---part-1---the-big-picture/
http://www.themodestrubyist.com/2010/03/05/rails-3-plugins---part-2---writing-an-engine/
http://www.themodestrubyist.com/2010/03/16/rails-3-plugins---part-3---rake-tasks-generators-initializers-oh-my/
http://www.themodestrubyist.com/2010/03/22/rails-3-plugins---part-4---more-on-generators/
I wouldn't use engines. Engines are meant to be used to share functionality between apps. What you want to do is not to share functionality but to organise it.
In order to organise your code you can do a lot of things.
Use namespaces.
Keep your controllers thin.
Keep your models thin (Yes, your models; see next bullet point)
Use the Data Context Interaction (DCI) pattern.
Use a widget framework like Apotomo, or Cells.
Write tests, so you can refactor.
Consider a Service Oriented Architecture(Consider Hypermedia API design) if your app's responsability grows too much.
Andrzej has very good articles about DCI.
http://andrzejonsoftware.blogspot.com/2011/08/dci-patterns-how-to-write-dci-contexts.html
One application, one database.
Share the models between the modules.
Namespace your controllers and views.
Test.
You can also use Rack Middleware to handle specific tasks.
For the bulk of your application, Engines seem like the best solution – it's something I'm looking at doing too. Looks like you can define generators in the Engine easily enough.
Depending on the structure of the data, and access patterns, it might be useful to separate the app into multiple apps, and possibly, additionally, provide data access by (RESTful) APIs.
In my experience, this allows for the best structures when your application(s) grow from middle to large size, and forces you to think about structures and separation of concern. Scaling up is also usually easier.
I have a created a userdriven gallery with Ruby on Rails.The site is using a few plugins to create friendly links, permissions, pageless pagniation etc. The application controllers and views has gotton quite complex and I find it difficult and very time consuming to work with. So I thought about rebuilding the app with hobo, as it includes all the user and permission logics and another template system. However I am affraid that I will be to limited, or maybe not win anything becasue I will loss a lot of time hacking hobo. I am planning to add frinedships and personal messing to my website. Could this be to compelx for hobo? Does hobo use jquery?
Best regards.
Asbjørn Morell.
Hobo is not that complex, however you would need to study documentation which takes some time. But, in the long-run any refactoring such as Hobo could help, if the code is currently getting unmaintainable.
JQuery can be used in any sytsem as it is independent of script frameworks etc. AFAIK,
No one can tell you if Hobo will help your specific program.
That said, I have been using Hobo for a while and I have found it to be very effective. It handles a good part of the standard rails logic every site needs (such as routes). The dryml system has been useful in my work as well, reducing the size and complexity of my views.
If your code is becoming unmaintainable and you feel a refractor is necessary, you could definitely do worse than Hobo.
i have been building a few hobo apps and they work rock solid, problem is dryml is quite peculiar and you must learn and do a lot of test and try, but in the end it allways comes along quite nicely. i recommend you start quickly with hobo and you will end up faster..!!
I am (quite) an experienced programmer but totally new to Ruby and Ruby on Rails.
RoR looks great to get working quickly, specially the automatic screen generation for CRUD operations.
It really it gets you productive quickly.
The questions is with the last 20% of the work, when I must finish my application. Won't RoR conventions stand in my way? Because not every database table must be available for all users, and not all users can edit all columns and/or all rows, and the views must be adapted to my site's look and feel, etc.
I understand RoR has been used successfully in live sites, but how exactly do you gain enough speed in RoR to escape gravity after the first phase has been burned out.
I don't think scaffolding gets you 80% there. Scaffolding is nice in that it shows you how the pieces of Rails fit together, but I wouldn't build my application off of scaffolding code. Now that you've been impressed by scaffolding it's best that you forget all about it. :)
Where Rails really shines in my mind is database migrations, the awesomeness of how dynamic ActiveRecord is, and the plugin ecosystem.
There's a lot to learn when deciding to go with Rails. You have a new language, new framework, and new plugins - but if you take the time to learn those things you can be very productive with Rails.
I've been doing ruby on rails for quite sometime. The 80/20 problem is not unique for rails. It applies generally to the entire world. I'm also not aware of any framework that can just do business logic for you.
To answer your specific questions. Conventions will not stand in your way while doing the 20%. Instead, conventions will help you to get through that 20% quicker.
Personally, for user authentication, I use Authlogic. For user authorization, I use Lockdown or Authorization plugin depending on customer need.
I also use inherited_resource in most of my projects to simplify controller code. This is another power of convention.
To increase speed of development, you will not only need to know Rails, but rails gems/plugins that does the right things for you, so you don't have to reinvent the wheels again. Also, knowing Ruby language is a must for quickly develop beyond the 80%.
Ruby Toolbox provides some of the most popular gems and plugins used in typical rails projects targeted at specific domains. You can look through the relevant categories and know what most people use. (And it's probably a good idea to use popular, well maintained gems)
TDD/BDD style development will also help you to speed up in the long run.
Lastly, a warning: If you stray away from rails convention, you will have a painful time in general.
P.S. I used Merb before. My feeling is that conventions helps you in merb, but you won't get too much penalty for not following them in merb. However, my experience with Rails is that if you decide not to follow rails convention while developing rails app, it will come back to bite you in one way or another! So think twice when you really attempted to stray away from rails conventions... (This is from my own experience, and of course subjective, but you can think of it as a warning...)
Won't RoR conventions stand in my way?
Because not every database table must
be available for all users, and not
all users can edit all columns and/or
all rows, and the views must be
adapted to my site's look and feel,
etc.
This is a bit of a non-sequitur. Rails is a framework that has been lifted from real world applications. Those applications had to deal with all those issues also, as well as others you may not have thought of yet. Generally, the conventions make life easier once you learn them.
Another point is that the conventions are merely conventions. You don't have to follow them. You do not even have to use RoR for everything, though I've yet to find a case where I didn't/couldn't, I do generally try to push as much into the DB or cache layers as possible.
I don't believe that you'll ever have a serious problem with Rails conventions. Just stick with the conventions and trust the RoR system. The people behind Rails put a lot of effort into these conventions to support 99% of the common usage scenarios.
If you really need to do something outside the conventions it will eventually get complicated quite fast. However, you are not alone. There are a lots of excellent resources on the net to get help (for example the StackOverflow community).
To sum it up:
Stick with the conventions whenever possible (excellent resource to get started: Rails Guides.
Don't reinvent the wheel. Look for Rails plugins and Ruby Gems instead (don't forget GitHub).
Consult the StackOverflow community if you need something out of the ordinary.
Test all the f***ing time (just for fun).
Now about 2 weeks into learning Ruby and Rails, I've found myself using the File class a lot for things like File.join, File.open, etc. Then I bumped into a need for File.copy only to find out that no such method exists. A little more looking uncovered Rails' FileUtils class and now I'm a little confused.
There are differences, of course, but there are also what appear to be redundancies. Is one preferred over the other where there are differences? Why do both exist (is it solely to handle the omissions in the Ruby core class)?
I'd just like to get a feel for how these things work together or conflict so I know how to move forward.
Thanks.
FileUtils is part of the Ruby Core API. It's not Rails specific. Also, it's a module, so you could mix in some of the abilities it has to offer into another class. Your best bet is to probably read the File RDoc, as well as the FileUtils RDoc. Hope this helps you out a bit. Cheers.
Edit:
Is one preferred over the other where there are differences?
I don't know if there is much consensus over which to use when the methods have the same ultimate end–result, such as File.makedirs vs. FileUtils.mkdir_p, but I often see the latter in other peoples code. I think you will almost always use the two (File & FileUtils) in conjunction.
Duplicate: Django or Ruby-On-Rails?
I have been reading on Ruby on Rails, and it seems like on some threads, some users like Django a lot too?
Can someone who have used both give some insight about using them, such as
ease of use
productivity
fun factor
deployment issues
or any other framework you'd highly recommend?
Both are excellent frameworks. Though, I've found Rails to be more suited for the agile developer. For the most part, you'll run some generators to get the files you need as placeholders for your code. Things will work right away, and you just build up from these conventions. It's really flexible and has a large community, lots of innovation and interesting practices are being put into Rails. It's development cycle seems faster paced than Django.
After only touching the surface with Django, it has some interesting differences. As far as I know, you don't get the schema migrations like Rails has out of the box. But you get an extremely simple CRUD mechanism for your models with the extensible admin interface, which is great for testing/managing content. The entire project is documented really well, from the Django Book to the vast amount of information on docs.djangoproject.com.
I personally prefer the Rails way of doing things. But honestly, you need to try them both to see what works for you, and since we're talking about two very good, yet totally different frameworks, it's a tough decision to make either way. So, if you already know Ruby or Python well enough, start with what you know and just go from there. Once you understand how one works, you'll be able to evaluate the smaller differences yourself. Hope that helps.