What are some of the best practices for OOD with Ruby? Mainly, how should files and code be organized?
I have a project that uses several classes and files and I am just wondering how it should all be organized, grouped and included.
It sounds like you're asking which pieces go in which files.
Is your project a Web application? In that case you would most likely use the system of organization imposed by your framework (Rails, Merb, Sinatra, etc.)
Other kinds of projects also have their own typical structure that you can just follow. E.g. gems are usually set up in a certain way.
If it's a console app, there's no strict rule. Usually people put no more than one class or module in a file. You could have one main file that requires all the others.
Standard OOD concepts apply to ruby. For specifics, maybe this guide will be helpful:
http://www.rubyist.net/~slagell/ruby/oothinking.html
Related
I'm building a small framework to be used by several internal applications. What is the best way to separate the framework and use it for other projects?
My initial thought was to create it as a gem, but it's only used internally. Does it still make sense to create it as a gem to be used only internally? If not, is there a best practice for a shared code location?
Probably going to depend on use-case, but the gem structure is pretty standardized and is going to give you easy translation to other projects and new developers coming on. Beyond just simple and generic scripting, I always use a gem framework for internal utilities.
Check out RubyGem-Bones, it's a handy skeleton framework generator.
I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
I was wondering if there is an off the shelf tool to help create a 'web application' directory structure with a basic application up and running? The source code would already be pre-written I'm guessing or based on the options some files may/may-not be generated.
I'm not sure what you'd call it but say we have a custom framework* which are to be used for web application development - rather than 'creating' a directory structure all the time we could just create it once and have a console like interface similar to the play framework to generate a basic application or an empty one as per the developer's choice.
We could just give various types of 'zip' files and ask folks to unzip it and import it in their IDE of choice and continue. However, we'd prefer to have an 'installable' to run from the command line (or GUI but no such preference) to have a basic application up and running without everyone wanting to do it all over again.
How does the Play framework do it? What do they use? (I'm guess similar things exist for RoR, Groovy/Grails.)
*It's not custom per se, but similar to having all the spring/hibernate/restlet/freemarker etc files pre-configured, up and running and a directory structure with packages for the various components by convention
I think one of the key points here regarding the Play framework is that it uses the concept of convention over configuration. Your applications are forced to follow the same pattern for the different parts of your application, or it will not work. I personally like this because it makes working on different projects easier, as the rules are always the same, rather the somewhat unwritten rules of best practice.
Java EE on the other hand takes the concept of configuration over convention. Therefore all your files and structures are defined in your relevant XML documents that specify your frameworks, classpaths, etc. There do exist some tools to try to bridge the gap. For example
IDE's will have project creation tools for your chosen framework, so will create a Struts or Spring MVC project structure with a few simple wizard steps. Eclipse does this for sure as one example.
Spring MVC also has Roo. This is a boilerplate code generation tool that creates large parts of your initial project for you.
From your description it seems you have a few different frameworks that you want to have auto-generated, but I don't think any tool currently will serve your purpose. Your concept of a zip file is your best bet here.
If you want a kind of scaffolding in the Java EE world, take a look at Appfuse which provides some archetype with several implementations on the views layer (JSF, Spring MVC, Struts 2...).
Preface: This is not much about how to structure code within files. I have that down. This is more of the topic of organization of your source tree. Hopefully someone will just say, "Here's a great link on the topic." However, firsthand opinions on the subject are welcome too.
So I've done a bit of digging on this subject and find tons of material on simple structure. I guess the assumption is that, by the time you need to deal with the problems of the size of your codebase, you'll already know the answer. However, even the IDEs seem to be waging a holy war on how these projects should be structured (which is NOT what I wanted to start in this thread).
Java enforced the package structure in the language. Kudos for that. Eclipse then lets you use projects to have (potentially) independent -- we'll call them 'buckets' in this example -- buckets of related code. Intellij has distinct but similar concepts with 'modules' within a singleton instance of a 'project'. If you want another project, you're essentially starting from scratch.
However, RubyMine offers no such modules in ruby apps, and by default just wants to slam everything into the root directory. It allows Directories, so one could essentially just pick some arbitrary tree structure and run with it. This implies to me their intent was that all classes have access to all other classes within your project. This might have some resolution through the use of Ruby 'modules', or might just be an honor-system pattern of "don't reference that stuff."
So, to put it succinctly, say I were building a 'foo' and a 'bar' concept, and both depend on a 'util' class. maybe I'll deploy them as gems, maybe I won't. I could:
Slam them all into one RubyMine project and just ignore the fact that 'foo' and 'bar' have no reason to be aware of each other.
Put each in its own RubyMine project. This seems like a real pain if there is any concurrent development. First of all, 'util' would have to be packaged separately and then included as an external resource in the other projects.
Neither seems particularly appealing. Thougts?
I'd develop all three independently, then make util a gem. In the Gemfile for each of foo and bar, you can give a path to the gem so that you can develop them all concurrently without the pain of messing with version numbers and so forth (for production, you would then point it to the real gem on Rubygems or at some git repository).
For project structures, check out the Ruby Packaging Standard and Gem Patterns.
I'm building several sites that need similar "modules." For example, the sites may have the exact same login system, forum, etc.
Is there a way I could build these modules once and just "drop" them in these various sites? Some of the challenges I see:
Keeping the code consistent in the various sites. Any changes made to a module should propagate to all of the sites using that module. I guess I need a way to upgrade?
Database: these functionality need to work as part of a bigger application. Maybe the module needs to define relationships with other tables in its respective site.
I'm sure there are more problems. I think I should be looking at this: https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, but I don't have any experience with it.
So, I'm looking for solutions, suggestions, or more problems to this idea.
You can create and use third party packages by adding them to the third party folder (which is new for CI 2). There is not much about it in the docs, but i found this.
http://codeigniter.com/user_guide/libraries/loader.html
You can autoload the third party packages in the autoload file. Packages can have their own controllers, models, views etc.
Interestingly, Phil Sturgeon wrote a bit (http://philsturgeon.co.uk/blog/2010/04/codeigniter-packages-modules) about packages not being modules (in the strict sense of the term), but you could probably use third party packages for what you need.
I would write them as libraries and use Git submodules to manage each module. Phil Sturgeon actually just wrote a great post about doing this in CodeIgniter.
If you're not using version control, I can't see an easy way to sync across all of your applications. Yes, HMVC will let you break apart your application into actual modules, but it won't help in syncing those modules across your applications.
Here is my question about 'Database communication in modular software'
that you may find useful.
I'm little bit familiar with Drupal, and as a modular application, I think it can be taken as good example of how relationships between modules should be defined.
Here is one good post about art-of-separation-of-concerns
I would like to hear if you have run into some concrete challenges, solutions and references concerning modular design in CI.