Hi Stefan, El 04/09/14 a las #4, Stefan Haslinger escribió: > Hi everyone, > > I'm currently struggling with the topic of managing two versions (soon > three) of an application. > I know, that's not real Hobo specific, but I know there are many > insightful people here, so I thought, I'll give it a try. > I would like to know about your best practices on this topic. > > I'm currently using these strategies: > - Configuration file config/application.yml for stuff even a local admin > should not be able to change > - A model Constant which is a simple key-value store, for stuff that can > be changed in production > - Both are used as configuration parameters and feature flags and > clutter my code with if's. (I've been thinking about getting rid of > those, but I didn't find a proper way.) > - Separation of specific modules in Gems as Engines and use them only in > the installations where they are needed. > > My biggest issue is getting rid of the if's . Even if it's a gem I have > to check if a constant is set to determine which branch is the right one. > Am I missing out here on something or should I just live with it? > Sometimes I'm thinking about using different actions for different > versions, unDRYing my code and still having an if somewhere to decide > which action to take.
I've struggled with similar issues, and I can't say that I have found a really satisfying solution. You probably know more than me, but I'll share the conclusions I have reached regarding two types of applications: Application with more than 5 clients, lots of configuration options: -------------------------------------------------------------------- * All clients want lots of options configurable by them, so getting rid of many "ifs" is not an option. * You can divide methods and tags into the smallest units possible, so the "ifs" are simple to read and they can be tested. * Try to get rid of "application.yml" config files, and move config options to the DB (even if it can only be set through the Rails console). This way config is only in one place, and for me it makes it a bit easier to write tests. Application with 2-3 clients, each with independent needs --------------------------------------------------------- * You can use Rails Engines/gems. This is probably the coolest solution :). As you have already started using these, have you tried overriding methods? The idea is that if one client wants something specific, this client has his own Engine. In this Engine you override the behaviour of the default method. * The "overriding" methods idea also works by including modules. You can have a model which includes different modules depending on one configuration option. This allows you to have the "if" in once place. > > I split up bigger controller actions into reusable chunks (mostly > instance and class methods of model classes, very rarely introducing > pure ruby classes...). I tried going at least a part of the POODR > (http://www.sandimetz.com/products/) way, that helped me a lot getting > where I am right now. > > If you have different strategies, please let me know. Also if you know > about blog posts or literature on this topic - it would be highly > appreciated. One nice Engines post you have probably read :) http://pivotallabs.com/migrating-from-a-single-rails-app-to-a-suite-of-rails-engines/ > The bigger my app (https://github.com/informatom/mercator) gets, the > more i get the feeling, that I'm building a huge think, that I don't > wont to work on in a few years from now because of it's complexity. That's an important point! Regards, Ignacio > > Test coverage on the models is OK'ish, on controllers it's next to 0. > Maybe my feelings will get better, when I will be improving that. > I'm also thinking about splitting up into microservices, but I think I > would loose lots of Hobo's features then and shy away from the work. > > Ciao, > Stefan > > -- > You received this message because you are subscribed to the Google > Groups "Hobo Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/hobousers. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/hobousers. For more options, visit https://groups.google.com/d/optout.
