Lightning Talks

by Michael Hartl, David Bock, Benjamin Fleischer, Steve Downie, Reid Morrison, Randy Coulman, Billy Watson, Ray Hightower, Clayton Flesher, Devin Clark, Scott Mascar, Paul Dawson, Miki Rezentes, Jordan Bach, Nat Budin, Rick Carlino, Ratnadeep Deshmane, Craig Buchek, Loraine Kanervisto, and Britni Alexander

Summary of Lightning Talks at RubyConf 2015

The video titled 'Lightning Talks' features a series of short presentations from various speakers at RubyConf 2015. Each speaker shares insights on different topics within the realm of programming and development, emphasizing hands-on experience and community contribution.

Overall, the series of talks emphasizes collaboration, practical solutions to common challenges in programming, and the importance of community-driven initiatives.

Takeaways

Collaboration and community are essential in programming and technology development.
Open-source principles can drive business innovation and community engagement.
Continuous improvement and learning are vital for both junior and experienced developers.
Realistic expectations in technology projects enhance the likelihood of success.

00:00:16 Hello, my name is Michael Hartl. You may know me as the author of the Ruby on Rails Tutorial. I have two things to mention. One of the things I'm working on is a series of prerequisite tutorials under the brand 'Learn Enough to be Dangerous.' I am starting with 'Learn Enough Command Line to be Dangerous.' I am looking for newbies to help me work on this series of prerequisites leading up to the Ruby on Rails tutorial. The second thing is that if you are an expert on any technical subject, I'm looking for people to collaborate with under the 'Learn Enough to be Dangerous' brand. Examples include 'Learn Enough Vim to be Dangerous' and 'Learn Enough iOS to be Dangerous.' If you have ideas for tutorials, please reach out to me. I’m also interested in possibly writing a full Ruby tutorial at some point, but that's a huge project and I’m looking for someone to collaborate with. If any of this piques your interest, you can contact me at Michaelhartl.com. Thank you.

00:01:20 Any other takers? One-minute talks usually get one or two people. Come on up, you're on the list, right?

00:01:43 Hi, I'm David Bock. I also will be speaking tomorrow. This talk was originally a seven-minute Toastmasters speech, so I'm going to try to condense it into one minute. In 1922, a woman in Massachusetts who ran a restaurant was making Butter Drop Do cookies. She ran out of cocoa and put in a chocolate bar, thinking it would melt. Instead, she accidentally invented the Toll House chocolate chip cookie recipe. In 1938, Andrew Nestle showed up and offered to buy the recipe from her for $10,000 and a lifetime supply of chocolate, which he then printed on bags of chocolate chips for free, causing every chocolate chip manufacturer to copy it. This is the original open-source idea. He open-sourced the chocolate chip cookie recipe because he was selling chocolate, not the recipe. By giving away the cookie recipe, he raised his bottom line for everyone selling chips. The main idea here is that you can use this story to convince management to open-source anything that is not critical for your business. Open-source to give back to the community; we all rely on it. Thank you.

00:02:54 Excellent, superb! In fact, I'm even going to pronounce your name correctly, David. Good job and such high praise! Any other volunteers?

00:03:18 Hello, I'm Benjamin Fleischer. I am a rubyist, which means I get paid to do Ruby, that's how I think of myself. I wanted to share two interesting things with you that I find fascinating. The first is about string encoding in Ruby. If you've ever had issues with string encoding, particularly if you lived through the dark days of Ruby 1.8, then things are much better now. However, I did some work on the arpe library to make handling strings easier. If you ever have problems with string encoding, you can simply install the 'encoded string' gem; problem solved. The other example I want to share involves a one-character deletion in Rails, and I can provide more examples if you're interested. If you go to my Speaker Deck page, you can find additional examples of my contributions. That's about all the time I have. Happy Monday!

00:05:00 Without further ado, if I didn't say this before, I will be mispronouncing everyone's name, and I apologize in advance. The next speaker is Steve Downie.

00:05:20 Hi, I’m Steve Downie. This is my ninth Ruby Conf and each year they seem to get bigger and better, thanks to the great folks that run it. I’ve written a web app called Tommy Talker that, with help from the open-source community, can serve as a complete universal translator. Currently, it supports 26 languages. When you choose a phrase, it appears linked in your chosen language, and when you click on it, it speaks in English. I haven't stress-tested the app yet, so I’m not sure what will happen if too many people log on at once, as it’s hosted on a single dedicated server. You might want to try it after the show, or during if you are feeling brave. When you access the site, the default language is English and there's a dropdown menu to select languages. It will translate into your chosen language upon selection.

