Podcasts about programming ruby

For a long time, Programming Ruby was the authority in the developing world. Now, a much-needed update has been published. During this conversation, we are joined by Noel Rappin, who shares how his frustration at the idea of static type in Ruby motivated him to investigate why he felt this way, as he published his findings in The Pickaxe Book. We discuss how this book differs from previous material he has published, explore a recent blog post series that explored the idea of failing fast, and address the widespread opinion that developers should take a simpler approach that is more accessible. Noel also explores the responsibility of understanding how readers consume material and the importance of providing thorough context as an author, how Programming Ruby became the most significant programming reference, and the surprising journey that led Noel to realize he was able to provide an updated version of the theory in it. Next, we dive into some of the more opinionated blog posts Noel has posted and the harshest feedback he has received in response to them. You'll also hear about his research and learning during the act of writing the book. Join us today to hear all this and more. Key Points From This Episode: Noel Rappin's recently published work, The Pickaxe Book, on current versions of Ruby. The inception of the book during discussions about the collision of Sorbet and Ruby. How his background made him comfortable with the idea that there are no static types. A recent blog post series and how it answered a question about failing fast. Considering whether developers pursue simpler things that are more accessible to a wider range of coders. The problem of thoroughness and longevity in writing instructional material. Developing awareness of how readers consume and contextualize theory and opinion. How Programming Ruby became the most significant programming reference. Noel's updated version of this material in his latest book. His blog posts on real-life applications of Ruby and the feedback he receives. How he goes about framing blog posts as opinion or instruction. Determining what community consensus is. The bewilderment that often accompanies onboarding sessions. Research and learning leading up to writing and publishing the book. Feedback and reviews on the book. Links Mentioned in Today's Episode: Noel Rappin (Noel Rappin) Noel Rappin on X (Noel Rappin on X) Programming Ruby (Programming Ruby) How Not to Use Static Typing in Ruby (How Not to Use Static Typing in Ruby) David Copeland Talk (David Copeland Talk) Better Know a Ruby Thing (Better Know a Ruby Thing) How To Manage Duplicate Test Setup, Or Can I Interest You in Weird RSpec? (How To Manage Duplicate Test Setup, Or Can I Interest You in Weird RSpec?) Better Know a Ruby Thing: On The Use of Private Methods (Better Know a Ruby Thing: On The Use of Private Methods) Standardrb (Standardrb) Rails Test Prescriptions (Rails Test Prescriptions) Programming Ruby: A Pragmatic Programmer's Guide (Programming Ruby: A Pragmatic Programmer's Guide) The Bike Shed (The Bike Shed) Joël Quenneville on LinkedIn (Joël Quenneville on LinkedIn) Support The Bike Shed (Support The Bike Shed)

In this episode of the Maintainable Software Podcast, Robby is joined by Noel Rappin, Staff Engineer at Chime Financial, and the mind behind the latest edition of the classic Programming Ruby book, affectionately known as the "Pickaxe." Noel delves into the intricate process of modernizing a legacy technical book and the lessons learned along the way.Episode Highlights[00:05:32] A Legacy Revisited: Noel Rappin reflects on the process of updating the Programming Ruby book, navigating the balance between preserving its legacy and making it relevant for today's Ruby community.[00:10:17] The Challenges of Modernizing: Noel discusses the complexities of working on a legacy book, including maintaining a consistent tone, updating technical content, and making strategic decisions about what to include or omit.[00:16:12] Parallels with Legacy Code: Noel shares his insights on the similarities between updating a legacy book and maintaining legacy software, emphasizing the importance of understanding past decisions before making changes.[00:21:00] Curating Ruby's Evolution: How Noel approached the task of deciding which Ruby features and practices to highlight in the new edition, considering the evolution of the Ruby community since the book's last update.[00:27:00] The Ruby Ecosystem as a Legacy System: Exploring the idea that the entire Ruby ecosystem can be seen as a legacy system, shaped by past decisions and community standards.[00:33:47] Advice for Aspiring Technical Authors: Noel offers practical tips for those interested in contributing to or updating legacy technical books, including how to pitch ideas to publishers and navigate the challenges of working on established projects.[00:40:00] Maintaining Relevance: Strategies for keeping both software and technical books up-to-date, including Noel's thoughts on the importance of documentation and regular updates.Key TakeawaysUpdating a legacy technical book requires a deep understanding of the community's current needs and the ability to balance respect for the original work with the necessity of modern relevance.The process of modernizing a book like Programming Ruby shares many similarities with maintaining legacy software, including the importance of understanding past decisions and the challenges of working with outdated practices.Community standards play a crucial role in both software maintenance and technical writing, guiding the evolution of both fields.Noel emphasizes the importance of documentation in legacy projects, whether in software or publishing, as a tool for preserving context and aiding future contributors.Resources MentionedProgramming Ruby 3.3 (5th Edition) - The latest "Pickaxe" book, authored by Noel Rappin. Use promo code maintainablefm2024 to get 35% off the ebook.Chime FinancialMurderbot Diaries by Martha WellsWayfarers series by Becky ChambersRubular - Ruby Regular Expression EditorNoel Rappin's WebsiteNoel Rappin on LinkedInNoel Rappin on TwitterFor more episodes like this, be sure to subscribe to the Maintainable Software Podcast.Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

