I have read through Q&A/articles that explain the ideal structure of a Ruby project. I read the RubyGems guides on how to create a Ruby gem. I have just read a Q&A asking at what point a ruby project becomes a ruby gem but I can not for the life of me see the difference between the two. The structure seems to be the same. The files, where they go, everything looks the same to me. Is it how they're used? Can someone please explain the difference between the two to me?
The question that must be answered respect to 'Gemify' or not is: am I writing something that is readily reusable in a different context? If the answer is yes then your application is a candidate for 'Gemification'. If not then generally it is not worth the additional complexity to convert a Ruby project into a Gem.
For example. If one makes a CLI Ruby application that collects mortgage rates from multiple vendors and updates a database then there are two ways this could be converted into a gem.
First: You could generalise the interface/configuration and make it useful as a plugin/add-on/extension to projects written by someone needing the same or similar functionality. So someone could add the gemified version to their project and use it to do the grunt work for them and just make use of the results. This describes the most common use case for gems.
Second: However, you could also extract the framework of your CLI project layout into a generator gem for others to easily create their own CLI project layouts. This is how Rails came to be.
Related
Is there a tool for creating Ruby gem which automatically generate not only project file structure, but also tests file structure (with default ruby assert tests or rspec)?
You may want to take a look at hoe, which allows you to write your own project templates in erb, amongst other goodies. See http://docs.seattlerb.org/hoe/
Personally I have found, despite looking for something like this initially, that bundle gem <gemname> and a quick reference to an earlier project is not all that much work in practice, considering the number of gems I have written (about 7, though only one is published). Boris Stitnicky's comment rings true for me as well - understanding why a particular structure works, and building it from scratch at least a couple of times is worth the time invested in gaining Ruby knowledge.
However, if my day job project involved creating many in-house gems, I'd probably be using hoe, or a similar tool to get them started consistently.
Currently I am writing a Ruby on Rails application, and I am using Gems, however sometimes I feel that Gems are not as flexible as I want them to be. To make them more flexible. Should I
Fork them on github, and customize it, but this still present the challenging of managing everything.
or
Strip and merge the code of the gem to the main application? This will allow further customization of the gem. This would be for situations where a Gem require another Gem's functionality.
or is there a better way of doing this?
Thanks
B
Choice A is the better answer for a number of reasons.
You get to merge in security updates, enhancements, and bug fixes easily.
Your changes may get merged into the core--in fact, consider if you could implement them in such a way as they live alongside the core functionality as options. If this happens, you have the ultimate win--nothing to maintain, and you can retire your fork.
Others can benefit from your changes.
Your project's footprint is kept smaller and focused by keeping the gem code isolated.
You'll have something to add to your Github "resume."
If its some kind if not so popular gem or "bicycle" from some previous studio or developer who started project(in my case).
I prefer deprecate this gem's and move code into project,
for example they have c***la-deploy - it's just wrapper to Capistrano 2 with own methods))) - I just delete it and rewrite on last Capistrano 3
Than that have own "CMS" c***la-cms where they wrap standard form_for or simple_form with name "twitter_form_for" ? - fist of all I start try to find gem who use this name, and than find in dependency gem's ...
Its take a lot of time for new developer involve in project - better move to standard rails methods/heplers
But anyway i understand for a what this studio do that - its just vendor lock and for client more hard to move out from them to another developers.
For example for startup its bad to use a lot of dependencies and if it's just simple website - dose not matter.
I am developing a Ruby gem, Ampere, that acts as an ORM for the Redis database. I am trying to shore up its Rails integration, and was able to tie in an initializer and console hook, but my generators do not work yet. I have a generator, ampere:config that installs a default configuration YAML file, and a replacement for the model generator as well.
When I install my gem into a testing Rails app, the ampere:config generator shows up in the list when I run rails generate on the command line, but when I type rails g ampere:config, I get:
Could not find generator ampere:config.
and nothing else. My generator lives in "lib/rails/generators/config/" within the gem, and clearly Rails knows about it since it showed up in the rails g list, but something's not right. If anyone can help or knows of some better documentation for this than the Rails Guides, which are sparse to say the least, it'd be much appreciated.
Ok so I finally got this. For the generators to work, they have to call source_root with the relative path of their templates, and they have to live in lib/rails/generators/your_gem_name/, then the directory structure in your_gem_name/ is what you'd expect from reading the documentation (or running rails g generator in a Rails project).
The documentation is not very clear about this, so it was a bit confusing, but after looking at a few examples I tried this and it worked.
I know Github.com uses Rails.
But what template language does Github use? And what css framework does Github use?
Yes, Github uses Ruby on Rails.
When asked about the technology stack that they use to Sam Lambert, Director of technology he said:
MySQL is our core data store that we used for storing all data that powers the site as well as the metadata around the users. We also use Redis a little bit for some non-persistent caching, and things like memcached.
C, Shell, Ruby — quite a simple, monolithic stack. We’re really not an overcomplex shop, we don’t intend to try and drop new languages for every small project.
Here's a link to see the projects that power Github.
Edit
The original question was somewhat confusing and seemed to conflate Github with Rails. My answer below aimed to clarify the difference. The changes/clarifications made to the question later (after I posted my answer) have lead to the answer below to no longer respond to the question as (now) posted, but I cannot delete the answer as it has been marked as accepted...
==================================
It's hard to tell from the wording, but I think you're confused about several languages/tools that are found in Rails. Maybe this will help:
Git (http://gitscm.org/)is a version control tool (http://en.wikipedia.org/wiki/Revision_control) used frequently in Rails projects. It's used to manage the source code in your projects (versions, branches with different functions, etc.)
Github (https://github.com) is a place you can store source code that is managed with Git
the default language used in Rails views is called ERB (introduction example here: http://thinkvitamin.com/code/rails-views-erb-part-1/)
rails 3.1 uses Sass to create CSS files by default (http://sass-lang.com/)
Those are the languages you've mentioned having trouble with, and they're a portion of the languages you'll need to familiarize yourself with if you want to use Rails to its full extent.
You can learn more about Rails online (for example: http://ruby.railstutorial.org/, http://railscasts.com/), or with books (http://pragprog.com/book/rails4/agile-web-development-with-rails and http://www.manning.com/katz/ are 2 good books. The first one is easier for beginners, the second one goes into more detail and is for more advanced readers).
It appears github has moved towards converting their monolith from rails into microservices made in other languages. Doubtful rails is completely out of the picture IMHO.
https://www.theregister.com/2018/08/16/github_rails_microsoft/
I've looked in a lot of places - including www.rubygems.org - but can't find any tutorial that describes an easy, straightforward, technique for producing gems that doesn't rely on other (non-standard-Ruby) components, such as newgem and hoe.
I have several requirements for gem production, from the simplest case of one library file+one test file, to complex ones involving C source files and multiple utility .rb files.
All help gratefully received!
I was researching gem making recently and was also surprised that there wasn't a single, obvious way that everyone does it like how RubyGems is the one-stop shop for managing gems. I discovered that you can actually use Bundler to create gems, and I've chosen this route for my own gems. Take a look at this guide on gem development with Bundler by Radar.
look into Jeweler or one of these options:
http://ruby-toolbox.com/categories/gem_creation.html
its seems like overkill, but you don't need to use all the options, you can use it just to create the skeleton of the gem.
I've recently been looking into the same thing. Here are a few sources I found useful Walk through of a simple gem, Gem spec reference. Also I found it useful to check out large projects on github and model after them Thor's Gem spec.
Don't know if you've seen "Gemcutter Is The New Official Default RubyGem Host", but it's a good starting point. RubyGems.org is a good second stop to read Creating Your Own Gem.