00:06:40 I originally wrote this application as a touch-and-speak technology for my brother, who unfortunately has a chronic illness that is slowly causing him to lose his ability to speak. He knows a lot but won’t be able to form words. This application was designed for touch input so he could communicate easily. I owe many thanks to Robert Clem, who many of you know from the Ruby talk group, as he corrected the Google-translated German strings for me. I also collaborated with Simon, a member of the Paris Ruby User Group, who helped with the French translations. As of now, I still need recordings for the phrases in both French and German, as well as recordings in 23 other languages. If you speak multiple languages and can volunteer, I would love your help.

00:07:34 The project is open-sourced on GitHub; however, the MP3 data is not provided to keep the repo size manageable. I also have thousands of MP3 files stored at home that I can share directly. For the project, I created the source code which includes every line of coding and kept it updated. You don’t have to be a programming expert to contribute; if you know anyone who could help record audio with a microphone, that would also be fantastic. You’re welcome to reach out to me if someone you know would be interested.

00:08:30 Moving on, hello RubyConf San Antonio! Can everybody hear me? Excellent, it’s great to be back! We’re a large J-Ruby shop running a big production system, and I’d like to share our latest open-source project with you: RocketJob. Let’s dive straight into some code since we don’t have much time. We will create a simple job named 'MyJob' which inherits from the RocketJob base class, and we’ll implement a simple method called 'perform...'

00:09:15 The key highlight here is that creating the job is straightforward: use 'MyJob.create!'. You won’t have to deal with complex APIs like other systems. This process mirrors how you’d work with active record models. Once the job is created, you can add additional attributes. For example, we'll add a 'filename' attribute that defines the file type as string. Now, when creating this job, simply invoke 'MyJob.create!' with 'file_name: data.csv'.

00:09:40 Next, it's crucial to validate the job before execution. We do not want to run a job if the parameters haven’t been correctly validated at the outset. Regular validations can be applied, and they will fail if any parameters are incorrect. At the bottom of your log, you'll see error messages indicating where validations have failed. This makes it easy for the end-user creating the job to see clear failure messages instead of having to track through logs.

00:10:16 After that, it’s vital to keep track of your job status. Many of you have run jobs before and probably wondered what happened to their status. With RocketJob, you can easily check the job's state by using 'job.state' or 'job.reload.status'. The state will show you if it’s queued, running, or complete. This allows you to assess the job's current state without digging through complex records.

00:10:56 Another important element of job handling is getting back the results. When you send off a job to do some work, you want the results of that job without needing to store them somewhere else. RocketJob maintains a simple way of providing outputs so that once a job is created—be it a simple or complex job—you can easily track its state and results.

00:11:46 Let’s consider an additional example: what if you have a million line CSV file? In that case, you can create a CSV job, abstracting the workload across various workers to process the data efficiently. The jobs will process one line at a time in a scalable, distributed fashion.

00:12:15 The traditional way of tackling this would be cumbersome, but by leveraging RocketJob, you can define straightforward attributes and let the background workers execute these tasks simultaneously.

00:12:55 To kick off the upload job, you simply direct the job to take the CSV file, process the chunked lines collectively with a defined number of workers, and, when completed, the output can be fetched and downloaded again from the system. This whole process runs efficiently and aligns with enterprise features like data encryption for sensitive information.

00:13:35 This system is currently put into production for over a year, fully functional and well-tested, so please engage with us for any questions. You can join our GChat session for support regarding RocketJob.

00:14:05 Hello, everyone. I'm going to present some software engineering lessons from aviation, which I call 'Plane Programming'. My name is Billy Watson; I am the lead engineer at JD Power. I'm also a student pilot focusing on internet scale data.

00:14:40 In aviation, we follow immediate go-around protocols. The FAA dictates that anyone in the cockpit can call for a go-around; the pilot at the controls must immediately push the throttle and go around, period. This context translates to software development in that we need to ensure everyone can rectify problems as they occur.

00:15:24 In software, we have tools such as group code reviews and good method documentation for encouraging team members to fix problems early. In aviation, we have standard operating procedures (SOPs) that guide our actions. We can establish similar codes of conduct when working with software.

00:15:56 As we develop software, we engage in code review processes. We have instruments and checklists that help us ensure quality. I challenge every developer to back themselves up, as pilots do, by reviewing their work before pushing it. You’d be amazed at how this simple practice increases quality.

00:16:51 As developers, we should collectively establish flow checks where we monitor our instruments and our products in the development flow, ensuring we meet completion criteria before merging code. This saves efforts in fixing oversights that could become significant.

00:17:23 My name is Billy Watson. You can find me on Twitter as William R. Watson for any questions regarding aviation, software engineering, or the Dallas Cowboys.

00:18:08 Good afternoon, RubyConf! I’m here to discuss the challenges of Moore's Law and how we need to adapt to sustain our industry growth. Moore's Law stipulates that we double the transistor count on a silicon wafer every 18 months. However, this journey is reaching the end, and extracting performance from our systems will require a new approach.

