I am new to Ruby and I have written a small app, that consists of around 50 .rb files and 6 folders. The purpose of app is to be an SDK for Ruby users, to interact with my API. It also uses few gems. Now I want to release this app for specific users, but looking at the internet for the solution really confused me (may be just because I'm new to it) and MOST of the posts found were for Rails
Being through several posts, what I find to be reasonable is to make a gem out of it and publish this gem at rubygems.org. (but this also makes it fully public)
Question:
Is this the correct approach in my specific scenario?
How can I manage the dependencies? (This part is very confusing, I will need more guidelines on this)
How to limit audience? (I have personal git server, would this be of any help)
Other Info:
App is developed in Ruby version 2.1.8, It makes http Get/Post requests using TLS, and is NOT a Rails or web app
I have been through several SO posts like THIS, THIS etc. But I couldn't understand it for my case.
I created a project in Jetbrains' IDE, called RubyMine. My project doesn't have bin folder, etc. but only my own folders and .rb files. And most of the solutions also talk about bin.
Any help will be appreciated.
Gemfury is probably what you're looking for. You'll package your library as a gem the same way as if you were going to publish it publicly on RubyGems, but Gemfury lets you restrict access to it to only the people you want to allow.
Related
Disclaimer: I know ruby since quite long as language and i am a experienced programmer from the Java corner, but haven't really dealt deeply with the whole eco - culture of Ruby. I always liked Ruby, but only now I am starting to use Rubygems with Bundler and i am impressed. So i am assuming there is an easy answer to my question , which proves my ignorance ;-)
One thing i really like about gems and bundler is that you can package and distribute libraries and applications or even both... neat.
Let's keep it simple. Let's say i have a script, which does something in a database and which want to package and distribute with bundler with enterprise specific gems server. For the configuration of this script i need a db url, a userid and a password. The password should likely be encrypted. This configuration should be externalized in a host resp. installation specific config file.
In the Java Spring Boot world, where i am coming from , they have this mechanism with application.properties which can be a mix of build time, installation and runtime parameters and can be accessed through a common api.
I saw in the bundler documentation that one pass the local configuration file upon installation time : https://bundler.io/v1.5/bundle_config.html. Neat. But i am not quite sure how this could/ should work in detail. Here real world examples would help...
Is there a canonical form to have and deal with installation specific configurations for ruby apps distributed with gems and bundler?
Any pointers , input , feedback is very welcome.
There is no universal setting storage system in Ruby applications.
dotenv is popular for plain Ruby applications. Rails has its own system.
I want to build a plugin system for a web app I'm writing. I don't want to have to restart the application every time a plugin is added/removed/enabled/disabled. Also I won't know the names of the plugins or even how many there are (I want to make it 'infintely' expandable).
The obvious way would be to reload the app on every request (as in this question, the Sinatra FAQ, and with Sinatra-Contrib). Reloading on every request would have poor performance for a production environment, especially a popular app.
I have read an article about Kernel#load and that it reloads the file when called multiple times and Kernel#autoload which only loads the code if needed. But both methods require the name of the module/class to be hard-coded in.
Jenkins CI and WordPress imply they can do this. Jenkins says "1000+ community contributed Jenkins plugins" and WordPress says "48,492 plugins". So I imagine it must be possible, but maybe only in Java or PHP.
I am working with Ruby 2.2, Rack 1.6.5, and Sinatra 1.4.7. I'm developing on Windows and I plan to deploy to Linux. If what I want is impossible to do on Windows (annoyingly some things are :P) I will set up a dev server with Linux.
Thanks!
EDIT: I will also need to be able to unload plugins. I'm not aware of any unload/un-require methods
I am looking for error management service for my Ruby on Rails project, Can any one suggest the best tool with lower price.
I have 5 Rails projects.
I found one tool http://www.batbugger.io/ is free in beta version, Does have any idea about that. It looks fine.
Thanks for your suggestion
I would go with https://github.com/errbit/errbit. Errbit use the same API as Airbrake, but is an open source solution. Errbit itself is a Rails webapp, and can centralize errors from multiple sources.
There is also a nice integration with GitHub (to create issues from errors) and Campfire (to get the errors directly inside the team chat room).
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.
Me and my team are starting to build up a few re-usable scripts. They're re-usable within our org only as they work with proprietry apps and our particular server environment. So not really suitable for rubyforge or github, etc.
My question is, what is the best practice for ensuring we're all using the latest and greatest scripts across all users? We pretty much run these scripts on one server, but may need to expand to others.
Should we bundle them into gem(s) and start a private gem server?
Or something simpler like a common, shareable lib directory. Perhaps with a script to download/update from our SCM?
Other ideas?
Thanks....
This depends on some factors, like how many people want to change the code (only your team, or someone else too), or how much money you have for this?
Personally I'd create a build+gem server, where you can upload the scripts using some versioning system (like git or svn, depends on how many people are working on the project), and then create a cron job, that would automatically genereate the gems from the sources at generic intervals and store them as different versions. This way you can be sure that you always have an authorative server that stores your applications gems, and you can always get an earlier version if something breaks. Your script might create separate gem version names, like "appserv-edge" or "appserv-stable"
You might also want to check out github's closed source options too, if you have the money to afford that. I don't know however whether they have gem building and hosting facilities for non open-source programs.
I've created a private gemserver and it's dead easy. The only tricky bit is deciding how you want your users to upload gems. Personally, I just use a PHP upload form, and have it check to make sure that it's not masking any existing gems.
At my office we're using a bit of a hybrid approach for some of our shared scripts and libs. We do bundle them all in to a gem, but rather than using a gem server we keep them in source control, and then build the gem (using newgem) and install it locally as necessary.
The downside of this approach is that it takes two commands instead of one to install the gem, but this is largely mitigated in qa and production environments, since we use Capistrano for deployment.
The upsides are that it's dead simple, and in development there is a very short edit/build/deploy cycle if you're working with something that requires changes to the gem. I'm currently pulling a lot of common functionality in to the shared gem, so I'm really appreciating that aspect.