Documentation

Summarized using AI

Lightning Talks (Part 1)

TODO • March 15, 2015 • Bath, UK

The video titled Lightning Talks (Part 1) features a presentation by Andrew Faraday at the BathRuby 2015 event. The primary focus of the talk is the transition of the WebEx handler from PHP to a more production-ready Ruby on Rails codebase, discussing the challenges and insights gained throughout this process.

Key Points Discussed:

- Introduction to WebEx: WebEx is a video conferencing platform developed by Cisco, equipped with voice, chat, and video functionalities, mainly utilized in educational environments due to its ability to bypass network firewalls.

- Challenges with WebEx: Working with the existing PHP sample code and inadequate documentation posed significant hurdles. Faraday highlights examples, such as the 'get recording link' method, which operates unexpectedly by providing a web link instead of a direct recording link.

- Cleaning Up Code and Documentation: Emphasizing the importance of privacy, the team had to sanitize the codebase by removing personal data references and inappropriate instructional comments. The configuration was adapted for use as a gem, incorporating YAML for setup.

- Internal Processes and GitHub: The presentation covers the internal practices of the company with the use of GitLab for development, alongside the careful public release to GitHub, ensuring the stability of the code before committing.

- Developer Anxiety and Learning: Faraday shares his personal experiences of fear as a developer due to self-teaching, pushing himself outside his comfort zone, and tackling complex topics like SQL and JavaScript. He emphasizes the significance of continuous learning despite these fears.

- OSS Wednesday Initiative: To confront his challenges, Faraday started an initiative to work on open-source projects regularly, motivating himself through passion-driven development. He cites his current project, 'Smith Music', which encourages mastery over regex and the Web Audio API.

Conclusion and Takeaways: Faraday concludes that fear is a common experience among developers and encourages a proactive approach in facing challenges and learning new subjects. He highlights the importance of creating projects driven by personal interest as a method to grow not just technically, but personally as well. This talk is an insightful blend of technical guidance and personal reflection, aimed to inspire fellow developers to embrace their fears and cultivate their skills.

Lightning Talks (Part 1)
TODO • March 15, 2015 • Bath, UK

Help us caption & translate this video!

http://amara.org/v/G0HQ/

BathRuby 2015