00:18:55 We’re shifting toward parallelism, and I want to highlight a tiny device called Parallela. It’s a single-board computer, compact sizing and cost-effective—that runs Linux and has 18 cores. With this architecture, you can develop and execute programs more efficiently.

00:19:38 Now, let’s look into the practical functionality of Parallela. We can compute prime numbers between zero to 16 million in parallel with remarkable efficiency. These tests show substantial performance gains compared to conventional processing.

00:20:08 Regarding parallel processes, significant improvements can be observed—while traditional single-core execution takes much longer, the parallelized tasks are completed in mere seconds. This shift demonstrates the potential for wider applications using lower-cost machines that perform at levels previously only attainable with much pricier systems.

00:20:58 This process can serve as a key example of embarrassingly parallel problems, where dividing the work into smaller, manageable pieces allows for high-performing, efficient programming. You can learn more about utilizing parallel computing in your programs to extract the most out of your existing systems.

00:21:35 I applied my learning in developing my first Ruby application. My aim was to create something useful for myself and the community. After contemplating my options, I decided to leverage structs effectively to enhance data objects.

00:22:23 Many of us know the issues structs can cause; they allow optional arguments but lead to unexpected nil values. This is not ideal for creating rigid data structures. I also wanted to incorporate Ruby's keyword arguments which boost argument handling.

00:22:44 In looking to achieve these enhancements, I discovered that a good number of Rubyists have already ventured into crafting immutable data objects. They offer a clean solution but come with added complexity. Instead, I set out to create an alternative that would harness these benefits more naturally.

00:23:36 The objective is to ensure that the creation of these objects remains functional and flexible. I wished to add keyword arguments without the unnecessary complexity and improve extensibility. These methods fetch the expected behavior of a Ruby object while maintaining responsibility and flexibility.

00:24:32 I introduced a JSON method that outputs the object in a readable format for potential event usage with other developers. I'm eager for feedback so it can be improved further as I ramp up to make this my first library.

00:24:55 Thank you for listening! Now, the floor is yours.

00:25:32 My name is Devin Clark, and today I’m going to go over the differences between 3D printing and cooking a rotisserie chicken at home.

00:26:08 This analogy is exceptionally relatable, and the understanding of 3D printing warrants realistic expectations of output and processing time. So, I jumped into the world of 3D printing, hoping to craft a giant ruby figure for a unique conversation starter at RubyConf.

00:26:55 Throughout my journey, I’ve encountered numerous challenges that shed light on the truth behind 3D printing—namely that it is a slow and often delicate process.

00:27:13 This is particularly frustrating when parts break, as those components can also be hard to replace. An added layer of complexity arises when things refuse to stick to the print bed and fail partway through the process.

00:27:56 The common misconception of 3D printing being a 'set it and forget it' activity can lead to high expectations, but the truth is, it demands attention to detail and a patient approach to yield decent results. Each endeavor may result in failures before achieving success.

00:28:40 Thanks to the community, there are workshops available for those venturing into the world of 3D printing without the upfront cost of owning a device. Education can go a long way in ensuring newer makers are mindful of realistic budgets and the need for research on quality.

00:29:21 Communities often sprout across cities featuring tutorials and initiatives for beginners to share experiences and tools. I call out to those interested in exploring 3D printing to manage expectations and harness all the resources available.

00:30:10 This leads us to how we adopt newer methods in software and how treasured it is to understand their implications before diving headfirst. I’ll pause here and will gladly assist with any inquiries on practical applications or software projects in the 3D printing world.

00:31:22 Next up is our friend, Paul Dawson, who will share insights on problem approaches in software development.

00:32:11 Thank you. I would like to briefly talk about how the tools we use to approach problems affect the solutions we come up with. A struggle I had as a junior developer was figuring out where to start with my tests.

00:32:58 Initially, I found myself staring at the screen, unsure where to begin. As we grow as developers, we accumulate knowledge on where to break out abstractions and begin our test cases with greater ease.

00:33:44 Consider art classes where students are often instructed to flip their drawings upside down. This method breaks the preconceived notions of how a face should look, allowing clearer analysis of form. Similarly, we should aim to disassemble our tests by flipping the perspective while assessing outcomes.

00:34:15 Whenever starting a new project, consider diving into the UI interaction to help define what the backend needs. Avoid becoming trapped in building everything at once; take it step by step.

00:35:10 Sending messages to manage states simplifies feedback loops and enhances the development process. Rather than forcing everything into a single timeline, building iteratively cultivates a better understanding and approach.

00:35:54 Thank you for your time, and I hope we can all navigate through our journeys more effectively.

