 I started to talk to our middleware as code with MLV. So I changed my talk title after creating presentation slides, so I speak our slowly, slowly English. So my name is Shimata Hiroshi. So please call me Hiroshi. So my internet nickname is HSBT. So it is used at Twitter and GitHub, too. My job title is chief engineer at the GMO paperball. I have many commit bits, such as Ruby, and Rake, and RubyGMSRDoc, RAZeguard, et cetera. I maintain these websites are RubyLang, and RubyCI, and RAZeguard. So if you have questions and requests to this software and these websites, please pick up after this talk. So I'm from Tokyo. This is Tokyo. So MAT came from Matsue. So yeah, it's a Ruby's bus place. So I arrived every RAZeguard RubyConf from 2013. So it's three times for me, so thanks, Winston. I'm from Asakusa Ruby. So Asakusa Ruby is most active Ruby's meetup in Tokyo, Japan. So every Tuesday. If you visit Tokyo, Japan at Tuesday, so please call me. Please mention to these members on Twitter. It's a founder of our meetup, Matsuda-san. He's a Ruby and RAZegomite, and Ruby Kai is organizer. And Kaktani-san, Koichi-san, and me. So we will pick up near our meetup place. So it's a last advertised slide. So we are working on developing to Ruby 2.3 now. But we don't have the big future of Ruby 2.3 yet. Currently, so we removed some of the related and duplicate rivalries, like Rake and Terranet, from standard rivalry. But don't worry. So we already implemented the Bandos general mechanism. You can get these rivalries via Ruby Jamus when you install Ruby. And if you have any issue, please submit our track cards. Sorry, it's a red mine. So moreover, we schedule the core developer meeting every month. Please leave this link for details. So, OK. Today I talk middleware's code with Emory. It's straight talk target first web engineer, includes RAZ programmer, and operation engineer, and QA testing engineer, and Emory committers. Is Emory a committer in RAZ or RubyConf? But only. So I hope to show this presentation to Matt. So at first, I need to introduce Emory basis. Is there any person who uses Emory in production? Wow. What's Emory? So it is an official message. So Emory is a right-weight implementation of the Ruby language, compared to the ISO standard. Its syntax is Ruby 1.9-compatible. However, Emory has some differences compared to C-Ruby. I listed there. Input of things, Emory is a single binary without native extension and pure libraries. And it doesn't provide a require method. So we couldn't use require in Emory's world. It is confused many of Ruby's. Emory has many advantages, I think. First, the single binary, like Go-Rang. It is very portable with Ruby-James dependencies. Second, it can be embedded to some middleware, like HTTP server. It's a most important thing. So Emory is fun. Fun provides productivity to programmers. So that's what Emory is. Emory binary is controlled by build.conf.rv. I figure out this mechanism. This file is the Ruby script. If you want to customize the Emory binary, you can put your library or third-party library via Conf.James syntax, or like Bandra, the James file. It passes GitHub directory. You can use local file system, like this. Emory.James mechanism provides Conf.James. Please read this link for details. Emory.James, mainly component, is Emory.James Lake, and Emory.Live.Dx, and SRCDx3. Emory.James is end point of Emory.James. And Emory.Live is a primary source for Emory.James. It includes our pure Ruby files. SRC is native extension of Emory. So again, I will write coding. So it is my first time for write coding. OK. So hello, all. So MRV, I can't know our herald class. So I tried to create MRV herald MRV gem. So it's empty for the MRV gem lake. That is sense. MIT. Spec also me. So MRV lake, the specification, needs to are two attributes. So it's a license and author section. And I write, hello, gem. It's the same as C Ruby. The words, but RDRC. Yeah, so it's our first implementation of MRV gem. So I need to put MRV herald gem into our build config. So like a conf gem, reactive path, like on the build. Oh, so same. So the MRV herald words. Oh, RDRC. Yeah, so I'm now MRV gem author. So it's so easy. So and this binary move to homeholder. It includes our MRV gem. So it's a single binary that mattises. So it's an MRV gem mechanism. So next topic is a middle and mid MRV. So MRV has a meditable mechanism for middleware. So MRV provides a Ruby runtime and the syntax to middleware. It provides fun for us. I introduce NGX MRV. Matsumoto Ryosuke, who works JMO paperwork, made the NGX MRV. So here is my colleague. We can run Ruby code via NGX MRV or NGX process. So it is a NGX configuration file. It's not the Ruby file. You can play NGX MRV on OS 10 or Riax boxes. This list is a minimum instruction for playing NGX MRV. So it's a copy and paste building. NGX MRV have many points for invoking Ruby code on NGX. First, Ruby content handler. It is a fundamental usage of NGX MRV like this. So it invokes the RRV file with cache mechanism. So cache mechanism is this Ruby file is caching. And you can write inline Ruby code into our NGX configuration with code suffix mrvcontenthandler underscore code. NGX MRV invokes these handlers every request. It's important, every request. Next is a mrvset. It sets the return value for mrvcode evaluation. It results to NGX variables, like this back-end variable get proxy.rrv return value. Code suffix is the same as before slides. mrvset code and inline code. And every init is invoked once when NGX master process launches. It is not invoked every request, like this. HTTP section and mrv init file, initializer file, and location section is mrvcontenthandler. It invokes every request. mrv init worker, like mrv init behavior, but it invokes when a worker process launches. This is mainly a function of NGX MRV. So it is a sample code of NGX MRV. NGX MRV creates a request and the connection class and instances. We can use these instances for HTTP programming. This production called class handles these instances across the initialize request and the connection. And it detects ROD-RB from a remote IP address, like this, collection.remoteIP method. And some header, the request instance have some header and header attribute. So xrrp or xyrrp. So this program handles these attribute and ROD-IP address. If NGX requests have a connection, IP address is a local host address. So this production called pass-through, it requests. I put this code using mrv setHandle like this. NGX handles the return value of mrv and access control like this before black, middle layer, layer on rails. So we can access controls. So our company, jmopapable uses NGX MRV for these use cases. Example for a calculation of a digest hash for authentication and data sharing with the rails application and NGX. And to replace aggy-complexing NGX configuration to test our ROD-RB code. So we send middle-layers code as this concept using NGX MRV. I show more details on our use cases. So I introduced data sharing and the selected access with NGX MRV. We have post-sharing service named the 30 days album. I introduced this service architecture at the past RubyCon. So this figure shows the selected access mechanism without NGX MRV. So we use NGX and the rails application and the main cache and the power bar. Power bar is right-weight proxy middle-layer written by power. This figure is a complex architecture because it have much middle-layer and different languages. So I replaced power bar to NGX MRV. So I integrated power bar to function into our NGX MRV. So we can develop with only Ruby code now. So I introduce our code of data sharing using Memcache D like this. It is a pure Ruby code. It is not a specified MRV code. We have a collection leak issue at our first implementation. So I put Memcache D collection into MRV handler section. We face the correction over for after that. I discussed this issue with Matsumoto Ryosuke-san before he joined to our company. He solved this issue in a few days implemented by MRV init worker. We can share the Memcache D collection and use the MRV init worker handler. So NGX MRV and MRV is the open source of there. So if you have any issue and request, so please submit GitHub or authors. So we are developing together. It is a final version of our sharing code. We put the correction process into init worker handler like this and disconnect it like this. MRV user data is a user data class, provides a user data and user data class. It provides a global object in NGX MRV across each handler. We can share the correction via this code. We select some request with this code. It is simple Ruby code. We evaluate request parts and write session data like this. Sharing with this session ID key, it is powerful as comparison part of the NGX MRV. NGX MRV is faster 10% to 20% than power. We got more Ruby code and high performance with NGX MRV. It's so fast. Please start it. So I, Matsumoto Ryosuke-san said this slide. So next topic is testing. So testing is important. So someone said the test is redundant. Really? Yeah, we should test every production code in real world. I cannot find the MRV use case with testing code in these ads of Google search. So prototype concepts. My first implementation is these concepts. We use C Ruby without the MRV. And the user, test unit, simple X unit cells. And so we focus only Ruby's syntax. It is not MRV's behavior. It is a target code of MRV. It is the same as before slides. So we need to put much dummy class because Shilvi doesn't know MRV's words. So NGX requests and the connection and all of dummy attribute and the dummy class. And it is a dummy class of MRV user data and the MRV memcache class. So MRV memcache class name is memcache d. But Shilvi's memcache class is memcache. So it is too complex to me. And so test code is here. It is simple test case. So setup context creates dummy class of NGX requests and the connection instance. And require the target code and assert production code with setup context. It is a test case of memcache request. Memcache d usage. So same as before slides. And I create a memcache d instance and set data. And mocking out cookie data with session key. We can run tests. We can run these tests codes with this one writer. Simple Ruby code. So we can test it. Test is back. So we can test MRV codes. However, I have some concerns about the Shilvi testing. Shilvi testing is not the real behavior. So many work and stuff. So it's a Ruby's test of the dark side. So we try testing code of MRV using MRV. I found the unit test library named MRVM tests because it is MRV jam. We can put unit test tool into MRV binaries. So like this, I put like this MRVM tests and the building binary, and we can run this test code. I added test case into inline production code for using MRVM tests. If MRV binary has MRVM test class, it invokes these blocks. It is a test code. If MRV didn't have MRVM test class, it invokes our production code like this. We need to separate MRV binary from NJNX MRV. This instruction shows only build MRV binary before NJNX. I wrote this task runner for MRV testing. It is a simple task. I'm going to upload this slide after this presentation. Please check instruction details. So I can evoke this task runner results here. MRV testing is three times faster than CRV testing. All of the last time is seven microseconds. It's so fast. Last topic is deployment. We need to prepare NJNX MRV binary for production use. We use built NJNX MRV binary with Docker container like this. So please show that my gist files. You can get this complex Docker file, a copy and test. These instructions are simple Docker commands. You can get NJNX MRV binary with your build config via Docker easily. Only two commands like this. We put this binary into our official NJNX packages. So we replace only NJNX binary for NJNX MRV department or replace only NJNX binary. We are widely using Puppet for production department in my company. This manifest provides a NJNX replacement for official NJNX packages. If you use Chef or Ansible, please write like this. I introduced production use case of NJNX MRV and the test and the deployment. However, we have many challenges related to NJNX MRV. We use binary with M-test jam. It is defined from production binary. I hope to use same binary test and production. Second, we have no CI server. I think it is possible to prepare cross-compilation issue. We found MRVs serve no test issue for global NJNX configuration. I think NJNX MRV provides a testable world for 2S. MRV has a cross-compile configuration. We are trying to build MRV cross-compile directly now. I think it is evaluation status. I hope to build more easily to MRV binary like Goran. So I show MRV in the future. So MRV IPvS is an IP virtual server for MRV. We can use IPvS function using a simple Ruby code like this. Next is MRV Seagrid. Matsumoto Ryosuke makes it. It controls NJNX group function via MRV. So we can have the lower-level function of NJNX via MRV and Ruby code. Even if you can only write Ruby code, you can control the RLX world. So we should use MRV for expanding Ruby world. Thanks. That's all.