I'm pretty new to Ruby (though not to programming) and am trying to create a persistent config. Though I thought using Configatron would automatically make my config persistent, it does not seem to be the case. How would I make this persistent throughout multiple runs? Should I store this to a file? If so, how? I would think a ~/.myapp file might be good?
Persistence in Rails
If you're using Ruby on Rails, you need to modify your initializers for this gem:
app/config/configatron/defaults.rb
app/config/configatron/{development,test,production}.rb
Persistence Without Rails
Ruby Modules
If you're using Ruby itself, rather than the Rails framework, then you need to persist your configuration as a Ruby module (e.g. require "my_configuration") or serialize the Configatron class if it can serialized. It looks like the goal of the gem is to avoid serialization, so requiring a module that contains your configuration as executable code seems to be the canonical approach for this gem.
Serialization
I don't use this gem myself, so you'll have to experiment with serializers to see if they work for your use case. For serialization, I'd recommend using one of:
YAML::Store
PStore
Marshal
However, if you're using serialization to save and load your configuration, I'm not entirely sure why you'd need this gem in the first place. Your mileage may certainly vary.
Related
I'm going to write a service that will using amqp protocol, without http at all. I like hanami's paradigm of repository-entity-model-interactors and I wonder to use those in my project. Generating all that stuff by hand, sure, is boring.
So, I wonder to grab rake tasks. Looking into config/environment etc, ughhhh. What is the best method, shortly, to use those tools without hanami router and controllers? Or, it is all integrated tightly?
As I think for that moment, there are two ways:
a) To include only hanami-model into my Gemfile, then copy by hand every needed file from gem hanami.
b) To create hanami project and do not use rackup.
I'm disappointed.
Alternatively, you can add hanami as a development gem. That gives you access to the code generators. At the deploy stage, you don't bundle hanami, so the app will only have hanami-model and hanami-utils in production.
hello. If I understand you right, you want to use interactors only with models. Interactors you can use as a regular ruby library.
For model, you need to configure all this staff and load to memory. You can check the example from our playbook. Hope it'll be helpful for you
https://github.com/hanami/playbook/blob/master/development/bug_templates/model_psql.rb
I am writing a gem which adds dependencies to a gemfile from the command line. Given the gem name, it grabs the latest version from rubygems and adds it to the user's gemfile.
I practice test driven development using rspec. I'm wondering how do I mock the existence of a file and check it's contents?
Is there any pattern for doing this sort of thing? Tips, links or examples will help. I'm not set on a specific way of testing this. If mocking isn't the way to go, please let me know. Thanks!
If you want to mock a file object that only needs to be written and read from (no filesystem operations), try Ruby's builtin StringIO. Just require 'stringio', create a 'file' with any contents by using StringIO.new("Some contents"), and check its contents by using the string method on the StringIO object.
Unit Tests vs. Integration Tests
You didn't post any code, so I'm going to have to make some assumptions. In general, exercising behavior from Ruby's core or standard libraries is a waste of time. In addition, your tests should exercise methods that define class behavior, not necessarily every single method in a class.
When you cross the boundary to testing I/O, you're often doing integration tests. Sometimes integration tests are necessary, but they should make a very small subset when compared to unit tests.
With all that said, while integration tests that involve filesystem, database, or network I/O are often slower than unit tests, whether or not they are slow enough to warrant stubbing, mocking, or test-specific work-arounds will be specific to your code base.
Options for Testing
If you really need to do this, you have a lot of options. Some of these options include:
Using a RAM disk for your filesystem I/O.
Stubbing calls to IO, File, or FileUtils.
Avoiding the issue by using a file fixture.
Avoiding the issue by using a StringIO fixture.
Re-writing your class under test to accept String and/or StringIO in addition to File objects.
Using a gem like FakeFS to handle the stubbing/mocking for you.
This isn't meant to be an canonically exhaustive list. There are doubtless other options, but one or more of the above should handle any common use case.
I have a gem that I want to be capable of creating its own database (and later making migrations to that database if necessary). The gem uses ActiveRecord when reading and writing to the database. Short of embedding my gem in a non-serving Rails application just to get the necessary rake tasks, is there a best practice or community-promoted method for doing this? Attaching a whole Rails infrastructure to my little command-line only app just to get future migration upgrades seems like way too much overhead.
You can use DataMapper, which is a relatively lightweight ORM system (compared to ActiveRecord) in combination with an SQLite database. You don't need to use Rails for this, DataMapper drops nicely into a regular app, even something that isn't web-based.
You can use standalone_migrations gem to manage ActiveRecord environment outside of Rails: https://github.com/thuss/standalone-migrations. If you include your migrations or schema into a gem package, consumers of your gem can recreate db structure from scratch. I agree with robbrit that SQLite is the easiest choice for a database.
I'm starting a new project and I have maybe three resources defined. Not a lot of code so far. (Rails 3.1)
But I'm interested in trying out DataMapper. I'm used to ActiveRecord (and actually enjoy it) but I'm always on the lookout for new things. Plus, my application uses Backbone.js but I don't believe that's relevant.
So how hard is it to switch out the ORM "mid-app" like this and do you think the learning curve to DM is that hard?
PS, there is a chance that I might be using other engines alongside my application. Such as MongoDB running along with Postgres. Will DM be at an advantage there?
To use Datamapper itself, there isn't much to it but it is some of the Rails niceties that require additional work (like the SQL execution times in "rails s") and there is also the rake tasks.
Check out dm-rails - They have a template that you use to provision the initial Rails project that sets it up with everything for Datamapper. You can also look through the source and see how it hooks everything. There is a small issue if you use database-backed session stores with Datamapper, which involves a monkey patch.
How to properly implement RSpec, ActiveRecord and Factory Girl in non-rails application. I also need that every test case would run on a clean database.
Thanks!
ActiveRecord outside of Rails is a pretty common request, so there's plenty of blog posts and tutorials on getting it done, just Google it. Using it outside of Rails isn't very different from using it within Rails. The major difference is that you'll have to handle the things that Rails usually does for you, like creating the connection, and handling migrations.
RSpec was not designed specifically for Rails, so using that outside of Rails is a non-issue. Just follow the standard tutorial.
Same thing for factory_girl. Rails support was separated from factory_girl proper and moved into a separate gem, so using it without Rails is also simple. Its standard README should be sufficient.
For cleaning the database, use the database_cleaner gem.