I came to work for a company recently that has been working on a specific rails project for a while. Dropped in the middle of the development process, I'm beginning to go back and write tests for the existing code as well as the code currently being produced.
Testing the rails 4 app was easy enough, but once I got to testing the engine, I hit a mental block. After doing my due diligence, I found that most people take an approach like this (http://viget.com/extend/rails-engine-testing-with-rspec-capybara-and-factorygirl), but the common thread I saw in all of these responses was that people were building these apps from scratch, and thus had a dummy app generated for them automatically. I don't have the benefit of being able to generate everything from scratch, and have to work with what I was given, so what
I'd like to know is if there's a way to retroactively generate just the dummy application. Is there something simple I can type into the console and have it generated for me? Or is there a longer, slightly less pretty route? Or would a different strategy be better altogether?
Given that the dummy app is not supposed to be tied to the parent gem except for some vague names, that may do it:
cd some_path_where_your_engine_IS_NOT
rails plugin new YOUR_ENGINE_NAME --mountable --dummy-path=spec/dummy --skip-test-unit
mv YOUR_ENGINE_NAME/spec/dummy /real/path/to/YOUR_ENGINE_NAME/spec
rm -rf YOUR_ENGINE_NAME # cleanup useless cruft
Also, you may be interested in this answer to generate the app with the exact same rails version.
If the engine is within a parent app delete the engine from your Gemfile
Rerun the rails plugin new .. command you used to create the rails engine, but with the --skip parameter. This will create all the files, including dummy that do not exist in your engine, but leave existing files alone.
Related
First, I am fairly new to Ruby/RoR and so you'll have to forgive me for any wrong terminology, but hopefully I'll get my point across.
I built an ruby app that I am needing to add an extremely simple UI layer using rails. Read up on a previous post of mine that explains the project thoroughly to give you good an idea of what it does. Specifically take a look at the tree outline that I pasted in so you see the existing file structure for the project.
What I need to know, is how to convert this existing project into a rails app? My experience in building something with rails has always started out with rails new app_name, but never anything like this. Any tips would be appreciated.
I saw your parser script, and it is not a daemon (a program that keeps running indefinitely in the background), right?
If I'm right, then you have several options:
The easiest option
Just build a rails application using rails new app_name, and inside some controller action, make a system call to run your script
class SomeController
def some_action
succeeded = system(:ruby, '/path/to/main.rb', '/path/to/some.txt')
# Do some rendering stuff here based on the result of the system call
end
end
This approach is somehow nasty for me, and it's not performant because each system call reads your ruby script and compiles or interprets it then runs it.
The harder option
Refactor your script so that it's features can be wrapped into a gem.
Then you install that gem, require it in your rails app, and use it.
I saw your original ruby script is almost there, it shouldn't be that hard to make it become a gem.
Rails is just "something" on top of Ruby. Especially, you can use any plain ruby objects inside of Rails, anywhere, and this is nothing unusual (google "PORO").
In your case, I would make a simple Rails app in the way you have mentioned yourself with rails new. Then trivially refactor your existing code until you have a simple, standalone class that does what you need to be done but takes its input/output from simple ruby data structures (i.e., method arguments, return values, no global state, no file operations). Then you can use that class from inside your Rails controller (taking input from a HTML form, rendering output to HTML), and also from inside your script (reading input from a file or STDIN, rendering output to STDOUT).
Where you put that class is up to you. In the MVC paradigm, it is not "C" or "V", and one could argue about whether it's "M". So put it into app/models/ or lib/, whatever you like more.
These were great answers and I'm sure they would have worked perfectly. However, they were a little bit more complex than what I was looking for.
What I ultimately ended up doing was just cd into the directory above where the ruby app was located and then just simply ran rails new app_name. Rails will ask if you'd like to overwrite any files that exist already. From there I just integrated my script into the controller actions and created the views.
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 have installed CKeditor for my Rails app and while doing the Formatting, the Formatted code does not display in the screen, instead, HTML is rendered, like this
<h2><strong>In this project</strong> you’ll create a simple blog system and learn the basics of Ruby on Rails including: Models, Views, and Controllers (MVC) Data Structures & Relationships Routing Migrations Views with forms, partials, and helpers RESTful design Using Rails plugins/gems The project will be developed in five iterations. I0: Up and Running Part of the reason Ruby on Rails became popular quickly is that it takes a lot of the hard work off your hands, and that’s especially true in starting up a project. Rails practices the idea of "sensible defaults" and will, with one command, create a working application ready for your customization. Setting the Stage First we need to make sure everything is set up and installed. See the Environment Setup page for instructions on setting up and verifying your Ruby, Rails, and add-ons. This tutorial was created with Rails 4.0.0, and may need slight adaptations for other versions of Rails. Let us know if you find something strange! From the command line, switch to the folder that will store your projects. For instance, I use /Users/jcasimir/projects/. Within that folder, run the rails command:</h2>
Use the html_safe method
So, something like:
puts my_variable.html_safe
Lots more info here: http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/
As we create more Rails applications, I find myself routinely adjusting the project generated by rails new ... in exactly the same ways: adding rspec, capybara + capybara-webkit support, adjusting config/application.rb to our tastes, including several gems we came to love.
I had a look at suspenders, it's a good starting point, but some of their choices differ from ours. Plus it's flexible in places where we don't really want any choice. In fact we'd rather have a couple project boilerplates sharing some customizations and each adding some unique extra's.
What are the options for streamlining/automating a project "bootstrap"? How could we organize a set of boilerplates and let them evolve as our preferences change (not adding options, but changing which made choices are hardcoded)?
I'm thinking in the direction of scripting what I normally do manually starting from rails new, editing the Gemfile, config/application.rb etc, but may be there is a cleaner (future versions compatible) approach or tool?
I really like using the Rails Composer gem/tool for this.
At the basic level when you run Rails Composer it will ask you a series of questions about what gems/configuration options you'd like your new Rails app to have. Then generates your app for you.
I like the "ask me for what I want" approach because different Rails projects may need different things: Postgres vs MySQL, Bootstrap vs Zurb Foundation, etc. 90% of these are usually the same, but it's the 10% difference that gets me.
At the more advanced level, Rails Composer shows you how to use Rails templates to create your own standard modifications, or you could fork Rails Composer to add the options you want (maybe sending a PR back to the project if it's something useful?)
At the expert level, Rails Composer has "starter apps": just pick one of those and go, choices already made for you. Depending on your needs this might be just the kind of thing you're looking for -- digging into how these "starter" apps are created and making one yourself.
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.