Search
Tyler Hunt
Raising the Bar
Edit
#rubygems
#gem-development
#ruby-community
#code-quality
#best-practices
#bundler
#versioning
Summarized using AI

Raising the Bar

Tyler Hunt • September 29, 2011 • New Orleans, Louisiana • Talk

Summary of 'Raising the Bar' Talk

In the talk titled Raising the Bar, Tyler Hunt addresses the current state of quality in the Ruby gem ecosystem, highlighting the importance of not just quantity of gems but the quality of each gem developed. With over 25,000 gems available on RubyGems.org, it is essential to follow best practices to maintain a consistent standard that benefits the Ruby community. Hunt emphasizes the joy that Ruby provides, which is often enhanced by the libraries and frameworks that contribute to the ecosystem's vibrancy.

Key Points Discussed:

  • Flexibility and Quality: While Ruby’s flexibility allows for innovation, it also results in varying quality levels among gems, which can frustrate new users trying to choose the best option for their needs.

  • Creating a New Gem: The process of creating a gem involves several steps:

    • Setting up the gem directory and writing the gemspec,
    • Defining the essential metadata like gem name, version, author, etc.,
    • Building and pushing the gem using gem build and gem push commands.

  • Dependency Management: Hunt explains that handling dependencies properly is crucial. Each gem can have runtime and development dependencies that are specified in the gemspec, highlighting the importance of version management to avoid conflicts.

  • Testing and Documentation: The significance of writing tests and producing good documentation is emphasized as these play vital roles in gem adoption and code quality. Proper testing frameworks ensure that gem users can rely on the gem's functionality.

  • Conventions for Best Practices: These include:

    • Keeping all code in designated directories like lib and bin,
    • Avoiding pollution of the load path,
    • Using versioning strategies such as semantic versioning to manage changes and releases effectively.

  • Engaging with the Community: Hunt encourages gem creators to welcome contributions from users. The culture of open-source development, particularly facilitated by platforms like GitHub, allows for faster improvements and greater community involvement in gem development.

Conclusions:

Tyler Hunt concludes by stressing the importance of adopting best practices to ensure the Ruby gem ecosystem continues to thrive. He encourages developers to engage with the community, contribute back, and implement the conventions discussed to raise the quality of gems being produced. With low barriers to entry, the opportunities for innovation and improvement are greater than ever.

In summary, Hunt's talk not only outlines the steps for creating high-quality gems but also actively promotes community involvement and adherence to best practices to ensure long-term sustainability and quality in the Ruby ecosystem.

Raising the Bar
Tyler Hunt • New Orleans, Louisiana • Talk

Date: September 29, 2011
Published: December 13, 2011
Announced: unknown

Now that there are now over 25,000 gems on RubyGems.org, it's time we took a step back to look at the quality of what we're producing and the best practices we can all follow that will benefit the community. Other languages expend a lot of effort maintaining a standard coding style and consistent APIs among their shared libraries, but the Ruby community doesn't. This has done a lot to lower the barrier to entry and allow the Ruby ecosystem to flourish, but it has also produced a lot of code of questionable quality that doesn't always mesh well in our applications. There are simple conventions we can follow, though, that will make a big difference in establishing a consistent baseline for our gems. These include things like writing gemspecs instead of Rake tasks that generate them, properly namespacing your libraries, and not polluting the load path. But there are also other practices that will benefit others, like producing good documentation, including binaries when needed, and establishing a sane versioning strategy. We'll cover the full lifecycle of a gem from beginning to end, from your first push to RubyGems.org to making and accepting community contributions, and consider the conventions that we can establish each step of the way to increase the value of the gems we're producing.

RubyConf 2011

