Lightning Talks

by TODO

Summary of Lightning Talks at RubyConf AU 2014

The video features a series of swift presentations at RubyConf AU 2014, showcasing a variety of technical topics from Ruby and software development. Each speaker delivers their talk in a concise five-minute format, emphasizing practical insights and experiences in coding and software architecture.

Key Points Discussed:

Mario Visik opens with interesting facts about lightning, drawing a metaphor for harnessing the potential of energy in coding, encouraging creativity in developers.
Nigel discusses creating dynamic drop-down lists in HTML. He shares code snippets and methods to manage defaults, archived records, and custom orders efficiently, emphasizing the importance of maintaining organization in code.
Shameem shares frustrations about unclear and complex code. He urges developers to write maintainable code that considers future readers, sharing personal anecdotes about struggling to understand experienced developers' code due to its complexity.
Matt Connolly introduces new authorization techniques in a Rails application. He discusses how to structure authorization better to mirror route definitions, which simplifies the process of debugging and refactoring.
Andrew Harvey presents the Hub project, built with Middleman instead of Rails. He explains how Middleman's features, like its intelligent sitemap, allow for easier management of content and improvements in service delivery for conference sponsorship.
Beth discusses the use of Pact for consumer-driven contract testing in a microservices architecture. She explains how Pact streamlines testing, enhances API design, and improves CI/CD pipelines by simplifying the integration process.
Ryan concludes with considerations for choosing CI servers, recommending Travis CI for its ease of use, while also critiquing its limitations and praising TeamCity’s speed and control, despite its complex interface and costs.

Conclusions and Takeaways:

Quality coding should prioritize maintainability and clarity for future developers.
Dynamic elements in web applications can be effectively managed with proper planning and code organization.
Practical tools and libraries like Pact and Middleman can significantly enhance workflow and project management.
Choosing the right CI tools is crucial for efficient development and can impact project success significantly.

Overall, the session successfully combines diverse insights into Ruby development practices, offering valuable tips and strategies for both novice and experienced developers.

00:00:07.600 First up is Mario. Take it away! You've got six minutes, or you're out. You've got one minute left. I've got another mic. Hear me? Great! This is the best photo I could find of myself. So that's me, Myro Visik. I work for a company called Envato in Melbourne. It's great! You should speak to the lovely people around here; they are handing out free gifts. We have popcorn and pinball, it's lovely! Today, I would like to talk to you about some fun facts that I've recently learned. Did you know that the temperature of a typical lightning bolt is hotter than the surface of the sun? In fact, it's about six times hotter. Lightning strikes the earth on average 100 times per second, and each time it hits, it creates enough energy to power 50 homes for an entire day. If only we could harness that power! Thank you very much.

00:01:23.840 Awesome! We're now back on time. Nigel, you're up! How do I follow that? You're not having my mic.

00:01:48.799 Yes, okay. My name is Nigel, and I'm here to say that drop-downs are easy, right?Whoa, going too fast! Slow down. So, all we need is a little bit of HTML like this, and we get a simple drop-down list. Cool! But what if we want it to be dynamic? We might have a little table, do a little bit of code, and end up with a drop-down list. But what if we want blanks in there when we have a new record? So, we might add that little bit of code. What if we want a default option? When we're creating something new, we get a default record by adding a new field at the top and putting in this bit of code. Okay, what if the item's archived and we don't want to show those archived items? We would add an archived record field and this little piece of code. What if we want to add an item with an archive selection — something that used to have an archived item? We would need to throw in this bit of code. What if we need a custom order? Sometimes we don't always want to do it in alphabetical order, so another field is needed. We repeat this for each list that we might need. What about the show page? Typically, we'd do something like this. However, if we didn't set up any relationships and ran into a new error, we would get an error like that. So, we have to throw in tries. What about matching? Normally, we would have something like this, but would that solution be the same in production? So, there was light at the end of the tunnel here, guys! Instead of all this code, you could just do this, or if you wanted checkboxes, you could just do that. Coming soon are checkboxes so that you can actually manage multi-relationships. It has view helpers so that instead of putting the try name in there, we can just do that, and if it's blank or nil, it just displays blank. Instead of handling this as a big conditional matcher, it automatically does that on the instance, allowing you to find all the different selections on that particular one. It also supports looking up records by single or pluralized lookup. If you provide the singular, it will find that; if you provide the plural, you can find other things accordingly. In summary, have one table for all your selection lists in your project, handle defaults, manage archived items, maintain an order for lists, ensure consistent IDs, and consistent matches. All you have to do is add that. Thank you!

