I already have experience with Rails development process but i still have confusion about to maintain standard development of Rails Application, mean how to maintain standard of assets, views format etc.. can anyone explain about standard rails application repo
Read this rails style guide.
You will get a better picture about folder structure and standards about Rails.
Related
I'm building a Single Page (Web) Application. I'm quite smitten by Rails v5.0, especially its built-in API capabilities.
In the past I've built JavaScript frontends using Vue.js, usually with the templates provided by the Vue-CLI project. This allows deployment of Vue component-based static sites basically anywhere. It's great.
Now, Rails 5.1 has some built-in Webpack and Yarn features which look pretty compelling too. I'm not sure how to proceed with my new application.
My questions:
What are the pros/cons of integrating Webpack and Vue into Rails itself, using the Webpacker extensions available in Rails v5.1? I
intend to deploy to Heroku.
On the other hand, what are the pros/cons of using the Rails API-only mode for the backend, and maintaning the Vue/Webpack-based
frontend in its own directory? I'd keep everything in the same
repository, deploy the backend via Heroku, and the frontend via a
static host like Netlify.
Which approach would have more cognitive overhead or technical complexity?
Over the past few days, I've been looking around, and I've not found much concise information on the web about this. People seem interested in the auto-reloading features of the Rails development environment, but I get that for free already with Vue-CLI.
As far as I can discern, these are reasons for keeping them separate:
Deployment of the frontend is pretty darn simple to anywhere.
The Webpacker mode for Rails is very new, and not many tutorials or guides exist yet, especially regarding integration testing. Keeping
things separate means that my existing testing apparatus should still
apply.
Here are some pros for integrating the two parts together:
The possibility of using static assets both for the frontend and possibly for server-generated pages in the future, should that be
necessary.
Buy-in to "the Rails way", with implied future maintenance by the Rails team.
the JS Frontend would not need to be hosted separately.
Don't need to worry about CORS (?)
What other concrete benefits exist for either approach?
When i started i went the webpacker way, somewhow because that's what it looked like it was "supposed" to be. As you say, very little guidance.
Webpacker (with it's reliance on the latest node) seems a moving target, making deployment and even development more complex. For what benefit i asked and got rid of it.
Now i use vue from the cdn. Benefits:
cached close to user
almost zero installation
easy to have dev/production versions
The i write app code into the rails templates. Using haml, and in fact ruby2js, but you can use javascript just fine. That's how i started, but i like ruby, and the ruby code is almost half the size than the generated js, but i'm getting off track.
So templates are your "vue annoted" rails templates.
Small code also goes into the rails template.
More code can be defined in the assets and referred to from the app.
Even components can be written into template using the x-template syntax.
And last but not least: Data can be transferred by to_json, directly into the templates. And in the same render. Much faster than an additional query. When to_json is not enough one can use rabl to get exactly what is needed.
I hope i made that clear. I am in the process of writing some vue-rails stuff up, as there is so little to be found. Look out here (and i'll comment when the post is ready)
I have a question. I'm moving from PHP with Symfony2 to RoR for my next project, with the main priority being RAD when I become fluent in RoR.
What (Ruby/Rails) tools can I use to achieve incredibly fast prototyping and development?
I've read into the Rails generators and such. My team mate has been using Rails for 3 years but doesn't use scaffolding. Does anyone have any gems they use to speed up development time or if scaffolding should be used?
Thanks for any input.
Given your requirements of an incredibly fast prototyping and development environment:
Use generators (model, controller and others).
Use scaffolding for prototyping and also for created all the right files, etc.
Use formtastic or (even better) simple_form to make forms MUCH easier.
Use rails3+ now the standard.
Use ruby 1.9.2+
Use Devise for authentication and authorization.
Use cancan for roles- admins, read-only, etc.
Use rubyMine for more hints than you can imagine.
Use VI for cred, ed for even more.
Use mySQL for your database.
Rails Composer seems to be good all-inclusive collection of highly recommended gems, an easy setup of a fully-featured RoR project.
I've been using online tutorials to learn ROR. I've used www.lynda.com video lessons to get a basic idea what Rails is all about, and for practice I used Rails version 2.0.2, during my training period. But now I'm into a development team in a starter company where there are no senior/experienced programmers to assist me and we're working on gitorious source code modification using Rails 2.3.8. I'm facing a lot of difficulties to understand the source code and some of the major differences I could notice is as follows:
Inclusion of XML and HTML to render views in scaffolds, in Rails 2.3.8(I don't understand what this is, as I'd never come across this during my training period using Rails 2.0.2)
In gitorious source directory, in addition to Controllers, Models, Views and Helpers there are two more directories namely, Processors and Metals. I don't understand what their significance is.
Extensive usage of .yml files. What are those for? In rails 2.0.2, all I came across was the database.yml. Now, in gitorious, I see gitorious.yml. How are all these so customized? I mean, how do rails app(controllers, models, etc..) communicate with gitorious.yml?
With respect to all these questions, how do I move a level or two up, to call myself an "intermediate Rails programmer" from "Rails novice programmer"? and how do I stay updated of new api, deprecations, in all upcoming Rails transitions?
Inclusion of XML and HTML to render views in scaffolds, in Rails 2.3.8
Yes, the way scaffolding works has changed - I can't remember exactly when it changed, but I can certainly believe the change happened between 2.0 and 2.3.
When you generated a scaffold the old way, it would just include 'scaffold' commands in the controller, which would render up a default interface for each of the actions until you replaced them with your own HTML templates.
The new way actually generates the HTML templates as files: so, in the views directory, there will be a directory containing ERb (HTML with embedded Ruby). You can then go and edit those directly.
It also renders XML - this is done by default, but you can choose what other formats are produced. Rails lets you produce multiple output formats for each controller action - so that you can easily produce RESTful web services. So, you obviously produce XML by default, but you may want to produce machine other formats too: XML (including RSS/Atom), JSON (and JSON-P etc.), RDF, YAML. I use this to produce CSV and Excel so users of the site can get data exported to their spreadsheet package.
In gitorious source directory, in
addition to Controllers, Models, Views
and Helpers there are two more
directories namely, Processors and
Metals. I don't understand what their
significance is.
processors/ is used by ActiveMessaging - it contains ActiveMessaging processors - basically code that gets called as part of communication with a message queue that ActiveMessaging is hooked up to.
metal/ contains code that can best be characterized as 'middleware' - basically, to deploy a Rails application you use a library called Rack which abstracts away the interface between the server and the app itself. It allows you to use the same web server and other infrastructure and switch between different Ruby frameworks - so, if you are using Rails or Sinatra or Merb, Rack lets them all communicate with the same server.
Now, Rack allows you to write 'Metal' code, which is code that gets run directly on the server without the framework getting in the way. The reason you write Metal code is for performance - when Metal code is running, it is running directly rather than with the weight of the Rails framework getting in the way. This way, you can get better performance. I haven't ever had to write any Metal code, so I can't really explain it beyond that.
Extensive usage of .yml files. What
are those for? In rails 2.0.2, all I
came across was the database.yml. Now,
in gitorious, I see gitorious.yml. How
are all these so customized? I mean,
how do rails app(controllers, models,
etc..) communicate with gitorious.yml?
.yml files are files in the YAML format. In Rails, these are mostly used for configuration. Just as XML files are used by Java applications for configuration, .rc files are used in Unix for configuration and .ini files are (were?) used for various apps on Windows for configuration, you can store data in the YAML file which the Rails app uses for configuration. Because of the simplicity of the format, a lot of Ruby and Rails apps use YAML for configuration files.
Ruby has a built-in YAML module that loads these in using methods in the YAML module including YAML.load, YAML.load_file, YAML.load_documents etc. To see how they are being loaded in, I suggest the easiest thing is to find the string "YAML." in the project - or, indeed, the name of the yml files.
With respect to all these questions,
how do I move a level or two up, to
call myself an "intermediate Rails
programmer" from "Rails novice
programmer"? and how do I stay updated
of new api, deprecations, in all
upcoming Rails transitions?
I would suggest that a fair amount of conservatism is appropriate with Rails updates. I'm still using Rails 2.3.3 on a production site, and that's fine. I should probably upgrade to 2.3.8, but I tend to not run with the bleeding edge on production projects.
As for the best way to learn, I'd suggest that you work through Railscasts - these are excellent short screencasts that describe all sorts of useful techniques and help you learn lots about the Rails framework. When you need to do something, obviously there is the API docs - which are okay. The Rails Guides are pretty good and worth reading.
As for books, there's Agile Web Development with Rails - which is a pretty good tutorial. There's also The Rails Way, which is a massive desk reference and in my experience one of the only good ways to learn about some of the minutiae. You might also want to check the StackOverflow question What’s the best resource for learning Rails for a raw beginner? - because although you obviously aren't a raw beginner, the resources recommended are up-to-date and useful for going from novice to intermediate and on upwards. Good luck!
Does Rails 3 have anything akin to slices in Merb, or areas in Django where there is a layer of organization above the controller? I heard at some point that they may allow hosting one rails app within another but I can't find any information on that in the pre-release material. Any hints on how to do something like this?
You're right there doesn't seem to be a lot of official documentation on it yet. But yes, you can have application slices -- they're called engines in Rails. Actually they've been available in Rails since 2.3. Currently, you basically make a plugin that has a complete application structure and set up your routes in there to "mount" your app against a specific URL. In Rails 3, engines are basically first-class objects in the Rails stack. I believe they can still be plugins but you will also be able keep it away from your application in a separate gem and require it in your application much more easily. You should be able to find stuff pretty easily on teh Google, but here's an oft-linked but informative reference: https://gist.github.com/af7e572c2dc973add221
I have a Rails 2.3 application which I would like to extract into a plugin, or engine. The application has user authentication, and basic cms capabilities supported by ancestry plugin.
I want to extract the logic for the application into a plugin/engine so that I can use this code for future projects, with a different "skin" or "theme" if required.
I'm not entirely sure I actually understand the difference between plugin and engine concepts, so that would be a good first point.
What is the best approach, are there any good starting points, links, explanations, examples that I should follow. Also, with the release of R3 to consider, is there anything that I should be aware of for that, with regards to plugins etc.
I am going to start off by watching Ryan's http://railscasts.com/episodes/149-rails-engines
but obviously thats over a year old now, so one of the challenges I'm faced with is finding the most up to date and relevant information on this subject.
All tips and help gratefully received.
Actually, converting an application is pretty straigtforward. Just create a plugin-folder, put an app-folder inside containing all yor model-views-controllers folders, and that's it.
You will have to manage your migrations yourself though. Also you have to define rake-tasks to copy files to your public folder. I think the railscasts is still pretty up-to-date, if anything it is now easier in rails 2.3.
Good luck!
[EDIT: for rails3] Rails 3 engines are very clean and powerful. Check this gist by Jose Valim.
You will probably be better off focusing your engine on Rails 3, as opposed to trying to make it compatible for Rails 2 and Rails 3, due to the backwards incompatible changes. Here is a more up to date tutorial for Rails 3
also the book "Crafting Rails applications" by Rails Core member Jose Valim, has a good chapter on it. Int he shows how to use his tool EngineX which generates a Rails 3 engine structure, so you can more easily create engines for your Rails 3 projects. His gem devise is also a rails engine which is also nice, because you can easily customize it by copying the templates into the application directory, and allowing you to subclass the controllers that you want to customize more.
Writing a plugin is an entirely different process than writing an app, if you already have your app code it should be straightforward converting it into a plugin.
Consider that if you use third-party plugins in your app it could get pretty messy.