00:00:16.960 i'm tyler hunts and you can find me on twitter and github at tyler hunts i work
00:00:22.240 for envy labs a little rails consultancy in orlando florida and i also blog over
00:00:28.320 at devo.com so you can look there later for the slides to this talk
00:00:34.160 so i'm sure we can all agree that ruby is great thanks to mats we have a language that's a joy to use and it's
00:00:41.760 why we're all here today but a big part of that joy comes from the flexibility that ruby affords with creating
00:00:48.239 libraries and frameworks that make our lives easier with nearly 29 000 gems now on
00:00:55.719 rubygems.org the true beauty of ruby is found in its vibrant community of gem
00:01:00.879 contributors we have a plethora of choices when it comes to libraries and frameworks and while that's great it can
00:01:08.000 be problematic sometimes too take orms for instance we have
00:01:14.080 active record data mapper sql og
00:01:19.280 and then web frameworks we have even more choice we have
00:01:25.200 rack rails sinatra pedrino merb camping ramaz nitro
00:01:33.200 and what this means is we have lots of choice every day that goes by there are more gems than ever to choose from
00:01:40.640 and this brings with it some great benefits having choice allows people to
00:01:45.840 experiment with new ideas and break conventions and it also allows people with differing
00:01:51.680 opinions to be able to thrive in our community without having to abandon the language
00:01:57.119 entirely but it comes with some detriments as well it can be confusing and frustrating
00:02:03.920 for new users to have to decide between multiple libraries that perform the same
00:02:09.520 function and then we also have to deal with varying levels of code quality and determine which gem of the ones that do
00:02:16.879 we want is the best so what's the solution to this how do we fix it well
00:02:22.400 what needs to be fixed i mean we don't want to stifle innovation or limit people's choices
00:02:28.319 but there is an overall need to improve the quality of some of the gems being released so that's kind of what i want
00:02:34.560 to focus on today we've got the quantity so let's increase the quality
00:02:40.319 so we're going to start by walking through the the steps involved in creating a modern gem and
00:02:46.239 then take a look at some of the conventions that will result in better gems and then close with kind of where
00:02:52.560 we are today with the rubygems ecosystem
00:02:58.239 let's first go through what's involved in creating a gem from scratch some of this material is geared towards showing
00:03:04.159 how to make gems but it's also going to touch on some of the conventions that we'll go into a little more later
00:03:10.560 we're going to walk through the steps to create a new gem called stardust the name comes from a great little indie
00:03:15.680 coffee shop in orlando called stardust video and coffee where i've been co-working every tuesday for
00:03:20.959 the past couple years and it's not actually going to do anything which is why the name doesn't really matter all that much it's just going to contain
00:03:26.720 everything but the functionality needed for our gem the first thing we want to do is
00:03:33.599 create a directory to hold all of our files and we'll name this after the gem that we're creating and switch into that
00:03:39.920 directory and then we're going to edit our gem spec now the gem spec is a
00:03:45.840 file that defines all the meta information about our gem that includes things like the gem name and the version
00:03:51.599 the author and email address for the author and all of the dependencies and this is what uh kind of the core of
00:03:59.120 the gem spec looks like and these are the required fields name version and summary
00:04:04.159 that's all you need to start but you probably also want to add in some of those other fields like authors email
00:04:10.000 home page etc you can get the full list of those parameters in the gem specification
00:04:15.519 reference at docs.rubygems.org and then once we have this we're
00:04:20.799 actually able to build the gem and this will create the gem file for the version
00:04:26.639 specified in our gem spec just gem build and then the file for the gem spec
00:04:32.080 since we haven't listed any files yet there won't be anything included in our gem other than the metadata itself and
00:04:41.120 a gem file is actually just a atar archive with a gem extension so if we kind of look here at extracting those
00:04:47.680 files out you'll see there's two files inside that's
00:04:52.840 data.gzmetadata.gz and every gem is going to look this way regardless of what it includes
00:04:59.040 the metadata file after you unzip it contains a yaml file
00:05:04.240 containing the metadata we defined in our gemspec plus some additional information that ruby gems adds in when
00:05:10.560 it's building the gem with default and that sort of thing and if we look at the data file and
00:05:17.120 extract that we see all the files for the code included in our gem in case of our stardust gem there aren't any
00:05:23.199 files yet so this will just be an empty archive so let's add some files we'll create a directory first called
00:05:29.919 lib and this is where all the files all the code for our gem lives
00:05:35.120 this is where our ruby files go we make the directory from within the starters directory we created originally
00:05:41.759 and then we're going to add our first file stardust.rb and this is just named after our gem as
00:05:48.000 well to make it simple for people to know that if they install the stardust gem they can require stardust to load that gem
00:05:55.840 inside that file what we want to do is again create a module with the same name as the name of the gem and this is going
00:06:01.039 to be responsible for kind of namespacing all of the code within our gem
00:06:07.280 now we'll jump back into the gem specification again and tell it about the directory we've just added
00:06:13.440 the jam spec has a files attribute that is just an array
00:06:19.600 of all the files you want bundled inside that data archive within the gem
00:06:25.360 these paths are all relative to the root of the gem directory and the gem spec is just ruby so we can
00:06:31.680 use other libraries and ruby facilities to kind of generate that file list for us if we want to
00:06:37.919 the required paths line just lets ruby gems know that it's the lib directory that should be added to the load path and this value
00:06:45.120 of lib is actually the default provided by rubygems so we don't actually need to add this line to our rubygems we can
00:06:50.639 just rely on that default i'm sorry to our gemspec
00:06:57.199 next we want to kind of create a subdirectory under lib again named after our gem and this is where the rest of
00:07:02.960 our files are going to go so that we don't clutter up the load path um keeps all the files in the gem from being
00:07:09.120 directly accessible via require kind of putting them under that directory so everything has to be
00:07:14.400 required via stardust slash whatever if we want to require something underneath that directory
00:07:22.160 now let me go over the version a little bit we do have a version defined in our gem spec but we're going to go ahead and
00:07:27.520 create a second file called version.rb under that stardust directory
00:07:32.880 now this file isn't required since we have already defined the version the gemspec but it's become a
00:07:38.720 fairly commonplace practice to do this sort of thing and it gives us some additional benefits that file just contains again our module
00:07:46.160 stardust and then a constant defining our version and that's it that's all that goes in the file
00:07:51.440 but this is going to allow our gem users to programmatically kind of determine the gem version when they're using their
00:07:57.840 applications it's possible to get this information through some of the rubygems libraries but that
00:08:04.080 kind of gets messy and it doesn't really work for everyone so this is an easy way for people to kind of determine what
00:08:09.199 version of the gem they're running the problem now is we've got the version number defined in two places it's here
00:08:15.039 in this file and it's also in our jump spec so
00:08:20.960 before we jump into the gem spec we want to open up that start us file again as well and require stardust version and
00:08:29.360 this means that if somebody just says require stardust on our gem they don't have to also require stardust version if
00:08:34.399 i know what the version is so and this is how you'll require all the sub files for your gems as well just using
00:08:39.839 stardust since that stardust directory is going to be in the load path thanks to the lib directory being
00:08:45.519 added back into our jump spec now we see we
00:08:50.800 originally defined the version number just as a hard coded string so we're
00:08:56.080 going to update that to use the constant we just defined we've got to add two lines here
00:09:02.080 just to add the lib directory to the load path and then load in our version file
00:09:08.560 i'm not a huge fan of modifying the lid path here but that's kind of been the established convention at the end of the
00:09:13.920 day this is just our gem spec which is only used when we're building the gem so
00:09:19.279 modifying the load path shouldn't really be all that big of a deal then we're going to swap out that
00:09:24.320 version line with the constant we've defined instead of using the hard-coded string
00:09:29.760 so now we need to update the version of our gem we just edit that version file and we don't have to do it in one place
00:09:35.519 and we don't end up with duplicated version numbers they could um veer off from one another
00:09:42.720 and then we can ship it with all that we have the core of our gem built out and we're ready to actually push this out to
00:09:47.920 the world so everyone can hook up the stardust them and the gem in their own apps so the first step is to build the gem
00:09:54.560 file and this again just uses the gem command gem build in our jump spec file and we did this once already but we need
00:10:01.279 to do it again since we made some changes since then and once it's built we can use gem push
00:10:07.200 to push the gem up to rubygems.org and this does require that you have an account in place on rubygems.org but i
00:10:13.680 think it kind of walks you through some of those steps if you don't have that set up already and this will make it
00:10:18.959 publicly accessible to everyone to install via gem install
00:10:24.240 and it's kind of a a nice side effect of this after you push your jum to rubygems.org you'll get your 15 seconds
00:10:29.839 of fame as the on the top of the list for the new gems on rubygems.org on the front page
00:10:37.279 and that's it that's all there is to building and releasing a gem aside from actually implementing your
00:10:42.560 gem but one thing we haven't discussed yet is how your gem can depend on other gems
00:10:48.640 and dependencies are the mechanism for that they let rubygems know what libraries need to be installed in order
00:10:55.040 to use your gem they're specified again by adding additional lines to the
00:11:01.120 gem spec file so here we've added a runtime dependency on active support and a development
00:11:07.680 dependency on our spec now development dependencies are used for dependencies that are only needed
00:11:13.200 when developing your gem and they won't be installed by default when someone installs your gem
00:11:18.240 so if we do gem install stardust and after we kind of rebuild the gem and
00:11:26.240 we'll see that those dependencies are installed but it's just active support we don't see our spec there and that's because it's been defined as the
00:11:31.920 development dependency if you want those development dependencies installed there's a flag on gem install
00:11:38.079 development that will install them for you um
00:11:43.760 be thoughtful though when you're choosing your dependencies it's uh if it's just simple functionality that
00:11:49.600 you need you might want to just write it yourself in the gem rather than requiring additional
00:11:54.720 dependencies because every dependency you add has the potential to complicate things and introduce further conflicts
00:12:01.040 when people are trying to pull this gem into their own applications there's also a small gotcha to watch out
00:12:07.120 for there's a post up on rubygems.org right now that kind of details an issue with parsing that yaml metadata file and
00:12:14.720 it has to do with whether it's being parsed by psyc or sick the two different ammo parsing libraries
00:12:20.399 that exist right now the tl dr on that is that rubygems.org needs to be fixed but in
00:12:26.880 the meantime there's a workaround in the latest version of rubygems 1810 so upgrading to that version will work
00:12:33.120 around this another way is to just avoid using equals dependencies in your gems
00:12:38.560 so use greater than equal to or use pessimistic kind of locking and that should keep this issue from
00:12:44.240 popping up um bundler since we're talking about dependencies let's talk about manila for
00:12:50.720 a minute we when we're doing gem developments bundler provides us a couple of useful
00:12:57.519 tricks so the first thing we need to do is add a gem file within our gem directory and
00:13:03.600 that gem file is just going to be two lines we have the source defined and then we have this gemspec command
00:13:09.920 and that's the first assist we get from bundler this is a shortcut that tells bundler to consult our gemspec to
00:13:16.480 determine our dependencies all your dependencies should be defined in your gem spec not in your bundler
00:13:21.680 file so we don't end up having to define them in multiple places and now when we do bundle
00:13:28.399 bundler will consult that gemspec file and install all the dependencies based on what's defined there instead of what
00:13:34.480 you typically do which is adding those to your gem file the other feature bundler provides to us
00:13:40.800 as gem developers is bundle gem and this effectively automates all the steps we've seen so far
00:13:47.600 plus some more things it also initializes a git repository for us and sets up a rake file with some helpful
00:13:52.880 tasks so a lot of this kind of hand coding stuff we've looked at so far can just be done
00:13:59.040 with bundle gem if you're using bundler and then
00:14:04.560 once that bundle gem command has been run you'll see everything that bundler has done for
00:14:09.680 us we've got the libstardus.rb file and the version rb file we took a look at
00:14:14.800 we've got the jumps back set up already referencing that and then we've also get our gem file a rake file and our get
00:14:21.199 ignore file um already set up for us and now we're just command away from the first commit to
00:14:27.760 our new gem bundler also defines three rake tasks for us to use when
00:14:33.440 we're doing developments as well we get rake build which will build the gem for you and this is basically just the same
00:14:39.519 as doing gem bill stardust.gemspec like we saw before but it's simpler to type
00:14:45.040 and it allows us to it will also place the gem into the package directory
00:14:50.720 where it will be ignored by the git ignore file kind of keeping the root directory tidy
00:14:56.079 there's rake install which will build the gem and then install it into your system gems and rake release which is probably one
00:15:02.720 of the most useful and this will create a git tag for the current version number then build the gem and then push it to
00:15:09.720 rubygems.org for you kind of automating the release process even further
00:15:16.000 before you push though you should really be writing tests for the code that you're writing
00:15:21.760 as good rubios we know how important tests are to code quality but with gems they're even more important since you'll
00:15:28.399 have other people relying on that same code within their own application so the key thing to remember here is just to make sure that you're writing those
00:15:34.240 tests and it doesn't matter if you're using test unit or r-spec as long as you're testing the gem so
00:15:40.639 there is one thing to keep in mind uh test unit when you're writing gems will actually add the gems lib directory
00:15:46.480 to the load path for you so you can just require relative to that our spec doesn't do that so you'll have to add
00:15:51.600 that to your spec helper yourself this is what the spec helper might look like in that case and it's just a matter of
00:15:58.079 kind of adding that lib directory onto the load path and then requiring your gem into it as well
00:16:06.079 and then make sure you add our spec as a development dependency of your gem and not a runtime dependency so people
00:16:12.399 using your gem don't have to have our spec installed as well you should also be looking for tests
00:16:18.079 when evaluating gems you've never used before reading through a gems test gives you a fairly good picture of the
00:16:24.560 overall code quality of the gem and the absence of tests in a gem should at the very least cause you to hesitate before
00:16:30.639 adopting the dependency into your application so now that we've seen
00:16:37.040 kind of a rough overview of how to create the gem we're going to go through um some additional conventions to keep
00:16:43.040 in mind when doing gem development some practices we haven't touched on yet
00:16:49.120 um all the code needed to use your gem should be placed into the lib and bin directories bin is just used for
00:16:56.560 command line tools and that sort of thing that are actually executable after installing your gem
00:17:03.600 in some cases when using non-rubygems package managers things like rip
00:17:08.880 anything outside of these two directories won't even be loaded so it's a good idea to stick with those
00:17:14.319 directories when you're on gems keep all your code within a module with the same name as your gem this ensures
00:17:21.360 that you won't inadvertently clobber someone else's classes or modules with ones in your own gem and it
00:17:26.799 keeps everything your gem provides encapsulated and avoids cluttering the global space
00:17:34.799 don't pollute the load path your gem should never need to modify the load path the gem packager handles all that
00:17:40.799 for you so be careful what you place in lib though since it will be directly requireable anything under that lib
00:17:47.440 directory is just a require file name away from being loaded so
00:17:52.640 it's a good idea to stick to just using the rb file named after your gem
00:17:59.679 since lib is added to the load path there's also no need to use things like expand path or underscore file
00:18:06.720 when requiring files within your gem just require them relative to lib
00:18:13.200 there's also no need to require ruby gems anywhere within your jam if someone's using your gem they've already
00:18:18.320 got ruby gems loaded or whatever package manager they're using so adding this require just forces people to have ruby
00:18:23.679 gems installed which might not necessarily be the case
00:18:29.200 if you do run into cases when you're developing your gem where rubygems isn't loaded rather than adding that require
00:18:35.039 line for it just use something like ruby dot ruby dash rubygems or set rubyops to rubygems and either one
00:18:42.320 of these will load rubygems for you without forcing you to modify your code
00:18:49.200 don't use class variables when configuring your gems i see this most often with api client
00:18:55.440 gems where the authentication credentials are provided at the class level and this can be problematic because it prevents users
00:19:02.400 from having multiple instances of that service with different credentials defined at the same time so sticking
00:19:08.720 with instances for configuration allows for more flexibility in how your gem is used by your users
00:19:16.640 okay this is a big one that not many gems get right all the potential errors from your gems should use an error class
00:19:23.120 defined by your gem this means that if you have dependencies that might be throwing exceptions you should be
00:19:28.799 catching those exceptions and re-raising them kind of wrapped in your own error classes
00:19:34.559 so as an example of this inside your module you want to define a base error class
00:19:39.760 which any additional errors used in your gem should inherit from an idea here is that people using your gem shouldn't
00:19:45.760 have to know about its internals in order to handle exceptional cases they should be able to do something like
00:19:51.440 this where you have a simple rescue block for the base error on your gem and you shouldn't have to expect to
00:19:56.880 receive any other error when dealing with that gem and this goes especially again for gems that interface with web
00:20:02.320 services and use dependencies like rest client i shouldn't have to know that
00:20:08.320 um which which http library my gem is or the gem i'm the library i'm using is
00:20:14.000 using to rescue its errors i should be able to rescue a single error defined by that gem
00:20:21.600 testing do it documenting it's even easier to overlook
00:20:28.000 documentation than it is to skip out on testing but having a readme is critical to gem adoption it should be considered
00:20:34.320 vital to its success at the very least you should be describing what the gem does and how to
00:20:39.520 get started using it so it's easy to quickly see how it works and
00:20:44.640 what it does when you're browsing around on github packaging write your own gem specs
00:20:51.280 instead of complicated rake tasks in gems like jeweler it's easy enough to write yourself and
00:20:57.200 it makes it easier for people to build your gems too so then once you have your gem spec
00:21:03.039 building the gem is just a matter of gem build you know to worry about installing other gems just to build your gym
00:21:10.400 for any of you who have used ruby forge before you know the pain of having to
00:21:15.840 set up new projects get them approved using the web interface to upload gem files
00:21:21.039 but thanks to the new rubygems.org you're just a gem push away
00:21:26.159 it's a good idea to also create that git tag when releasing a new version so people who are trying to debug issues
00:21:31.840 can look back in the code and at that particular tag and view the source code
00:21:39.600 having a good versioning strategy also plays a big role in releasing gems tom preston warner has proposed a
00:21:45.520 specification called semantic versioning and many in the ruby gems community have
00:21:50.880 begun to adopt this specification and for good reason it makes a lot of sense and
00:21:56.000 it solves issues that have been problematic um in the past and provide some standardization for how everyone's
00:22:01.679 versioning their gems it's called semver for short and there are a few basic requirements that it
00:22:07.280 defines the first is that your gem provide a well-defined public api
00:22:13.280 this means that the interface used by consumers of your gem is clearly delineated from its internals either
00:22:19.440 through code things like method visibility indicators like private or through the documentation
00:22:27.280 the next is the use of a three-part version number with major minor and patch versions and each must be an
00:22:33.120 integer and be increased numerically and once a specific version has been
00:22:38.320 released the code for that merchant must not be modified it's think of it as an immutable release so once it's out there
00:22:44.640 if you want to change something you have to increment the version number the major version zero is reserved for
00:22:51.360 initial development and should not be considered to have a stable public api there's still a lot in flux if you see a
00:22:57.919 zero version gem that's using semantic versioning the patch version should be incremented
00:23:04.799 if only backwards compatible bug fixes are introduced where bug fix is defined as an internal change that fixes
00:23:11.520 incorrect behavior the minor version should be incremented if new backwards compatible
00:23:17.919 functionality is increased to the public api so here you haven't broken anything that was already released you're just adding
00:23:24.000 new functionality if you're breaking backwards compatibility the major version must be
00:23:29.280 incremented anytime backwards incompatible changes are introduced to the public api
00:23:35.679 after seeing these definitions it should be clear why the requirement of well-defined public api is necessary for
00:23:40.960 a versioning scheme because depending on what type of changes you're making to that public api defines which part of
00:23:46.960 the version number should be incremented there's also a requirement that if you create a version
00:23:53.520 new version you tag that version in version control like we've already talked about and proceed it with a v
00:23:59.600 as the tag name now once a gem is using semantic versioning you can use pessimistic
00:24:06.400 locking on your dependencies at the major version level and rest assured there won't be any upgrades to that gem that will break
00:24:12.960 your gem with a minor or patch level version change
00:24:18.640 the specifications hosted at sember.org and it's short and easy to read so i'd encourage all of you to read the full
00:24:24.960 specification if you haven't already uh one of the greatest parts of releasing your own gem is getting
00:24:31.440 feedback and contributions from people who are using it having that sort of instant feedback and
00:24:37.520 the ability for anyone using your software to send patches to fix bugs and add functionality is amazing so don't
00:24:43.760 take that for granted of course much of the credit for the more recent proliferation of community
00:24:48.960 contributions must be given to github and for the incredible job it has done reducing the friction required to create
00:24:55.679 send and merge patches via their forking and pull request features anyone can fork a project and make
00:25:02.159 changes themselves and those changes can be contributed back to the project via pull requests so
00:25:08.559 letting people know that you're open to accepting such contributions to your project might just encourage more users to give back in the form of code
00:25:15.200 contributions you can add that into your readme bumping versions for contributors do not
00:25:21.760 bump version numbers as part of the changes you're contributing version changes should be separate
00:25:27.200 should be a separate commit from the code you're requesting be merged in and not be in
00:25:33.600 that pull request this allows gem maintainers to handle version changes on their own schedule it makes it easier
00:25:39.360 for them to merge in the pull requests through things like the web interface
00:25:46.559 ruby's seen a huge amount of growth over the past few years thanks in large part to rails but that's met a lot of new
00:25:52.000 developers coming out of the scene from all different backgrounds the gem ecosystem has been flourishing
00:25:57.600 ever since the switch away from ruby forge as well and i'll just reiterate this point again the number of gems has essentially
00:26:03.600 doubled since the transition over from ruby forge to rubygems.org and lowering the barrier
00:26:11.039 of entry makes it easier for developers to release new gems and part of that barrier to entry is
00:26:17.120 making releases easier thanks rubygems.org releasing new gems is now as simple as gem push gone are the days
00:26:23.600 of waiting for project approvals and uploading gems via a web form you can just push now simply as gem push
00:26:31.840 but quantity doesn't equal quality as you're all well aware with that new code being released we end up with a few
00:26:36.880 questions we have to ask ourselves sometimes one of those is whether
00:26:41.919 to use an existing gem or write one yourself or just write code within your app to handle it
00:26:48.159 there's a lot of code great code we can use now but when you start getting into some
00:26:53.200 more obscure subject areas obscure web services and that sort of thing this question becomes a little more
00:26:58.880 relevant another question is duplication how do we decide between several different gems
00:27:05.600 that do the same thing you don't want to limit innovation but choices can be confusing to newcomers
00:27:12.799 take for instance json gems and also the how the multi json metagem and then xml
00:27:18.960 gems where you have things like beige prakada and nokigiri
00:27:24.000 um it also presents a lack of focus in the part of the community there's it's tempting to want to rewrite gems we're
00:27:30.880 easily distracted by what's new in shiny and we love to reinvent the wheel
00:27:36.159 but sometimes we'd be better served by spending that time improving what already exists so think twice before
00:27:41.360 starting developments on a new gem what we've looked at today is
00:27:47.360 how we can extract and define some simple conventions that go a long way towards improving code quality
00:27:53.520 for everyone and now that the barrier of entry has been lowered the ecosystem is thriving and flourishing so there's
00:28:00.159 never been a better time to introduce new gems so i hope you'll be able to take away some of what we've discussed
00:28:06.480 today to get out there and create something new
00:28:12.320 so i want to say thanks to a few people for getting us to where we are today thanks to nick carranzo for
00:28:19.360 putting in the work to make rubygems.org a reality and thoughtbot for making it pretty for us
00:28:25.600 to use thanks to yehuda and carl collectively
00:28:30.960 known as carl huda for spending their countless days developing bundler uh thanks to github for giving us
00:28:37.039 amazing tools that advance the state of open source and thanks to everyone else who's ever
00:28:42.880 released the gem and community is all the richer for the value you guys have
00:28:47.919 contributed by shipping code can i answer any questions
00:29:16.240 that is actually covered by the specification i didn't mention it today but if you're doing release candidates you can just append something like rc1
00:29:22.720 to the end of the version number without a dock so just be 1.0.0 rc1
00:29:29.039 and that's defined in this fact yeah uh i implemented a gym that that
00:29:35.200 handles cement and versioning for you and if anyone wants to take a look at it it's called version simply enough but uh
00:29:42.480 it automatically will it keeps a version file at the root of your project it will uh read it in into
00:29:49.200 uh to a module of your choosing but then also there's great tasks that let you bump it uh bump pre-release
00:29:55.440 versions uh you know bump whatever the lowest increment is but the major version and it can even automatically
00:30:01.279 get tagged for if you want and it just means doing that gets rid of the friction so
00:30:06.880 take a look just called version okay yeah
00:30:13.279 so back when uh was building gyms i used to be able to perform something and let's say
00:30:34.080 assuming that i can't get back upstream right one of the easiest things to do if you're using bundler is just to add that
00:30:41.200 as a dependency in your gem file you can specify the git repository as one of the parameters in the bundle in the gem file
00:30:48.159 but i don't think i can do that like if my gym depends on another general i can't do it isn't that true oh so it's a sub dependency basically
00:30:55.360 right um it'll use two specs yeah for
00:31:00.880 it it'll attract uh dependencies and gyms through get repositories and working the gyms back
00:31:06.720 but he's saying if you want to modify one of the dependencies of your dependency yeah but you can put that at the top level of your gen file and yeah
00:31:14.240 would say oh you want this one and not the other and then i wouldn't fulfill it
00:31:22.080 well i think what they're saying is you can just add that sub dependency to your gem file and bundler is smart enough when it's
00:31:28.640 resolving the dependencies to use that instead of the one defined in the gem spec in your dependency
00:31:35.600 but as far as like pushing it up to uh or any recommendations about that
00:31:42.399 rename it yeah just have to push it up with a different name basically
00:31:54.799 anything else okay well there's um up front on the
00:32:01.039 table here there are some stickers and things so feel free to grab some of those on the way out um for envy labs
00:32:06.720 we've got business cards and code school stickers all kinds of stuff so thanks a lot
00:32:35.440 do
00:32:53.519 you
TH
Tyler Hunt
1 talk
Explore all talks recorded at RubyConf 2011
+55