00:00:24.560 As that part of the slide says, my name is Steve, and this is the WebEx handler. This talk is about how we took the WebEx handler from the PHP code that Cisco produced and turned it into production-ready Rails code, technically Ruby stuff that we use in our Rails app.
00:00:28.720 So what is WebEx? WebEx is a video conferencing platform built by Cisco. It includes voice, chat, video, and all that sort of normal functionality. We use it primarily to facilitate communication, particularly in an educational setting, connecting teachers with students. The great thing about WebEx is its ability to punch through firewalls in schools.
00:00:41.600 It's mature technology—perhaps a bit old and flabby—but dependable, so it won't crash unexpectedly. However, the downside is that all the sample code is written in PHP, and the documentation is nearly useless. That said, you can make it work. The user interface, as you can see on the right side of the slide, is not what you'd expect from a modern web app.
00:00:58.719 We took this clean PHP code and turned it into something more elegant. Converting code from one language to another is not particularly challenging; the real problem lies with WebEx itself. For instance, they have a method called 'get recording link.' You might expect that it retrieves the link to the recording, but it instead provides a link to a web page that opens an iframe, sets a token, redirects, and then downloads the file. Yes, it’s the latter scenario.
00:01:27.840 We wondered why anyone else should have to endure such misery. The company I work for decided to release our work so that others could benefit from what we've learned. We wrote the code, but then realized we needed to clean up the comments before releasing it. It wasn’t profanity; it was instructional comments detailing how to use the methods, which isn’t suitable when dealing with sensitive data about students' details. We needed to ensure no personal information was made public.
00:02:26.879 We also had to clean the configuration settings, as it changed from being part of an app to being a gem. We needed to adapt the configuration to accept it via YAML files, which the code demonstrates. Renaming things was also crucial, as we are specifically dealing with tutors and students, a setup that isn’t universal in other applications. As a result, we opted for 'attendee' and 'host' to make our code clearer, though it did complicate the gem structure.
00:02:47.599 In terms of documentation, we faced challenges. Typically, you could just search the codebase to understand how to utilize various methods, but since we aren’t distributing our codebase publicly, I had to document everything along with the necessary legal disclaimers. We put this into GitHub. Internally, we use GitLab, so rather than creating a straight branch between GitLab and GitHub (due to concerns over potential unintentional issues in the code), we cleaned it up before committing it back to the repository.
00:03:35.120 It wasn’t a monumental task, but all steps were necessary. On the plus side, Cisco's API is fairly consistent; they haven't made many changes. The focus now will be on adding new API calls moving forward. As you can see, our GitHub account is up, and yes, we are hiring! I brought a bag of fortune cookies, courtesy of my boss for the train ride; I've eaten most, but there's still some left if you're interested.
00:04:00.639 Let me introduce myself further: I'm Andrew Faraday, and I must admit I'm a bit terrified. For most of my five years in Ruby development, I have lived in a state of fear. I would like to share why this is and why I believe it’s a universal experience among developers. First off, I am not a ninja. I've never been a ninja. I don’t dress in black—or wield deadly blades. I can’t sneak into a company unnoticed, leaving behind only well-structured code. I get noticed. I am also not a guru or a unicorn—I lack the necessary traits like a magical ability to navigate obstacles effortlessly.
00:05:00.200 This lack of supernatural skills leaves me feeling frightened in the face of exciting opportunities. It's inherently scary when someone who should not be telling me what to do is suggesting I should get excited about a project. If I were to hear that on a bus, I’d likely change seats. Rocketing into the sun sounds exciting, but that doesn’t mean I want that. Setting recruiters aside, there are specific reasons I feel terrified as a developer; one foundational reason is simply that learning to code is challenging. I’m largely self-taught and started late in life.
00:06:10.160 This means that I've spent significant time staring at errors, searching online for solutions, and frequently feeling lost. As I understand more, I find a comfort zone that increasingly excludes regular tasks, forcing me to continuously explore unfamiliar and often intimidating aspects of development. My comfort zone shrinks while my scary zone expands. SQL is an example; I now appreciate its significance, but three years ago, I thought Active Record sufficed. Frameworks like Rails can be misleading, giving the impression that learning fundamental concepts isn't necessary.
00:07:23.520 JavaScript is another area where I initially felt comfortable with RJS, before realizing the depth of knowledge required. For a long time, regex appeared to me as ASCII vomit, which made it challenging for me. As I reflect on all this fear, I realize there are solutions to address it, but a common mistake is learning everything on the job when other existing solutions might have addressed those fears. The best approach to tackle this is to work outside the confines of your fear-induced bubble and focus on creating something you genuinely want to build.
00:08:20.360 Introducing an initiative I call OSS Wednesday: every Wednesday this year, I’ve committed to making significant contributions to projects that excite me. The latest project I’m working on is called 'Smith Music', which employs a command-line interface requiring me to learn about regex—an area I admitted previously to fearing. The application uses the Web Audio API, thus encouraging me to engage with various functions that I need to master mathematically.
00:08:40.360 The best part of this process is that I am making something I genuinely want to create, which alleviates the pressure of deadlines and allows for a more self-driven exploration of the subject matter. The intrinsic motivation towards developing something great is indispensable. To recap, there's no shame in feeling scared as a developer; it's an experience we all share. Face your fears, challenge them, learn those difficult subjects, and above all, create something you yearn to build. Whether it's an artistic endeavor, a game, or even a practical application like an Arduino-based robot, ensure you are evolving not only as a programmer but as a person.
00:09:55.200 Thank you very much for your time today.
Explore all talks recorded at BathRuby 2015
+2