You know it, a Rails project is growing for years, many developers comes, many developers go...
Now it's your turn, You are a newcommer in the company and you are sitting for the "shiny" Rails app source code.
You task is to remove all plugins that clutters the source and are not used anymore.
How will you find them ?
If you have any tests on that rails app you could use rcov to see how much test coverage on the project, if its a good amount of coverage then remove one of the plugins, run the test suite and see if anything fails.
Look at each plugin's source code (usually lives in /lib of the plugin or gem folder).
Most of them only define a handful of methods that you are supposed to call in your application code. Search your project directory for all of these method names to see if they are called anywhere.
For example: you have acts_as_ferret plugin, search your codebase for the words "acts_as_ferret".
If you have delayed_job, search for "delay", "send_later", or "handle_asynchronously".
Sure it will take some time, but removing dependencies isn't something you want to do haphazardly.
Related
I'm building a social network and have been using the gem community_engine but have been having trouble implementing the large amount of customization that I need for my app. I figure this will make it easier for me to override and add methods, as well as help me to better understand and learn from the code since I will be able to actually see all of it in action.
So far in my attempt I downloaded the source code, added the default bin directory and config files that were missing, as well ass all the gem dependencies.
What else do I need to do to get the app to work? I realize that there may still be a lot and that it might not be easy to explain, but at the very least is there any sort of documentation out there that might help me understand how to convert the gem to a Rails application?
Heres the community_engine repo: https://github.com/bborn/communityengine
Because this idea may draw some criticism, I'll add that I was originally building the app without any huge plugins accept for devise however I'm running out of time to finish this.
More stuff I've tried:
Moving files to a new rails app, got server to run but encountered many seemingly random errors, fixed a few but more just seem to pop up that I cant figure out:
I also took a look at http://guides.rubyonrails.org/plugins.html but this gem seems to go beyond that.
I would suggest that you clone the gem and begin copying files from the gem into your a new Rails application.
The engine gem probably has a similar structure to a Rails application, so you should be able to move the files from the corresponding folder to the same folder in your Rails root folder.
You may need to move gem files out of modules, change namespaces etc. Relevant folders to look at files you'll want to include might include app/ config/ db/, any gem dependencies in Gemfile or the gemspec file, as well as spec/ or test/.
Beyond that I think there's no silver bullet answer to your question, you're just going to have to work through problems until you have this up and running, and perhaps ask subsequent questions if you hit on an obstacle that you don't get beyond.
I think what you're looking for is a way to hook your Rails Engine into a rails app. The Hooking Into an Application section of the Getting Started with Rails Engines guide should be exactly what you're looking for.
Here are two additional resources on Rails Engines.
A Guide to Rails Engines in the Wild
Rails::Engine - Ruby on Rails API
How do I create a gem project nested inside my current Rails project?
I've got a Rails project with several parts that could easily be gems. I would like to extract these parts into gems but not leave the current Rails project. Creating new source control repos for the gems add additional complexity that project or organization is not ready or able to handle. These complexities will be overcome at some point and I would like to be ready.
So far I can only think of these items.
Relocate code to a single directory root. I'm guessing this would be in the vendor path
Create a <something>.gemspec
Link to the gem in the Gemfile of the Rails app
gem 'my_lib_code', path: 'vendor/my_lib_code'
What else do I need to do? I'm sure I'm missing something important.
If this were a c project I would create another shared library that the make process spits out. Or if this where a c# project I would make a .dll. For Java I would...
I'm sure Ruby can do the same as all the other languages. Something that is a half way step between a normally fully extracted gem and just some code siting in my lib path.
This is a perfectly fine approach for a component-based architecture.
You have a single repository, a single test suite, and a single deployment process, while at the same time you are "forced" to think of clean interfaces and separation of concerns.
Of course if you are planning on sharing this functionality with other projects, an externally hosted (but not necessarily public) Gem would serve better.
Implementation wise, you can get some nifty ideas from Stephan Hagemann's talk at this year's RailsConf: "Get started with Component-based Rails applications!"
I'm currently looking into what language to build a web application on that will be sold to companies. To make things easier, I was hoping to package the webapp into a convenient installer that contains the entire stack which will run automatically.
Is there any way to create a self contained RoR package?
The only project I'm aware of is called pkgr, which bundles an entire rails app into a DEB package. So if you don't mind limiting your installs to Ubuntu/Debian, you could give it a try.
pkgr home page
Github
You can write a rake task to automatize everything for you. Migrations, bundling, enviroment setup. And it's pretty much plain Ruby, too.
In the end it would be just running a script file to do the job.
We have a website using Rails 2.3.x, bundler, nginx, passenger and git, and would now like to use the same code to deploy a very similar site. Differences between the two will include:
Locale
Databases
Validations in some cases
Views in some cases
What is the best way to manage these differences while using the same code base?
Some ideas we've had:
Create new Rails environments, such as production-a and production-b and handle differences in the appropriate environment files. One potential problem is that many gems and plugins are hardcoded to look for production or development environments.
Use Passenger to set a global variable or use the domain per request to determine which context to use. The problem with this are rake tasks, cron jobs, etc that would not have access to this state.
Maintain two versions of the config directory. This would be inconvenient maintaining 2 versions of all the config file, many of which would be identical. Also, I'm now sure how to leverage git to do this correctly.
Any ideas, tips, or examples would be greatly appreciated! Question #6753275 is related but seems incomplete.
One solution I have used in a rails 2.3.x project was to convert the entire site to an engine. That actually is pretty easy, create a folder under vendor\plugins\ and move all the app stuff there. You can see an explanation for rails 2.3 here.
If needed you can even move all migrations and stuff there as well, and use a rake task
to run those.
Everything that needs to be overruled can then just be placed in the actual rails project using the engine. So you would have two rails-projects, with their own configuration, locales and some local overrules, and one big shared plugin/engine.
We used git submodules to keep the code in sync over different projects.
In rails 3 this is even easier, since the engine can now just be a gem.
Hope this helps.
I'm in the process of creating my first rails plugin and am finding managing version control of the plugin and testing app rather annoying.
Here's my problem:
To actually test my plugin in action I need to run it within a test application (which is basically just a scaffold app where I install the plugin)
When I'm making changes to the plugin, it's convenient for me to change it within the test application so i can immediately see the changes come through. However, when I want to commit and push my changes back to github I end up copying all the files out of the test app back into my "naked plugin" folder and doing my commits.
Is there a better way to manage this without copying files back and forth? I'm interested to hear from other plugin developers if possible on how you manage this situation.
One potential solution I've conceived of is to have another git repository within the vendor/plugins/myplugin directory (which will have the remote repo of github). Im not sure if this is best though (and so far I haven't been very successful in making it work...)
I recommend to use git submodules, check a detailed description.
I create a soft link in the vendor/plugin directory to point to the plugin source code.
If you are on Windows you can use the junction tool to create a softlink.
E.g:
c:\test_app
vendor
plugin
foo_plugin -> points to c:\foo_plugin
c:\foo_plugin
lib
Submodules are going work best I think. What I don't like about developing plugins is that you're always starting/stopping the script/server. Without knowing what kind of plugin you're building, I'll just assume that you're building an abstracted class of some kind.
I personally think the best way to go is to develop the class in the lib directory of your rails app. Once you get it about 99% done, then move the class into the lib directory of your plugin. Then commit the changes to the plugin repo.
If you're willing to package your final plugin as a gem, then there is a much easier way. In your basic scaffold app, inside your Gemfile you can point to a local path:
gem 'foo', :path => "../foo"
This way your scaffold app and engine/plugin are in two separate directories; two completely unrelated git repos. You don't even have to start & stop your scaffold web server when you make changes to the plugin (at least in rails 3).
I just wrote up a tutorial for how I created my first rails engine and I extracted the foundation into a good starting point for other engine builders:
http://keithschacht.com/creating-a-rails-3-engine-plugin-gem
As an end user of a plugin, I think it's much easier if it's packaged as a gem. Not only is more functionality possible with a gem, developers can install it once and use it in many apps, dependencies can be easily handled, upgrades are as simple as changing a version number, and you don't have to store the entire plugin in your main app's repo.