We discuss rubyday 2023, taking care of large applications, testing strategies for startups, and the dearth of practical literature around startups in general. rubyday 2023 (https://2023.rubyday.it/) Metaprogramming Ruby 2 (https://pragprog.com/titles/ppmetr2/metaprogramming-ruby-2/) Programming Ruby (https://pragprog.com/titles/ruby5/programming-ruby-3-2-5th-edition/) (Pickaxe book) Pragmatic Programmer (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) packwerk (https://github.com/Shopify/packwerk) Software Testing | worx4you Inc (https://www.worx4you.com/) Scratch from MIT (https://scratch.mit.edu/) Gosu (https://www.libgosu.org/) PyGame Zero (https://pygame-zero.readthedocs.io/en/stable/) Guinea Pig YouTube channel (https://www.youtube.com/@DieQuieckerbande) Ask questions via our anonymous feedback form (https://forms.gle/MW8qZFD7RLYriqKj8) You can reach us via email at hosts@expandingbeyond.it (mailto:hosts@expandingbeyond.it). You can follow us on Twitter at @podcast_eb (https://twitter.com/podcast_eb). Where to find Monica on the internet: Website: monicag.me (https://monicag.me/) Mastodon: @nirnaeth@mastodon.online (https://mastodon.social/@nirnaeth@mastodon.online) Github: @nirnaeth (https://github.com/nirnaeth) Blog: dev.to/nirnaeth (https://dev.to/nirnaeth) Where to find Urban on the internet: Mastodon: @ujh@masto.ai (https://masto.ai/@ujh) Github: @ujh (https://github.com/ujh/) Blog: urbanhafner.com (https://urbanhafner.com/) The intro and outro music is Our Big Adventure (https://freemusicarchive.org/music/Scott_Holmes/Happy_Music/Our_Big_Adventure) by Scott Holmes (https://freemusicarchive.org/music/Scott_Holmes). It's licensed under Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) (https://creativecommons.org/licenses/by-nc/4.0/).

The 1st edition of Programming Ruby, commonly known as "The PickAxe" book, came out in 2001. Now, in 2022, Noel Rappin is releasing the beta of the 5th edition, updated for Ruby 3.2. Why should you pick up the book? To get mind on how Ruby works, what makes it unique, and how Ruby developers think about Ruby.These are some of the topics we cover: How Noel decided the book was ready for early access  Noel gives the history of the PickAxe book Why Noel decided to update the book What will be different in the 5th edition What you need to know before reading the book What's left to do before the final edition is ready How long Noel has been working on the book What the expected final release date is What the hardest part of the project has been How Noel recommends you read the book How Rubyists of all levels will benefit from reading the book Why you will benefit from reading the latest edition SponsorSpecial thanks to Andy Croll for personally sponsoring this episode. Be sure to check out firstrubyfriend.org and onerubything.com for nice, free community resources for newer devs!Links Programming Ruby 3.2 (5th Edition) Programming Ruby 3.2 (5th Edition) Devtalk Noel on Twitter Noel's Website Sorbet RubyMine RBS Support

Noel Rappin joins the show to talk about his new book, "Programming Ruby 3.2", best known as the "Pickaxe Book".  Noel talks about his adventures working on a legacy book and even having to deal with some legacy code in a legacy book. The Pickaxe Book is one of the biggest, and oldest, books on my shelf so it's no surprise that this was a beast of an update.@noelrap on Twitternoelrappin.comRuby DiscordThe Ruby Learning CenterPurchase "Programming Ruby 3.2" from The Pragmatic BookshelfDiscussions on devtalk.comReport Errors on devtalk.comSupport the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.SponsorsA big thanks to OBLSK for being the very first sponsor of the show!

Tammy and Tim have a chat with Chris Pine, author of Learn to Program, about his journey to becoming a Pragmatic author. * Recorded 10-February-2021 Show Links Chris Pine on Twitter Learn to Program Sourcegraph Alan Watts, Out of Your Mind (Part 1) Alan Watts, Out of Your Mind (Part 2) Programming Ruby (2nd edition) Tim and Tammy are back with Episode #2 of the Pragmatic Hero's Journey podcast. This month, our hosts chat with Chris Pine, author of Learn to Program. From tiny houses to huge programming concepts and everything in-between, this episode has it all. --- Chris Pine started his Hero's Journey in 2002 when he thought about using Ruby to teach people how to program. There wasn't much Ruby documentation for beginners at the time, so he decided to stop thinking about teaching and start writing a tutorial aimed at beginners. But the task of writing a great tutorial for non-programmers was a bit more challenging than Chris first anticipated. But, he kept at it---adding more and more polish with each revision. Because Chris made it so easy for people to contact him, he was able to rework the tutorial based on reader feedback. Just as Chris was ready to wrap up the tutorial writing, he was contacted by a handful of publishers, including the Pragmatic Bookshelf---he's been with us ever since and is now working on the 3rd edition of Learn to Program, which is currently in beta. Listen to the rest of Chris's story on this episode of the Pragmatic Hero's Journey podcast. You can stream the episode here: https://pragprog.libsyn.com/ or subscribe to the RSS feed using the following link: https://pragprog.libsyn.com/rss.

Dave Thomas is recognized internationally as an expert who develops high-quality software–accurate and highly flexible systems. He helped write the now-famous Agile Manifesto, and regularly gives inspiring and controversial speeches on new ways of producing software. He is the author of six books, including the best selling The Pragmatic Programmer: From Journeyman to Master and Programming Ruby: A Pragmatic Programmer's Guide. In this episode, we discuss everything from learning computer science in an academic setting, test-driven development, and state to architecture, libraries, and what Dave loves about what he does. Dave talks about his students, both those who are passionate and those who are just going through the motions, as well as his own experience of being a student. He explains to us what he means when he said he doesn’t write unit tests at an Elixir conference in Austin recently, we talk about his favorite and most rewarding books, and Dave gives us a really unique answer to our architecture question. We discuss domain-driven design, microservice architectures, and Elixir libraries, and Dave shares why is so passionate about what he does. Tune in to hear some of Dave’s strong opinions on programming! Key Points From This Episode: The Coding Gnome and how it bridges the gap between learned and practical experience. Dave talks about being a lecturer at SMU and why students aren’t prepared for the real world. Why Dave stopped teaching Elixir at SMU. Students who study computer science for passion versus those who study it to get a job. Dave talks about his experience of studying computer science at university. The inspiring and controversial keynote addresses Dave has given at conferences. What it means when Dave said he doesn’t write unit tests and the projects he’s working on. The culture around test-driven development and writing tests when Dave was at university. Dave tells a story about writing the incoming telex switch for the UK. Why the first edition of Programming Ruby was Dave’s favorite book to write. Why The Pragmatic Programmer is the book Dave is most proud of. Dave isn’t currently writing a new book, so he can concentrate on pseudo-course material. Dave explains the process of developing a narrative arc when writing a technical book. What the state of a system is and how it is distinct from data. Dave describes why he believes architecture is a misunderstood and borrowed metaphor. Dave’s opinions on buzzwords like domain-driven design and microservice architectures. The status on The Component Library, as mentioned by Dave in his EMPEX 2018 keynote. Getting involved with publishing Elixir libraries and what his process looks like. How Dave likes to receive product specification when dealing with clients. What Dave loves about the programming industry. Why Dave doesn’t write Elixir anymore and why he became frustrated with it. Where Dave is going from here to how best to express what he wants. Final advice from Dave, not to abandon Elixir if it makes you happy. Links Mentioned in Today’s Episode: Dave Thomas on Twitter – https://twitter.com/pragdave The Coding Gnome – https://pragdave.me/ The Coding Gnome Training — https://codestool.coding-gnome.com/ Agile Manifesto – https://agilemanifesto.org/ The Pragmatic Programmer – https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition Programming Ruby – https://en.wikipedia.org/wiki/ProgrammingRuby Robert Kowalski on Wikipedia — https://en.wikipedia.org/wiki/RobertKowalski Dave Thomas on Wikipedia — https://en.wikipedia.org/wiki/DaveThomas(programmer) Space-state representation — https://en.wikipedia.org/wiki/State-spacerepresentation Christopher Alexander — https://en.wikipedia.org/wiki/ChristopherAlexander A Pattern Language — https://en.wikipedia.org/wiki/APatternLanguage Dave Thomas Keynote at Empex NYC 2018 — https://www.youtube.com/watch?v=6U7cLUygMeI SmartLogic — https://smartlogic.io/ Justus Eapen on Twitter — https://twitter.com/justuseapen Eric Oestrich on Twitter — https://twitter.com/ericoestrich Special Guest: Dave Thomas.

Ruby is a scripting language created in the mid-1990s by Yukihiro "Matz" Matsumoto in Japan. It's popularity surged in Japan by 2000, which was also when the first English language book about the language, Programming Ruby was printed. After that, Ruby had its sunrise and sunset in terms of favor amongst developers, but continues to have a robust community of users. In this episode, we talk about the history of the language, some of its benefits and pitfalls, and why we continue to use it at DEV, with Vaidehi Joshi, senior software engineer at DEV, and James Harton, software engineer at Balena, and author of the 2018 DEV post, "Please stop using Ruby." Show Notes DevNews (sponsor) Triplebyte (sponsor) CodeNewbie (sponsor) RudderStack (sponsor) GitHub Distributed system Ruby Balena Please stop using Ruby Please keep using Ruby Rails Ruby New Zealand Yukihiro "Matz" Matsumoto Rust Elixir MINASWAN JavaScript Open source https://elm-lang.org/ Duck typing Node Shopify Stripe COBOL Go Java The Odin Project reddit PHP Crystal Base.cs Python C Perl Smalltalk

David A. Black, Software Engineer IV at 2U, joins Charles Max Wood on this week's My Ruby Story. David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years as well as organizing conferences. David has been coding since he was 13 years old. He was introduced to Ruby in November 2000 when he was looking at the computer section at the old bookstore Borders and picked up the book Programming Ruby by Dave Thomas and Andy Hunt. Five years later, David, who has a Ph.D. in Cinema Studies from New York University, resigned from a tenured professorship in the communication field to become a full-time programmer, trainer, and author. His book The Well-Grounded Rubyist is now in its third edition. Host: Charles Max Wood Joined by Special Guest: David A. Black Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan React Native Radio My Angular Story CacheFly Links RR 423: The Well-Grounded Rubyist with David A. Black & Joseph Leo III David's Twitter David's LinkedIn 2U The Well-Grounded Rubyist: Covers Ruby 1.9.1 by David A. Black David A. Black Books https://www.davidablack.net/ Picks Charles Max Wood Nikon D5600 Digital SLR Camera RØDE Microphones

David A. Black, Software Engineer IV at 2U, joins Charles Max Wood on this week's My Ruby Story. David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years as well as organizing conferences. David has been coding since he was 13 years old. He was introduced to Ruby in November 2000 when he was looking at the computer section at the old bookstore Borders and picked up the book Programming Ruby by Dave Thomas and Andy Hunt. Five years later, David, who has a Ph.D. in Cinema Studies from New York University, resigned from a tenured professorship in the communication field to become a full-time programmer, trainer, and author. His book The Well-Grounded Rubyist is now in its third edition. Host: Charles Max Wood Joined by Special Guest: David A. Black Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan React Native Radio My Angular Story CacheFly Links RR 423: The Well-Grounded Rubyist with David A. Black & Joseph Leo III David's Twitter David's LinkedIn 2U The Well-Grounded Rubyist: Covers Ruby 1.9.1 by David A. Black David A. Black Books https://www.davidablack.net/ Picks Charles Max Wood Nikon D5600 Digital SLR Camera RØDE Microphones

David A. Black, Software Engineer IV at 2U, joins Charles Max Wood on this week's My Ruby Story. David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years as well as organizing conferences. David has been coding since he was 13 years old. He was introduced to Ruby in November 2000 when he was looking at the computer section at the old bookstore Borders and picked up the book Programming Ruby by Dave Thomas and Andy Hunt. Five years later, David, who has a Ph.D. in Cinema Studies from New York University, resigned from a tenured professorship in the communication field to become a full-time programmer, trainer, and author. His book The Well-Grounded Rubyist is now in its third edition. Host: Charles Max Wood Joined by Special Guest: David A. Black Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan React Native Radio My Angular Story CacheFly Links RR 423: The Well-Grounded Rubyist with David A. Black & Joseph Leo III David's Twitter David's LinkedIn 2U The Well-Grounded Rubyist: Covers Ruby 1.9.1 by David A. Black David A. Black Books https://www.davidablack.net/ Picks Charles Max Wood Nikon D5600 Digital SLR Camera RØDE Microphones

Sponsors Sentry use code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments: Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Panel Charles Max Wood Andrew Mason With Special Guests: David A. Black and Joseph Leo III Episode Summary David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years. Joseph spent 12 years in software and started the company Def Method Inc. Together, they co-authored the book The Well-Grounded Rubyist, which will soon have its third edition released. They give some of the history behind The Well-Grounded Rubyist. Joseph talks about his experience being brought into the project. David and Joseph talk about how The Well-Grounded Rubyist is different from other books on Ruby. This book is helpful because a lot of people begin by understanding Ruby more than Rails, and this book talks about ways to think about Ruby and understand how it’s structure. Joseph and David talk about how The Well-Grounded Rubyist 3rd edition differs from the 2nd edition. The book has been updated so that a lot of the code and solutions for the exercises are available online and there is an additional chapter in part 3 about Ruby dynamics and how one would write functional programming with Ruby The panel discusses how important it is to learn Ruby before starting a job in Rails 2. They agree that if you are a Ruby developer, even if you’re working on Rails apps, so you should know your tools. They discuss how far down that road The Well Grounded Rubyist would get readers. They panelists talk about other books that are a natural prequel or sequel to the The Well-Grounded Rubyist. Joseph and David talk about their approach to reading books and how The Well-Grounded Rubyist should be read. Their goal in making the book was not to have people work on an overarching application while reading the book, but rather there are exercises and examples that you are encouraged to work through. There are some lessons in the book that you won’t write often, but you still need to know how to do it. While the book doesn’t have everything about Ruby, but the examples are designed to give you the best returns for you study. David and Joseph conclude by giving their final thoughts on the book. Links The Well-Grounded Rubyist, Third Edition Perl Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (The Facets of Ruby) 4th Edition Practical Object-Oriented Design: An Agile Primer Using Ruby (2nd Edition) by Sandi Metz String mutability Follow DevChat on Facebook and Twitter Picks Andrew Mason: Default Gems Charles Max Wood: Good to Great: Why Some Companies Make The Leap and Others Don't by Jim Collins David A. Black: Pragmatic Programmer 2nd edition Davidablack.net and @david_a_black on Twitter Joseph Leo III:  Barbarians at the Gate Firehydrant.io @jleo3 and defmethod.com

Sponsors Sentry use code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments: Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Panel Charles Max Wood Andrew Mason With Special Guests: David A. Black and Joseph Leo III Episode Summary David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years. Joseph spent 12 years in software and started the company Def Method Inc. Together, they co-authored the book The Well-Grounded Rubyist, which will soon have its third edition released. They give some of the history behind The Well-Grounded Rubyist. Joseph talks about his experience being brought into the project. David and Joseph talk about how The Well-Grounded Rubyist is different from other books on Ruby. This book is helpful because a lot of people begin by understanding Ruby more than Rails, and this book talks about ways to think about Ruby and understand how it’s structure. Joseph and David talk about how The Well-Grounded Rubyist 3rd edition differs from the 2nd edition. The book has been updated so that a lot of the code and solutions for the exercises are available online and there is an additional chapter in part 3 about Ruby dynamics and how one would write functional programming with Ruby The panel discusses how important it is to learn Ruby before starting a job in Rails 2. They agree that if you are a Ruby developer, even if you’re working on Rails apps, so you should know your tools. They discuss how far down that road The Well Grounded Rubyist would get readers. They panelists talk about other books that are a natural prequel or sequel to the The Well-Grounded Rubyist. Joseph and David talk about their approach to reading books and how The Well-Grounded Rubyist should be read. Their goal in making the book was not to have people work on an overarching application while reading the book, but rather there are exercises and examples that you are encouraged to work through. There are some lessons in the book that you won’t write often, but you still need to know how to do it. While the book doesn’t have everything about Ruby, but the examples are designed to give you the best returns for you study. David and Joseph conclude by giving their final thoughts on the book. Links The Well-Grounded Rubyist, Third Edition Perl Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (The Facets of Ruby) 4th Edition Practical Object-Oriented Design: An Agile Primer Using Ruby (2nd Edition) by Sandi Metz String mutability Follow DevChat on Facebook and Twitter Picks Andrew Mason: Default Gems Charles Max Wood: Good to Great: Why Some Companies Make The Leap and Others Don't by Jim Collins David A. Black: Pragmatic Programmer 2nd edition Davidablack.net and @david_a_black on Twitter Joseph Leo III:  Barbarians at the Gate Firehydrant.io @jleo3 and defmethod.com

Sponsors Sentry use code “devchat” for $100 credit Cloud 66 - Pain Free Rails Deployments: Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Panel Charles Max Wood Andrew Mason With Special Guests: David A. Black and Joseph Leo III Episode Summary David A. Black has been a Ruby user for 19 years and has been writing books about Ruby for the last 14 years. Joseph spent 12 years in software and started the company Def Method Inc. Together, they co-authored the book The Well-Grounded Rubyist, which will soon have its third edition released. They give some of the history behind The Well-Grounded Rubyist. Joseph talks about his experience being brought into the project. David and Joseph talk about how The Well-Grounded Rubyist is different from other books on Ruby. This book is helpful because a lot of people begin by understanding Ruby more than Rails, and this book talks about ways to think about Ruby and understand how it’s structure. Joseph and David talk about how The Well-Grounded Rubyist 3rd edition differs from the 2nd edition. The book has been updated so that a lot of the code and solutions for the exercises are available online and there is an additional chapter in part 3 about Ruby dynamics and how one would write functional programming with Ruby The panel discusses how important it is to learn Ruby before starting a job in Rails 2. They agree that if you are a Ruby developer, even if you’re working on Rails apps, so you should know your tools. They discuss how far down that road The Well Grounded Rubyist would get readers. They panelists talk about other books that are a natural prequel or sequel to the The Well-Grounded Rubyist. Joseph and David talk about their approach to reading books and how The Well-Grounded Rubyist should be read. Their goal in making the book was not to have people work on an overarching application while reading the book, but rather there are exercises and examples that you are encouraged to work through. There are some lessons in the book that you won’t write often, but you still need to know how to do it. While the book doesn’t have everything about Ruby, but the examples are designed to give you the best returns for you study. David and Joseph conclude by giving their final thoughts on the book. Links The Well-Grounded Rubyist, Third Edition Perl Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide (The Facets of Ruby) 4th Edition Practical Object-Oriented Design: An Agile Primer Using Ruby (2nd Edition) by Sandi Metz String mutability Follow DevChat on Facebook and Twitter Picks Andrew Mason: Default Gems Charles Max Wood: Good to Great: Why Some Companies Make The Leap and Others Don't by Jim Collins David A. Black: Pragmatic Programmer 2nd edition Davidablack.net and @david_a_black on Twitter Joseph Leo III:  Barbarians at the Gate Firehydrant.io @jleo3 and defmethod.com

Chad Fowler is an author, developer, speaker, and investor. He's been a CTO, he founded Ruby Central, the non-profit behind RubyConf and RailsConf, and is a recognizable tech figure, particularly in the Ruby community. But before he knew what code was, he was a professional musician. He shares how he switched careers without a computer science degree and how he's ended up with such an incredible tech career. He also shares how he's managed his bipolar disorder over the years, and how mental health has affected him and his career. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Ruby Central RailsConf Ruby Gems Wunderlist Delphi Perl Novell Directory Services (NDS) Smalltalk Matz Rails Recipes (book) Dave Thomas (CodeNewbie Podcast interview) Programming Ruby (book) "How to become accomplished" (video) What is Linux? Codeland Conf Codeland 2019

Panel: Charles Max Wood Guest: Andy Hunt This week on My Ruby Story, Charles talks to Andy Hunt. Andy has previously been on Ruby Rogues for Episode 277, and is known for his book The Pragmatic Programmer, his company The Pragmatic Bookshelf, and much more. He first got into programming because of his interest in electronic music and his first RadioShack project he created, which led him to finding a book on the future of integrated circuits. They talk about how he found Ruby, why he wrote Programming Ruby, what he is working on now, and more! In particular, we dive pretty deep on: Ruby Rogues Episode 277 His book The Pragmatic Programmer His company The Pragmatic Bookshelf How did you first get into programming? Interest in electronic music RadioShack project Book on the future of integrated circuits Fire in the Valley by Michael Swaine Exposure to the programming as it was being born How did you find Ruby? Time as a consultant Needed a flexible and fast language Couldn’t use C++ or Java Using Perl Amazed by the Unix shell Loved that he could write pages of code that would actually work Lacked documentation in the beginning Writing his Programming Ruby book Been messing around with Elixir recently Ruby is still his number one language And much, much more! Links: Ruby Rogues Episode 277 The Pragmatic Programmer The Pragmatic Bookshelf Fire in the Valley by Michael Swaine Ruby Perl Programming Ruby Elixir Andy’s GitHub @PragmaticAndy Andy’s Website @pragprog Sponsors: FreshBooks Picks: Charles Google Drive ScanSnap S1300i Andy PragProg.com

Panel: Charles Max Wood Guest: Andy Hunt This week on My Ruby Story, Charles talks to Andy Hunt. Andy has previously been on Ruby Rogues for Episode 277, and is known for his book The Pragmatic Programmer, his company The Pragmatic Bookshelf, and much more. He first got into programming because of his interest in electronic music and his first RadioShack project he created, which led him to finding a book on the future of integrated circuits. They talk about how he found Ruby, why he wrote Programming Ruby, what he is working on now, and more! In particular, we dive pretty deep on: Ruby Rogues Episode 277 His book The Pragmatic Programmer His company The Pragmatic Bookshelf How did you first get into programming? Interest in electronic music RadioShack project Book on the future of integrated circuits Fire in the Valley by Michael Swaine Exposure to the programming as it was being born How did you find Ruby? Time as a consultant Needed a flexible and fast language Couldn’t use C++ or Java Using Perl Amazed by the Unix shell Loved that he could write pages of code that would actually work Lacked documentation in the beginning Writing his Programming Ruby book Been messing around with Elixir recently Ruby is still his number one language And much, much more! Links: Ruby Rogues Episode 277 The Pragmatic Programmer The Pragmatic Bookshelf Fire in the Valley by Michael Swaine Ruby Perl Programming Ruby Elixir Andy’s GitHub @PragmaticAndy Andy’s Website @pragprog Sponsors: FreshBooks Picks: Charles Google Drive ScanSnap S1300i Andy PragProg.com

Panel: Charles Max Wood Guest: Andy Hunt This week on My Ruby Story, Charles talks to Andy Hunt. Andy has previously been on Ruby Rogues for Episode 277, and is known for his book The Pragmatic Programmer, his company The Pragmatic Bookshelf, and much more. He first got into programming because of his interest in electronic music and his first RadioShack project he created, which led him to finding a book on the future of integrated circuits. They talk about how he found Ruby, why he wrote Programming Ruby, what he is working on now, and more! In particular, we dive pretty deep on: Ruby Rogues Episode 277 His book The Pragmatic Programmer His company The Pragmatic Bookshelf How did you first get into programming? Interest in electronic music RadioShack project Book on the future of integrated circuits Fire in the Valley by Michael Swaine Exposure to the programming as it was being born How did you find Ruby? Time as a consultant Needed a flexible and fast language Couldn’t use C++ or Java Using Perl Amazed by the Unix shell Loved that he could write pages of code that would actually work Lacked documentation in the beginning Writing his Programming Ruby book Been messing around with Elixir recently Ruby is still his number one language And much, much more! Links: Ruby Rogues Episode 277 The Pragmatic Programmer The Pragmatic Bookshelf Fire in the Valley by Michael Swaine Ruby Perl Programming Ruby Elixir Andy’s GitHub @PragmaticAndy Andy’s Website @pragprog Sponsors: FreshBooks Picks: Charles Google Drive ScanSnap S1300i Andy PragProg.com

RR 317: Computer Science at University and the Future of Programming with Dave Thomas Charles Max Wood interviews Dave Thomas about the Computer Science course he's teaching at Southern Methodist University, Elixir, and the future of programming. Dave is the author and co-author of several well known programming books including Programming Ruby (also known as the PickAxe Book), Programming Elixir, and the Pragmatic Programmer. This episode starts out discussing Dave's course and Computer Science education, then veers into Elixir and the future of programming. Tune in to hear where Dave thinks the programming industry is heading next. [00:02:30] Dave's Computer Science Course at SMU  Dave's advanced computer science course covers topics like source control and testing. He's been wanting to get into formal Computer Science for a while, so when he pulled back on his work at the Pragmatic Bookshelf, he approached SMU about teaching a course. He selected Advanced Application Development since he could teach pretty much whatever he wanted. The class is made up of Seniors and Master's students whose coursework primarily focused on theory, but lacked in the basics of coding as it happens "in the wild." The plan was to go in and subvert them with Elixir.  All of the assignments are coding assignments and must be submitted with a pull request. Chuck recalls taking a class similar to the one that Dave describes.  [00:06:22] Computer Science's focus on theory People who go into academia generally get their degrees and don't spend any time in the non-academic world. So, they don't know what's important when it comes down to nuts and bolts programming. This serves the students that stay in academia, but fails to teach the skills needed by their students. They also focus on the mathematical aspects of Computer Science and fail to show students that if they get excited about software, it can be fun. [00:09:55] This is a job where we make a difference Sometimes we do great harm. and sometimes great good. [00:10:23] How do you communicate all of these aspects of coding to the students? You can't just tell them. Mostly, Dave just tries to be enthusiastic. The teaching as it's done now is like a eulogy given by someone who doesn't know the person. Instead, Dave shows his passion for coding, tells stories, and shows how fun it is to write code. Imagine walking down the street and seeing the code you wrote being used. Dave's code was used on the satellite sent to see Haley's Comet. [00:13:04] Software as a tool for change A painter's medium is paint. Sculptors' stone. People in software don't "write" per se, but they still express themselves. This is a medium for programmers to get their thoughts out and interact with other people all over the world. We do a really crappy job explaining this to students. Dave is involved in after-school programs for software development as well. The ones that succeed don't approach software head on. They do fun and fancy stuff with Raspberry Pi or put a webserver up and then point out the concepts used in the programming. This approach is the future of development training. [00:16:01] Do you feel like CS programs aren't preparing students well? or have the wrong focus? Students come out well versed in the theoretics of programming and can write programs. These are good things to know. The assumption is that they'll pick up the rest in their first couple of jobs. They're not preparing people to walk straight into a job, but prepares them to learn the rest on the job. A 4 year program should be done after 2 years working in the real world. Most of the things not taught don't make sense until the student has the problem that it solves. For example, source control. This would give them context for the things that are important and bring the knowledge back to the  [00:20:26] What is in the curriculum? In a few years, these students will probably be writing a functional language like Elixir. They start out writing a hangman game using Elixir. Then they add Phoenix. Then they add a webserver. The focus is around the fact that what you care about is state and transformations. Then someone will realize that you're really just implementing objects. Dave is trying to teach how to think in decoupled services. [00:22:28] The future is functional? Elixir is a practical functional language and solves some problems that programmers have been trying to solve for a long time. Clojure has a strange relationship with the JVM. Elixir is not as cleanly functional as other languages, but it's functional enough. At the same time, you can write kick-ass web services as well. You also get the power of the Erlang virtual machine. Looking at Moore's Law, why aren't our processors getting faster? Over the last 10 years, they're not that much faster and the next generations are slower. But they have more cores. If you double the clock speed, you 8x the power dissipation. So, there's a limit to how fast you can go before you melt the processor. So, you run more cores at a lower speed. This vastly increases your processing power and lower your consumption. If you're writing processes that run on a core from start to finish, then it only uses 1/16th of the processor's power (if it has 16 cores.) So, we need a programming paradigm that supports parallelism. Concurrent programming is hard.  Making data immutable makes it so you can eliminate common problems with threading and concurrency. Read-only (immutable) Object Oriented programming is effectively functional programming. We should see this change occur over the next 3-7 years.  [00:31:05] Most of the people at Ruby conferences are using Elixir When Dave goes to conferences about Ruby, he finds out that about 50% of speakers and many of the attendees are doing Elixir and/or experimenting heavily with it. Ruby and Rails changed the way we work, but in many ways the functional programming is changing things again. Scaling matters. We can't just throw hardware at it. You can drop your server bill by 10x or 100x. Elixir can get you there fast like Ruby, but it can also cut costs of running your server. [00:35:43] Is a computer science degree that way to get in? or should people get in through bootcamps or self learning? It depends on your learning style. You do not want to get into Computer Science because your parents wanted you to have a good job. The students that get into it because of family pressure don't love what they're doing and are kind of stuck. Programming is hard enough that if you don't enjoy it you won't excel. In any case, do what works for you. You don't need to do a 4 year course of study to be a successful programmer. Quite a few good programmers Dave knows never took a CS course. If you do a course, find out that if the teachers are doing or have done the kinds of things you want to do. The better IT shops also tend to recognize that it's the person, not what they know, that really matters. So go to them and ask to apprentice with their good programmers at a lower salary. Then if you're contributing, ask for a competitive salary. [00:41:03] What do we as programmers assume about CS degrees that we need to change? Don't let the HR department do the hiring. Making them happy is what gets you bogus job requirements. Instead, put together some requirements that hint that enthusiasm trumps everything else. Or, have criteria like "must be able to fog a mirror" and pick for enthusiasm. Or, go to local maker groups or users groups or community colleges where the kinds of people you want are, and talk to people. Then network into the people you want. Ignore the qualifications and pay attention to the qualities. One of the best people Dave hired was an alcoholic chemistry teacher, but he could get into a project. [00:45:00] You don't want a career. Spend the next 5-10 years job hopping. You want experience, not a career. You have no idea what you want to do right now, so try lots of things. Then if it's not working move on. Picks Charles: Ubuntu Bash on Windows VMWare Workstation: https://www.vmware.com/products/workstation.html Dave: Have something in your life that is relatively simple and relatively mechanical that you can fix if something goes wrong. (Dave tells us about his tractor.)

RR 317: Computer Science at University and the Future of Programming with Dave Thomas Charles Max Wood interviews Dave Thomas about the Computer Science course he's teaching at Southern Methodist University, Elixir, and the future of programming. Dave is the author and co-author of several well known programming books including Programming Ruby (also known as the PickAxe Book), Programming Elixir, and the Pragmatic Programmer. This episode starts out discussing Dave's course and Computer Science education, then veers into Elixir and the future of programming. Tune in to hear where Dave thinks the programming industry is heading next. [00:02:30] Dave's Computer Science Course at SMU  Dave's advanced computer science course covers topics like source control and testing. He's been wanting to get into formal Computer Science for a while, so when he pulled back on his work at the Pragmatic Bookshelf, he approached SMU about teaching a course. He selected Advanced Application Development since he could teach pretty much whatever he wanted. The class is made up of Seniors and Master's students whose coursework primarily focused on theory, but lacked in the basics of coding as it happens "in the wild." The plan was to go in and subvert them with Elixir.  All of the assignments are coding assignments and must be submitted with a pull request. Chuck recalls taking a class similar to the one that Dave describes.  [00:06:22] Computer Science's focus on theory People who go into academia generally get their degrees and don't spend any time in the non-academic world. So, they don't know what's important when it comes down to nuts and bolts programming. This serves the students that stay in academia, but fails to teach the skills needed by their students. They also focus on the mathematical aspects of Computer Science and fail to show students that if they get excited about software, it can be fun. [00:09:55] This is a job where we make a difference Sometimes we do great harm. and sometimes great good. [00:10:23] How do you communicate all of these aspects of coding to the students? You can't just tell them. Mostly, Dave just tries to be enthusiastic. The teaching as it's done now is like a eulogy given by someone who doesn't know the person. Instead, Dave shows his passion for coding, tells stories, and shows how fun it is to write code. Imagine walking down the street and seeing the code you wrote being used. Dave's code was used on the satellite sent to see Haley's Comet. [00:13:04] Software as a tool for change A painter's medium is paint. Sculptors' stone. People in software don't "write" per se, but they still express themselves. This is a medium for programmers to get their thoughts out and interact with other people all over the world. We do a really crappy job explaining this to students. Dave is involved in after-school programs for software development as well. The ones that succeed don't approach software head on. They do fun and fancy stuff with Raspberry Pi or put a webserver up and then point out the concepts used in the programming. This approach is the future of development training. [00:16:01] Do you feel like CS programs aren't preparing students well? or have the wrong focus? Students come out well versed in the theoretics of programming and can write programs. These are good things to know. The assumption is that they'll pick up the rest in their first couple of jobs. They're not preparing people to walk straight into a job, but prepares them to learn the rest on the job. A 4 year program should be done after 2 years working in the real world. Most of the things not taught don't make sense until the student has the problem that it solves. For example, source control. This would give them context for the things that are important and bring the knowledge back to the  [00:20:26] What is in the curriculum? In a few years, these students will probably be writing a functional language like Elixir. They start out writing a hangman game using Elixir. Then they add Phoenix. Then they add a webserver. The focus is around the fact that what you care about is state and transformations. Then someone will realize that you're really just implementing objects. Dave is trying to teach how to think in decoupled services. [00:22:28] The future is functional? Elixir is a practical functional language and solves some problems that programmers have been trying to solve for a long time. Clojure has a strange relationship with the JVM. Elixir is not as cleanly functional as other languages, but it's functional enough. At the same time, you can write kick-ass web services as well. You also get the power of the Erlang virtual machine. Looking at Moore's Law, why aren't our processors getting faster? Over the last 10 years, they're not that much faster and the next generations are slower. But they have more cores. If you double the clock speed, you 8x the power dissipation. So, there's a limit to how fast you can go before you melt the processor. So, you run more cores at a lower speed. This vastly increases your processing power and lower your consumption. If you're writing processes that run on a core from start to finish, then it only uses 1/16th of the processor's power (if it has 16 cores.) So, we need a programming paradigm that supports parallelism. Concurrent programming is hard.  Making data immutable makes it so you can eliminate common problems with threading and concurrency. Read-only (immutable) Object Oriented programming is effectively functional programming. We should see this change occur over the next 3-7 years.  [00:31:05] Most of the people at Ruby conferences are using Elixir When Dave goes to conferences about Ruby, he finds out that about 50% of speakers and many of the attendees are doing Elixir and/or experimenting heavily with it. Ruby and Rails changed the way we work, but in many ways the functional programming is changing things again. Scaling matters. We can't just throw hardware at it. You can drop your server bill by 10x or 100x. Elixir can get you there fast like Ruby, but it can also cut costs of running your server. [00:35:43] Is a computer science degree that way to get in? or should people get in through bootcamps or self learning? It depends on your learning style. You do not want to get into Computer Science because your parents wanted you to have a good job. The students that get into it because of family pressure don't love what they're doing and are kind of stuck. Programming is hard enough that if you don't enjoy it you won't excel. In any case, do what works for you. You don't need to do a 4 year course of study to be a successful programmer. Quite a few good programmers Dave knows never took a CS course. If you do a course, find out that if the teachers are doing or have done the kinds of things you want to do. The better IT shops also tend to recognize that it's the person, not what they know, that really matters. So go to them and ask to apprentice with their good programmers at a lower salary. Then if you're contributing, ask for a competitive salary. [00:41:03] What do we as programmers assume about CS degrees that we need to change? Don't let the HR department do the hiring. Making them happy is what gets you bogus job requirements. Instead, put together some requirements that hint that enthusiasm trumps everything else. Or, have criteria like "must be able to fog a mirror" and pick for enthusiasm. Or, go to local maker groups or users groups or community colleges where the kinds of people you want are, and talk to people. Then network into the people you want. Ignore the qualifications and pay attention to the qualities. One of the best people Dave hired was an alcoholic chemistry teacher, but he could get into a project. [00:45:00] You don't want a career. Spend the next 5-10 years job hopping. You want experience, not a career. You have no idea what you want to do right now, so try lots of things. Then if it's not working move on. Picks Charles: Ubuntu Bash on Windows VMWare Workstation: https://www.vmware.com/products/workstation.html Dave: Have something in your life that is relatively simple and relatively mechanical that you can fix if something goes wrong. (Dave tells us about his tractor.)

RR 317: Computer Science at University and the Future of Programming with Dave Thomas Charles Max Wood interviews Dave Thomas about the Computer Science course he's teaching at Southern Methodist University, Elixir, and the future of programming. Dave is the author and co-author of several well known programming books including Programming Ruby (also known as the PickAxe Book), Programming Elixir, and the Pragmatic Programmer. This episode starts out discussing Dave's course and Computer Science education, then veers into Elixir and the future of programming. Tune in to hear where Dave thinks the programming industry is heading next. [00:02:30] Dave's Computer Science Course at SMU  Dave's advanced computer science course covers topics like source control and testing. He's been wanting to get into formal Computer Science for a while, so when he pulled back on his work at the Pragmatic Bookshelf, he approached SMU about teaching a course. He selected Advanced Application Development since he could teach pretty much whatever he wanted. The class is made up of Seniors and Master's students whose coursework primarily focused on theory, but lacked in the basics of coding as it happens "in the wild." The plan was to go in and subvert them with Elixir.  All of the assignments are coding assignments and must be submitted with a pull request. Chuck recalls taking a class similar to the one that Dave describes.  [00:06:22] Computer Science's focus on theory People who go into academia generally get their degrees and don't spend any time in the non-academic world. So, they don't know what's important when it comes down to nuts and bolts programming. This serves the students that stay in academia, but fails to teach the skills needed by their students. They also focus on the mathematical aspects of Computer Science and fail to show students that if they get excited about software, it can be fun. [00:09:55] This is a job where we make a difference Sometimes we do great harm. and sometimes great good. [00:10:23] How do you communicate all of these aspects of coding to the students? You can't just tell them. Mostly, Dave just tries to be enthusiastic. The teaching as it's done now is like a eulogy given by someone who doesn't know the person. Instead, Dave shows his passion for coding, tells stories, and shows how fun it is to write code. Imagine walking down the street and seeing the code you wrote being used. Dave's code was used on the satellite sent to see Haley's Comet. [00:13:04] Software as a tool for change A painter's medium is paint. Sculptors' stone. People in software don't "write" per se, but they still express themselves. This is a medium for programmers to get their thoughts out and interact with other people all over the world. We do a really crappy job explaining this to students. Dave is involved in after-school programs for software development as well. The ones that succeed don't approach software head on. They do fun and fancy stuff with Raspberry Pi or put a webserver up and then point out the concepts used in the programming. This approach is the future of development training. [00:16:01] Do you feel like CS programs aren't preparing students well? or have the wrong focus? Students come out well versed in the theoretics of programming and can write programs. These are good things to know. The assumption is that they'll pick up the rest in their first couple of jobs. They're not preparing people to walk straight into a job, but prepares them to learn the rest on the job. A 4 year program should be done after 2 years working in the real world. Most of the things not taught don't make sense until the student has the problem that it solves. For example, source control. This would give them context for the things that are important and bring the knowledge back to the  [00:20:26] What is in the curriculum? In a few years, these students will probably be writing a functional language like Elixir. They start out writing a hangman game using Elixir. Then they add Phoenix. Then they add a webserver. The focus is around the fact that what you care about is state and transformations. Then someone will realize that you're really just implementing objects. Dave is trying to teach how to think in decoupled services. [00:22:28] The future is functional? Elixir is a practical functional language and solves some problems that programmers have been trying to solve for a long time. Clojure has a strange relationship with the JVM. Elixir is not as cleanly functional as other languages, but it's functional enough. At the same time, you can write kick-ass web services as well. You also get the power of the Erlang virtual machine. Looking at Moore's Law, why aren't our processors getting faster? Over the last 10 years, they're not that much faster and the next generations are slower. But they have more cores. If you double the clock speed, you 8x the power dissipation. So, there's a limit to how fast you can go before you melt the processor. So, you run more cores at a lower speed. This vastly increases your processing power and lower your consumption. If you're writing processes that run on a core from start to finish, then it only uses 1/16th of the processor's power (if it has 16 cores.) So, we need a programming paradigm that supports parallelism. Concurrent programming is hard.  Making data immutable makes it so you can eliminate common problems with threading and concurrency. Read-only (immutable) Object Oriented programming is effectively functional programming. We should see this change occur over the next 3-7 years.  [00:31:05] Most of the people at Ruby conferences are using Elixir When Dave goes to conferences about Ruby, he finds out that about 50% of speakers and many of the attendees are doing Elixir and/or experimenting heavily with it. Ruby and Rails changed the way we work, but in many ways the functional programming is changing things again. Scaling matters. We can't just throw hardware at it. You can drop your server bill by 10x or 100x. Elixir can get you there fast like Ruby, but it can also cut costs of running your server. [00:35:43] Is a computer science degree that way to get in? or should people get in through bootcamps or self learning? It depends on your learning style. You do not want to get into Computer Science because your parents wanted you to have a good job. The students that get into it because of family pressure don't love what they're doing and are kind of stuck. Programming is hard enough that if you don't enjoy it you won't excel. In any case, do what works for you. You don't need to do a 4 year course of study to be a successful programmer. Quite a few good programmers Dave knows never took a CS course. If you do a course, find out that if the teachers are doing or have done the kinds of things you want to do. The better IT shops also tend to recognize that it's the person, not what they know, that really matters. So go to them and ask to apprentice with their good programmers at a lower salary. Then if you're contributing, ask for a competitive salary. [00:41:03] What do we as programmers assume about CS degrees that we need to change? Don't let the HR department do the hiring. Making them happy is what gets you bogus job requirements. Instead, put together some requirements that hint that enthusiasm trumps everything else. Or, have criteria like "must be able to fog a mirror" and pick for enthusiasm. Or, go to local maker groups or users groups or community colleges where the kinds of people you want are, and talk to people. Then network into the people you want. Ignore the qualifications and pay attention to the qualities. One of the best people Dave hired was an alcoholic chemistry teacher, but he could get into a project. [00:45:00] You don't want a career. Spend the next 5-10 years job hopping. You want experience, not a career. You have no idea what you want to do right now, so try lots of things. Then if it's not working move on. Picks Charles: Ubuntu Bash on Windows VMWare Workstation: https://www.vmware.com/products/workstation.html Dave: Have something in your life that is relatively simple and relatively mechanical that you can fix if something goes wrong. (Dave tells us about his tractor.)

So, a lot of you guys requested a Top 10 Ruby Books and well... There you have it! Lately, I've been doing a lot of different Top Books on my channel. I figured it is an awesome way of providing a good way to start for those who want to learn new programming languages or even for those people that want to study more about a specific language. So, in this video I'll give you my Top 10 Ruby Books. This will be an awesome resource for those who want to learn Ruby, especially nowadays if a lot of information overload. Having focus and knowing where you want to go will definitely make a big difference on how fast you'll learn Ruby. Ruby is a general purpose programming language created in the 1990s by Yukihiro “Matz” Matsumoto. It’s also one of the best languages to start with when you’re first learning to code. The general purpose nature of Ruby makes it suitable for a wide array of programming tasks, just like Perl, Python and other general purpose languages. The key features of Ruby focus on developer "happiness" and ease of use, making it a good language for those just learning to program and for those who want to get more done with less code. It's pervasive object-oriented features also make it very intuitive. So... Do you want to learn Ruby? Here are the Top 10 Books you should be aware. Beginning Ruby: https://simpleprogrammer.com/beginningruby The Well-Grounded Rubyist: https://simpleprogrammer.com/wellgroundedrubyist Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide: https://simpleprogrammer.com/pragmaticruby Ruby Cookbook: Recipes for Object-Oriented Scripting: https://simpleprogrammer.com/rubycookbook Effective Ruby: 48 Specific Ways to Write Better Ruby: https://simpleprogrammer.com/effectiveuby Metaprogramming Ruby 2: Program Like the Ruby Pros: https://simpleprogrammer.com/metaprogrammingruby Eloquent Ruby (Addison-Wesley Professional Ruby): https://simpleprogrammer.com/eloquentruby Clean Ruby: https://simpleprogrammer.com/cleanruby Agile Web Development with Rails 5: https://simpleprogrammer.com/agilewebrails5 Learn Ruby the Hard Way: https://simpleprogrammer.com/rubyhardway Top 10 C++ Books (Beginner & Advanced): https://www.youtube.com/watch?v=nXFBJkTCabA&index=6&list=PLjwWT1Xy3c4XoA9VdooMPPiDFsckl1d_2

Спонсор выпуска — Vexor CI – облачный continuous integration сервис для ruby разработчиков с поминутной оплатой. С учетом поминутной оплаты, Vexor очень выгоден для маленьких проектов и эффективен для больших. Каждому новому пользователю предоставляется $10 на счет для экспериментов. Попробовать Vexor CI Расшифровки Коллекция рецептов для быстрого руби от Эрика. Интервью с Эриком Кир Первый раз в Москве? Эрик Ага, да. Кир И как тебе Москва, что думаешь о городе? Эрик Очень красивый город. Первый раз тут, и мне все очень нравится. Погода хорошая; вчера гуляли, были в музее космонавтики и в музее холодной войны — было здорово. Кир Круто. Эрик Ага. Кир Так вот. Ты работаешь в SoundCloud, в Берлине? Эрик Да! Кир Можешь рассказать об архитектуре SoundCloud? Эрик Так, в SoundCloud мы используем архитектуру микросервисов. Я работаю в команде, которая занимается платформой, проще говоря — серверным API. Публичный API — который используется, если использовать SoundCloud API — там запросы обрабатываются Rails приложением. Но вот как мы работаем.. Как только у нас появляются новые сервисы, и есть смысл их как-то отделить от основного, сделать их отдельным сервисом — мы так и делаем. В общем, мы используем Ruby, Rails, еще довольно много используем Scala, Clojure; все наши утилиты командной строки написаны на Go. Да, у нас даже сервисы на Julia есть. Все зависит от того, что лучше подойдет для задачи, которую мы пытаемся решить. Кир Интересно. То есть, как я понимаю, вы мигрировали с монолитного Rails приложения, да? Эрик Да! Думаю, многие компании, когда они развиваются и начинают масштабироваться, переходят с такой монолитной архитектуры приложения на архитектуру микросервисов. И да, мы довольно далеко в этом деле продвинулись. Кир Ясно. Давай поговорим про open source, над которым ты работал — какой проект твой любимый? Эрик Ох, их много — сложно выбрать. Не знаю, некоторые обертки над API, над которыми я работал — таких было несколько.. Я сделал octokit, обертку над API GitHub; еще обертку над API RubyGems.org, чтобы можно было доставать метаданные о gem'ах. Ну и, наверное, самая популярная обертка, которую я сделал — gem twitter. Да и gem soundcloud, я его сейчас поддерживаю, но автором был не я. Да, думаю, решать проблемы такого рода, причем несколько раз для разных сервисов, стало таким неплохим шаблоном, так что я горжусь теми gem'ами. Думаю, приемы работы над кодом, которые я использовал там, приводят к коду довольно чистому, хорошо покрытому тестами, и все такое. И, знаешь, наверное самый популярный мой gem — это rails_admin, там код и близко не такой чистый, так что для меня над ним не так приятно работать по этой причине. Каждый раз, когда с ним работаю, всегда нахожу какие-то вещи, которые стоит зарефакторить; но раз уж столько людей его используют, просто приятно было сделать что-то такое — люди постоянно ко мне подходят, благодарят. Так что им приятно заниматься по другой причине — не из-за красоты кода, а из-за пользы, которую он дает. Кир Понятно. А что вообще помогает тебе работать над новыми open source проектами? Эрик Ну, думаю, как и у всех — главная причина, наверное, в том, что когда я использую какой-то проект и нахожу баг, я вкладываюсь в проект просто чтобы пофиксить этот самый баг, или просто в какой-то степени этот проект улучшить. Иногда я начинаю проекты только затем, чтобы чему-то научиться — попробовать в деле новый фреймворк или новый язык; да, в общем, получается такое игрушечное приложение или игрушечная библиотека, и тогда нет причин не выпустить этот код как open source, чтобы другие люди могли учиться так же, как учился я, или научиться чему-то на моих ошибках. Да я и сам учусь на своих ошибках, потому что когда ты выпускаешь что-то как open source, другие люди видят твою работу, присылают пулл-реквесты, чтобы ее улучшить, и каждый раз, когда это происходит — это возможность мне чему-то научиться; другие же люди это увидят и тоже сделают какие-то выводы для себя. Кир Точняк. Ты упомянул, что в SoundCloud используется много разных языков, так вот, есть у тебя какой-то open source не на Ruby? Эрик Да, у нас есть. Кир Scala, Clojure? Эрик Да-да. Посмотри на https://github.com/soundcloud, думаю, у нас там больше сотни публичных репозиториев. И да, там есть проекты на Ruby, наш самый популярный — Large Hadron Migrator, LAM (https://github.com/soundcloud/lhm). Там идея в том, что если у тебя есть действительно здоровенная база данных (MySQL — прим. пер.), и тебе нужно сделать миграцию, с помощью этого проекта можно это сделать без даунтайма. Если на пальцах, он работает вот так: копирует таблицу, прогоняет миграцию на копии, потом на копию переносит все данные, которые скопились с момента начала миграции. Довольно эффективный способ делать миграции в БД. Нам этот проект был реально нужен, у нас были очень большие таблицы в MySQL, на которых нужно было делать миграции, а если мы делали обычные миграции, мы могли попасть на несколько часов даунтайма. Так что мы сделали такой вот инструмент. Другие компании, у которых тоже было много строк в таблицах их баз данных, большие таблицы, и нужно было делать миграции над ними, тоже оценили наше решение. Кир На каком это языке? Эрик На Ruby. Так что да, это в основном для миграций с Rails. Но у нас.. Если посмотреть на https://github.com/soundcloud, у нас есть репозитории почти на всех языках, что можно представить — Ruby, Clojure, Scala, Go.. Как я уже говорил, у нас есть код на Julia, думаю, мы его тоже выложили. Да, ну и на других языках. В SoundCloud мы гордимся тем, что всегда используем лучший инструмент для каждой конкретной задачи, а инженеры принимают решения основываясь на том, что по их мнению лучше всего использовать. Так что если давать инженерам автономию для принятия решений, последуют лучшие решения, чем если в компании просто есть правила — «использовать один язык для всего», или «использовать этот фреймворк для всего». И даже внутри нашей организации, мы иногда используем Rails, иногда Sinatra или другие фреймворки. Это действительно зависит только от характера проблемы, которую мы пытаемся решить. Кир Какое будущее у Ruby, по твоему мнению? Эрик Хм. Хороший вопрос. Надеюсь, что будущее будет таким же, как и прошлое — за последнее время каждый год выходит новая версия Ruby, и каждый раз она быстрее и лучше предыдущей. Так что да, надеюсь, такое продолжится в будущих версиях. Что я действительно хотел бы видеть (я упомянул об этом в своем докладе), так это JIT компилятор в MRI (CRuby). Кажется, над этим уже работают, так что я настроен оптимистично — думаю, скоро мы это увидим. Так же, как и AOT компилятор. Я еще работаю над парой интерфейсов для командной строки; Ruby не очень хорош для работы с командной строкой, потому что время запуска может быть большим, а вот если был бы компилятор, который бы предварительно парсил весь Ruby код в бинарник, было бы круто — особенно для штук вроде CLI (Command-Line Interface — прим. пер.). Так что вот, JIT и AOT компиляторы. И еще получше примитивы для параллелизма. Матц говорил, что он сожалеет о решении использовать Thread как главный примитив для параллелизма в Ruby, так что он вместе с Core Team думает над использованием actors, и может каких-то еще примитивов. Чтобы они появились в core библиотеках языка. Так что я этого очень жду, думаю, будет круто. Кир Да, я заметил тренд с переписыванием инструментов командной строки на Go. Эрик Да, точно. Кир Вот Heroku так делает. Эрик Да, это хороший пример. Их CLI для выполнения разных команд, раньше был на Ruby, но, вообще, думаю, он намного лучше стал на Go, по ряду причин. Во-первых, у Go весь runtime включен в бинарник, так что нет такой зависимости, как Ruby — не надо сначала устанавливать Ruby, а потом уже CLI. Можно просто установить бинарник, в котором все уже есть. Ну и то еще, что можно кросс-компилировать сразу на несколько разных платформ, делает разработку инструментов для командной строки намного проще. И вообще тот факт, что Go — язык компилируемый, означает, что никакой подготовки кода во время запуска нет, как в Ruby. Так что если есть, скажем, 30 библиотек, от которых зависит инструмент, то в Ruby даже для самой простой операции сначала нужно пропарсить все эти библиотеки, а это может занять много времени, особенно если нужно выполнить какую-то простую команду — такую, как help, version или что-то такое, и во многих CLI на Ruby это работает куда медленнее, чем должно бы. Так что AOT компилятор существенно этому поможет, Ruby сможет составить конкуренцию языкам вроде Go в борьбе за CLI. Кир Давай поговорим о Берлине. Эрик Ага. Кир Что ты думаешь о стартап-культуре, об атмосфере? Эрик Очень хорошая. Я переехал в Берлин из Сан-Франциско, где я до этого прожил 8 лет. И в Сан-Франциско чувствуется такое отношение, словно это единственное место в мире, где можно сделать стартап, и что если тебе нужно сделать стартап, то нужно переехать в Сан-Франциско, если хочешь добиться успеха. Это сработало для многих компаний, но в SoundCloud нам этого делать не пришлось. Есть много преимуществ работы в Берлине. Главное преимущество — мы можем нанимать талантливых людей со всей Европы, да и со всего мира, вообще говоря. У нас отличный офис, где есть разработчики из.. кажется, 35 разных стран, или вроде того. Думаю, эмиграционные законы США делают такое куда более сложным. У меня был такой скепсис, когда я переезжал из Сан-Франциско, но.. Мои коллеги — невероятно талантливые люди, я каждый день у них чему-то учусь. Да, Берлин — отличное место для работы. И стартап сцена — не только SoundCloud, у нас куча других стартапов! От самых маленьких, где пара человек работают над какой-то идеей, до людей, которые уже подняли венчурный капитал и теперь быстро растут. Да и просто классное сообщество и отношение. Митапы каждую неделю, наверное, даже каждый день — можно ходить на разные технарские митапы в Берлине. И вот что еще круто в Берлине: классное сообщество для тех, кто хочет учиться. То есть, если вы хотите научиться программированию, или если вы пока юниор, и вы ищете возможность подкачаться, Берлин — отличное для этого место. Вот Rails Girls начинались не в Берлине, но благодаря Travis CI, да, там много классных людей — Свен (Sven Fuchs — прим. пер.), Аника (Anika Lindtner — прим. пер.), да и вся команда — Джош (Josh Kalderimis — прим. пер.), Константин (Konstantin Haase — прим. пер.)… Такое комьюнити они создали! Меня пригласили выступить на Eurucamp пару лет назад — тогда я в первый раз оказался в Берлине, еще до того, как я туда переехал. Перед конференцией я побыл коучем на Rails Girls, и это был первый раз, когда я помогал на Rails Girls, и было круто. Но, думаю, Rails Girls проводятся в Берлине уже очень давно, теперь и Summer of Code проводится оттуда. Есть целые четыре разные команды Summer of Code, которые расположены в Берлине. Так что вот, это отличное место для того, чтобы научиться программированию и прокачаться. Кир Все, спасибо большое! Эрик Да, конечно. Спасибо за вопросы! Интервью с Божидаром Ярослав Привет, Божидар! Как тебе Москва? Божидар Все здорово. Фантастический город, счастлив, что я здесь и что меня пригласили. Это мой первый визит в Россию, для меня все в новинку и очень увлекательно. У вас прекрасный город, прекрасная страна. Ярослав Первый вопрос будет про Rubocop. Многие из наших ребят знают о gem parser нашей местной знаменитости, Петра (Зотова — прим. пер), который, кстати, выступал в прошлом году на этой самой конференции. Можешь рассказать немного о том, как parser и Rubocop работают вместе? Божидар Да, конечно. Когда я начал работать над Rubocop, я использовал Ripper, внутренний парсер MRI, у которого есть две фундаментальные проблемы: во-первых, он работает только с MRI, что сделало бы Rubocop несовместимым с JRuby и Rubinius. Во-вторых, он генерит ужасный AST. Я пытался отправить несколько багфиксов в Ripper, но стало понятно, что это ни к чему не приведет. В одном из сообщений об ошибке, которое я открыл на официальном багтрекере Ruby, кто-то упомянул, что мне лучше бы не использовать Ripper вообще, потому что есть новая библиотека под названием parser от Петра. Я ее посмотрел, она работала замечательно, выдавала отличный формат AST, в общем, делала ровно то, что нужно. Была переносимой, правда очень глючной, но я намеревался работать с ней, несмотря на это. В основном из-за Петра, отличного мейнтейнера. Я зарепортил, наверное, около 50 багов, или вроде того. И он обычно отвечал в течение пары часов. После того, как вышла первая версия Rubycop с использованием parser, обнаружилось еще больше багов — пользователи умудрялись писать такой Ruby код, что мы даже не знали о том, что так можно написать. Но в течение следующих релизов Петр все исправил, и я уверен, что это лучшая библиотека из тех, что существуют. Производительность отличная, почти так же быстро, как и с Ripper, но выдаются структуры данных намного проще, с этим намного приятнее работать. Если мне бы пришлось работать с Ripper, я бы, наверное, забросил Rubocop. Ярослав Мы говорим о Ripper, но ведь еще есть gem.. как его.. Божидар ruby_parser? Ярослав Да, ruby_parser. Божидар Да, проблема с ruby_parser была в том, что его не мейнтейнили особенно. Думаю, Петр изначально хотел улучшить ruby_parser (так и было — прим. пер.); он был совместим с Ruby 1.8, но не обновлялся для 1.9. Я видел от него несколько пулл-реквестов, но ребята, которые мейнтейнили ruby_parser, сказали, что изменения слишком сложные, или что-то в этом духе, и что они не будут их применять. Думаю, это и было мотивацией для Петра сделать новый gem. И еще дело было в том, что ruby_parser не был так производителен, как parser, так что при работе с огромными проектами это могло стать проблемой — можно было ждать целый час, пока идет анализ кода. Ярослав Ага. Следующий вопрос про твою самую известную работу — Ruby Guide. Можешь рассказать о процессе, о том как ты работаешь над ним? У тебя просто появился набор каких-то правил, ты сделал первый коммит и потом ты начал их обновлять? Как ты итерируешь, как обновляешь эти правила? Думаешь ли ты, что многие из них обязательные, или какие-то нет? В общем, твой Ruby Style Guide и Rails Style Guide не высечены в камне, они обновляются, так что хочется послушать про процесс. Например, как ты их валидируешь. Божидар Ну, обычно я делаю что-то, что называю проверкой толпой (Crowd Validation). Я добавляю правила иногда, когда натыкаюсь на хорошие идиомы в книгах, докладах; встречаю что-то, чего я раньше не замечал. Если я делаю правки и они не вызывают существенной негативной реакции в сообществе, значит, это и правда хорошая рекомендация. Если я что-то добавляю и все начинают на это жаловаться, значит, я сделал ошибку. Если мнения разделяются, мы начинаем вдаваться в детали. Например, мы делаем поиск по ruby-исходникам на GitHub, и если мы видим, что недавно добавленное или предложенное правило имеет смысл, если большинство отобранных проектов используют это правило, иначе мы его убираем, или правим существующее правило. Это уже много раз случалось. Но, в конце концов, кто-то должен проталкивать эти правила — обычно это не только я; можно видеть, что довольно много людей предлагают новые правила. Но я всегда стараюсь делать проверку, чтобы быть уверенным, что мы не предлагаем что-то, что нарушает сложившиеся практики. Так что если что-то звучит как хорошая идея, но никто ее не придерживается, мы не будем ее рекомендовать. Мы не хотим заставлять кого-то следовать стилю, который не принимается, не является естественным для Ruby сообщества. Ярослав Ясно. А ты начал с своего собственного набора правил, или ты использовал другие источники для вдохновления? Божидар Я начал с правил, которые я собрал из моих любимых книг по Ruby. В основном.. Моя любимая книга по Ruby — это, наверное, “The Ruby Programming Language”.. Ярослав Pickaxe? Божидар Не-не. Это “Programming Ruby”. Ярослав А, другая. Божидар Да. Так вот, я начал с советов из «Библии», то есть, единственной книжки, написанной самим Матцем, по крайней мере, частично. Я детально сверил стиль, который он использует, со стилем, который используется в Pickaxe. Были некоторые различия в верстке кода, например, Матц не использовал столько пустого места, отбивок, как использовал Дейв Томас, а я люблю читаемый код. Так что я взял у Дейва стиль для таких случаев. После этого, я начал добавлять вещи из “Eloquent Ruby”, “The Ruby Way” — книг, которые я считаю каноническими для сообщества. Так что начинал я оттуда, а после первого публичного релиза гайда, я получил массу отзывов — часто с приложенным анализом использования из поиска по GitHub, о котором я уже говорил. Например, все книги утверждали, что стоит избегать использования тернарного оператора, а использовать вместо него if/then/else в одну строку, но оказалось, что ни в одном Ruby проекте такого нет, наоборот, все используют тернарный оператор. Да, так что если люди хотят писать код так, кто я такой, чтобы им запрещать. Так что мы изменили это правило, да и другие правила тоже подверглись изменениям с изначальной версии. Мы обновляем правила все время. Например, когда все начиналось, еще не было Ruby 2.0 и 2.1, так что не было правил о аргументах-ключсловах (keyword arguments), использованию private на той же строке, что и определение метода, потому что это не имело смысла. Но гайд постоянно развивается, и, думаю, чем больше проходит времени, тем больше мы приближаемся к настоящей душе Ruby-стиля. Ярослав Я спрашивал, потому что еще до того, как я увидел твой гайд, был гайд от Кристиана, автора Rack (https://github.com/chneukirchen/styleguide — прим. пер.). Видел его? Божидар Да, видел. Ярослав Я его использовал неоднократно для обучения внутри команды, и только потом увидел твой гайд, который намного больше и подробнее. Божидар Да, я проводил поиски по гайдам. Я видел этот, видел веб-страницу, не помню URL, что-то от zenspider, наверное. Я видел три ресурса, но во всех отсутствовали примеры. Были правила, но без объяснений о том, почему это вообще хорошая идея. Некоторые правила были явно в противоречии с устоявшимися практиками. Это все были попытки, предпринятые одним человеком, больше похожие на личный набор правил. Вместо чего-то, что могло бы использоваться всеми, что и было моей целью. Потому что изначально я занимался документом по заказу компании. И мой проект случайно стал популярным. Ярослав Еще что хочу спросить о твоих гайдах. В каком-то смысле использование гайда по стилю — это как принятие методологии разработки ПО, методологии гибкой разработки ПО, например. Это много как можно сделать — кто-то делает все в точности по правилам, по книге, кто-то начинает использовать некоторые вещи и модифицирует их потом, и получается его собственная методология, и все такое. То есть, одни люди пишут книги, а другие люди просто используют их, как им заблагорассудится. Так как ты думаешь, как лучше всего применять твой гайд, или, может быть, как ты сам его применяешь на своих проектах, когда работаешь консультантом? Ты заставляешь людей ему следовать, или это процесс, шаг за шагом? Божидар Ну, обычно на моих проектах, Ruby Style Guide в его чистой форме дается как правило. Но это правило лишь до какой-то степени; некоторые правила абсолютны — например, не нужно мешать метод и его алиас в проекте, нужно выбрать одно название и использовать его везде. Правила про отступы тоже абсолютны, но, с другой стороны, у нас есть вещи вроде правил по метрикам: короткие методы, короткие классы, и вот они иногда довольно субъективны, нужно идти на нарушение правил: как ни старайся, иногда нельзя раздробить какую-то задачу на больше частей, чем ты уже сделал. Есть точка, после которой попытки упростить что-то просто вредны: больше это не оптимизация, ты уже делаешь код сложнее. Так что.. Есть другие такие правила, которые не следует применять вслепую.. Нужно думать. Я всегда говорю людям: это не десять заповедей, ниспосланные нам свыше. Многие из них — крайне разумные практики, и ничего плохого от их применения не случится, но нужно знать, когда их нарушать, и нужно знать, почему они были хорошей идеей изначально. Не нужно их нарушать, если нет четкой причины это делать. Ярослав Еще вопрос. Посмотрел на твой профиль на GitHub, и оказывается, что ты интересуешься Clojure. Божидар Да-а-а. Ярослав И у тебя даже гайд по стилю для Clojure есть. Не знал раньше. Так вот, в Ruby сообществе много разговоров идет.. В общем, на каждой Ruby конференции по крайней мере в России есть много людей, которым вообще не интересно разговаривать про Ruby, они хотят говорить про Clojure, Scala, функциональные языки, Elixir тоже популярная тема. Так вот, почему именно Clojure? Божидар Ну.. По той же причине, по которой я изначально выбрал Ruby. Я был очарован простотой и мощью языков из семейства Lisp. Когда я был начинающим программистом, я немного писал на Common Lisp. И потом я наткнулся на Ruby, и, хотя он не был Lisp'ом, очевидно, но в нем было много наследия Lisp. И это был язык, для работы на котором я хотя бы нашел людей, готовых мне заплатить. Rails был на волне, все хотели разрабатывать на Rails, веб. Это был хороший компромисс. Но сейчас есть Clojure, настоящий Lisp, со всей мощью, без ограничений Ruby. Все говорят о проблемах с производительностью Ruby, но, думаю, что есть ряд проблем, для которых объектно-ориентированный подход становится «бутылочным горлышком» в архитектуре. Ты сказал об Elixir, еще одном не-ООП языке, который недавно стал набирать популярность. Люди делают на нем классные вещи. Haskell становится популярным после того, как существовал уже 20 лет. Ярослав Да, но есть много людей, которые называют его академическим языком — в противовес Erlang и Clojure. Божидар Ну да, но нельзя отрицать и то, что количество open source проектов, использующих Haskell, выросло в 4 раза за последние пару лет. Не думаю, что люди занимаются на Haskell только исследованиями. Люди используют его для реальной, полезной работы. Есть известные веб-фреймворки для Haskell, его точно используют для решения реальных проблем, а не вычисления чисел Фибоначчи. Так что думаю, что с тем, как мультиядерность становятся нормой, языки, которые могут масштабироваться, языки, на которых можно строить распределенные системы, будут становиться все более и более популярными. А Ruby придется развиваться быстрее, или он потеряет в популярности. То, о чем ты говоришь — что люди на Ruby-конференциях здесь не хотят говорить о Ruby — это не случайность. Если посмотреть на Ruby-конференции в Штатах, например — всегда есть доклады об альтернативных языках. На последней конференции был доклад по Elixir, перед этим Рич Хики собственной персоной докладывался по Clojure на RubyConf (думаю, речь идет о RailsConf'2012 — прим. пер.), а это что-нибудь да значит. И еще нам нужно иметь в виду, что многие известные рубисты забросили Ruby и стали работать на других языках. Например, Аарон говорил о Хосе Валиме.. Ярослав С которого и начался Elixir, ага. Божидар Да. Я почти уверен, что ему Ruby уже не интересен — да, его компания известна среди рубистов, он все еще мейнтейнер Rails и сопутствующих проектов, что нужно для клиентов, но его настоящая страсть — Elixir. Он об этом сам несколько раз говорил. Был еще известный рубист, Фил Хагельберг (@technomancy — прим. пер.), сейчас он один из самых известных кложуристов. Ярослав Да, но он всегда был поклонником Emacs, и поклонником Lisp. Он был главным источником всего, что в Emacs было связано с Ruby. Все люди, которые начинали с Lisp в университете или школе, которые хакали на Emacs долгое время.. У них теперь время возмездия. Божидар Да, но думаю, что Ruby-программистов привлекает мощь всех этих новых альтернативных языков. Думаю, некоторые из хороших идей этих функциональных языков рано или поздно окажутся в Ruby. Я говорил об идее сделать строки иммутабельными, не уверен, как это можно сделать, учитывая что весь код, который зависит от строк, мутабелен, но люди говорят о персистентных структурах данных в Ruby. Матц говорил, что главная фича в Ruby 3.0 — фреймворк для параллелизма, видимо, похожий на actors. Весь мир ПО движется в этом направлении; нельзя отрицать и то, что нельзя бесконечно делать веб-приложения. Ландшафт рынка веб-приложений существенно изменился. Rails стал популярным, когда все веб-сайты были довольно стандартными. Была довольно статичная прослойка для представления, довольно простые модели. И сейчас все дошло до клиентских приложений, когда весь твой фронтенд — это отдельное приложение, а твое Rails-приложение — просто JSON-сервер. И ты начинаешь спрашивать себя — а нужен ли мне Rails только для JSON сервера? Почему бы мне не сделать приложение на чем-то высокопроизводительном — Java, Erlang? Потому что если избавиться от тесной интеграции представлений-моделей в Rails, его ценность резко уменьшается. Думаю, что мир ПО изменяется очень быстро, и сообщество Ruby и Rails должно реагировать мгновенно, или сгинет в геенне огненной. Как и много других классных технологий. Ярослав Депрессивно, но справедливо. Еще вопрос, чтобы не очень долго тебя задерживать. Очевидно, написание правильного Ruby — очень важная тема в эти дни. Ruby вырос, люди должны перестать делать отстойные приложения, чтобы их было проще поддерживать. Один из докладчиков на этой конференции — удаленный докладчик, правда — Сэнди Метц, она тоже рассказывает о способе писать на Ruby правильно, но она делает это с помощью книги. Вот. А у тебя есть гайд, с пятью тысячами вотчеров, кажется, на GitHub, огромное число, я точно не помню, но это все-таки open source проект, у него есть URL, надо ему поставить звездочку. Так вот, есть планы написать книгу? Божидар Да, я об этом говорил на докладе. Я запланировал написать книгу, но потом я стал мейнтейнером Cider, это IDE для Clojure, очень популярная. Пришлось много с этим работать, и это выкачало из меня все силы, которые я откладывал на Rubocop, Ruby Style Guide, Rails Style Guide, и вообще на все связанные с Ruby проекты, потому что очень уж я вдохновлен Clojure. Но моя работа с Cider сейчас в таком состоянии, что я ей более или менее доволен, так что я думаю, что продолжу там, где я остановился. И сделаю маленькую книгу, очень маленькую книгу. Но, думаю, будет здорово, если у всех правил будут описания побольше, примеры подлиннее. В Styleguide я этого сделать не могу — это как README длиной в 50 страниц, это было бы странно. Но, думаю, небольшая книга будет полезна многим. Ярослав Ну что же, удачи в написании книги. Спасибо, что зашел! Божидар Вам спасибо. Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.

Новости Ruby warrior с музычкой и видео Готов ли мой проект к 4 рельсам Книга «Programming Ruby 1.9 & 2.0, 4th Edition» Support Vector Machines Вышли рельсы 3.2.14 Перевод статьи про стриминг в четвертых рельсах Статья про паттерн шаблонный метод 10 причин не использовать статически типизированный функциональный язык Интервью с 15 или 16 коммитерами в руби Page object pattern Обсуждение Интервью с Андреем Дерябиным GitHub профиль Андрея Твиттер Андрея Разбор приложения Rocketbank в блоге Тани Мисютиной Рокетбанк Приложение в АппСторе для Рокетбанка Проект Rove.io Проект Vagrant Различные образы для Vagrant Opscode Chef Проект Veewee Проект Cobbler для генерации образов Проект bento — настройки Veewee от Opscode Vagrant файл Андрея Мастер-класс по разработке на рельсах от Злых Марсиан Отличная подобрка ссылок по Шефу от Равиля Остальное Билеты на railsclub уже продаются, скидка 500 рублей — промокод «rubynoname» Гем Jeremy Evans Sequel Обучающий курс Brainwashing по DevOps от «Экспресс 42» 21 и 22 сентября Подкаст DevOps Дефлопе — первый выпуск

Andy Hunt is the author or co-author of several programming books including: The Pragmatic Programmer Programming Ruby (the Pickaxe book) Pragmatic Unit testing in C# with Nunit Practices of an Agile Developer Pragmatic Thinking and Learning: Refactor Your Wetware He's also one of the original signatories of the Agile Manifesto. Andy is a great person to talk about regarding Agile Development. Here are some things he says you need to become agile and where to start: Do a little of the right things all the time You'll be the expert on the project at the end of the project. Defer important decisions until you understand the problem. Stand up meetings Set ground rules Make sure you have a stable build environment and version control Unit Tests Continuous Integration Code Reviews/Pair Programming – Check the code Involve the Customer Produce something every 1-4 weeks Retrospectives – Get Feedback Download this Episode

Dave Thomas is one of the founders of the Pragmatic Programmers. He is a signatory of the Agile Manifesto. He's written several books, including: The Pragmatic Programmer, Programming Ruby (The Pickaxe Book), and Agile Web Development with Rails This discussion covered a wide variety of topics, including how he picked up Ruby, learning new languages, and building businesses. I think one of my favorite parts were his description of how he came to write his books Programming Ruby and the Pragmatic Programmer. For me it was valuable to get that type of view into some of the early documentation on my primary programming language. I also appreciated his insight into building code better, rather than building better code. He offered insight into code that is appropriate to the task that is being built. He offered the following questions as qualifying whether you're building code better: Does it do what the customer wanted? Can it continue to provide value so in the future? This sort of purpose driven development is really the whole point of what we do as programmers. Thank you Dave for pointing out that the important thing is keeping the practices that allow us to adapt to changes in the ecosystem our applications run in. Dave also shared with us that talent in programming is important. Like musicians, you need talent to be able to perform. You can only get so far pushing your way through programming. Can you think about things as explicitly as a computer? More importantly, rather than the introverted programmer who doesn't communicate, a good programmer has the ability to translate the customer's requirements into computer instructions. You need the ability to communicate clearly and represent the computer and its capabilities to the customer. One of the most important things you can do is find a good set of mentors. Someone who can teach you what you're doing right and what you're doing wrong. Dave shared a terrific example where he said the right thing in the wrong way and explained how his mentor approached him and what to look for in a great mentor. Here is what Dave recommends in looking for a mentor: Spend some time getting to know them. Look for people around you. Look at what they do, since you'll be modeling yourself after them. Ask them to be your mentor. If they're not willing, they're not a good mentor. Oddly enough, the person I approached after this podcast is also named Dave. If you want to know where the Pragmatic Programmer came from, Dave tells us toward the end of this episode. We pick up the discussion next week talking about his businesses and entrepreneurship. Download this Episode