Ruby
Lightning Talks
Summarized using AI
Lightning Talks
by Amanda Chang, Dave Rupert, Jordan Reuter, and Nickolas MeansThe video 'Lightning Talks' from the Keep Ruby Weird 2017 event features a series of quick presentations from various speakers discussing their experiences in coding and development.
Main Topic: Each speaker shares valuable lessons learned through their unique journeys in the coding world, with an emphasis on personal growth and the challenges faced in programming.
Key Points Discussed:
Amanda Chang:
- Shared her transition from a theater major to a coding educator at a boot camp.
- Discussed the courage required to be a beginner and how struggles foster growth.
- Highlighted the positive impact of a beginner’s mindset on mental health.
- Gave an example of a student club that enhanced learning through positivity.
- Emphasized the importance of continuous learning and personal happiness in a coding career.
Dave Rupert:
- Focused on the Ruby ecosystem's compatibility with Windows after his switch to the platform for a year.
- Discussed challenges faced, such as gem compatibility issues and the impact of Microsoft’s enhancements for development on Windows.
- Encouraged developers to explore compatibility solutions and highlighted the evolving nature of technology.
Jordan Reuter:
- Introduced Elm as a functional programming alternative to JavaScript.
- Described Elm’s architectural principles, emphasizing one-way data flow and reducing side effects.
- Explained how Elm’s design can facilitate clearer and more predictable programming, reflecting a shift in modern development practices.
Nickolas Means:
- Presented a case study on the Crofts Folly nuclear disaster to draw parallels with software development.
- Discussed the importance of balancing pragmatism and idealism in engineering practices to avoid technical debt and disaster.
- Concluded that the insights gleaned from historical errors can inform better decision-making in coding projects.
Conclusion and Takeaways:
- The talks collectively illustrate that learning to code involves both personal and technical challenges, and fostering a supportive environment can enhance this experience.
- Understanding historical lessons in engineering can improve current practices in software development.
- Emphasis on the importance of continuous learning and a positive mindset in the ever-evolving tech landscape.
00:00:10
Hi guys, my name is Amanda Chang, and I'm going to talk quickly about what I've learned about life through teaching adults to code. The other day I was going through some old blog posts, and I found one that I wrote when I was 23, which, contrary to popular belief, was three years ago, not five years in the future.
00:00:30
At that time, I was teaching at a coding boot camp. I am a big proponent of coding boot camps, and I think, in order to understand why these lessons were so important to me, I'll take a tangent and talk about what I was doing before and then come back to these lessons.
00:00:49
Unlike many of you, I was not a computer science major; I was a theater major. That blob on the right is me in a really low-quality photo. After college, I pursued lighting design for theater. My first job was working at a summer camp, and the director of the camp each year had a counselor she just didn't like for no particular reason.
00:01:04
And unfortunately, that was me. I'm still not sure why she didn't like me; I think it had something to do with her unrealistic expectations. But five weeks in, after being completely exhausted and having pulled some all-nighters, I woke up and realized I couldn't do another seven weeks, and I had to leave.
00:01:40
When I told the camp director that I was leaving, she said something I will never forget: she told me that she thought I would never have a career because if I was the type of person who leaves when things get hard, nobody would ever want to work with me. That was really hard to hear at 22 from a 40-year-old.
00:02:06
Next, I went down to Florida for an internship and after five weeks, I got fired. It was a great time—I didn't work much that next year. I was freelancing, and I started to believe that I might not have a career until one day, something had to change.
00:02:31
I read an article about coding boot camps, which led me to the Flatiron School in New York City. At that time, I had a year of college computer science under my belt, having initially started as a computer science major. However, I had no idea how to use that knowledge practically; none of it had stuck.
00:02:51
For the first time, I really had the opportunity to challenge myself intellectually again. I learned that code is creative, and I fully embraced the Flatiron School culture. I drank the Kool-Aid a hundred percent and ultimately ended up teaching there after I graduated, which brings us back to the article.
00:03:16
So what did I learn about life through teaching adults to code? First, I learned that being a beginner takes courage. I taught almost a hundred students, a range of people who left their jobs, and each day reminded me that the best things in life come from hard work and struggle. If you're not struggling, you're not learning.
00:03:41
Another thing I discovered is that there’s something really great for your mental health about being a beginner: this idea of being good. We really like being good as adults, but when we're beginners, we don’t have to worry about it. As beginners, nobody is good, and nobody is bad. When you start something, you can't just say, "Oh, I took my first dance class, and I'm really bad at dance." No, you took your first dance class, and you are a beginner.
00:04:11
Realizing this allowed me to start playing ultimate frisbee after I began teaching. Let me tell you, I was terrible! There's a picture of me dropping a disc. I've been playing for about two and a half years now and I'm still not good, but those beginner periods made me realize that despite not being very good at it, it's something I love to do.
00:04:37
So I really encourage everyone to take advantage of that beginner mindset. The next thing I learned about life is that a positive or negative attitude is contagious. I have a little anecdote from my time teaching: I had a student named Seiji, and you may have heard of Project Euler. For those who haven't, Seiji set up a club called Club Euler to meet at 8:30 every morning to do puzzles.
00:05:00
Not only were they learning from 9:00 to 6:00, but they were also meeting half an hour early. Most of the class chose to attend it twice a week because Seiji was so positive. The same contagion applies negatively: in theater, you often work with a lot of jaded people, and that cycle just continues.
00:05:31
At my current job, I'm fortunate enough not to be stressed most of the time, but one week was particularly challenging. I was on call while also working on several features. One of my co-workers came in and offered to take my on-call shift, and I was so grateful and felt he was the best person ever. A few weeks later, he needed me to work late to get out a deploy, and it was easy to agree because he had done something positive for me.
00:06:08
The last lesson I want to share is that there is always more to learn. When I was working in theater, a more experienced designer advised me to be a sponge. In development, you can learn anything without needing anyone else around. In theater, I couldn't create new work without a team; I had to be hired to do so. However, in programming, I recently started playing with Processing and it's been really fun. I can make a bunny move from the bottom of the screen to the top, and it makes me feel accomplished.
00:06:33
In conclusion, I'm thrilled that my first full-time job demonstrates how important it is to strive for happiness, both your own and that of the people around you. Everything I shared today may not be groundbreaking or new, but these reminders are valuable to me, and I hope you all enjoyed it.
00:07:00
I'm Dave Rupert. You might remember me from the internet. I am here to tell you...
00:07:11
Oh, she just had slides here, so I made a slide deck called "Hey, Did You Know Ruby Kind of Actually Works on Windows Now?" You may not have known that unless you were someone who does cats. I wanted to share a story about my experience with this.
00:07:36
I do a podcast with Chris Coyier from CSS Tricks, who likes CSS, but apparently not too many people here do. I was surprised to see the demographic split between Windows and Mac users was about 50/50. That’s unexpected because at events like this, it seems macs are everywhere.
00:08:12
The podcast has about 16,000 listeners and we receive requests for advice—how to deal with this or that. Our common advice was simply to buy a Mac if your designers wanted you to do something in Sketch. This is good advice if you do a lot of Sketch work, but it's bad advice if you come from a country where that costs 12 months of work.
00:08:50
So I pulled a stunt on the podcast where I switched to Windows for a year. It was quite a challenge for me. I received a Surface laptop from Ray Bingo at Microsoft for a year, and I installed a set of my projects onto it. However, when I tried to set it up for a Ruby on Rails project, nothing worked.
00:09:26
The Nokogiri gem had been broken since January and it was nearly September. One guy in Germany patched it, but nobody merged the pull request because nobody had a Windows machine to test it. This made me wonder—why is Ruby treated like this? There was a video of DHH stating, "Windows is stupid and is never going to succeed." It was discouraging to see.
00:09:57
Getting back into development was really frustrating. I even had Skype calls with Scott Hanselman, a notable open-source developer, and we spent hours gem installing various packages only to watch them break repeatedly. Then, about three or four months into my stint, an exciting announcement came out from Microsoft about the Linux subsystem on Windows.
00:10:47
They hired Canonical, who makes Ubuntu, to patch this subsystem into native Windows functions. I use it every day, and it’s truly remarkable. At this point, I wanted to show you guys how the entire system works if you're interested.
00:11:13
You simply head to the Microsoft Store, type in "Ubuntu" (yes, I realize that's difficult to spell), and you'll find it as an app. Install any flavor of Linux you want, and then you can type 'bash' to get a Bash prompt. You can do anything you would do on your Mac or Linux machine within this Windows interface.
00:11:45
Hi, I'm Jordan. Can you see this arcane syntax on the top left of the screen? Great. How many of you here are Rails developers? That makes sense. How many of you here do any front-end development, especially with React or Redux? It seems there's a mix. I recently started working with JavaScript about six or seven months ago.
00:12:50
I'll say the JavaScript ecosystem is fantastic: it's enthusiastic, fast-paced, and always evolving. However, keeping up with changes can feel overwhelming, especially moving from Ruby or Perl where things were slower and more stable. In the Ruby world, you could simply say 'gem install whatever,' but with JavaScript, it’s a different ball game.
00:13:25
Running away from JavaScript led me to discover Elm. How many of you have heard of it? Wow! Instead of using JavaScript for the front end, Elm is a functional programming language that compiles to JavaScript. It doesn’t yet handle server-side stuff, but it aims to replace everything you do on the front end.
00:13:54
Elm emphasizes purity, meaning side effects are eliminated. All your functions have inputs and outputs, with no side effects like console logging. One of the great things about Elm is that it is a programming language, but it also comes with a design pattern that guides how you write applications.
00:14:20
Elm's architecture, which influenced React and Redux, focuses on constraint-based design. The more constraints you impose, the better your designs become, helping to streamline development and execution. For example, Elm's basic structure comprises three functions: the model (similar to a Redux store), the view (like your React JSX), and the update (akin to a Redux reducer).
00:14:50
In essence, you start with an initial state, and the program operates by rendering a view composed of a tree of HTML. The views integrate event handlers dispatched to Elm’s runtime, which utilizes an update function to handle changes.
00:15:25
The beauty of Elm is in its functional programming model. For instance, rather than modifying existing data, you always return a new version of the data. Thus, if you want to decrement a value, you return a new model rather than mutating the current one, and this creates a more predictable development flow.
00:15:58
Today, decentralized programming like Elm has really changed how we perceive data handling. It allows you to write clear, concise programs without falling into traditional shared state pitfalls. Thanks to the one-way data flowing through Elm, your applications maintain stability and predictable behavior.
00:16:39
Thanks for listening to this overview of Elm. It’s a functional language that can simplify a lot of the complexities we face in JavaScript land. I appreciate your attention and encourage everyone to explore this great tool!
00:17:10
Now, my name is Nick, and I'd like to give you a disaster talk. This one is about Crofts Folly, my favorite British nuclear disaster because it’s the only one that truly stands out. After World War II, Winston Churchill concluded that the UK needed to become a nuclear power to remain relevant.
00:17:42
However, the United States was very cautious in sharing nuclear technology and only did so with those nations that had already developed nuclear bombs. Despite British scientists being part of the Manhattan Project, the U.S. wouldn’t share intelligence with them.
00:18:10
As a result, Churchill enlisted those British scientists to build a bomb, but they needed fissile material. So, they decided to bypass uranium and go directly for plutonium. To obtain plutonium, they realized they would need to construct a nuclear reactor. And notably, the reactor they designed was based on the knowledge gathered from Hanford B.
00:18:50
Now, there was a challenge here; if you lost electrical power in a water-cooled reactor like Hanford, the reactor would explode. However, in the UK, they had limited space as an island nation. Therefore, they needed to focus on making their reactor passively safe. They opted for an air-cooled nuclear reactor, a decision that seemed brilliant at the time.
00:19:18
This reactor design allowed air to be forced through it by large fans. If the power failed, theoretically, convection would keep it cool. However, one physicist, Terrence Price, identified a potential flaw: he raised a concern that a fuel canister could theoretically fall out, crack open, and introduce harmful materials into the atmosphere.
00:19:56
While he insisted that a filter should be installed at the top of the chimney to mitigate this risk, the team felt that the cost was prohibitive. Although this concern was dismissed in meetings, it posed a significant risk. Days later, Sir John Cockcroft, the director of the program, recognized the importance of Terrence's suggestion and insisted they implement a high-performance filter.
00:20:30
As such, those filters became known as Crofts Folly because it seemed unnecessary to the rest of the team. On the technical side, the reactor utilized graphite as a moderator—a substance essential for slowing down the neutrons and sustaining the nuclear chain reaction. However, irradiating the graphite over time would eventually impact its structure.
00:21:10
Heating the graphite allowed its crystalline structure to reset, and annually they would perform this process. Yet, during the annealing process on October 7, 1957, the reactor’s temperature began to rise unexpectedly in one channel.
00:21:45
After several attempts to cool down the pile, they turned the ventilation fans to full blast. However, as the radiation alarms rang out, they mistakenly assumed it was an isolated issue. However, a team member physically saw the glowing, cherry-red fuel rather than a simple malfunction.
00:22:10
Ultimately, the reactor's core caught fire. At this point, attempts to cool the core using carbon dioxide and water proved ineffective because water can lead to a potential explosion in such scenarios. After four days of intense heat, they evacuated everyone except the fire chief and the site manager.
00:23:00
Slowly, after turning off all cooling mechanisms, they noticed the core temperature began to decrease. At last, they were able to decommission the reactor. As of last summer, they've begun to clean it up, but it was necessary to avoid scattering toxic waste around the English countryside.
00:23:25
Reflecting on the lessons of this incident brings parallels to the software world. Building software, especially new products, is like getting fissile material: urgent and often leading to shortcuts. I've seen that software engineers often fit into two categories: pragmatists and idealists.
00:24:05
Pragmatists prioritize getting the job done, which sometimes means taking on technical debt, while idealists strive for well-engineered systems and optimal coding practices. Both perspectives are essential.
00:24:35
In the end, it’s crucial to maintain both viewpoints on your team. They allow you to access unique ideas while avoiding the pitfalls of haste that could lead to disaster. The Windscale team could have faced significant consequences had they not heeded Team Cockcroft's inclinations.
Explore all talks recorded at Keep Ruby Weird 2017
