I'm new to Ruby on Rails and have been seeing people use auto boilerplate generators like Rails Brick or Rails Composer to create boilerplate user-management systems, etc. Coming from a background that doesn't trust auto-generated code, is it good/legitimate practice in Rails to use such systems. Also, I'm working on a project with a startup. Is it fine to use such generators and how widespread a habit is this.
P.S. Mods please note that this is not a question asking comparisons/opinions/disputes. I'm curious about the general practice in Rails and how often is this used in production.
I'm the maintainer of Rails Composer so I believe I can answer this question with authority.
I respect (and share) the urge to build from scratch. That's a healthy impulse. Rails includes a facility for application templates (Rails Composer is an application template) because automation saves time and effort. For people who build many web apps, a time comes when you decide to automate the process.
Rails Composer offers an advantage over roll-your-own application templates because it is open source, used by thousands of developers with code contributions by many. As Rails and gems change, Rails Composer gets updated so you get a current "reference implementation" every time. It gives you well-tested starter apps that integrate all the bits and pieces that require tweaking, like RSpec plus Capybara and FactoryGirl, flash messages and navigation with either Bootstrap or Foundation front-end frameworks, Devise or OmniAuth for authentication, Pundit for authorization, and many utility gems that developers like to add (Guard, Pry, etc.). It lets you choose your stack (for example, ERB, Haml, or Slim), offering choices to the extent that the community has contributed options.
If you're concerned about the safety of running an install script, the code is open source and used by thousands of Rails developers (you can see over 2000 watchers on the GitHub repo). It's purely an application template using the Thor library, and though in theory someone could contribute code that tampered with your files, we'd never accept a pull request like that. Rails Composer only offers well-known popular gems, so you are not exposed to potential risk of using unknown gems.
Rails Composer is widely used, particularly by consultants who build lots of apps. Many of the prominent consulting firms have an in-house application template (Thoughbot Suspenders, for example) and some use Rails Composer or the rails_apps_composer gem that generates custom application templates. Developers who work on on only one application regularly (maintaining a big project, for example) tend to be less familiar with application templates like Rails Composer, but it is popular with developers who start a lot of apps.
Stack Overflow is not a place for opinions, so if you want a range of opinions or debate about the merits of Rails application templates, Reddit or Quora might be a better place to ask.
Welcome to Stack Overflow! I hope all your questions will be answered accurately and timely.
I'm the developer of Prelang which is similar to the generators you mentioned. It differs by adding data modeling, GitHub integration, and deeper configuration for some features. Like Daniel, I believe I too have some authority on this and agree with his very complete answer.
To answer your question, Prelang is newer but it's already used by thousands of developers ranging from beginners to dev shops.
I'd like to note that Prelang (and the other builders) are different than what you traditionally think of when you hear "code generation". When working on Prelang, my goal is to automate "everything that a Rails developer would have done anyways". Prelang does generate methods/code but mostly it's automating install processes of Gems, setting configuration values, creating models, and running rails commands. That said, Prelang is opinionated in terms of which gems it uses but I've selected the most popular gems for each feature and will give the flexibility to choose between multiple routes once I get a little more traction.
Prelang also makes real Git commits so you can look through every commit after your project generates giving you full visibility into your codebase. This is intended to further ease concerns relating to generated code.
Erik
Most gems are so easy to set up nowadays, that I think you won't need such a generator. After all it's just a question of taste – I like using the command line, and I like knowing exactly what's in my codebase. From my personal experience, I have never seen someone use such a thing in professional Rails development, but clearly there are people out there who use them.
The one case I can think of where these generators make sense is when you're bootstrapping projects very frequently. In this case however, I find the existing generators not to be flexible enough. Thoughtbot for example has built their own app generator called Suspenders, which of course includes a very opinionated set of gems etc. but it gives them exactly what they need.
As a side note regarding your security concerns: for me, the dependency trees that are spanned up when you use many gems are a far worse security threat. For example in a medium sized Rails project it is not uncommon to depend on 100+ Gems; no-one can read all of them. You'll have to trust all of those as well.
Related
soliciting advice about upgrading (or re-writing?) a legacy app. It's a single page webapp with lots of dynamically generated windows and forms, roughly comprised of
13,000 lines in .rb files
11,000 lines in .erb files
25,000 lines of javascript (not including large 3rd party libraries that bring this to nearer 60000 lines)
This acts as a UI for end users of our system, which also has a number of core business services (mostly written in Java, with a small amount of Node.js) and a fairly sizeable MySQL database (>200GB). Some of these services push AJAX to the client browser for real-time updates.
Reasons for upgrade
It's ruby 1.8.7, rails 2.3.15. Most of the core code dates from 2009. This makes it both insecure and hard to maintain (think "predates the existence of gemfiles".)
The app has been maintained by Java devs for most of its life, as most of the company's devs have been hired as Java devs to work on all the other services that perform business logic. It's probably safe to assume that this has lead to lots of hacks from people who didn't want to break anything, and certainly lots will not be done in a "rails way".
The javascript is also a bit of a mess. It's got a knot of frameworks (the original Angular is used sporadically; jquery and prototype are both fighting over the $ symbol in different places.) There are files that are 7000 lines long.
the css styling has been upgraded since 2009(!) but is starting to look a little tired. We'd like to implement a bootstrap theme that will look sharp without too much front-end skill, but right now the code that renders all of our pop-up windows, sidebars etc breaks badly if we try and add bootstrap.
It would be nice to modernise our push servers, replacing them with websockets.
Context
There are 3 of us on the dev team- this is my first job, and I've only been here since January. Of the other two, one has only been here about 4 months longer than me, and it's his first dev job too. The other guy is the only one who has ever spoken to someone who spoke to someone from the original team.
Oh, and of course we have little or no test coverage.
Options
When I was hired (as a Java developer), I was told that we were looking to replace the website with one based on Spring MVC. This effort is partially underway, having been attacked in drips and drabs over a couple of years. Because different devs who never met have attacked it as if it's their own brand new project, the same problems are solved in different ways in different places. They've tried some flashy techniques such as custom annotations that I find hard to follow, but as far as I can tell don't fully work. The most senior of us estimates it would take our team a year's dedicated full-time work to finish it (which is not a realistic business proposition, based on how many requests for new features we get from customers).
I'm inclined to upgrade the website rather than spin out a new one. This is partly because I can see the sense in that post. Another reason is that we're all employed as jack-of-all trade full stack developers (doubling as DBAs, sysadmins, etc...). We've got no particular expertise in UI design, and the UI for our present interface, although dated, is pretty user-friendly; it feels like a blank canvas would throw that structure out, and play to our weaknesses. Upgrading ruby/rails would also make any features we add during the upgrade much easier to add to the new site.
Apparently some experienced ruby devs who are friends with my boss have advised him informally it'd be so much work to bring the website up to date that it would be comparable to a complete re-write, which was the motivation for the spring project. This would have the advantage of only having to think about Java + javascript, and not trying to hire people who know both Java and ruby well.
Conventional wisdom seems to be upgrade rails in stages. I'm not sure how well this would work for us, for 2 reasons. For one thing, there 3 major versions for us to upgrade, which might have significant changes between them. More importantly, the code needs some TLC anyway with refactoring and the creation of a test suite.
I'm inclined to follow the following strategy:
Invest some developer time in training, to get a sense of the relevant best practises and the "rails ways" of doing things, rather than the "good enough to hack" knowledge most of us have now.
fire up a new rails 5.1 project on ruby 2.4.0
Configure active record to use our old database
Copy across the javascript from the public folder of the existing project in to the relevant parts of the asset pipeline and save that headache for "phase 2".
Sort out a gemfile with updated versions of our dependencies (for example, mysql gem has been replaced by a mysql2 gem.) Installing rubocop seems like a good idea at this point.
Copy files across from old to new project one at a time. Read the code, figure out what it's doing, write the relevant tests, fix where they break. Use the ruby API and rails upgrade guides to update the syntax. Refactor until rubocop is appeased.
Once we've reproduced the functionality of the existing site, write a new stackoverflow post on how to sort out the javascript ;)
This certainly sounds like a lot of work, but seems less likely to produce a buggy mess than trying to reproduce our existing functionality from scratch in a different language. So...
Questions
Does this strategy seem sensible? Is this a case where the re-write is really a better option? Is tackling the JS separately the best call, or is it better to restructure it as we're examining the calls to it from the views? Or should we really upgrade -> 3.0, 3.1, ... 5.0, 5.1?
We've altered the database manually, adding new tables, new fields and whatnot directly rather than using .rails generate. 'Rails magic' seems to make this work at present, but should we anticipate problems in step 3?
Is there any logical order in which to approach the migration of ruby? As there's major changes to the routing, which is the central entry point of the application, it seems sensible to start there, followed by authentication, then the main page, and then add functions one at a time.
Part of the problem is "not knowing what we don't know" about the rails way of doing things. Apart from the canonical Ruby/Rails tutorials (Hartl, Ruby Monk, Ruby Koans, Kehoe's rails book), is there any essential reading we should be aware of before trying to take on such a large job? I'm especially thinking about things that may not be immediately obvious, like proper use of helper functions, module structure, etc.
Any other advice, comments, prayers, ... welcome!
For the first time I'm creating a quite complex Rails app.
I'd like to know what's the best way to organize that app by folders. Until now, I'd do everything under one app (all the models, controllers, etC) but reading some open source code I realize that they put everything under different apps.
Like for example Spree Commerce. They have a general folder and inside that they have different apps (API, core, admin, etc). How is that done and is that the best way to do it?
I'd like to get pointed to the best way to do it (a book, blog, anything) so I can understand how I can architect my app for future maintenance.
thank you
As an aside I think the title of your question is a little confusing. Rails, by using convention over configuration, defines 'how to organise a Rails app'. I think your question is rather about how to architect your application as opposed to anything Rails-specific. Maybe tweak the title?
That aside, without knowing any more detail about your project it's a tricky question to answer, but I'll give it a go.
All applications should start off simple, if you believe (like I do) that you should start by building the simplest thing that could possibly work. Given this, since you're using Rails, then in all likelihood the simplest thing would be to structure your app as a vanilla Rails 3 application. This will probably (I say 'probably' because I don't know any specifics about the app) allow you to get a beta version of your app up and running pretty quickly without worrying about complexities which at this stage in the development of your project are not a problem.
If you need to create an XML or JSON-based API then Rails makes this really easy using the standard framework, which will allow you to spend more time thinking about the API design than how to code it, and it's the API design which is the most important thing to get right in the first instance.
Similarly, your Admin site can be part of the same app just in a different namespace. If you find later down the line that you want it as a separate app, you can do this (maybe you could use the awesome API you designed to facilitate this), but why bother designing it with this added complexity (and hence extended development time) in the first place if you don't have a good reason for doing so?
Once you have your app up and running and people are starting to use it, you start to get a picture of where the bottlenecks are and where the design could be improved. At this stage, if there's a need, you can start to move parts of the app to scalable solutions, such as running your API as a standalone service, introducing caching, changing data stores and other improvements and optimisations.
Even if your app is as wildly successful (and I hope it is!) then re-architecting your application whist continuing to run the existing service is still entirely possible, as Twitter have proved. Just stick to Knuth's statement and you'll be alright.
Regarding reading material, that's a tricky one. For me a lot of the XP and agile development classics taught me a huge amount about how to approach program and app design. I'd also check this StackOverflow topic for book inspiration.
Good luck!
Spree uses Rails' Railties (Rails::Engines). Railties are introduced in Rails 3 to make it more modular and easy to extend. Rails 3 itself is a collection of Railties (ActiveSupport, ActiveModel, ActiveRecord, etc.).
If you are developing a complex app I would suggest spending some time planing its' architecture. Designing a complex app without any initial planning would definitely end with a maintenance nightmare down the road. It also introduces a huge learning curve for the new team members, slow down your new feature introduction and of course, frustration.
Anyway, don't over optimize, but don't forget to design your architecture for your needs.
IMHO, I will create very complex projects as one app. I have reason to believe that Spree and Radiant build under seperate apps so that under the pretense of their open source communities, contributors can contribute code easily without tampering with the core data, and the core workings of the application.
Otherwise, you should be alright just building it as one app. Just keep it neat.
Here is what have kept me sane for several years of RoR development:
I use Rails Engines, but keep them in same codebase as the main app. Here is good starter for modular Rails app:
https://github.com/shageman/the_next_big_thing
Wherever I can I try to reduce coupling and use composition to make things easily testable, reusable and maintainable. This helps to eventually extract module or engine as separate gem. Composition is done by routes (mounting), directory overlaying (assets), dependency injection or configuration.
If I don't need to re-use an engine I put it in the same code base as the main app which is single deployment unit. Thanks to that I don't need to switch between projects in my IDE. While in development environment any changes to the engine code are instantly picked up by Rails reload mechanism.
I am a somewhat experienced rubyist, but I am now starting to do rails development. I know rails is used to make "web applications" but what exactly does that mean? Do you build entire sites with rails or do you build a feature for a website in rails, and integrate it in to an existing website? (I know this question is kind of vague, but any answers to how ROR is used in the creation of websites would be much appreciated).
Generally speaking, you will build a full site with Rails, though you can integrate it into an existing website, as well. It is designed to provide a top-to-bottom solution for entire websites.
For standalone features or small scripts you just want to expose to the web, you might look at something like Sinatra or Camping.
What is Ruby on Rails?
I'm also build some rails applications in that I had entirely use rails to develop my web application. It's quite easy rather than using two or three languages. But when I developed I had to use Javascripts, CSS and Ajax to create more attractively
For me it's a great framework to build website and minimal knowledge is required although experience and knowledge of ruby gives you an upper hand.
I also feel that rails is good not only to build websites but to manage it.
Also the support community of rails is awesome and is complemented by guys like Ryan bates with their screen casts.
Also when we build a website using ror, we have the flexibility to concentrate on different features at different times or by different person.
This gets a great modular structure.
So you can design the basic functionality today and tell your colleague to get the views attractive using JS and friends without affecting your functionality.
Also the external support for rails (like gems and plug ins) is awesome and makes life heaven!
I would suggest that it's a great framework and the best feature is that it is a very easy to begin and learn but it always surprises you with new things.
Thus it allows you to learn a lot!
Hope it helps.
The website/web application distinction is made because there are many Rails apps in existence with no front end or 'website' to speak of. Using Rails, one could serve JSON amongst a cluster of compute nodes for data aggregation, or text to unix sockets for display on terminals. The uses for Rails are only limited by ones imagination, and you could even use Rails for single host interprocess communication if you desired. This might prove effective for a highly skilled rails programmer rather than learn a new tool to achieve similar results.
I'm a big fan of ruby on rails, and it seems to incorporate many of the 'greatest hits' of web application programming techniques. Convention over configuration in particular is a big win to my mind.
However I also have the feeling that some of the convenience I am getting is coming at the expense of technical debt that will need to be repaid down the road. It's not that I think ROR is quick and dirty, as I think it incorporates a lot of best practices and good default options in many cases. However, it seems to me that just doesn't cover some things yet (in particular there is little direct support for security in the framework, and plugins that I have seen are variable in quality).
I'm not looking for religious opinions or flamewars here, but I'd be interested to know the community's opinion on what areas Rails needs to improve on, and/or things that users of Rails need to watch out for on their own because the framework won't hold their hand and guide them to do the right thing.
Regardless of framework the programmer needs to know what she's doing. I'd say that it's much easier to build a secure web application using something as mature, well designed and widely adapted as Ruby on Rails than going without the framework support.
Take care with plugins and find out how they work (know what you do, again).
I love Rails too, but its important for us to understand the shortcomings of the framework that we use. Though it might be a broad topic addressing these issues wont hurt anyone.
Aside from security issues, one other big issue is DEPLOYMENT on Shared Hosts. PHP thrives in shared hosting environments but Rails is still lagging behind.
Of course most professional Rails developers know that their apps need fine-tuned servers for production and they will obviously deploy on Rails-Specific hosts.
In order for Rails to continue success the core team should address this issue, especially with Rails 3.0 (Merb +Rails) coming..
An example of this is simple: I have a bluehost account, and i noticed the Rails icon in my cpanel. I talked to the bluehost support and they said its more or less a dummy icon, and that it doesn't function properly.
Having said that any professional who wanted to deploy a Rails App would not use bluehost. , but it does hurt Rails, when hosts say that they support it and then users run into problems which their support know nothing about..
The article you refer to defines technical debt as
[the] eventual consequences of
slapdash software architecture and
hasty software development
With rails, any development that is not test driven incurs technical debt. But that is the case with any platform.
At an architectural level Rails provides some deployment challenges. A busy site must scale with lots of hardware or use intelligent caching strategies.
My advice to anyone adapting Rails would be to:
use TDD for all your development
verify the quality off any plugin
you use by reading its tests. If
they are not clear and complete,
avoid the plugin
read "Rails
Recipes" and "Advanced Rails
Recipes" (Advanced Rails Recipes has
a good recipe for adding
authentication in a RESTful way)
be prepared to pay for hardware to scale your site (hardware is cheaper than development time)
From my experience, by far the biggest tolls you end up paying with RoR are:
Pretty big default stack (not counting plugins you might be using)
Updating models tends to be a pain in the ass, at least in production servers.
Updating Rails or Ruby themselves is a bit more complicated than it should, but this differs depending on your server setup.
As ewalshe mentioned, deployment is sometimes a drag, and further down the road, should you require it, scaling gets a bit iffy, as it does with most development frameworks.
That being said, I'm an avid user of RoR for some projects, and with the actual state of hardware, even though you do end up paying some tech debt to using it, it's almost negligible. And one can hope these issues will be reviewed eventually and solved.
With any level of abstraction there is a bit of a toll you pay - genericized methods aren't quite as fast as those specific to something built just for your purpose. Fortunately though, it's all right there for you to change. Don't like the query plans that come out of the dynamic find methods? write your own, good to go.
Someone above put it well - hardware is cheaper than developers. I'd add "at a sufficiently low amount of hardware"
I'm reading Deploying Rails Applications and recommend it highly to answer your concerns.
The book is full of suggestions to make life easier, taking a deployment-aware approach to your Rails development from scratch, rather than leaving it to later.
I don't think the choice of RoR implies a technical debt but just reading the first few chapters alerted me to practices I should be following, particularly on shared hosts, such as freezing the core rails gems so you can't be disrupted by upgrades on the host.
The 30-page chapter on Shared Hosts includes memory quote tips such as using multiple accounts (if possible) with one Rails app per account. It also warns about popular libraries such as RMagick possibly pushing your memory size to the point where your processes are killed (such as a 100MB limit, which it suggests some hosts periodically apply).
I would like to use a lighter framework than Rails (Sinatra/Ramaze/Camping) but am concerned that by doing so I will not be able to use a lot of shared libraries that have been tailored to Rails in the form of plugins. Is this a major concern or are most of these plugins usable across different Ruby frameworks?
Are there any other potential disadvantages in using a Ruby framework other than Rails?
You can still use gems in all of the frameworks you mentioned, so a ton of stuff is reusable. Want to swap in a new ORM, no problems. Want a fancy shmacy syntax highlighting, no problems. Rails has been making a huge push to move away from the old plugin model to use gems exclusively.
If one of the other frameworks fits your needs better use it. Keep in mind that when it comes to documentation and samples rails has more.
If I was learning Ruby and wanted to try out a web framework I would probably go with Rails not because its better, but because its got much better tooling and documentation.
Most Ruby modules used by Rails (even ActiveRecord) can be used without Rails. But then you lose the extra benefit of integration provided by Rails. You may have to work extra hard to glue Ruby modules to the framework of your choice. Please also note that most of the documentation about Ruby modules used by Rails tells you only how to use that module with Rails.
Network effects play a bit of a role.
One issue that comes up when you use other frameworks like sinatra, camping, etc is that rails gives you a proven structure for your files in the your application. Smaller frameworks are quite open and free.
This can be a downside when you are working with multiple developers as you need to have conversations about creating conventions rather then simply following them.
If you've been using Ruby for less than a year, stick to Rails, unless you have a very clear need that is better handled by one of the other frameworks.
The lighter frameworks, most notably Sinatra, tend to be popular with people who know exactly what they will need and can't afford to have any additional overhead from unused code. Essentially, you pick your toolchain, instead of generally being stuck with what Rails gives you. (Yes, in Rails, you can replace ActiveRecord, et al. with other libraries, but it's not exactly easy.) So the lighter frameworks give you significantly more freedom, but you also have quite a bit more work to do in many cases.
I think no rails plugin is going to work out of the box with any of the alternative frameworks, except for ActiveRecord plugins (such as acts_as_nested_set etc.) which are still going to need some plumbing work (setting $LOAD_PATH and requiring right files). I'd recommend DataMapper for ORM, not only it's way faster than ActiveRecord, but it's also very modularly built and plugins are actual gems that you can easily install. In difference, ActiveRecord plugins are mostly monkey-patches that tend to break with every new version.
Sinatra doesn't come with any "goodies", no Rakefiles, no skeletons, no script/generate, but actually that's what it's been written for. You can gradually "plumb in" all the extra stuff. There are also skeletons for sinatra apps that come with some basic layout and defaults, you may find these useful.