Val Aleksenko (muzzy)
- Val has 4 plugins published and has 0 fans on Railsify!
- http://blog.hungrymachine.com/
Acts As Readonlyable by Val Aleksenko (muzzy) in ActiveRecord Gem Available!
ActsAsReadonlyable adds support of multiple read-only slave databases to ActiveRecord models. When a model is marked with acts_as_readonlyable, some of AR finders are overridden to run against a slave DB. The supported finders are find, find_by_sql, count_by_sql, find_[all_]by_*, and reload. Finders can be forced to fall back to a default DB by passing the :readonly flag set to false.
Acts As Secure by Val Aleksenko (muzzy) in Security & Protection and ActiveRecord Gem Available!
ActsAsSecure adds an ability to store ActiveRecord model's fields encrypted in a DB. When a model is marked with acts_as_secure, the :binary type fields are recognized as needed to be stored encrypted. The plugin does before_save/after_save/after_find encryption/decryption thus making it transparent for a code using secured models. The plugin supports a master key approach as well as individual records encryption keys. It does not contain any crypto provider but allows to plug in any external one as long as it supports encrypt/decrypt methods.
Configuration Loader by Val Aleksenko (muzzy) in Utilities Gem Available!
Configuration Files Loader can be used as a gem or a Rails plugin to load various config files. It finds config file fragments in a Rails config directory and in config directories of plugins and dependent gems. It then tries to merge them in the following order: gem<-plugin<-application. This allows overrides of global (gem/plugin) configs by individual applications. The supported types for merging are String, Hash, and Array. It also caches the content of loaded files.
Enhanced Rails Migrations by Val Aleksenko (muzzy) in Utilities and ActiveRecord
Enhanced Rails Migrations makes easier rails development in a large team with multiple code branches. The plugin monkey-patches ActiveRecord classes to replace the sequential number based rails migration mechanism with the timestamp based one. That allows to avoid name collisions when migrations are generated. In addition, it maintains a tracking table of already run migrations instead of the standard single number schema_info. The table is being used for decision whether to run a migration. The biggest difference from the standard way is that migrations below the current schema version are still applied if they have not been applied yet (not in the tracking table).
