00:00:18.439
We all know how to build web applications. Most of us can build command line applications, but what about user interfaces? Who here knows how to do that?
00:00:25.800
Not too many people, I see. This presentation is about Shoes. Steve touched on the topic a bit earlier and mentioned that we are live and working on it.
00:00:32.800
Usually, when I talk to people in the Ruby community and tell them I'm working on Shoes, they respond with surprise. They assume it's outdated. I looked at the web page, and while it's old, I'm here to clarify that it's not dead. We’ve recently updated our webpage, and Steve mentioned that we replaced APR card with noi, which is a significant improvement.
00:01:06.199
For those of you who don’t know, I love Shoes. I’ve been trying to get into GUI programming ever since I started coding. Other frameworks often frustrated me. It took forever to get a simple window with a button, and I found that incredibly tedious. With Shoes, you can build user interfaces more intuitively and efficiently.
00:01:29.040
Let’s take a look at what you can do with Shoes. For instance, you can build a little tank game; I included it in the examples directory. I also wrote a Twitter client in Shoes, and you can create a music player as well.
00:01:36.560
Moreover, there’s Hack, which is designed to teach children how to program. It’s a fantastic resource! Here are some simple code examples: you can create a button that, when clicked, shows a popup message saying, 'Good job!'
00:01:49.840
Another straightforward example allows you to use an image as a clickable link to a URL. In typical Java or Qt, this would require many lines of code, including fetching the picture and embedding it. However, in Shoes, it’s significantly easier—just a few lines. You can also create gradients in one line instead of dealing with multiple objects.
00:02:24.120
People often get confused by the various color options available in Shoes. Currently, you should use 'red shoes' for official downloads. We're working on a new version called 'Sho far', aiming to unify all implementations together and simplify our backend structure.
00:02:49.840
We've made the backend pluggable, allowing for multiple backend systems in the future. We're implementing test-driven development, and by 'plug backend,' I mean we have a consistent domain layer with methods like 'alert' and 'button.' This flexibility allows us to instantiate various backend implementations.
00:03:12.240
Thanks to the structured backend, we're currently using SWT, but we could easily extend functionality to support Qt, GTK, or even Android. Now, let me show you a quick demo. I'm in the Shoes repository. If you wish, you can check it out. I’ve built a task that runs various simple examples. Here’s a basic one just to demonstrate.
00:04:02.319
Let’s see what else is available. We have some interesting implementations here. There’s an actual working hotel game; however, some of these examples do require a bit of time to show results. Here’s a digital clock we’ve coded in.
00:04:09.879
Okay, I’m running out of time, so I encourage you to try running these examples at home and report any issues that you encounter. For further information, visit shoes.rb.com, join our mailing list, or follow us on Twitter and GitHub.
00:04:45.240
Now I want to shift gears to something light-hearted yet serious: my lighting talk, titled 'Active Model Serializers.' First off, Ruby conventions. It’s encouraging that conferences like these support shared learning, particularly about Rails. Because of Rails' conventions, we can work efficiently, making collective decisions that streamline our processes.
00:05:01.320
This principle of convention is evident everywhere in Rails. Between routes, models, and controllers, Rails uses conventions for pluralization and directory structures. I want to touch quickly on APIs and JSON, specifically what Omas is. As of Rails 4, if you build a new application, you’ll get the Jbuilder gem, which allows you to build JSON APIs seamlessly.
00:05:42.360
Jbuilder lets you define how JSON should look, utilizing a Domain-Specific Language to accomplish this efficiently. However, while Jbuilder is powerful, it isn’t convention-driven, which I believe is crucial. On that note, I’d like to contrast it with active model serializers, which I’ve been maintaining. Active model serializers are beneficial because they allow you to create a structured path for API responses.
00:06:11.760
When you define a serializer, you specify exactly what attributes to include, and it simplifies the rendering of your models into JSON. These serializers can also handle associations, meaning if you have comments associated with a post, they can be included seamlessly. It reduces repetition, making it easier to maintain and read your code.
00:07:01.000
One of the awesome features is that it allows for nested attributes, so you can expose just comment IDs without constantly embedding the full comment objects. This approach helps keep your JSON response clean and prevents unnecessary data duplication. As this library matures, we are also working to ensure it integrates well with Ember and other JavaScript frameworks.
00:07:51.360
To summarize, leveraging active model serializers can provide a fast and efficient way to handle JSON in your applications while still making it easy to maintain and expand. If you want to try it, make sure to grab the latest version from GitHub, as I plan to release updated features shortly.
00:08:49.200
I’d like everyone to envision how this could integrate into Rails seamlessly and ignore the prior templates that Jbuilder has provided, as this is a better solution. Thank you all for your attention.
00:09:07.920
Next up, I’d like to introduce our next speaker. He has a talk titled 'Don’t R and I.' He enjoys red and has some personal feelings to share about it. Let’s give him a warm welcome.
00:09:25.320
So without further ado, I present someone who’s passionate about Redis and is going to tell us about his experience using it. Please share your stories!
00:10:21.999
Thank you for that warm welcome. So today I want to discuss my experience with Redis. I love it; it’s fast, cool, and a fantastic tool I use in my daily work. However, there's one specific scenario where I would caution against using Redis. Let me explain this through an example of an application I worked on.
00:11:42.000
Imagine an application handling significant web traffic and performing extensive data crunching, relying on MySQL for database interactions. To ensure that the application remained responsive, I decided to implement some background processing. After researching recommendations, I settled on using Resque and Sidekiq since they’re well-regarded for such tasks.
00:12:57.240
Initially, everything functioned well. The application was running smoothly. However, without warning, I encountered a problem when my client’s logs indicated that the workers could not do any processing for over 40 hours due to connectivity issues with the database. This was a nightmare scenario.
00:14:11.239
Consequently, Redis went into an unexpected memory consumption spree, which caused significant performance issues. As I tried to resolve this crisis, I felt overwhelmed, and things escalated quickly. My colleague relayed the urgency of the situation at an ungodly hour, stating that we were on the brink of failure.
00:15:36.520
In a panic, I made some rash decisions, including scaling our worker instances, but this was not an easy fix and came with consequences. Thankfully, when we finally restored connectivity to our database, our workers could resume processing. However, the ordeal was a valuable lesson in using Redis under pressure.
00:16:08.240
So, do I think that using Redis for queueing is a good practice? No. Instead, I recommend exploring alternatives like Beanstalk, which I’ve used with mixed results under heavy loads. Ultimately, I pivoted to a task queuing system based on RabbitMQ called Celery, which has proven to be more reliable.
00:16:47.560
This system has been a game changer for my applications. I encourage anyone who shares my experiences with Redis to reach out because the goal remains the same: we want to be effective developers, and RabbitMQ has provided a solid path for managing background tasks effectively.
00:18:05.040
In conclusion, every time I find myself considering Redis, I shift my mindset to think about RabbitMQ instead. Thank you all for listening, and I hope this encourages you to explore options beyond Redis.
00:19:00.239
Next, we have Norbert, who will talk about the dependency inversion principle, emphasizing the importance of single responsibility in our codebase. Let's welcome him!
00:19:59.999
Hello everyone, my name is Norbert, and I'm thrilled to be here. I’m going to elaborate on the principle of dependency inversion, a favorite of mine. We need to build systems composed of small, independent objects focused on single responsibilities.
00:21:00.080
The problem arises when we find ourselves with a network of these objects. In Ruby, the conventional method is to link them statically, which leads to challenges when managing dependencies. For example, consider a Twitter class that uses an HTTP client to post messages.
00:21:45.879
In this model, we expose a static interface to link dependencies, which can become cumbersome. Instead, adopting dependency inversion means we rely on abstractions, which enhances flexibility and maintainability.
00:22:18.559
This way, we can easily change implementations without affecting the business logic of our application. The clarity and organization this brings allows us to keep focus where it matters most.
00:22:58.240
Static interfaces can lead to duplication as the logic becomes scattered throughout your code. Instead, by using an injector pattern, we simplify the arrangement of dependencies, which significantly improves testability and overall structure.
00:24:18.579
By leveraging the power of dependency injection, you can ensure that the components only interact with abstractions, promoting a decentralized management process that clarifies your architecture while reducing boilerplate.
00:25:00.999
In production, this pattern has allowed us to operate smoothly, and I've seen excellent results from it. If you'd like to discuss this further or explore practical implementations, let's connect after the talk.
00:25:51.120
Now, I’d like to introduce our next speaker, who’s been known for facilitating productive discussions. His approach emphasizes the community impact we can achieve when we collaborate more than we compete.
00:26:25.920
He’s particularly passionate about creating an efficient workflow in the Ruby community. Let's give him a warm round of applause!
00:27:28.920
Thank you, everyone. My name is Hubert, and I appreciate you all being here. I want to talk about several principles that can elevate our coding practices and enhance our collaboration within the Ruby community.
00:28:21.070
The core ideas involve creating clear, readable code and eliminating redundancy across our codebases—also known as the DRY principle. As we continue to build innovative solutions, I urge you to think about the implications of poor readability and how it can hinder our progress.
00:29:49.360
By adopting a declarative style, we foster an environment that encourages best practices, ultimately leading us toward more maintainable and cleaner lines of code. Let’s strive to find ways that allow our applications to communicate effectively, leading to less confusion and improving overall efficiency.
00:31:30.520
I can assure you that employing these strategies will enhance our community output. Just consider the rippling effects of cleaner code and effective practices—focus on improvement, and we can collectively foster a stronger community.
00:32:50.999
In closing, I want to encourage you all to pursue the principles I’ve mentioned. That way, as we share knowledge and perspectives, we can continue to grow both personally and as a community.
00:34:12.999
Thank you for this opportunity! I’d love to engage more with everyone afterwards, so feel free to approach me. Our community is only as strong as our conversations and cooperation!
00:35:19.920
Just before I conclude, I’d like to highlight a new feature about RVM that’s on the horizon. This isn’t in the stable version yet, but I’m hopeful everyone will appreciate what’s coming down the line.
00:36:35.999
With RVM, we’re switching to using package managers for Ruby installations, rather than integrating packages internally. This will streamline installations and improve overall experiences for developers. I'm looking for feedback on these updates as we move forward. Thank you.
00:39:00.999
This has been an awesome conference, and I appreciate all of you being here. Let’s keep pushing the boundaries of our programming practices, and I look forward to what we can accomplish together in the future.
