![]() However, because the context of what we are building is for Rails, our consideration will primarily focus on the Rails version. If you are creating a gem that could be used in any Ruby program, you will need to consider specific Ruby versions as well. What Rails version(s) will your gem support? For the gem we are building in this tutorial, we will use the MIT license. The type of license you choose may depend on your philosophy on open source, a specific business objective, or something else entirely altogether. The whole topic deserves its own blog post, so instead of rehashing definitions, let me list a few well-known Ruby gems and their licensing models for reference. ![]() I recommend you check out the Open Source Initiative's License & Standards page for details. There are many types of open-source licensing models. Very often, I have seen a variety of gem names where I have had to manually check what their purpose is as a dependency.įor our FilePond integration gem, we will call it filepond-rails. While consulting with companies, I have seen some very large Gemfile files. However, if you are planning on publishing to, you still want to respect the namespace of organizations and individuals who have an existing trademark.įor myself, I prefer descriptive (ie. What will I call my gem?Ĭhoosing a name is a personal preference. For our discussion, I assume you are thinking about open-sourcing your gem. When you release any code that is meant to be consumed by others, there are several things you need to think about. ![]() With that out of the way, let us talk about some general considerations when you create a Ruby gem. The usual questions I ask myself would be:Ĭan this gem function on its own, specifically for a small subset of features? Or,ĭoes this gem add a functionality - although coupled (such as with Ruby on Rails) - that is limited in scope and has a relatively stable implementation? Like everything else in programming, there are always exceptions to the above reasons and examples. external service, database, etc.)įunction specific (eg. Gems that are limited in scope are easier to maintain, understand, and use.ĪPI wrapper (eg. It aligns this shared codebase that eases upgradability and maintainability.Ī scenario you typically want to avoid is creating a gem that adds too much functionality. If you are adding the same code on multiple projects - say, in a single organization or company - and there are little to no customizations for this particular set of code, then packaging them into a gem may make sense. Here are a few reasons: Package code for reuse Having said that, sometimes it does make sense to use a gem. It affects code maintainability and makes upgrading (eg. Having too many dependencies in projects is a sure way to make things difficult for yourself in the long term. This will consist of both Ruby code for our custom controller and code to load the JavaScript library.Īdd tests to check our controller, the loading of the JavaScript code, and system tests to check the functionality of our integration.ĭocument our gem so that others can use it. It will give you some context as to what we are building here.Ĭreate (using the code from our previous post) an integration library to the FilePond JavaScript library. ![]() If you have not yet read through the previous blog post ( How to use FilePond with Rails' Active Storage), I recommend you do so now in a new tab. So from here on out, I will only refer to Ruby libraries as gems. There are, however, some general best practices I will outline.īy the way, if you are new to Ruby land, we call libraries "gems". There is not a single way to do this, and you will notice as you read through various source codes of different gems that authors have various preferences. As you are reading through this post, keep in mind this is my approach. In this blog post, I will take my previous blog post ( How to use FilePond with Rails' Active Storage) and turn the code from there into a gem. (Even better if there is a preexisting library that we can plug right into our code and save ourselves some time, right?) It is almost instinctive for developers to search for solutions that other developers have successfully used when faced with a problem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |