00:00:08.830
My name is Manuel Morales, and I am addicted to health checks. It's a bit of a lame addiction, but it has happened. When you have a system that grows in complexity, it doesn't matter if it's a monolith or microservices architecture; eventually, you end up with many potential points of failure. Are all those microservices alive and capable of communicating with each other? Is MongoDB taking an unusually long time to respond? Did your AWS keys expire unexpectedly? Did you forget to input the correct password in that configuration file? Or did you overlook the random aggressions? The most ironic issue is forgetting to configure your error notifications properly. For that reason, we started resorting to health checks. A health check is a simple concept; it is a single endpoint that performs all necessary checks and returns a ‘200 OK’ if everything is functioning well or a ‘500 Internal Server Error’ if something is wrong, ideally providing information about the error.
00:01:05.089
When you have all these stress-inducing issues, having a single endpoint that you can query to check on the system's health gives you a nice, reassuring feeling to which you can become addicted. When do we use these health checks? We utilize them in several scenarios. We check them every time we deploy a new version of a microservice because you can't overlook migration issues or forget to update the config file. We also check them when you're configuring that service for the first time, whether it's on deployment or setting it up on your local machine. When you start that service for the first time, the first thing you do is query the health check to verify that everything is okay. Our monitoring tools also constantly poll the health checks to ensure that everything is running smoothly. They are particularly useful when troubleshooting; if something goes wrong and the monitoring tools indicate that everything is on fire, you can check the relevant health checks, which will help you trace back to the original issue.
00:02:14.790
Because we implemented this mechanism repeatedly across different microservices, we decided to build a library for it. It's open source and available on GitHub under the name ‘Mini Check’. It's very easy to implement; you simply create a new health check for your application. You define which endpoint you want to expose, register the various checks you would like to run—such as checking the database connection or confirming the Redis client is working. You can integrate it with middleware like Rails or Rock. But here's a funny story: be careful what you test. It's not advisable for microservices to check each other's health if one service depends on another. If one service calls another service's health check and they are set up to communicate, it can result in an endless loop of requests that will crash both services.
00:03:31.140
When you query the designated endpoint, it returns the results of the checks along with metrics like how long each took to run and whether they're healthy. If a check fails, you receive an error message, an exception, and a stack trace. This can lead to information disclosure, so be cautious with this in production environments—hide these endpoints behind Apache or other security measures; you don't want hackers to access such detailed information. While we primarily work with Ruby, we also use Elixir. My colleagues Manuel Alejandro and Roberto Pijo developed an Elixir equivalent of our health check mechanism, which is exemplified in a project whimsically named Gondor. They are definitely better than I am at naming libraries.
00:04:41.300
And of course, at our company, we have offices in London and are about to open an office in Barcelona next month. Thank you very much.
00:05:39.650
Hello! I'm here to talk to you about 'Warm Blanket,' a gem designed to eliminate poor performance on the first request after deployment. What do I mean by poor performance? It's common for web services to experience unpredictable latency on the initial request. This could be due to lazy loading of code, where the first request hits certain code paths, triggering auto-loading of gems, classes, and the initialization of singletons. Alternatively, it could be related to lazy database connection establishment, where the first request has to initiate all the database connections. If you're using a just-in-time compilation version of Ruby, such as JRuby, the first request could suffer from higher latency costs. This becomes problematic for user experience when services restart or deploy. Your application could slow down random times, resulting in varied experiences across multiple servers.
00:06:31.150
At Talk Desk, we encountered this issue, prompting us to develop Warm Blanket. The concept behind Warm Blanket is simple: it warms up your web service by looping over a configurable number of HTTP requests that you deem representative of your application’s typical workload. When your application starts, Warm Blanket connects to the web server and begins sending these requests in a loop, allowing all auto-loads and databases to warm up. If you're using a hosting solution like Heroku, you can utilize the pre-boot feature, which provides a three-minute window to warm up your application before it's put into production. If you're using Kubernetes, you can set it to delay while your application initializes, thus ensuring your performance remains consistently high from the first request onward.
00:07:34.100
In conclusion, with Warm Blanket, you achieve consistent high performance right from the start, as users experience it. If you'd like to read more about Ruby and JRuby, please check out my blog and find me on Twitter. Thank you!
00:08:54.900
Hi! I'm Jan Lelis from Berlin. In my free time, I enjoy exploring Ruby and its capabilities. Recently, I was documenting the Ruby standard library, and I came across something intriguing. The goal is to gamify the Ruby standard library, transforming each standard library component into a gem. This initiative aims to be completed in one of the next Ruby versions, and it is being coordinated by Kenta Murata from Heroku.
00:09:17.220
There are two types of standard gems: builtin gems and standard library gems. Built-in gems are part of the current Ruby standard library, and you can require them without needing to load anything directly. They are also maintained by the Ruby core and examples include OpenSSL, JSON, and the upcoming Bundler, which will be included in Ruby 2.5. On the other hand, standard library gems are similar to regular gems but do not require installation because they are already included with Ruby. These gems are maintained externally, outside of Ruby core. Popular examples of these include Minitest, Rake, and PowerAssert, which you can find listed when you run a command that lists all installed gems. The concept behind transitioning to standard gems allows for greater flexibility and means that gems can be updated outside of the regular Ruby release cycles. This will also facilitate various Ruby implementations in maintaining the standard library.
00:10:44.260
However, this change could have potential downsides, such as confusion regarding which Ruby version comes with which default gem. It may also lead to uncertainty about where to direct pull requests—whether to Ruby core or a specific gem repository. I have established the Standard Gems tool to help clarify which standard gems correspond to which Ruby version, so you might want to check that out. In conclusion, while this transition presents both challenges and opportunities, it is ultimately a positive step towards improved maintenance and adaptability of the Ruby standard library.
00:12:06.600
Next, I'd like to invite Victor Shepelev to the stage.
00:14:27.860
Hello, everyone. I'm planning to talk about a gem I attempted to present last year at a previous Euruko lightning talk, which some of you might remember. The concept is quite different from what has been shown today, focusing more on pragmatic, materialistic work. I had an intro that stretched over five and a half minutes during my last presentation before I could even get into the core of the topic. Unfortunately, I faced internet issues back then. Today, I will avoid all distractions, have prepared the code in advance to demonstrate to you, and let the code speak for itself.
00:14:50.519
So let's get started.
00:15:18.949
That’s it!
00:16:18.480
Hello, everyone. My presentation will be more straightforward and basic. I have a question: who here wants to be really fast at fixing bugs and extending functionality? Anyone? I hope for more responses. And who wants to genuinely enjoy coding? Good! I believe that having good names in your code plays a substantial role in achieving these goals. If you think back to your university days, coding examples often started with ‘a’ and ended with ‘z’, making it difficult to understand the underlying logic.
00:17:10.610
This struggle is why I emphasize the importance of good naming conventions when working with junior developers and my team. Good names serve as half the battle—if not more—because code should read like prose, making the developer's intentions clear through the logic and algorithm. Who among you has hit a major roadblock trying to decipher some poorly named code? This experience proves that good naming is crucial. Even if your code may not function perfectly, having descriptive names allows follow-through on the underlying logic. This not only helps you during the project lifecycle but also aids in their understanding when colleagues need to work on iterations of your code later on.
00:18:41.780
Therefore, my proposal to you is to extract smaller methods from your main methods, clearly labeling them so that anyone looking at the code can easily follow what needs to change when the project evolves. For instance, in a user signup process, instead of clustering all logic together, use descriptive method names such as ‘CreateUser’, ‘EmailUser’, or ‘AddSocialMediaUser’ for each step. This way, if someone needs to adjust when an email is sent, they know precisely where to go for changes. In conclusion, if you find yourself needing to write a comment to explain your code, it’s likely that you're not giving your names the proper effort.
00:19:45.730
Thank you!
00:21:12.200
Hello, everyone, I’m going to speak about a project I’ve created called TTY, designed to aid in building terminal applications with Ruby. Observing that Ruby's capacity extends beyond just web frameworks, I wanted to develop tools to help transition away from bash habits, which I successfully achieved.
00:21:35.410
You can find the project along with all its components documented on the website and its source code hosted on GitHub. Currently, I have about fifteen components, but I’ll only highlight a few in this talk. Firstly, there's TTY Prompt, this component won the Fukuoka Ruby Award, which indicates its wide approval. You can use it by simply requiring it and instantiating your prompt, and it offers a selection of choices that display right in the terminal.
00:22:50.220
Another component that I worked on is called TTY Progress Bar, which assists with multi-rendering in applications. Using it, you can create multi-progress bars and register several bars that run in different threads. Additionally, I have implemented a TTY Spinner, which indicates unknown progress during processes like file downloads.
00:23:31.960
Ultimately, if you’re unsure about building terminal applications, I created an executive tool called TTY, which is built on top of Bundler to streamline the process of creating Ruby applications.
00:23:45.350
You can locate it all on Bundler to help organize and create your terminal apps. Thank you for your time!
00:24:09.690
Hi! I'm Yan from Depfu. For those unfamiliar, we are a service that helps you keep dependencies up to date by sending pull requests as soon as updates are available. However, today, I'm here to talk about an upcoming feature in Bundler 2.0.
00:24:30.830
We've published a blog post about it, and out of curious vanity, how many of you have read that post? Great! So, one main change in Bundler 2.0 will be a shift in default file names where you declare your dependencies. The ‘Gemfile’ will be renamed to ‘gems.rb,’ and the ‘Gemfile.lock’ will become ‘gems.lock.’ Why this change? Firstly, the capitalized naming of ‘Gemfile’ is a bit peculiar, as it's often seen as unnecessary. More importantly, the lack of an extension could create confusion when identifying the file's purpose.
00:25:30.540
Lock files are commonly associated with resources in UNIX systems and are treated as temporary; therefore, automatically deleting a ‘gems.lock’ can lead to problems, particularly when various systems and tools have assumptions about naming conventions. When Bundler 2.0 is released, we will ensure it remains compatible with existing profiles, meaning your old Gemfile will still work, though discussions on future releases indicate that bundles 3.0 may not. Transitioning to these new naming conventions might take consideration, particularly regarding existing infrastructures' readiness to adapt to the changes.
00:27:09.440
In conclusion, while there’s opportunity for confusion with this transition, it is more about improving clarity and maintainability going forward. Thank you very much for your attention!
00:28:11.600
What a day! Thank you to our amazing lightning talk speakers. Everyone had something fascinating to share!
00:28:23.570
As a few last announcements, please remember you can still send your proposals to [email protected]. Also, make sure to read our blog posts that have been published over the past few days for updates. Our party will be at 8 p.m. at Uncapped, so don't forget your badge. We will only allow entry for those with badges. I hope you enjoyed today; I had an excellent time! See you at the party and tomorrow!
