Ruby
Lightning Talks
Summarized using AI

Lightning Talks

by Sarah Mei, Marlena Compton, Andrew Cantino, Enrique Morellón, Layne McNish, Yehuda Katz, Conrad Irwin, Aarti Parikh, Brian Leonard, and Josh Susser

The video showcases a series of lightning talks presented at GoGaRuCo 2014, focusing on various topics related to Ruby and programming practices. The speakers share their insights and experiences, emphasizing the importance of effective bug tracking, community feedback, and innovative tools in enhancing developer productivity and skills.

Key Points Discussed:

  • Effective Bug Reporting: Andrew Cantino discusses the importance of creating clear, concise bug titles and descriptions. He stresses the need for scannable titles and detailed steps to reproduce bugs, as well as the significance of differentiating expected vs. actual results. He recommends including relevant screenshots and environmental details to enhance clarity in bug reports.

  • Introduction to Hugin: Andrew introduces Hugin, an open-source system for creating automated agents similar to IFTTT but allowing users to maintain control over their data. He explains its various applications, from emergency alerts to monitoring web content and integrating different systems using Ruby.

  • Feedback in Development: Enrique Montgomery reflects on the value of constructive feedback in programming, describing his experiences with assertive communication. He advocates for positive reinforcement and the importance of clarifying discussions through questions.

  • ObjectSpace in Ruby: Layne McNish explains the ObjectSpace module, which aids in managing memory through garbage collection in Ruby. He highlights its features, including traversing live objects and performing actions during memory deallocation.

  • Advocacy for Ruby: Yehuda Katz emphasizes the need to defend Ruby against criticism, particularly regarding its performance improvements over the years. He encourages the community to acknowledge Ruby’s advancements and contribute positively to discussions about its capabilities.

  • Logging with console.log: Conrad Irwin presents a new gem, console.log, which allows Ruby developers to log information directly to the browser console for easier debugging, enhancing the debugging experience without sifting through Rails logs.

  • Learning through Exorcism: Aarti Parikh introduces Exorcism, a platform for developers to enhance their coding skills across multiple languages through hands-on practice and community feedback, aimed at learning without the pressure of their own projects.

  • Geohashing: Brian Leonard shares his recent discovery of geohashing, a method of encoding geographic coordinates. He explains its utility in location-based services and the importance of understanding proximity through shared hash characters.

  • Creation Myth of GoGaRuCo: Josh Susser shares his motivational journey behind establishing the GoGaRuCo conference, aiming to provide a community-driven alternative to existing Ruby conferences, encouraging new leadership for future events.

Conclusions:

The lightning talks not only cover valuable technical insights and innovative approaches to programming and community engagement but also foster a collaborative spirit among developers. Community support, constructive feedback, and knowledge sharing are emphasized as vital components in the development landscape, encouraging continuous learning and improvement among Ruby enthusiasts.

Overall, the conference serves as a reminder of the collective effort that drives Ruby’s progress and the importance of community involvement in advancing the tech landscape.

