 So, I talked about genification for Ruby standard library in Ruby 2.5 and Ruby 3. So, my interest is this thing. So, I'm core team member of Ruby language. So, I'm meeting around the standard libraries and the two trains in Ruby language. So, also I'm meeting an official site called Rubylang.org. This site built by Herok and AWS and Fuzzly and other compute and network resources. So, I operate all of these sites. So, and also I'm meeting Rake and RubyGems and Ardek and Cyc and other stuffers. So, also I'm member of Asakusa ROV. So, Asakusa ROV is a meetup around Kanda and Akihabara in Tokyo, Japan. So, we chat about our programming every Tuesday. So, if you come to Tokyo, Japan, please join our meetup. So, mention to me or Akira Matsuda-san, please join me. So, and I introduce our Ruby language sponsor So, we have a lot of sponsor for development, Ruby language. So, these are Herok and Fuzzly and LSEA Microsoft. So, Herok provides unlimited dynamic resources for our website, so named Rubylang.org. So, Fuzzly provides CDN free plan for our website. So, LSEA provides a network and computer resources for package distribution like a tower wall. So, Microsoft provides Azure environment. So, we can support Windows environment with these resources and the license. So, thank you Herok and Fuzzly and LSEA and Microsoft. So, and we got these sponsors. Ruby Association in Japan and Nihon Rubinokai and Sugaya Research Laboratory Ibaragi University. So, Ruby Association provides a grant money for our AWS infrastructure. And Nihon Rubinokai and Sugaya Research Laboratory provides a Mac OS server resources. So, we can support a Mac OS continuously used by these sponsors. Thank you Ruby Association and Nihon Rubinokai and Sugaya Research Laboratory. Thank you. So, I will start talking about place demo first. So, I will introduce the background that's the demification project. So, what's the standard library? So, the standard library is a library that installed together with Ruby interpreter, French or Ruby. It needs to require different embedded libraries like string and thread and other stuff. So, and you can use standard library without a boundary and Ruby gems. So, standard library are written in two languages. First one is a pure Ruby. Second one is a C. So, there are three types of standard libraries. They are called standard library and default gems and bundled gems. I'm going to describe these in details later. The status of the current stable version, Ruby 2.4 so we have over the 80 libraries are standard libraries. Default gems and bundled gems are only certain libraries. So, 80% of Ruby's library are standard libraries. The term of standard libraries means all libraries but it is also a subset. So, standard library is not a good name but this is what we call it today, standard libraries. So, well, I will introduce the differences in the Ruby languages. In standard library, their upper frame is svm.rubylang.org same as the Ruby languages. So, we use subversion for development in standard library. The recycle is also same as the Ruby interpreter every year. Next one is a default gem. This is somewhat different from the standard library. Development upper frame is a Ruby organization on GitHub or Ruby query repository. This recycle is the same timing as the Ruby interpreter or the maintenance conveyance. Finally, bundled gems. So, these are not developed in the Ruby query repository. All of the bundled gems are developed on GitHub and this management is not done by the Ruby query team. These are trends of the number of standard libraries of Ruby languages. So, in Ruby 2.4, 105 libraries nearly all are standard libraries. However, in Ruby 2.5, 14 libraries are going to be default gems and the rate of standard libraries is about to cut off less than 80%. So, let's look about the default gems. And did you know the default gems, please raise up? Only one, two, three. Thank you. The difference between default gems and standard libraries is only that the default gems have a gem spec file. The Ruby run-gauge installer copies the gem spec of the default gem to our specification directly. However, the default gem library files are located at the same location as the standard libraries. They are not in our gem structure. So, you cannot uninstall default gems using the gem command, like a gem uninstall. This default gem is also released on RubyGems.org as a regular gem using this gem spec file. Moreover, you can determine the default gems used these week-olds, these week-olds. So, gem.road.specs, openSSL, and method called default gem. If openSSL is default gem, returns are true. Here are some typical examples of default gems. One is openSSL, Ruby slash openSSL. So, openSSL is Germany's most successful example with default gems. OpenSSL initially started as a standard library in June 2017, this year. This upstream was changed to GitHub from the Ruby repository and became independent from the Ruby run-gauge release cycle. OpenSSL gem added a new feature and fixed many bugs. You can use new features and the stable version of openSSL library by using the gem installation. You can install via the gem install openSSL command. So, we can use part of the new feature of Ruby 2.5 on Ruby 2.3 and Ruby 2.4 by installing these gems. As a benefit, security fixes. So, Ruby Core Team has not secured a key spot. So, all vulnerability reports are handled brand-wide. If a security problem happens, the maintainer of the stable version of Ruby releases a new version of Ruby. The release work of Ruby run-gauge is a very, very hard work. But by using the mechanism of default gems, we can release default gems independently on Ruby gems without releasing Ruby run-gages. So, you can fix vulnerability and overwrite the standard library using default gems. So, you don't need to upgrade a new version of Ruby run-gages for fixing vulnerability. So, the next example of Psyche and RLoc. So, the app story repository of Psyche and RLoc also moved to the Ruby organization on GitHub. So, we accept pre-request and merge feature for these default gems on GitHub. So, you can use GitHub-style development for default gems used by pre-request. So, I merge these changes into Ruby Core repository simultaneously. And so, we can involve more people to Ruby run-gauge development through the default gems. Next up is bundles gems. So, bundles gems are entirely different from default gems. It has different architecture from Ruby's standard library. In Ruby Core repository, we unpacked gem file of bundles gems and the gem folder, the Ruby package. Moreover, Ruby installed them to your environment. In other words, this bundles gem is a normal gem that was installed at the same time as installed Ruby run-gages. So, uninstalling bundles gem is also possible. You can install bundles gems. It's different from default gems. So, you can see a list of bundles gems in gems-bundles-gems file on the Ruby repository. So, there are the latest list of bundles gems in Ruby 2.5. So, you can use these gems when installing Ruby run-gages version of Ruby 2.5. So, these gems are installed at the same time as when you install new version of Ruby. So, there are test unit and main test and the lake and the digital mean and other stuff. So, bundles gem is a better solution for rival distribution without a network installation of Ruby gems. However, there are some problems. The first problem is that bundles gems cannot use C extensions. This is necessary to ensure cross-compiled binary support by installing the Ruby run-gages. So, we need to add support a cross-compilation feature to our Ruby gems. So, we are working now. So, the second problem is there is no mechanism to guarantee it works with the head version of Ruby run-gages and Ruby interpreter every day. So, I created an experiment implementation called a test bundles gems task. This task involves test suite of bundles gems running with the development version of Ruby interpreter. So, I try to integrate this task our CEI now. So, we can guarantee to work all bundles gems with the development version of Ruby interpreter every day. So, I talk about what gemification. So, the original proposal was issued six years ago. Currently, we can get standard rivalry like Net Terrain, Rake, Minitest, and Test Unit, and other stuff via bundles gems. So, these can be released independently of the Ruby release cycle. So, we change the standard rivalry to our normal or regular gems and use default gems and bundles gems mechanism. So, I called this promoted for the two gemification. So, this is a verfit summary of default gems and bundles gems. Again, so, gemification provides advantage to Ruby developer and Ruby users. So, our first thing, it targets fixing security vulnerability. So, we can install safe version without upgrading Ruby languages. An example is OpenSSL and CycGems. So, secondly, so, you can use new feature and backfix of the latest release version of Ruby languages on past stable version like Ruby 2.3 or Ruby 2.4. For example, so, logger library, logger library has not been released as gem yet, but if logger gem was released, we could use a new feature like a multi-process logging with Ruby 2.3 or Ruby 2.4. It's an example. So, sadly, default gems and bundles gems use GitHub and its workflow. Developer can quickly send a patch to default gems and bundles gems by pre-request. Finally, I believe that genification make it possible for a Ruby interpreter developer like Nobu and Koichi-san interest to focus on Ruby internal without standard libraries. So, however, there are some problems with genification. For example, there are dependency problems with Ruby gems and bundler. I'll talk about this problem later. Next one is duplication of maintenance code base. So, library. So, standard library maintenance needs to support GitHub repository and Ruby query repository used in the subversion until changing up the story. Other cons is maintenance policy. So, you can use default gem with several versions of Ruby, include Ruby 2.3 and Ruby 2.4. The maintenance should support all versions before all versions. Before the genification, maintenance only supports the latest version of Ruby interpreter. It increases support costs to our library maintenance. So, for example, Ruby gems still support Ruby 1.8. It's a rarely. So, when you try to make change Ruby gems, you need to write code that works even with Ruby 1.8 in 2017. Also, this is a very, very hard work to make. So, Ruby 1.8 cannot use 10.5 code exclamation method. So, we need to detect our used response to method. So, I introduced the progress of Ruby 2.5 of the genification project. So, first of all, I explain repository of Ruby gems. So, Ruby gems slash Ruby gems all is raise application that run as a Ruby gem site. So, Ruby gems org is a defined team from a CLI and the library team. So, Ruby gems slash Ruby gems is a command line 2 of Ruby gems. Now, some L and I maintain our Ruby gems library. And I merge or backbought into the Ruby query repository from our Ruby gems slash Ruby gems repository. So, there is hard things to advance the genification project and there's a Ruby gems. So, some of the name of standard library were reserved on the Ruby gems org. For example, so you create a storing gem and push it into our Ruby gems org. But you cannot push it. So, Ruby gems org has a reserved wireless same as a standard library. You can check this list on our Ruby gems org repository like this. So, there was a significant problem here in the spring in this year. Because this reserved world back started after the initial release of our Ruby gems org. So, some Ruby gem that was the same name of a standard library was registered. In this spring, it was not possible to push, but it was able to install. It's a first example. So, fire utilities. So, which is one of the gems registered as a gem. So, this gem handles fire formats such as Excel and Office format. So, it is a completely different future library from our fire utilities of standard library on Ruby language. When you add fire utilities into your gem file and install it, so you can see your Ruby environment is broken. I found this problem for our gemification project. At first, I couldn't infrastructure team of Ruby gems org. I got to transfer to the name space of standard library because an owner of fire utilities has no activity now. After that, I pushed the implementation of the standard library of Ruby. So, you can you you are you are relieved from this problem with our fire utilities now. So, in the case of fire utilities, I got an approval of name space transfer from our Ruby gems org infrastructure team without contacting the name space folder. But, in the case of FIDL, it was still maintained by a valid user account. So, I contacted him first and talked about a gemification project. Finally, I got a name space of FIDL and overrided by an implementation of FIDL which exists as a Ruby's standard library. The next example is a ZDBM. This is a this is a complicated problem. So, it was the same future of the standard library named ZDBM. Same future. Only difference was that it uses live FFY. Standard library ZDBM of standard library didn't use a live FFY. So, I also spoke about the gemification project to the owner of ZDBM gem. After that, I got the name space of ZDBM and overwrote with the implementation of standard library. So, the gemification project involves a team of Ruby gems, Ruby gems infrastructure gem and collaborate with many owners of existing gems. I have done transferring name space and preparing gem release and remove gem name from the reserved list on RubyGems.org and finally, I saved it between this spring and the summer. It is my work in this year. So, this is a list of default gems on Ruby 2.5 targeted to release as December 25th, Christmas day. So, when the gem release command is invoked, it shows a list of installed gems like this. So, you can see default storing on this result. These are default gems. You can see these results at the end of the year. I have advanced plan to promote these standard library default gems in 2018, like Matlix and Digest and OpenStack and StringIO, Loga and other stuff. Maybe you can install this library as default gems on Ruby 2.4 or Ruby 2.5 on the next year. So, finally, I introduced plan or the gemification for Ruby 3. So, this is my roadmap of Ruby 3. So, however, I didn't get approval from Matlix yet. So, in Ruby 2.5, so, I bundled the bundler as a default gem. So, you can use bundle command without gem installation via the gem install bundle. I believe we have to quickly set up your Ruby environment. So, next target are RubyGems 3. So, integrate RubyGems and Bundler. Moreover, I promote all of the standard library to the default gems. I hope to separate a list cycle and the responsibility from the Ruby Core theme. Finally, my goal is promoting all of the library to bundle gems without dependency over RubyGems and Bundler. So, we need to remain a dependency library over RubyGems and Bundler to default gems. So, I describe the bundle-bundler feature. So, we have a big issue with this feature. So, the issue was that the bundle test suite is RSpec. So, Ruby Core repository could not support to invoke RSpec test suite. It only supports testing it and mid-test. So, I make a test task for a bundler named the TestBundlerTask used non-installation Ruby interpreter in Ruby Core repository. So, Ruby Core theme confirms to run bundler on development version of Ruby interpreter, like Ruby 2.5 or Ruby 2.6 and Ruby 3. So, you can get improvement of bundle as standard library developed by Ruby Core theme. So, in Ruby Gems 2.7 it installed a bundle bundle and partition bundle feature on Ruby Gems. So, test code of Ruby Gems 2.7 loaded to bundle our future. So, we work towards Ruby Gems 3 which integrates bundle our future. So, therefore, in Ruby 3 so, we can use Ruby Gems 3 and bundler 3 so, we got Ruby 3 by 3 by 3. So, I brave that the bundle-bundler future helps this integration strategy, I believe. So, however, there is one big problem to our genification and the Ruby Gems and bundle. So, we cannot determine any version on the files if it was dependency of Ruby Gems or bundle. So, this is an example of this problem. So, Ruby Gems loads the latest version like 2.0.5 OpenSSL Gems. So, but we hope to use an old version of OpenSSL like 2.0.4 but Ruby Gems cannot activate past or old version of OpenSSL now. It is activation problem. So, I created our proposal for this problem. I hope the new syntax and the future that can place modules under the arbitrary namespace, like require to into some arbitrary namespace like review like this. So, there are many problems in current Ruby specification such as shared library of extensions and all the loaded future variable problem. So, in current status we cannot fix this activity problem for Ruby Gems and bundle dependencies. So, it needs to continue the discussion and work. This is a list of dependency of Ruby Gems and its test suite. So, these may remain as default Gems because activation problem with in Ruby 3. So, in other words, our rivalies without this list are bundle Gems or regular Ruby Gems. How do you feel about this plan in Ruby 3? So, I work to promote it with genification project in this year and next year and the next next year. So, in short time view, so, genification serves a security vulnerability provides a future backpotting and GitHub backhaul to Ruby users. It seems to only benefit that in the long-term view, so, it became a complicated dependency and increasing maintenance cost to our library maintenance. And confusion experience to Ruby users like your activation problem. So, we need to discuss and involve a lot of use case and user interactions. If you have some concerns, please ask your idea to me. So, that is summary. Today, I introduce Ruby's standard library, like difference gem and bundle gems. And also specification of this library. And I share the kind of status of genification project and development plan for Ruby 2.5 and Ruby 3. I'm Hiroshi Shibata. So, I'm from Tokyo, Japan. So, I'm also the executive officer and general manager of the business process re-engineering office as JMO Peppable. So, JMO Peppable has many web services like shared hosting and domain registration and e-commerce support and a lot of web services. So, JMO Peppable sponsored my travel free and accommodation cost in RubyConf 2008-17. So, many of thanks to JMO Peppable. Thank you. So, each final slide. So, it is a photo view of a developer meeting in Tokyo, Japan. So, we are working and developing towards Ruby 3 in Tokyo, Japan. And Ruby Committer arrives at this RubyConf New Orleans. So, please talk to them about Ruby 3. So, we are happy to discuss about Ruby. Thank you.