I need to define a global variable in my Cucumber env.rb file which can be accessed throughout the framework in all step methods. Currently i am defining as this in my env.rb file:
$global_var ||= false
And i need to access this var into the Before hook as well After hook and few step methods where i am re-initializing this. It is working perfectly as i want. But the problem is, rubocop doesn't like this and throwing error as "do not use global variable". How can i resolve this ???
FYI, I tried using singleton to define this var as accessor and not quite sure where i am missing.
Change the config file for rubocop. use the link:
Example to Change
Look for the passage starting with When we look in the .rubocop_todo.yml file we see something like this: and also Configure Rubocop to be your style guide
Link to List of Configuration Changes possible:
Link to List of Styles
change .rubocop.yml file:
Style To Change:
GlobalVars: Enabled: false
Example File : Example file - how it looks like
How to Configure Style: Style/Inheritance Guide
Related
I want to invoke irb dynamically from my Ruby program, but have it not to load the default ~/.irbrc, but a file ./custom_irbrc instead. I can do it like this:
require 'irb'
ENV['IRBRC'] = './custom_irbrc'
IRB.setup(nil)
# My configurations follow here
IRB.conf[...]=...
IRB.start
I wonder whether I can set my custom irbrc also via .conf instead of polluting the environment. I didn't find a really comprehensive description of the possible conf-settings, but from what I found, I tried as educated guess:
IRB.conf[:IRB_RC] = './custom_irbrc'
IRB.conf[:RC] = './custom_irbrc'
but neither one seems to have any effect.
The desired effect can be achieved, although by using an undocumented feature, and there is no guarantee that it will be available in future Ruby versions too:
IRB.conf[:RC_NAME_GENERATOR] = proc { './custom_irbrc' }
This has to be done before IRB.setup is called.
I am trying to develop a simple Lita chat bot with more flexible command routing.
There are a couple of issues I am having difficulties with.
1. Conditional routing
How can I use config values before or inside route definitions?
For example, instead of this definition that needs a "run" prefix:
route(/^\s*run\s+(\S*)\s*(.*)$/, :cmd, command: true)
I would like to use something like this, with a flexible, config-based prefix:
route(/^\s*#{config.prefix}\s+(\S*)\s*(.*)$/, :cmd, command: true)
Which fails. So I also tried something like this:
if config.use_prefix
route(/^\s*run\s+(\S*)\s*(.*)$/, :cmd, command: true)
else
route(/^\s*(\S*)\s*(.*)$/, :cmd, command: true)
end
Which also fails with a not very helpful error.
In both cases, I defined the proper config key with config :prefix and config :use_prefix.
2. Showing the bot name in the help
I know there is a robot.name property available for me inside the executed command, but I was unable to use it inside of the help string. I was trying to achieve something like this:
route(/^\s*run\s+(\S*)\s*(.*)$/, :cmd, command: true, help: {
"run SCRIPT" => "run the specified SCRIPT. use `#{robot.name} run list` for a list of available scripts."
})
but it just printed something unexpected.
Any help is appreciated.
The issue is that you're confusing the config class method and the config instance method. config at the class level (code in the class body but not inside an instance method definition) defines a new configuration attribute for the plugin. config at the instance level (inside an instance method or in an inline callback provided to route using a block) accesses the values of the plugin's own configuration at runtime.
In the current version of Lita, there isn't a pretty way to use runtime configuration in class-level definitions like chat routes. The workaround I've used myself is to register an event listener for the :loaded event, which triggers when the Lita::Robot has been initialized. At this point, configuration has been finalized, and you can use it to define more routes.
For example:
class MyHandler < Lita::Handler
on :loaded, :define_dynamic_routes
def define_dynamic_routes(payload)
if config.some_setting
self.class.route(/foo/, :callback)
else
self.class.route(/bar/, :callback)
end
end
end
You can look at the code for lita-karma for a more detailed example, as it uses this pattern.
The next major version of Lita is going to include an overhaul to the plugin system which will make this pattern much easier. For now, this is what I'd recommend, though.
I have a gem which uses Faker to help build mock data. I'd like to add a new class that generates a new category of stuff, using the same syntax Faker itself uses. The first half is easy, I simply define the class, and make sure my gem loads the file:
# lib/faker/restaurant.rb
module Faker
class Restaurant < Base
class << self
def name
parse('restaurant.name')
end
end
end
end
So far, so good. Now, to describe what values can come out of this, I create a YAML file:
faker:
en:
restaurant:
suffix: [Cafe,Restaurant]
name:
- "#{Name.first_name}'s #{suffix}"
So, the actual question: Where does this file go, and what name should it have? If this were a Rails application, it would be config/locales/faker.en.yml. In a gem, that doesn't appear to work - there isn't actually a 'config' directory, for one thing, but creating it for this purpose doesn't help, I get:
> Faker::Restaurant.name
I18n::MissingTranslationData: translation missing: en.faker.restaurant.name
Ok, figured it out. Special thanks to dax, whose comments prodded me in the right direction.
Faker uses the I18n gem for localization (which is why the YAML files live in a 'locales' directory). This means that I needed to add my custom YAML to the I18n load path. It doesn't matter exactly where the files are, as long as they're added to the load path. In my case, I put it at lib/faker/locales/en-US.yml, and added that entire directory to the load path, thus:
lib/my_gem.rb:
I18n.load_path += Dir[File.join(File.expand_path(File.dirname(__FILE__)), 'faker/locales', '*.yml')]
require "faker/restaurant"
Any .yml files I put in that directory should be loaded and available to Faker.
Side note: I also needed to change the YAML format slightly - it should be
en:
faker:
<stuff>
rather than with faker at the top level, as I had it.
In my Capistrano's deploy.rb file, I set up different environments such as server names, ports, etc. I also require the users to send a callback to another server, also defined in the deploy.rb. How do I cleanly pass this value to my app?
Something to this effect:
config/deploy.rb:
set :callback_url, "http://somecallbackurl.com:12345/bla"
app/controllers/myapp.rb:
def get_callback_url
???
end
I'm using Sinatra.
I found a solution, and that is to use the environment variables.
Set it from deploy.rb
run "export CALLBACK_URL=#{callback_url}"
From app:
def get_callback_url
ENV['CALLBACK_URL']
end
I wouldn't say it's the cleanest solution, but it works.
I'd probably recommend using a shared YAML file to store this kind of configuration, and loading it separately. For example, have a file named something like config/settings.yml, containing something like:
:callback_url: "http://somecallbackurl.com:12345/bla"
In config/deploy.rb, you could have:
settings = YAML.load_file('config/settings.yml')
set :callback_url, settings[:callback_url]
And in config/initializers/settings.rb, you could have:
settings = YAML.load_file('config/settings.yml')
CALLBACK_URL = settings[:callback_url]
Finally, in app/controllers/myapp.rb, you would do:
def get_callback_url
CALLBACK_URL
end
Using a shared YAML file is just the first thing I thought of. Another approach would be defining some constants in a ruby file, and requiring that file both in an initializer, and in deploy.rb. The basic idea is that you don't really want your app to depend on your capistrano environment, so you should find a way to separate the shared configuration.
I've got a Rails 3.1 project that I'm working on, but I don't want controller_name.css.sass and controller_name.js.coffee to be generated each time I run rails generate controller controller_name. I could swear I've seen the setting somewhere on the internet, but I can't find it now for the life of me. What is it?
Keep in mind that I'm still wanting to use the Asset Pipeline and the CoffeeScript/Sass integration, but I'm organizing those files in my own way.
I'm pretty sure the answer is a command line argument, but bonus points for turning it off with a generator setting or a hidden file or something.
EDIT: I've found the command line flag for it.
rails generate controller controller_name --assets=false
Or something of the like (that line actually errors out, but it also doesn't generate the assets). The API here shows :assets => true as a default option. How do I change that to false and have it always be false every time I generate a controller?
Add these lines to application.rb:
config.generators.stylesheets = false
config.generators.javascripts = false
New syntax is rails generate controller Resources --no-assets.
Don't forget you can also use g in place of generate. And you can skip the creation of a controller helper using the --no-helper flag.
For just one time, use:
rails generate controller controller_name --no-assets
An update on #Dmitry Maksimov's answer for Rails 4.2. You can disable generation of controller-specific asset files by default with the following in your config/application.rb file (source: the guide):
config.generators do |g|
g.assets false
end
My whole options in the application.rb file:
config.generators do |g|
g.stylesheets = false
g.javascripts = false
g.test_framework :rspec, fixture: false
g.template_engine :haml
g.fixture_replacement :factory_girl, dir: 'spec/factories'
end