00:00:13.519 Today, I would like everyone in the audience to consider the common experience we all have with fixing bugs. If you're a good developer, you regularly review your app and encounter bugs. Think back to a time when you have had to fix a bug that was not very descriptive. Often, it might look something like this.
00:00:41.040 While that bug description may not be very helpful, it’s possible that someone added more information in the description. Let's take a closer look at that. The first thing I want to do is give the bug a clear, scannable title. When someone sees this title, they should immediately have a good understanding of what is going on. Bug titles can persist for a long time in whatever issue tracker you’re using, so it's worth spending some time on this.
00:01:10.720 If you know a bit about the environment related to the bug, it would be beneficial to include that information as well. Now that we've got the title fixed up, let’s move on to the description. As was mentioned before in the talk about the scientific method, it's essential to work through steps to reproduce the bug. This serves two purposes: firstly, it helps communicate a shared understanding of what you observed to the person who will fix this bug, and secondly, it allows you to think through the steps you took to reproduce the bug.
00:01:29.520 Sometimes, you won’t be able to replicate the bug accurately, or there could be variations from what you initially thought. It's crucial that the next person has a clear idea of what they need to do. The next addition I want to make is a distinction between expected and actual results. This is significant because it might highlight gaps in the requirements, or it could clarify situations where the bug may not actually indicate a failure but is rather confusing for the user.
00:02:01.119 Separating out these two perspectives—what you expected to happen and what you actually observed—can be very helpful. We’re progressing well with this bug report. The next thing I usually like to incorporate is a screenshot. While screenshots are beneficial, you still need to provide the steps to reproduce the bug and a good title. I've noticed a common trend where screenshots are often used inadequately.
00:02:44.720 In this screenshot, you have more context about what you observed. For instance, it’s helpful to specify the browser used, since users often forget to include that information. You can even show specific details such as the URL and whether you opened the web inspector to check the console. I recommend everyone consider doing this the next time they need to report a bug.
00:03:29.120 Thank you. I’m Andrew, and I work at a company called Mavenlink. Today, I’m going to talk to you about Hugin, which is not related to Mavenlink. Hugin, spelled H-U-G-I-N-N, is an open-source system for building automated personal or business agents. It’s somewhat similar to If This Then That (IFTTT) or Yahoo Pipes, except you run it yourself, so there’s no risk of the service disappearing, and you retain control over your data.
00:04:00.599 Hugin is named after Hugin and Munin, two ravens belonging to the Norse god Odin. These ravens flew across the world, reporting back everything they observed. Similarly, Hugin flies across the web and reports information back to you. It’s an open-source project that I've been developing over the last two years, initially created to meet a personal need. It has received nearly 8,000 stars on GitHub, which is astonishing to me, as I never expected to maintain a project with such widespread interest.
00:04:46.560 People are using Hugin for various applications, such as alerting them when there’s an emergency by sending a text or email, monitoring sites without RSS feeds, keeping an eye on local events, tracking music venues, and searching Twitter for travel or weather alerts. It has also been useful in business settings. For example, the New York Times Interactive Team utilized it to monitor their Olympic coverage, ensuring that their systems emitted the correct alerts when medals were awarded.
00:05:57.600 I know a DJ who uses Hugin to watch for new music and receive digest emails. Another person monitors New York Times public data releases, getting notified via email whenever a new dataset is published. Essentially, if there’s information you want to know about but don’t want to check daily, Hugin can notify you when something interesting occurs. Additionally, it can help you tie different systems together, such as sending a HipChat message when a new Basecamp project starts or monitoring the status of expense reports in an internal system.
00:06:32.400 With Hugin, agents are written in Ruby and function as simple Ruby classes with specific purposes. They have memory, configurable options, and can emit and receive events that flow in a directed graph, allowing you to connect different agents to create a more complex system. Coding in Ruby makes this straightforward. You derive your custom agents from the base agent class, define their properties, write descriptions in Markdown, and have methods that receive events.
00:07:05.320 For instance, let’s say you want to remind yourself to take an umbrella if it’s going to rain tomorrow. You would create a new weather agent, provide your location, and utilize an external API to check the forecast. Then, you would set up a trigger agent that looks for specific conditions through the JSON data returned from the weather API. If the conditions indicate rain, the agent could send you an email at a designated time, say 5 a.m. However, it’s important to check your email to ensure you receive those reminders.
00:08:06.560 Here’s another quick example—consider setting up an alert using Twitter. Treat the Twitter API like a universal API. By consuming Hugin’s machine learning capabilities, you can watch for significant spikes in data trends. This functionality emits an account every few seconds, capturing any relevant tweets. The data is then processed by a peak detector agent that identifies significant deviations, and when it detects them, it sends out a digest email.
00:08:32.960 Thus, when there’s a notable occurrence, like a popular article in machine learning, you'll receive an email prompting you to check the topic. Additionally, you can track real-time events like a fire that occurs nearby, tapping into this functionality. There are various integrations, including SMS notifications, sentiment analysis, and even tracking your location. While you might not know what to do with this location data, it’s intriguing and possesses value that you might want to keep private.
00:09:43.760 Lastly, I invite you to join us at Mavenlink, where we emphasize extreme pairing. Thank you.
00:10:16.880 Four minutes exactly! Andrew gets the prize for precision today. Next up, we have Enrique Montgomery.
00:10:21.600 Hello! I've had great experiences receiving feedback within the Ruby community, be it through wild pair programming or in pull request reviews. However, I also had a challenging experience in a C# project. During my first code review, I received some harsh feedback during a call. I was contracting from Mexico, and while I was on the phone with the manager and a senior engineer, he bluntly told me, 'There is the right way to do it and the stupid way to do it, and this is not the right way.' At first, I felt offended by the term 'stupid'.
00:10:56.720 However, I later realized he was merely discussing my code. I responded cheekily, 'Yeah, that's just to keep you awake,' which prompted him to admit he was tired from working late. Negative feedback can be tough, but I believe it’s crucial that we provide positive feedback as well. Positive reinforcement is essential because we tend to make better decisions and feel better when we receive it.
00:11:29.680 Additionally, incorporating an assertive approach in our feedback helps. There’s no need to be aggressive; what’s essential is to express your ideas clearly while respecting differing opinions. I find that the best way to be assertive is by asking questions. Posing questions like, 'How do you feel about trying this differently?' or 'Why did you approach it this way?' encourages dialogue and learning.
00:12:02.560 If you’re on the other side of that feedback, it’s important to remember the Rails Bridge way: assume the other person has certain knowledge but infinite intelligence. This mindset will foster productive conversation. So, let’s maintain a positive attitude, be assertive in our discussions, and continue to engage with one another. And by the way, how awesome is this conference?
00:12:55.680 Thank you. Next up, we have Layne McNish.
00:13:05.040 Hey, I'm Layne. This is my first conference, and I'm from Denver. So, what is ObjectSpace? In the past, I was a cellist, and then I transitioned to working in tech. Now, I’m here talking about ObjectSpace in Ruby.
00:13:43.840 The ObjectSpace module in Ruby contains routines for interacting with the garbage collection facility. It allows you to traverse live objects using an iterator. ObjectSpace also offers support for object finalizers—procs that are called when a specific object is about to be destroyed by garbage collection.
00:14:00.960 But why do we need garbage collectors? A garbage collector manages memory in languages with managed memory. Its primary function is to determine when a piece of memory has been allocated and is no longer needed. Keeping track of this is crucial when using a language with garbage collection because there might be actions you want to perform whenever a piece of memory is freed.
00:14:33.920 ObjectSpace provides us with the ability to do things like count instances of a class that are currently using memory, or count instances across all classes. One advantage of dynamic languages like Ruby is their introspection capability, which allows examining aspects of a program from within the program itself. This can help us discover what objects exist at runtime, the current class hierarchy, and the behaviors of objects.
00:15:05.600 For example, you could check how many coffees I've had today, what type of beverage it is, what it inherits from, and consider what you might want to add to it—perhaps if you signed up for a last-minute lightning talk, you might want to add some alcohol to it.
00:15:32.640 That’s all for me, thank you.
00:15:42.240 Next up, we have Yehuda Katz, who will present without slides.
00:15:53.440 I often work in areas outside of the Ruby community. While I write a lot of Ruby code, I’m also involved in communities like Rust and JavaScript. I appreciate the Ruby community and find many of its practices interesting and useful.
00:16:16.960 I often cite Ruby examples within other ecosystems, aiming to encourage others to consider good ideas from the Ruby community. Unfortunately, laughter is a typical response I encounter, which is unfortunate because historically, Ruby’s implementation has not been viewed favorably.
00:16:54.720 Bloggers have criticized Ruby's implementation harshly, describing it as a 'pile of rubbish.' This negativity can influence discussions around standards, making it challenging for me when trying to advocate for Ruby's capabilities in broader contexts.
00:17:15.760 One reason for this negativity is that the Ruby implementation was developed by individuals whose primary language is not English. As a result, when Ruby is criticized, there are often no responses or defenses from its creators. I believe this silence is detrimental, especially when Ruby has seen significant improvements, particularly in its garbage collector.
00:17:54.320 We should defend Ruby and its community, highlighting the progress made. Ruby now features a generational garbage collector with incremental mark-and-sweep capabilities, improving performance significantly. I believe we need to spread positivity about the Ruby implementation and acknowledge the contributions of its developers.
00:18:35.760 In recent benchmarks, Ruby reliably outperforms Python, demonstrating its evolution. Let’s avoid self-deprecation and instead support those who work hard to improve Ruby. If you observe negativity towards Ruby's implementation, please consider speaking up in defense of the community.
00:19:24.720 Thank you.
00:19:30.880 Next, we have Conrad Irwin.
00:19:39.680 Hi, I’m Conrad, and I work for Bucksnag and on Pry. Today, I want to introduce a new gem I created called console.log, which allows you to log directly from your Ruby code.
00:20:05.680 On a recent project, I was tasked with implementing a feature for users to change their email addresses. I realized something was wrong when my Rails logs indicated an empty email address. This raised a red flag because I knew the user had an email.
00:20:34.560 I wondered how to identify the issue using the scientific method, so I opened the user's controller to debug. During this process, I found it tedious to add numerous lines of code just to view the logs after refreshing the page.
00:20:54.480 This is where console.log comes in—it functions like puts but sends output to the browser console instead of Rails logs. When you refresh the page, it directly displays the user object in console.log, eliminating the need to sift through extensive Rails log entries.
00:21:22.760 Thank you very much. Next, we have Aarti Parikh talking about Exorcism.
00:21:37.920 Hello, I'm Aarti Parikh. Today, I'd like to introduce you to Exorcism. As a developer, I typically work with two to three languages, including JavaScript, Ruby, and Lua, as I create both web and iOS applications.
00:22:23.760 As mentioned by Sarah Allen earlier, developers often select frameworks for the functionality they provide rather than the languages themselves. I found Exorcism to be an excellent resource for deepening my knowledge of programming languages apart from the respective frameworks.
00:22:54.080 Exorcism, created by Katrina Owen, offers various exercises in different languages. It helps you set up your environment from scratch and enables you to write expressive code while incorporating feedback from other developers using the platform.
00:23:22.000 In my solo projects, receiving feedback is invaluable, allowing me to learn from my mistakes and improve my skills. I appreciate the thoughtful and lengthy feedback I've received from others on my JavaScript projects.
00:23:37.760 Exorcism provides a platform where you can go, enhance your coding abilities, and separate your learning from your own projects. You are presented with problems to solve, and the unit tests are prepared for you, allowing you to focus solely on implementing solutions without the overhead of generating good questions to practice.
00:23:56.160 As you work through these problems on the command line, you can submit your solutions directly. This structure offers a practical way to learn, and I encourage you to explore it if you're looking for effective learning resources.
00:24:18.560 Thank you for listening. Next, we have Brian Leonard who will discuss geohashing.
00:24:26.720 Hi, I'm Brian Leonard, and I'm excited to share something I learned recently called geohashing. I discovered it only a few weeks ago and thought it was fascinating enough to share.
00:25:00.080 I work for TaskRabbit, and our company focuses on connecting people with local tasks, which means understanding the location of where these jobs need to be completed is crucial. We gather information from taskers who indicate where they want to work, often drawing a map that may be a bit unconventional.
00:25:36.160 In analyzing this data, I found that heat maps are beneficial visualizations, but they don’t provide actionable insights. Thus, I sought a method to quantify and evaluate the locations effectively, which led me to learn about geohashing.
00:26:02.160 Geohashing encodes latitude and longitude information into a concise string format. The process involves continually dividing the geographical area in half until it creates a unique hash representation for the coordinates. This string can effectively represent proximity; geohashes matching at the initial characters indicate closeness.
00:26:49.760 For context, if two locations share the same starting position in the geohash, they are geographically near each other, quantifiable to specific meters apart. This characteristic is very handy when managing dozens of taskers and their respective locations.
00:27:17.760 An interesting usage of geohashing is within Elasticsearch, which serves as a powerful tool for location-based comparisons. However, there are caveats: if two spots differ significantly right from the beginning of their hashes, the proximity measures can become misleading. Finding strategies to mitigate this is an important aspect of using geohashing effectively.
00:27:51.440 Thank you for your attention, and I appreciate the opportunity to present this.
00:28:08.480 Next, our final lightning talk features a very special guest: Josh Susser. I have never spoken at GoGaRuCo before, but Sarah insisted I share my story. I apologize for reading my talk, but I want to ensure I present it accurately.
00:29:11.160 Two years ago, Sarah May shared a creation myth of Ruby with us. Today, I would like to share the creation myth of GoGaRuCo. Like any epic tale, this one begins with an injustice.
00:29:31.160 There once was another Ruby conference in the Bay Area that started strong. However, after its first year, it seemed to devolve into a fundraising tool for its hosting organization, contributing little to the community. This made me upset, and when I become angry, I tend to channel that energy into action.
00:30:15.160 In this case, I rashly decided to establish another conference that would better serve our community needs: the GoGaRuCo conference. The backlash on Twitter from those who dubbed me a 'conference killer' only fueled my resolve. However, I didn’t think I was in the wrong; competition is normal, and poor businesses should be replaced by better ones.
00:30:53.760 I had faith in my ability to create a strong technical program, but I lacked experience with the business side of running a conference. After a year of struggles, I mentioned this to Yehuda Katz, who suggested I meet Leia. Shortly after, Leia and I found ourselves talking over coffee about how we could organize the conference of our dreams.
00:31:28.600 Leia was immensely passionate about conferences and quickly became the perfect partner to work alongside. As we began to grow, we realized we needed a larger team, and that's when Jim came into the picture. He was responsible for an excellent startup crawl event at RubyConf SFO, and we invited him to collaborate with GoGaRuCo. Jim's experience and enthusiasm were invaluable.
00:32:24.840 Our only goal was to elevate the standard for Ruby conferences, striving to set an example that other conferences would aspire to follow. While we may have appeared arrogant, we've managed to create an excellent conference experience.
00:32:55.840 I don’t say this to brag, but rather to remind everyone that this conference is built on the community's effort. Yes, we may be on stage right now, but all of you are what made this possible. This isn’t just about our work; it’s about the community rallying together.
00:33:17.840 While we’ve enjoyed this journey, it has now reached a point where we feel it’s time to step back. After giving it our all, we believe it's time for the next set of leaders in the community to take charge. We hope the community continues to thrive.
00:33:35.680 We’re grateful for the opportunity to serve our community at this level. Although we weren’t financially compensated, the privilege to support our community remains unmatched. Thank you all for being here with us, and we look forward to seeing the new leaders moving forward.
00:33:55.360 Okay, let's take a break now.
Explore all talks recorded at GoGaRuCo 2014
+14