00:36:36 Hello everyone! My name is Mickey Rezentes, and I have spent 20 years teaching math and coaching high school sports. Transitioning to software engineering over the last three years brought two lenses to the onboarding of junior developers.

00:37:14 A strong onboarding process is crucial when not only conveying knowledge to young developers but facilitating their growth as they integrate into new environments. Key takeaways from traditional teaching can be leveraged to enhance onboarding.

00:37:50 From my experience as a teacher, it is pivotal to ensure that the instructor is equipped with knowledge but also a structured lesson plan to aid junior developers who may feel overwhelmed.

00:38:32 Avoid using heavy jargon or acronyms—the simpler the language, the more accessible the content becomes. You want to ease them into complex topics through familiar language to build their foundational understanding.

00:39:11 Fostering open communication is essential. Provide clear expectations so that junior developers know what to aim for while also ensuring there's a feedback mechanism in place. This avoids frustration and failure instances.

00:39:55 Finally, use structured processes to guide junior developers through peak lessons, offering clear checkpoints of progress. Ultimately, the aim is to nurture their growth and retention through community and support.

00:40:32 Thank you. I am Ratnadeep Deshmane, and I’m here to discuss Ruby Vernac—a programming language that is not in English.

00:41:13 The driving force behind creating this project stems from a desire to make programming more accessible. I stumbled into a challenge while teaching my younger brother Ruby programming; the English keywords posed a barrier to his understanding.

00:41:51 This led to my understanding that presenting programming in native languages could significantly enhance comprehension. The project aims to enable Ruby code to be written in various spoken languages, eliminating the English-only barrier.

00:42:24 Ruby support for UTF-8 makes it feasible to create this bridge, where concepts resonate better when presented in familiar terms. For example, keywords in programming can be translated into meaningful synonyms that carry the same functional weight.

00:43:06 The outcome has been exciting; we've seen that learning becomes fun and intuitive when terms reflect their meanings. This project lets non-native speakers grasp Ruby concepts effectively, transforming how programming is taught worldwide.

00:43:42 My hope is to encourage educators and developers alike to consider producing programming languages in diverse native languages, and I invite collaboration for anyone interested in this ongoing initiative.

00:44:15 Thank you for listening, and I encourage you to share any insights or questions regarding Ruby Vernac.

00:44:56 I’m not going to introduce myself again. I want to begin by asking you all if you feel comfortable estimating your workloads versus feeling unprepared.

00:45:38 Often it seems we estimate much too high or too low when it comes to workload expectations. Many developers feel pressured to calculate return on investment before embarking on projects.

00:46:04 It’s critical to manage those expectations well. We can calculate ROI only by looking back rather than ahead at the story level. We shouldn't expect overly detailed estimations since they often hurt more than help.

00:46:33 Instead, by assessing project aspects holistically, we encourage iteration while focusing on defining clearer, more manageable scope limits. Overall, I would advocate for actions leading toward better-performing estimates than hard numbers.

00:47:06 In conclusion, these strategies should help you find your footing and navigate challenges as you progress through your careers.

00:47:47 I appreciate all your attention today, and I'm happy to discuss further or clarify any points raised.

00:48:23 Book duets are an exploratory project I developed to create mashups of lyrics and literary quotes. It was presented at RubyConf and incorporates elements of interesting algorithmic work.

00:49:04 This project yields intriguing blends stemming from authors and musicians, engaging creativity and showcasing the power that generative algorithms can have.

00:49:49 This was developed using a Marov Chain, where I constructed a probabilistic model to craft these lyrical combinations. If anyone is inclined to try this project out or give feedback, I fully welcome the input!

00:50:32 Thank you, everyone, for your enthusiasm and assistance on this initiative.

00:51:07 Hi, I'm Britni Alexander, and I'm here to provide them with some insights on landing your first Junior Developer job. This includes tips for what you might want to consider when heading into interviews or applying.

00:51:51 The first thing I’ve learned is to stop self-sabotaging your progress. If you’re waiting for a perfect moment to apply, it likely won’t happen unless you take actionable steps forward.

00:52:31 You should create a list looking at what you want from a role, but be flexible about what you can do and what’s right for your circumstances.

00:53:13 Establish your brand. Employ terms like software engineer or full stack developer as a way to present your capabilities. Embrace challenges and new experiences as motivating opportunities for learning.

00:53:52 As you put yourself out there, utilize online and in-person platforms to attract opportunities. Join local tech networks or communities, and don’t shy away from emailing companies you admire.

00:54:12 Once the interviews start rolling in, feel free to take as many as you are offered. Each experience is a learning curve despite the outcome—don’t miss growth opportunities. Reach out to others in your journey!

00:54:40 In conclusion, embrace the journey to your first developer job, and remember that every experience counts.

00:55:01 Thank you all for your time! If there are questions, or you’d like to connect, I’m here till the end.