00:05:11.590 Oh, awesome! Thank you. We're back on schedule, so we can fit in more talks or just listen to me. Yay! Next up we have Shameem.

00:05:42.880 Hello everyone! My name is Shameem, and I work at Ninefold. I'm very happy to be here. I have a complaint, and that's why I'm here. Everywhere I've worked and every source code I've seen has a pattern that drives me crazy. As developers, we often fail to put ourselves in the shoes of the person who will be reading our code after us. It’s funny because I was usually that person who had to maintain other people's code, often from experienced developers who had years of Ruby knowledge. Yet, when I looked at their code, it appeared written for a very smart person. I want everyone to take a moment and think about the next person who is going to maintain their code. For example, in this service class, there is a method called 'current for app' that has a block with an each method and another custom method defined within it, using yield with passed values. If you check the load balancer service class and examine the remove and add methods, these also have blocks where information is sent to the yield. When I came across this code, it took me an hour to comprehend what it was doing. I couldn't refactor it at that moment and had to return a week later, which then took me another 20 minutes to understand it again. I share this to highlight that the person who wrote this code was a very experienced developer, yet we often don’t consider the next person who will read or maintain our code. That’s what I want to convey today: just think about how your code will be perceived by others, particularly those who may not have the same level of expertise. Thank you!

00:10:04.720 Hey everyone! My name is Matt. I’ve put together a little talk about some new authorization techniques I've been working on in an app. It’s a simple application; you’ve probably seen something like this where you have Rails, Devise, and CanCan for authentication and authorization. Imagine a set of routes where each client might have a project, users, and items. The items belong to clients, projects, and users. You might also see a global list of items scoped to your authorization. This setup creates blocks where you define your authorization. However, it becomes unwieldy with all the before filter blocks, and the interaction between them isn't obvious, making maintenance challenging especially as you add more routes and actions. I've been working on declaring the authorization in a nested manner, similar to how we structure our routes. The goal is to make debugging, refactoring, and understanding the code easier. This lets our authorization blocks match closely to what we see in the routes, making it clear which authorizations correspond to which routes. If we need to change routing or authorization, those changes take place in the same context. To develop this further, I looked into how CanCan works. Learn Authorized adds a before filter that utilizes a controller's resource class, often the CanCan Controller Resource. This method automatically loads and authorizes resources. When you yield into a block, that code only executes if the resource was successfully loaded. This process simplifies our code. Because this is instance code within your controller, whenever there's an access denied exception, you know exactly where in your code it occurred, making debugging efficient. In practice, I’m happy to report that this new structure has improved how my authorization processes work, allowing hierarchical definitions in line with our routing definitions.

00:15:17.760 Awesome! Next up, we have Andrew Harvey. Come on down, Andrew!

00:15:35.920 I wanted to talk to you a little bit about the Hub. I’ve seen many of you using it on your phones, which excites me. By the way, my name is Andrew Harvey, and I work for Ninefold as their technical community manager. The interesting thing about the Hub is that it’s not a Rails app, which piqued my interest from the start. I’d like to share why we built the Hub. Initially, we developed a conference Hub for RubyConf in Miami. It was our first attempt, and while it was fun, we realized we wanted to change how we sponsor conferences. We aimed to contribute to conferences in a tangible way instead of just providing financial support, which we still do. Version one was interesting, but we found issues with it, leading us to develop version two for Sydney, which we feel is much better and more responsive. I want to talk about how we built it, powered by Middleman. How many of you have heard of Middleman? Great! It’s a fantastic static site generator. People often compare it to Jekyll, but Middleman offers many of the conveniences of a Rails app without actually being a Rails app. You have Sprockets to handle Sass, Less, or other assets, along with the asset pipeline style template. You can wrap Markdown templates in ERB, allowing the use of Rails helpers within Markdown or opt for Slim or Haml. What’s particularly powerful about Middleman is its concept of a sitemap, which allows you to create almost dynamic static sites by accessing and traversing all your content. This is driven through markdown files using front matter for metadata. For instance, a page for a talk or speaker uses their respective content. I’ll share some code tricks with you, and the Hub is open-source, so you can explore it.

00:17:56.000 Here’s the first trick: we manipulate the sitemap to add functionality to different pieces of content. For example, if it’s stored in the speakers directory, it recognizes it as a speaker file with specific behaviors. This approach provides convenience methods and model object capabilities, making it easier to manage. We also compose finders, resembling arrow syntax, to scope our queries effectively. For instance, if it’s Friday, we can retrieve all talks scheduled for that day, simplifying view management. In the past, I dealt with chaining calls through metadata hashes, but with these enhancements, our query handling is organized and cleaner. The Hub has proven to be an exciting project for us, embracing Middleman allows for a more manageable code structure. It’s open-source so you can hack on it and discover just how fun using Middleman can be!

00:22:17.679 Awesome! Lastly, we have Beth. The stage is yours! Hi, my name is Beth, and I work for DS, currently out at realestate.com. To avoid monolithic software, ARIA has opted to write small focus services, commonly known as microservices. Microservices are beneficial because they help break up code into manageable segments that are easy to maintain, upgrade, replace, and refactor. However, the downside is an increased number of integration points. Does this mean we need to write extensive integration tests? We appreciate integration tests as they assure us that all parts of our system function correctly together, but they’re slow and have lots of setup. When they fail, it's hard to diagnose the issue. Is there a better alternative? A smart team at REA wrote a gem called Pact, based on consumer-driven contracts, which blends unit testing with integration testing. We're breaking our integration testing into two parts: the service consumer, which makes HTTP requests, and the service provider, which provides the HTTP response. In our consumer code, we mock the provider, similar to WebMock. We can check our consumer's behavior against expected responses, but until we validate against the real provider, we can’t guarantee our assumptions are correct.

00:26:12.159 Compared to WebMock, Pact allows us to record interactions while running the consumer tests, creating what’s known as a pact file. We then replay these interactions against the provider code to ensure the responses match our expectations. A feature called provider states enables us to set up fixtures for various responses like 200, 404, empty lists, or nulls. Testing with Pact is quick and reliable, with low setup requirements. When something goes wrong, debugging is simpler since you're only testing one part at a time. You don’t need additional infrastructure to get started, making it easy to integrate with CI/CD pipelines. Using Pact means you're also designing your APIs with foresight, thinking about the best way to expose your data consumption rather than just retrieving data from a database. In our projects at REA, we've used Pact for about a year with great success. Our CI builds span multiple microservices, and if we had to do traditional integration testing, it would be exceedingly difficult. We appreciate Pact's efficiency and the ability to test interactions without complicated setups. If you want to learn more, feel free to reach out to me after the session.

00:31:05.600 Now, last but not least, Mr. Ryan. You don’t need to clap; go ahead, clap! I love you too, Ryan! So today, I’m here to discuss which CI server you should use. My recommendation is Travis. It’s a great starting point for CI servers, especially for simple projects needing to run across multiple Ruby versions or database systems. The main guy from Travis is right here—Josh! If you have any Travis-specific questions, please ask him, not me!

00:31:18.740 While there are great things about Travis, it has some downsides, too. For instance, we sometimes encounter randomly failing builds on Spree. Some builds fail while others pass with the same part of the code, which can be tough to debug without access to the server.

00:31:26.480 The good news is that Josh is part of the Travis team, and we really appreciate that. Setting up Travis is easy; you just need a .travis.yml file in your project and a few scripts, and you can get your code running on Travis by pushing to GitHub.

00:31:35.600 Travis also offers PR testing, automatically running tests on pull requests, which is a fantastic feature. We've switched to TeamCity from Travis due to some indeterminate build failures. With TeamCity, you have access to run builds and view logs directly, allowing greater control over debugging.

00:31:50.320 Unfortunately, TeamCity has a very confusing interface that requires a lot of clicking. Furthermore, if you want to run more than 20 build configurations, it can become quite expensive, with licenses around $600 per year. However, if you're working on an open-source project, they do offer a free license.

00:32:07.440 Being an open-source project makes Team City worthwhile, and because you can control its architecture, you can run it on your hardware. In our experience, builds have run up to three times faster on TeamCity compared to Travis. So, to summarize: you should probably start with Travis, but also consider TeamCity based on your needs. Thank you!

RubyConf AU 2014