Podcasts about turbolinks

Jason announces DHH is back on Twitter, but not back in the Unites States! So, where is he? The guys wonder when the next versions of Turbolinks and Stimulus will be released. Some other topics discussed on this episode are Rails API guides being updated, Webpacker documentation, importing Sprockets files into webpack, problems with webpack configs, CoffeeScript, problems with UJS and Rails Scaffolds, Turbolinks Render library, Cloudflare, and generating routes in madmin. Also, have you heard of security.txt? You can learn more about it here.

Let's build Turbolinks for Livewire

KonukTayfun Öziş Erikan - https://twitter.com/toziserikanLinkler- Lab2023 Github - https://github.com/lab2023- Stimulus - https://stimulusjs.org/handbook/introduction- RailsConf 2016 - Turbolinks 5: I Can’t Believe It’s Not Native! - https://www.youtube.com/watch?v=SWEts0rlezA- Pandemide Yazılımcı Olmak - ACSDays - https://www.youtube.com/watch?v=9p74XLrshEANeler Konuştuk- Kebap project nedir? Nasıl ortaya çıktı?- Hangi problemleri çözüyorlar?- Ruby on Rails'a geçiş süreci- Ruby Gem'lerini kullanmaya başlama süreci- Kibele Gem'inin geliştirme süreci- Açık kaynak kültürü- Kullanacakları Ruby Gem'ine nasıl karar veriyorlar?- Geliştiricilerin rolleri ve çalışma şekilleri- T shaped person- Hill chart- Single Page Application'dan Monolith'e geçmek- Turbolinks ve Stimulus- Ruby on Rails variant mekanizması ve yönetimi- Test ve code review süreçleri- Uzaktan çalışma kültürü- İK süreçleri

The panel talks with Jonathan Reinink about his new library, IntertiaJS. InertiaJS is a tool that allows you to create a monolith server rendered site, but where you write your own custom back end, and then use a front end framework like React, Vue, or Svelte. We discuss how Intertia works at a very granular level, how it compares to tools like Next.js and Nuxt, why monoliths are better than using APIs, how Interita handles authentication and form submissions, and much more. Panel AJ O’Neal Aimee Knight Steve Edwards Guest Jonathan Reinink Sponsors Scout APM | We'll donate $5 to the open source project of your choice when you deploy Scout React Native Remote Conf 2020 Links Turbolinks Picks Jonathan Reinink: Follow Jonathan on Twitter > @reinink, Website Inertia.js - The Modern Monolith Lost in Space Aimee Knight: Our AWS bill is ~ 2% of revenue. Here's how we did it Steve Edwards: Colonoscopy Follow JavaScript Jabber on Twitter > @JSJabber

The panel talks with Jonathan Reinink about his new library, IntertiaJS. InertiaJS is a tool that allows you to create a monolith server rendered site, but where you write your own custom back end, and then use a front end framework like React, Vue, or Svelte. We discuss how Intertia works at a very granular level, how it compares to tools like Next.js and Nuxt, why monoliths are better than using APIs, how Interita handles authentication and form submissions, and much more. Panel AJ O’Neal Aimee Knight Steve Edwards Guest Jonathan Reinink Sponsors Scout APM | We'll donate $5 to the open source project of your choice when you deploy Scout React Native Remote Conf 2020 Links Turbolinks Picks Jonathan Reinink: Follow Jonathan on Twitter > @reinink, Website Inertia.js - The Modern Monolith Lost in Space Aimee Knight: Our AWS bill is ~ 2% of revenue. Here's how we did it Steve Edwards: Colonoscopy Follow JavaScript Jabber on Twitter > @JSJabber

The panel talks with Jonathan Reinink about his new library, IntertiaJS. InertiaJS is a tool that allows you to create a monolith server rendered site, but where you write your own custom back end, and then use a front end framework like React, Vue, or Svelte. We discuss how Intertia works at a very granular level, how it compares to tools like Next.js and Nuxt, why monoliths are better than using APIs, how Interita handles authentication and form submissions, and much more. Panel AJ O’Neal Aimee Knight Steve Edwards Guest Jonathan Reinink Sponsors Scout APM | We'll donate $5 to the open source project of your choice when you deploy Scout React Native Remote Conf 2020 Links Turbolinks Picks Jonathan Reinink: Follow Jonathan on Twitter > @reinink, Website Inertia.js - The Modern Monolith Lost in Space Aimee Knight: Our AWS bill is ~ 2% of revenue. Here's how we did it Steve Edwards: Colonoscopy Follow JavaScript Jabber on Twitter > @JSJabber

Welcome to Remote Ruby! The guys are all back together this week! In the last episode, COVID-19 was talked about, so the guys want to shift the focus to new and better things happening in the Gem world, like DHH’s Hey’s Gemfile and Basecamps Gemfile. Jason made an Avatar Component and how he uses formBuilder. They guys also talk about WebAuthn Gem, Two-factor Authentication, and Turbolinks. There are some newer Gems out there they discuss as well and some of their favorites. Jason brings back another question of the week to see if it will get answered. Will Jason’s secret question get answered? Download this episode now!

In this episode we start off with a quick conversation about ADHD, Chris' experience upgrading GoRails to Ruby 2.7 and Rails 6, Jason's new project ChurchChat, the new Bootstrap to TailwindCSS tool by Laravel Shift, upgrading Stripe subscriptions from a single plan to multiple plans, and Turbolinks.

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it.  To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited. Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins. If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive. Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React. The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it. Panelists Charles Max Wood Andrew Mason David Kimura Nate Hopkins With special guest: Graham Conzett Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in Angular Links Old School JavaScript and Rails at RailsConf 2018 React React Native React Native Web Jest Capybara Webpacker Rails-ujs Turbolinks Stimulus Stimulus Reflex Babel TypeScript Actionview components Angular Follow DevChatTV on Facebook and Twitter Picks Charles Max Wood: St. George Marathon OBS David Kimura: WeDo 2.0 by Lego Workflow Automation Self Hosted Andrew Mason: Publish to Github action JustDunning.com Nate Hopkins: Company of One by Paul Jarvis IndieHackers Graham Conzett: Basecamp’s Shape Up Pigeonforteachers.com  IKE Smart City Follow Graham @gconzett on Twitter and Github

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it.  To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited. Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins. If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive. Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React. The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it. Panelists Charles Max Wood Andrew Mason David Kimura Nate Hopkins With special guest: Graham Conzett Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in Angular Links Old School JavaScript and Rails at RailsConf 2018 React React Native React Native Web Jest Capybara Webpacker Rails-ujs Turbolinks Stimulus Stimulus Reflex Babel TypeScript Actionview components Angular Follow DevChatTV on Facebook and Twitter Picks Charles Max Wood: St. George Marathon OBS David Kimura: WeDo 2.0 by Lego Workflow Automation Self Hosted Andrew Mason: Publish to Github action JustDunning.com Nate Hopkins: Company of One by Paul Jarvis IndieHackers Graham Conzett: Basecamp’s Shape Up Pigeonforteachers.com  IKE Smart City Follow Graham @gconzett on Twitter and Github

In this episode, we sit down with Jason Meller to talk about the experience of building Kolide. We talk about how the vision for Kolide came about, how Ruby on Rails (and the Rails way) plays into the application's design (spoiler, we talk about Turbolinks and StimulusJS), building a security-based Slack app, and more.

Sponsors Sentry use code “devchat” for $100 credit Sustain Our Software Adventures in Blockchain Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood With Special Guest: David Heinemeier Hansson Episode Summary Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails.  David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers.    Links Action Text  Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow DevChat on Facebook and Twitter Picks Andrew Mason: How to Say It Rework episode Nate Hopkins: Stimulus Reflex Charles Max Wood: Atomic Habits Ed Mylet show The MFCEO with Andy Frisella David Kimura: Swing set kit Rails 6 His daughter Ruby David Heinemeier Hansson: Follow David on Twitter @dhh, dhh.dk and Rework.fm To Have or To Be Shape Up book Rails 6

Sponsors Sentry use code “devchat” for $100 credit Sustain Our Software Adventures in Blockchain Panel David Kimura Andrew Mason Nate Hopkins Charles Max Wood With Special Guest: David Heinemeier Hansson Episode Summary Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails.  David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers.    Links Action Text  Action Mailbox Stimulus.js Turbolinks Haml JBuilder Follow DevChat on Facebook and Twitter Picks Andrew Mason: How to Say It Rework episode Nate Hopkins: Stimulus Reflex Charles Max Wood: Atomic Habits Ed Mylet show The MFCEO with Andy Frisella David Kimura: Swing set kit Rails 6 His daughter Ruby David Heinemeier Hansson: Follow David on Twitter @dhh, dhh.dk and Rework.fm To Have or To Be Shape Up book Rails 6

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey  Taylor Jones:  Slack Engineering Team  Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey  Taylor Jones:  Slack Engineering Team  Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

Brittany and Nick host another catchup episode. They chat about Nick's Past Rubies project, Brittany's implementation of Google Pay in Rails and why Turbolinks can be awesome!

Brittany and Nick host another catchup episode. They chat about Nick's Past Rubies project, Brittany's implementation of Google Pay in Rails and why Turbolinks can be awesome!

In this episode, Adam talks to Jerod Santo of The Changelog about building their custom podcasting platform using Elixir and Phoenix. Topics include: How pattern matching works in Elixir and why it's more powerful than method overloading in other languages How Elixir's pipe operator makes the transition from OO to functional programming more natural Why you don't need to be intimidated by unfamiliar features like GenServers to use Elixir for web app development Noticeable differences between working with Rails and Phoenix and what it was like to transition How the Phoenix ORM makes n+1 queries impossible Why background tasks are a lot easier in Elixir than in an ecosystem like PHP What other tools and technology power the Changelog platform How the Changelog Phoenix app is deployed Sponsors: DigitalOcean, get your free $50 credit at do.co/fullstack Cloudinary, sign up and get 300,000 images/videos, 10GB of storage and 20GB of monthly bandwidth for free Links: Building rapid UI with utility-first CSS, Adam's episode of JS Party Elixir Phoenix Chris McCord on The Changelog The Changelog source code Confident Ruby "Why we chose Turbolinks" Programming Phoenix book Elixir Forum Our Slack

Chris and Jason spend the first ~20 minutes catching up and sharing personal stories. If you're not interested in that, fast forward 20 minutes to hear about Turbolinks for Android, Autoloading, suggest_rb, and run.rb.

We're back, yet again, talkin' Ruby. This week we caught up after our weekend trip to work on Secret Project X™. Such topics include Pay (our Rails gem for payments in Rails), separating your front-end from the backend, Stimulus JS 1.1, Turbolinks iOS + Android, and Mastodon.

Panel: Charles Max Wood Eric Berry David Richards Special Guests: Nate Berkopec In this episode of Ruby Rogues, the panel talks to Nate Berkopec about Ruby Performance. Nate is a freelance Ruby performance consultant and he writes and works on Ruby application performance, specifically Rails applications, which he has been doing for the past 3 or 4 years. They talk about his past experience, what led him to Ruby performance, and why he loves Turbolinks. They also touch on the two benefits to performance work, if Ruby performance on the back-end really matters for the majority of cases, and more! In particular, we dive pretty deep on: Nate intro Ruby and Rails Was on Shark Tank What led you into Ruby performance? Always enjoyed the easily quantified parts of development Performance work is very cut and dry Why do you love Turbolinks? 100ms to Glass with Rails and Turbolinks – Turbolinks article The beauty of Turbolinks The Complete Guide to Rails Performance The two benefits to performance work Making things scalable and back-end End-user experience Compiling JavaScript Does Ruby performance on the back-end really matter for the majority of cases? Making the experience feel faster Search Admin actions What would you do when you have a N+1 query problem? Finding a N+1 and fixing it on the back-end How he fixes an N+1 Bullet gem And much, much more! Links: Ruby Rails Turbolinks 100ms to Glass with Rails and Turbolinks – Turbolinks article The Complete Guide to Rails Performance JavaScript Bullet @nateberkopec nateberkopec.com Nate’s GitHub Speedshop Sponsors Sentry Digital Ocean FreshBooks Picks: Charles Golf Clubs Get a Coder Job eBook Get a Coder Job Video Course Eric Surviving the Framework Hype Cycle by Brandon Hays - talk TaylorMade M1 Driver David Every Chapter of Thinking Fast, and Slow in 7 Minutes by Conor Dewey Poem a day Nate jemalloc Queer Eye Kerbal Space Program krpc for Ruby

Panel: Charles Max Wood Eric Berry David Richards Special Guests: Nate Berkopec In this episode of Ruby Rogues, the panel talks to Nate Berkopec about Ruby Performance. Nate is a freelance Ruby performance consultant and he writes and works on Ruby application performance, specifically Rails applications, which he has been doing for the past 3 or 4 years. They talk about his past experience, what led him to Ruby performance, and why he loves Turbolinks. They also touch on the two benefits to performance work, if Ruby performance on the back-end really matters for the majority of cases, and more! In particular, we dive pretty deep on: Nate intro Ruby and Rails Was on Shark Tank What led you into Ruby performance? Always enjoyed the easily quantified parts of development Performance work is very cut and dry Why do you love Turbolinks? 100ms to Glass with Rails and Turbolinks – Turbolinks article The beauty of Turbolinks The Complete Guide to Rails Performance The two benefits to performance work Making things scalable and back-end End-user experience Compiling JavaScript Does Ruby performance on the back-end really matter for the majority of cases? Making the experience feel faster Search Admin actions What would you do when you have a N+1 query problem? Finding a N+1 and fixing it on the back-end How he fixes an N+1 Bullet gem And much, much more! Links: Ruby Rails Turbolinks 100ms to Glass with Rails and Turbolinks – Turbolinks article The Complete Guide to Rails Performance JavaScript Bullet @nateberkopec nateberkopec.com Nate’s GitHub Speedshop Sponsors Sentry Digital Ocean FreshBooks Picks: Charles Golf Clubs Get a Coder Job eBook Get a Coder Job Video Course Eric Surviving the Framework Hype Cycle by Brandon Hays - talk TaylorMade M1 Driver David Every Chapter of Thinking Fast, and Slow in 7 Minutes by Conor Dewey Poem a day Nate jemalloc Queer Eye Kerbal Space Program krpc for Ruby

Panel: Charles Max Wood Dave Kimura Eric Berry Catherine Meyers David Richards Special Guests: Daniel P. Clark In this episode of Ruby Rogues, the panelists talk to Daniel P. Clark about improving Ruby performance with Rust. Daniel has been a hobbyist programmer for over 20 years and started blogging about Ruby and other technical matters about 5 years ago. One of the things he is well known for is his Faster Path gem on GitHub, which has over 700 stars. They talk about his blog article Improving Ruby Performance with Rust, why he chose to use Rust, and the benefits of using a Rust extension in Ruby. They also touch on his faster path gem, the Helix project, and more! In particular, we dive pretty deep on: Daniel intro Likes to blog - 6ftdan.com Released Faster Path gem Ruby Improving Ruby Performance with Rust blog article Why Rust? Rust to the rescue (of Ruby) blog article Rust was exciting because of the promises it gave No garbage collector in Rust Why is not having a garbage collector a positive? Rust’s ownership model Why would use a Rust extension in Ruby? Have you played around with sending objects into a Ruby function? The story behind creating his Faster path gem rubyflow.com Turbolinks and Spring and how they react Helix project And much, much more! Links: Faster Path Improving Ruby Performance with Rust Rust CodeShip Rust to the rescue (of Ruby) Ruby 6ftdan.com rubyflow.com Turbolinks Spring Helix @6ftdan Daniel’s GitHub Sponsors FreshBooks Loot Crate Picks: Charles Logrotate charlesmaxwood.com devchat.tv/blog DevChat.tv YouTube Dave Orange Computers Proxmox Gitlab David Arrested Development Eric Dead Alewives Club YouTube video Catherine How I Built This with Guy Raz podcast Daniel Programming Rust by Jim Blandy and Jason Orendorff All Your Dev YouTube channel LegalShield GoSmallBiz

Panel: Charles Max Wood Dave Kimura Eric Berry Catherine Meyers David Richards Special Guests: Daniel P. Clark In this episode of Ruby Rogues, the panelists talk to Daniel P. Clark about improving Ruby performance with Rust. Daniel has been a hobbyist programmer for over 20 years and started blogging about Ruby and other technical matters about 5 years ago. One of the things he is well known for is his Faster Path gem on GitHub, which has over 700 stars. They talk about his blog article Improving Ruby Performance with Rust, why he chose to use Rust, and the benefits of using a Rust extension in Ruby. They also touch on his faster path gem, the Helix project, and more! In particular, we dive pretty deep on: Daniel intro Likes to blog - 6ftdan.com Released Faster Path gem Ruby Improving Ruby Performance with Rust blog article Why Rust? Rust to the rescue (of Ruby) blog article Rust was exciting because of the promises it gave No garbage collector in Rust Why is not having a garbage collector a positive? Rust’s ownership model Why would use a Rust extension in Ruby? Have you played around with sending objects into a Ruby function? The story behind creating his Faster path gem rubyflow.com Turbolinks and Spring and how they react Helix project And much, much more! Links: Faster Path Improving Ruby Performance with Rust Rust CodeShip Rust to the rescue (of Ruby) Ruby 6ftdan.com rubyflow.com Turbolinks Spring Helix @6ftdan Daniel’s GitHub Sponsors FreshBooks Loot Crate Picks: Charles Logrotate charlesmaxwood.com devchat.tv/blog DevChat.tv YouTube Dave Orange Computers Proxmox Gitlab David Arrested Development Eric Dead Alewives Club YouTube video Catherine How I Built This with Guy Raz podcast Daniel Programming Rust by Jim Blandy and Jason Orendorff All Your Dev YouTube channel LegalShield GoSmallBiz

In this episode, Adam talks to Jonathan Reinink about what it's like to build a Laravel application using Turbolinks, how it plays with front-end frameworks like Vue.js, and how it's helping him quickly develop web, iOS, and Android apps for his SaaS business all by himself. They also discuss the benefits of using a Turbolinks-style approach for small teams, and how Turbolinks on mobile compares to other popular tools like Ionic. Sponsors: Rollbar, sign up at https://rollbar.com/fullstackradio to try their Bootstrap Plan free for 90 days Codeship Links: Turbolinks Turbolinks iOS adapter Turbolinks Android adapter Turbolinks 5: I Can't Believe It's Not Native!, presentation by Sam Stephenson Hybrid Sweet Spot: Native navigation, web content, article on how Basecamp builds mobile apps by DHH Ionic, Angular based mobile framework Turbolinks lessons at Laracasts

Privacy Week zum Nachschauen; Chaos Computer Club Wien; Metalab; Buch Networks of Control von Wolfie Christl und Sarah Spiekermann; AJAX; WebSockets; Elixir; Phoenix Framework; Turbolinks; Vienna BEAMers; Knockout Javascript mit MVVM Pattern; IT-Keller Facebook-Seite; Aua-Uff-Code Podcast Folge 12 "Hardwareprojekte"; Amazon Dash und Raspberry Pi; Amazon Dash Button Fun; Flic Button; Spiegel mit Raspberry Pi Magic Mirror bzw. Smart Mirror; Mica, the Hipster Cat Chat Bot; The MAZE Chatbot; Microsoft Bot Framework; Textadventure "The Hitchhiker's Guide To The Galaxy"; Leisure Suit Larry; A.I. Experiments; Linq VR/AR Brille; Magic Leap; Sticker bei Flyeralarm gedruckt; Jekyll Static Website Generator unterstützt jetzt Themes; Podigee Podcast Player; Nitzer Ebb - Let Your Body Learn; Miniatur Wunderland Hamburg; Miniatur Tirolerland Gäste: Bernhard, Martin (@leyrer), Stefan, Ulrich

New details about Guilds, a free Ruby Tapas episode on Threads, mounds of new Ruby versions and features, a Rails feature diary, and Turbolinks without Rails.

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции. В этот раз мы поговорили с Владимиром Дементьевым про Action Cable, обучение и open source. Ссылки Профиль Владимира на Github первый проект Владимира – Teachbase Универсальный RPC фреймворк Brainwashing – Курс по Ruby on Rails Rubocop Первый open-source коммит в pry-byebug InfluxDB - БД написанная на языке Go Influxer - InfluxDB ActiveRecord-style Telegraf - сборщик логов Thinknetica Расшифровка эпизода, опубликованная на Habrahabr Расскажи немножко о себе? В Ruby сообщество я пришел не так давно. Примерно 4 года назад я в первый раз попробовал рельсы, поигрался. Мне понравилось. но проект, на котором я тогда работал, их не использовал. Поэтому пришлось отложить до очередной реинкарнации проекта Teachbase, нашего стартапа. Teachbase - это SaaS система для организации управления обучением, она позволяет вам сделать собственную Coursera в рамках компании или проекта. Когда я пришел, это был страшный проект на PHP, а я тогда мало что умел. Кодил, что говорили. Потом я познакомился с рельсами и с того момента, как стал техническим директором, начал вынашивать идею написать новую классную версию системы на продвинутой технологии. Такая возможность представилась в 2014 году, и тогда мы полностью перешли на рельсовый стэк в части веб-приложения. С тех пор я начал активно этим заниматься. Как ты смог убедить заказчика перейти на Rails? Все очень просто - я сам себе заказчик. Я один из основателей этого стартапа, двое моих партнеров не имели достаточной технической экспертизы, поэтому доверяли мне. Надеюсь, они не ошиблись и не жалеют об этом :) Выбор технологий был за мной. Вопрос был только в том, чтобы найти время на переход с одной версии на другую. Ну и деньги, естественно. Когда момент настал, мы переписали все на рельсы, и вот эта третья (или четвертая) версия системы работала быстро, четко, все были довольны - как мы, так и клиенты. Она и сейчас работает? Да, она продолжает работать. Мы довели проект до очень хорошего состояния, когда делать новую версию имеет смысл уже не по технологическим причинам, а скорее идеологическим. Не знаю, какие у ребят планы на данный момент. Пока они занимаются поддержкой этой системы, продажей. Все идет неплохо, проект жив, работает. Teachbase довольно большой проект на рельсах. Причем это были рельсы 4.1, на 4.2 мы не стали переходить, хотя планировали. Год с небольшим назад было объявлено о выходе 5 рельс осенью 2015, в этот момент мы решили, что нет смысла переходить на 4.2, когда можно сразу перейти на 5. Все знают, что потом было :). Прошел еще год, пятые рельсы уже вышли, но сейчас переходить на них, наверное, еще опасно. Надо подождать хотя бы 5.0.1, а лучше 5.1, тогда можно будет переходить. Мы понадеялись на релиз-планы команды разработчиков рельс, они не оправдались, поэтому наш проект до сих пор висит на 4.1. И особых проблем с этим нет. То есть, с точки зрения технологий проект закончен, и вы делаете что-то новое когда понимаете, что это нужно бизнесу? Да. Есть планы переделать значительную часть логики, и это, скорее всего, будет новый проект на новых рельсах, а может и не рельсах. В нашем стеке всегда был Erlang, так как мы занимались видеоконференциями, соответственно, нужен был стриминговый сервис, который работал бы с протоколом RTMP. Он нужен, чтобы люди, используя технологию flash (которую все ненавидят), могли общаться в браузере, проводить вебинары на большое количество людей и так далее. Бэкендом для всего этого служил сервис на эрланге, который отпочковался от довольно известного проекта Erlyvideo. Вы взяли форк, который был еще в open source? Да, это был open source, версия примерно 2.18. Происходило это в 2011 году. Сначала мы его просто использовали, потом стали вскрывать баги и править их, адаптировать все под нашу историю. А потом Макс Лапшин закрыл код и начал разрабатывать платный Flussonic. Нам это, в принципе, не мешало. Так у нас появился опыт в Erlang, и мы начали делать некоторые другие второстепенные сервисы для системы на эрланге. Наш стэк обрел второй основной язык Но найти разработчика на эрланге не очень просто. Тот единственный эрлангист, который у нас был, пришел студентом, он знал С и отлично знал математику, у него было олимпиадное прошлое и он хотел работать. Как эрлангиста мы его воспитывали с нуля. Он, кстати, до сих пор работает в проекте. Но больше таких людей не появлялось, поэтому в начале этого года, когда я еще работал в Teachbase, мы начали программу знакомства с Elixir (как для тех, кто программировал на Ruby, так и для тех кто программировал на Erlang). Был отдельный подпроект, в котором было 2 разработчика: рубист и эрлангист. Они должны были осваивать технологию вместе, используя каждый свои сильные стороны. Один лучше знает Ruby и его парадигму, знает Rails, которые похожи с Phoenix в части MVC. А второй человек, который знает Erlang, делал на Elixir какие-то более близкие к этой парадигме вещи. Проект пока не доделан, но он очень интересный. Мы начали переходить на этот стек, скорее из-за его популярности, чтобы было проще в дальнейшем жить и нанимать новых сотрудников. А не хотели все перевести на Phoenix? Полностью отказаться от Ruby, оставить Erlang, поверх него Elixir, а сверху еще Phoenix? Когда стоял вопрос о переходе на Rails, был альтернативный вариант сразу переходить на Erlang. Я готов был это сделать. Наверное, мы бы дольше стартовали, но вероятно это было бы лучше с точки зрения эффективности. Хорошо, что мы этого не сделали: наши нагрузки не требуют каких-то жутких оптимизаций, и рельса вполне справляется, а скорость разработки дает намного большую. Сейчас я не думаю, что Phoenix можно полностью заменить рельсы именно с точки зрения построения бизнес-логики, слоя работы с данными. Все что касается запросов, сокеты (это отдельный разговор мы к нему вернемся) - с этим в Phoenix все неплохо. Но Active Record (или его альтернативы) и экосистема вокруг него пока гораздо удобнее, чем все, что есть в Elixir. Это логично, там другая парадигма, там не так просто сделать удобный для использования инструмент. Поэтому, на мой взгляд, Elixir и прочие, с Phoenix или без, - это скорее технологии для идеологии микросервисов. Нужно использовать их в какой-то тяжелой части, в которую стучится очень много клиентов, с какими-то задачами, запросами. Такие части можно писать Elixir, решать их несколькими разными сервисами. А основная логика должна, мне кажется, оставаться в рельсах, если изначально была написана на них. Но даже если бы я сейчас начинал проект с нуля, я бы все равно не стал делать все на Elixir. Ты говоришь о Teachbase и своей роли CTO в нем, как о прошедшей истории. Сейчас, насколько я знаю, ты работаешь в Evil Martians, работаешь просто разработчиком. Почему ты перешел от управления к разработке? Чаще наоборот, люди хотят пройти путь от разработчика до управленца. Считаешь ли ты это шагом назад, или это какой-то промежуточный этап? Во-первых, долгое время я был в Teachbase единственным разработчиком. Я начал набирать команду только в последнюю пару лет, когда у нас появилась такая возможность. Проблема для меня, как для разработчика, была в том, что я много всего попробовал, много нового узнал, но в основном на собственном опыте. Я никогда не работал в команде под руководством кого-то, кто был опытнее меня и имел какие-то знания, которых у меня не было. Это была одна из причин: мне было скучно, я понимал, что мой самостоятельный рост в Teachbase будет идти тяжело. Особенно, когда проект стабилизировался, не было каких-то супер интересных задач, только текучка типа добавления фич, нет воли творчеству. Я рассматривал марисан, в первую очередь, так как я был знаком с некоторыми ребятами, я был на курсе Brainwashing, с тех пор у меня остались самые приятные впечатления об этой команде. Мне очень хотелось поработать с такими людьми, поделиться опытом, поделиться своими идеями. Когда я работал в Teachbase, мне не с кем было обсудить какие-то технические идеи, не было людей, которые разбирались бы хорошо в технических аспектах. Поэтому я хотел попасть в сильную команду. То, что в Teachbase у меня была “власть”, а теперь я рядовой сотрудник, не страшно. Наверное. Хотя моя жена говорит, что после того, как я перестал руководить, я пытаюсь немножко чаще руководить дома. Компенсирую :) Мне нравится отсутствие вертикали, можно со всеми спокойно общаться, разговаривать, спорить, ругаться иногда. Мне нужно было попасть в среду, скажем так. Мы начали говорить про Rails и долгожданную 5 версию, в которой много всего появилось. Например, Action Cable, про который ты и будешь рассказывать на конференции. Чего еще тебе не хватает в Rails? Я бы поставил вопрос по-другому: что в рельсе лишнее, что мешает. Да, это хороший вопрос В прошлом подкасте мы говорили с Алексеем Тактаровым о том, стоит ли выкинуть фронтовую часть. А что бы ты выкинул? Фронтовая часть и сборка ассетов с помощью Sprockets, на мой взгляд, уже устаревшая схема. Фронт сейчас пишется со своими сборщиками, там своя очень развитая экосистема. Которая работает, по моему опыту, гораздо приятнее, чем Sprockets. Это быстро, удобно, куча дополнительных возможностей, тонкая настройка и так далее.. Тот же автопрефиксер вставить в Sprockets, конечно, можно. Но если вставить еще 20 аналогичных плагинов, то ассеты, скорей всего, будут собираться очень долго. Я использовал рельсу, по большей части, неклассическим образом, с серверным рендерингом, используя javascript шаблоны и подобные вещи для обновления странички. Я использовал Rails практически в API режиме, только JSON. HTML-странички отдавались также рельсами, но была идея избавиться и от этого, грузить статику отдельно, так как динамического рендеринга был минимум, например, : вставка логотипа налету. Все фишки типа шаблонов,Turbolinks, вот это все, должны быть отдельными примочками к рельсам. Если хочешь - добавляй. В свое время Sprockets был настоящим прорывом. Возможно, сейчас эта технология устарела, потому что фронт развивается какими-то сумасшедшими темпами. Потому что на тот момент во фронте был популярен только Grunt, ужасный и монструозный, на мой взгляд. Он долго меня отталкивал от использования всего этого, пока не появились более приятные глазу альтернативы. Если говорить про текущий момент: если бы я сейчас начинал новый проект и брал бы в качестве бэкенда рельсу, я бы, учитывая, что у нас в Rails 5 есть встроенный API режим, сразу бы делал так, чтобы отдельно один проект делали фронты, отдельно бэкенды. Это очень удобно и с точки зрения разработки. Незачем фронту поднимать сервер, копаться там. Пусть он делает фронтовую работу и не знает, что на сервере. Пусть просто работает по спецификации, которую дают бэкенды. Ты поднял интересную тему: если сейчас делать проект на рельсе. А если не на рельсе, то на чем бы ты делал? Все зависит от того, какой проект, конечно. Давай как пример возьмем Teachbase. API, взаимодействие по JSON. Выкидываем Action View, выкидываем что-то еще. Может стоит использовать альтернативы на Ruby, но не Rails? Или вообще другой язык? Хороший вопрос. Если вопрос стоит как “что-нибудь другое на Ruby” - то нет. Во первых, у меня нет особого опыта. Я пробовал микрофреймворки типа Cuba, Sinatra. Такие микро-микросервисы, просто экспериментировал и смотрел, что это и зачем. Большие альтернативы, типа Trailblazer или Hanami, я не пробовал, они меня, в принципе, не заинтересовали. Я пока не понял, зачем они мне. Да, я видел бенчмарки, там все классно, быстро. Но рельсы и руби выбираются не для того, чтобы было быстро, а для того, чтобы было удобно. Поэтому такой аргумент для меня не самый важный. Да, у Hanami есть один очень большой недостаток: его никто не использует. Вот! Сложно тягаться в Rails, на котором пишут все, с них многие начинают свой путь в Ruby. Реальные конкуренты рельсам сейчас не внутри Ruby, а Elixir и Phoenix, которые набирают обороты. На мой взгляд это происходит отчасти потому, что Elixir хорошо пиарят. Его научились продавать командам разработчиков, говорят что Elixir классный, у вас все будет быстро. Даже в России уже есть люди, которые используют гибридный стек - часть рельсы, часть эликсира, все хотят его попробовать. И главное все хотят продать разработку на Elixir заказчику. Как коммерческий проект Elixir - очень классная штука. Он проще Erlang, хотя лично я бы все равно предпочел Erlang. Да, будет немножко больно, местами будет больше кода, хотя и это можно оптимизировать. Если отвечать на вопрос “что, если не Rails”. Я бы выбрал Erlang, но только в том случае, если мне дали бы пару разработчиков и чуть больше времени. В основном, все упирается в наличие разработчиков: их мало. С Elixir тоже проблема: многие, кто начал изучать Elixir и что-то на нем сделали, сразу считают, что они знают Erlang. Это примерно та же история, как когда люди, потыкавшие в рельсы, потом говорят, что они знают Ruby. Скорее всего, рынок пострадает от этого. Найти хорошего разработчика на эрланге будет еще сложнее, потому что будет много левого мусора. Во фронте сейчас похожие проблемы: если люди, которые выучили Angular, но не понимают, что такое JavaScript. Теперь везде есть такая проблема. Мы начали говорить про альтернативы Ruby. У тебя большой опыт работы с Erlang, ты писал на PHP, насколько я знаю, ты еще пишешь на go. На каких еще языках ты что-то пробовал делать и что хотел бы попробовать? Давай говорить хронологически. В школы и университете были Pascal, C, Basic, Assembler. Но в университете я пропускал программирование, оно мне очень не нравилось. Я до сих пор удивляюсь, как я так случайно стал программистом. Начинал я с ActionScript. То есть Flash? Да. Я начинал со второго ActionScript, он был ужасен. А вот в третьем появилось очень много изменений: нормальные классы, прокси объекты, которые все так ждут сейчас в JavaScript (но пока там не очень хорошо с поддержкой). Много всего классного, удобного. Как язык он был прикольным. Со своими минусами в виде не очень простой компиляции, в которой, если у тебя не Flash Builder от Adobe, приходится много колдовать. У меня был очень большой проект в рамках Teachbase, когда мы начали делать свое решение для вебинаров. Оно состоит из двух частей: клиентской и серверной. В серверной был Erlang, а в клиентской - большое ActionScript приложение. Это был мой первый большой проект, я продумывал его с нуля, с серьезной архитектурой, там было много классных идей. Это приложение до сих пор работает. В нем нет багов, я последний раз его правил два года назад! С тех пор оно классно работает. И это очень хорошо, потому что я даже не знаю, как мне его теперь собрать, запустить и так далее, у меня нет никаких систем сборки, и я уже плохо помню, как там все устроено. Подожди, третий ActionScript вышел очень давно, он старый. Около 10 лет. Он вообще развивается? Да, он очень старый, но еще жив, на нем пишут. Особенно много используют в игровой индустрии, сделали очень много оптимизаций с точки зрения графики, рендеринга, использованием GPU и так далее. На нем можно писать классные игры. Кажется, какая-то из популярных онлайн игр, типа танков, была изначально на flash. Сейчас не знаю, может, до сих пор. Был период, когда эти технологии были во всем реалтайме, когда, например, нужно было сделать видеочат, когда не было и намека на другие технологии, flash был везде. Это сейчас он мало у кого стоит. На Flash раньше было реализовано то, что сейчас есть в Web RTC, peer-to-peer. Этот проект в итоге был заброшен. Изначально он назывался Stratus, мы даже делали на нем побочный проект - портал для психологов с возможностью консультации онлайн. Работало через раз. Сейчас те вебинары, которые существуют и работают просто в браузере, заявляют, что используют Web RTC, но в большинстве случаев это не так. Именно для стриминга по прежнему используется flash, rtmp. Там он еще жив. Я очень хорошо знал ActionScript, но сейчас не сказал бы, что я в нем эксперт. И не планирую им заниматься. А теперь вернемся к нашему вопросу: что было после ActionScript? Потом был php. Не помню, какая там была версия, с ним были разные замуты. А как ты познакомился с Rails? Все получилось случайно и просто. Есть такая замечательная площадка Coursera, когда она только появилась, там было где-то пять курсов, один из них был про SaaS разработку и так далее. Этот курс, фактически, был таким введением в Rails, тогда еще 3. Не сказать, чтобы я выучил рельсы по этому курсу. Это был очень простой курс, вывод одной страницы и поиск по элементам из базы. Но там было хорошо рассказано про тестирование, про все его уровни. После этого я написал какой-то микро-микросервис для нашей системы. Очень страшный, некрасивый, он даже был запущен через rails s в development режиме. Но он работал, практически не падал. Сложно сказать, в какой момент я начал изучать и что-то делать, переключаться. Сильным толчком был поход на Brainwashing. Когда я туда шел, я практически ничего не знал именно про Rails: что там, как там. А на курсе получил пинок, скажем так. Сел и начал разрабатывать. Можно сказать что Равиль и Газай оказали на тебя большое влияние? Да, они подкинули вдохновения в этом направлении. Если дальше говорить о языках, потом был Erlang. Сейчас я иногда использую Golang для разных вещей. Язык довольно простой, можно выбирать его, если надо что-то быстро набросать. Он компилируется в исполняемый файл и его можно использовать. Еще я очень много занимался фронтом, сейчас уже меньше. Не тянет во фронт? Перейти темную сторону. Хороший вопрос. Наверное, нет. Я так себе фронетенд, потому что я не очень силен во всем, что касается стилей, верстки и прочего. Особенно с новыми замутами: какие-то CSS модули, CSS 4, все меняется очень быстро, не успеваю за этим следить. Мне никогда это не нравилось, я всегда считал верстку работой для каких-то…как-бы без расизма обойтись…не буду говорить :) Это черновая работа. Практически всегда мы отдавали ее на аутсорс. Нам присылали верстку, мы ее интегрировали. Один раз я предложил не мучиться, и все сделать самостоятельно. Тогда я начал этим заниматься. Спасибо Андрею Ситнику, который рассказал всякие интересные штуки и показал как делать не надо, дал некоторый вектор. И я начал делать много фронта, в итоге у нас в Teachbase основная логика на клиенте - это написанный мною фреймворк. Мы начинали еще до того, как React стал популярен, Angular еще не был особо популярен, но уже существовал. Я решил, что мне быстрее написать самому, я понимал как работает JavaScript, и не хотел тратить время на то, чтобы разбираться как работает Angular. Я ни разу не жалею об этом, потому что Angular работал в первой версии ужасно, на мой взгляд слишком неочевидно. Хотя кому-то это может казаться понятным. Во второй версии может быть что-нибудь поменялось. У меня был свой велосипед, он до сих пор работает, ребята его используют. В свободное от работы врем я пытался написать его новую версию на es6, но свободного времени оказалось не так много. Поэтому на гитхабе висит две недоделанных версии моего фреймворка :) Там прикольные идеи, но учитывая, что я тратил на это один день в месяц, они сильно отстают от тенденций, которые сейчас есть во фронте. Мы начали тему своих велосипедов. Как ты участвуешь в open source? Есть ли проекты, на которые ты хотел бы, чтобы ребята обратили внимание? Классный проект, но его никто не замечает. Свои проекты или чужие - не важно. Снова прорекламирую Brainwashing :) Open source для меня начался там, я сделал свой первый коммит в OS. В рамках курса ребята наткнулись на баг в pry-byebug, который был в экстеншене на C. Я его нашел, пофиксил, отправил и получил свой первый pull request, получил от этого удовольствие и немного подсел :) Начал этим заниматься. Если говорить про чужие проекты: я очень много работал над Rubocop, это проект Божидара Батсова. Мне очень нравится этот проект и в целом идея, что код должен быть стилизован. Я это везде пропагандирую, где есть возможность. Но ты же не используешь дефолтный конфиг rubocop? Конечно, я всегда там что-то правлю, что-то отключаю, что-то включаю. А меняются настройки из проекта в проект? У тебя есть сложившиеся настройки, которые ты всегда используешь или считаешь, что каждый раз нужно договариваться с другими разработчиками в проекте? По-разному. Сейчас я, например, пришел в проект с большой кодовой базой и мы прикрутили обязательную проверку rubocop’ом, но там у нас очень минимальный конфиг, который проверяет на очень плохие вещи, типа забытого дебага в коде или фокусы в спеках и так далее. И еще у нас включено несколько оптимизационных копов. Вещи типа длины строки, количества строк в методе и так далее мы в этом проекте не проверяем. А ты приверженец истории про 80 символов, 120 или просто отключаешь эту проверку? Я поддерживаю эту тему, обычно я ставлю 100. Это число получилось опытным путем: я долгое время работал на 21-дюймовом iMac и разрабатывал со сплитскрином. Я делал так, чтобы в обеих частях экрана входили все строчки. Это как раз примерно 100 символов. Логика выбора длины строки была такая, потому что горизонтальный скролл это очень неудобно. Про длину методов или длину класса… нет. Комментарий в начале строки, enter в конце Пустую строку в конце я всегда ставлю. Делаю это, потому что так удобно перейти в конец файла. Есть некоторый отступ снизу, тебе не надо попадать в границу дисплея. Я где-то читал, какими историческими ограничениями это правило было вызвано, в каких-то старых системах. Точно уже не воспроизведу, что там было. И сейчас гитхаб постоянно это подсвечивает в диффах, ругается когда у тебя нет пустой строки - это не очень приятно. В моем дефолтном конфиге на нулевом проекте многое включено, но эти параметры сложности немного увеличены. Если где-то очень большая сложность, и я не хочу рефакторить какой-то метод осознанно, то я просто отключаю этот коп локально, да и все. Но во всех гемах, которыми я занимаюсь, или в которые я активно контрибьютил, внедрял это дело. Про rubocop понятно. На какие еще проекты стоит обратить внимание? В каких ты принимал участие? Я много работал над проектами из экосистемы InfluxDB. Это база данных для хранения временных рядов. Интересный проект, сейчас он вырос в InfluxData, у них свой стек, это что-то похожее на стек от Elasticsearch, где у тебя есть сборщик логов, визуализатор, сама база, но он заточен не на логи, а на какие-то временные метрики. Я начал его использовать в Teachbase, он тогда был не очень известен, это было примерно полтора года назад. Их история очень похожа на историю с Rails 5: была версия 0.8, они обещали через месяц выпустить следующую, более стабильную и с багфиксами, с кластеризацией и так далее. Я даже с ними списывался, мне отвечали что работа идет, версия скоро будет. Было довольно рискованно использовать не очень production ready историю, пару раз все очень страшно падало. Но в итоге, обещанная версия вышла, как и Rails, только в начале этого года. Мы прожили год на нестабильной версии, пришлось все-таки с ней работать. Один из моих больших open source проектов, как раз известен тем, кто работает с этой базой. Я написал адаптер для работы с этой базой в стиле Active Record. Проект называется Influxer. Он очень похож на ActiveRecord: определяется некоторый класс, говоришь какие у него есть атрибуты (это атрибуты этих меток в базе), и он позволяет делать запросы, такой синтаксический сахар. InfluxDB поддерживает SQL-подобный язык, и вместо того, чтобы писать на нем можно использовать вот такую обертку. Это удобно, там есть некоторые фишечки, связи с моделями и так далее. Он активно использовался в Teachbase, для этого он и делался. Я и сейчас продолжаю его поддерживать, в связи с выходом новых версий базы и изменением API, там все более или менее актуально. Проект кто-то использует, есть несколько десятков звездочек. Помимо Influxer я занимался другими проектами для этой экосистемы. До какого-то момента весь код был открыт, сама база и все второстепенные сервисы, которые там использовались. В этом году они ввели коммерческий вариант. Часть кода, естественно, уже не в open source, особенно то, что касается кластеризации. Все остальное открыто, и разработчики рады, когда туда приходят люди и контрибьютят. Там все написано на go, и мой первый опыт с go получился именно там. Я делал пару патчей в проект, который называется Telegraf : это сборщик логов, что-то типа Logstash или новых beats от Elasticsearch. Проект очень активно развивается, до стабильной версии далеко. Если вы хотите попробовать go и поучаствовать в open source, знайте, что там довольно просто сделать pull request. Расскажи еще про Thinknetica. Ты там играешь роль наставника, что это значит? Какой опыт ты оттуда вынес? Сколько обучил человек? Да, слово наставник мне нравится больше. Раньше мы называли друг друга менторы, но это как-то не по-русски. Я работаю там 1,5 года, но с перерывами. Мы берем группу, занимаемся, потом делаем перерыв и так далее. Я обучил человек 50, может чуть больше. Из них процентов 20 очень классные ребята, которые хорошо трудоустроились после курса. Много кто из выпускников устраивается потом на профильные вакансии, но я не сильно слежу за этим. Когда обучаешь довольно простым вещам (мы не учим чему-то сложному), это расширяет кругозор, не дает глазам замылиться. Ты видишь разный код очень разных людей. Ты видишь разные ошибки, прежде всего. Некоторые ты встречаешь первый раз в жизни, то как люди пишут, странные баги. Очень много интересной информации для мозга. Не даешь себе засохнуть. Нравится ли тебе быть наставником? Когда ученики хорошие - нравится, когда плохие - нет. Я очень нервный человек, мне хочется всех послать. В этом плане я скорее тренер, чем учитель, я довольно жесткий. При этом мне нравится общаться с теми, в ком я вижу интерес. Не обязательно должно получаться, но когда ребята стараются, это очень классно, с ними можно поговорить, мы периодически встречаемся лично. Они задают интересные вопросы, которые меня самого заставляют подумать. В целом, любой вид преподавания, особенно если ты преподаешь что-то связанное с твоей профессиональной деятельностью, - это бОльшая прокачка для того кто преподает, чем для тех, кто учится. Помимо знаний, которые получаешь по Ruby, про то как общаться с людьми, можно оттачивать свое ораторское искусство, общение с публикой по ту сторону кабеля, когда проводишь вебинары. Плюсов в этой деятельности много, минусы тоже есть. Есть рутина, когда ты третий раз ведешь один и тот же курс, тебе не так интересно. Ждешь, когда ученики уже дойдут до интересных тем, чтобы с ними было о чем поговорить, а то все какую-то фигню делают :). Вот и мы дошли до интересной темы :) Лейтмотив нашего интервью - RailsClub, ты там будешь рассказывать про Action Cable. В основном, все ему рады. Есть недостатки, не все еще клево, он подтекает; бывает, что два треда пишут в один канал. Но в целом, все очень довольны. И только от тебя я слышу скепсис. Расскажи о чем будешь докладывать? Не хочется спойлерить, но я чувствую, что у тебя на эту тему есть боль. Поделишься? Давай вернемся в весну 2015. За некоторое время до того, как состоялась конференция, на которой DHH объявил об этой замечательной фиче. Это для тебя действительно замечательная фича или такая “замечательная фича”, в кавычках? У меня к ней двойственное отношение. В чем-то замечательная, в чем-то “замечательная”. В любом случае, это громкая фича. В Teachbase вебсокеты использовались. Естественно, они были поддержаны эрлангом, потому что это был наш стек. У нас были планы по тесной интеграции сервиса, который обрабатывал данные с веб сокетов, с рельсой. Готовые решения, которые были в рельсе, мы не рассматривали, потому что людям, у которых есть вебсокет сервис написанный на эрланге, зачем-то пихать вебсокеты на Ruby было бы странно. Это как дать дворнику игрушечный совок. У нас была собственная идея (она реализована, выложена в open source и работает), как подружить рельсы с сокетами. И вот, в марте или апреле выходит Action Cable. Я посмотрел видео, посмотрел примеры, которые были. Первое впечатление было: “Вау, ничего себе! Это круто, это выглядит очень классно, удобно, красиво - прямо то, что я бы хотел использовать”. Это был дополнительный аргумент, чтобы не мигрировать на 4.2, а ждать Rails 5, чтобы в новой сделать что-то, используя кабель, сделать все классно. Хорошее впечатление от Action Cable относилось в первую очередь к каналам, к тому, что сделано непосредственно в Rails, обертке бизнес-логики. Мне очень понравилось, как все сделано: очень rails way, все как надо. Но была и вторая мысль - а на чем это будет? Это мысль пришла мне в голову, когда репозиторий самого кабеля в исходниках отдельно выложили на гитхаб. Тогда это работало на Celluloid, если я правильно помню. То есть это было реализовано на Ruby, что, конечно, не круто. У меня предвзятое, но распространенное мнение, что писать конкурентные программы на Ruby не нужно. Это не то, для чего этот язык был создан, особенно если говорить о масштабируемости и эффективности с точки зрения потребления ресурсов. Тогда у меня возникла идея подумать над тем, как же нам взять хорошее от Action Cable и хорошее от того, что на тот момент уже было реализовано в сервисе на Erlang. А там было уже много всего: горизонтальная масштабируемость, различные авторизации и так далее. Тогда я еще не знал про Phoenix. Как потом выяснилось, это было очень похоже на то, с чего начинался Phoenix. Но только сделано на живом Erlang. Хотя по факту под капотом все мы используем один и тот же Cowboy как эрланговский веб сервер. За год в кабеле произошло, конечно, очень много изменений. Все они, пожалуй, положительные. Во-первых избавились от Celluloid в пользу nio4r (который тем не менее и к Celluloid имеет отношение).Добавили очень много различных возможностей синхронизации, адаптеры и прочее.Но основные проблемы уходить не спешат. Буквально недавно был нашумевший баг с утекающей памятью, незакрывающимися соединениями. Довольно странно, что он возник уже после релиза 5.0. Еще висит несколько багов, связанных с производительностью. Все это говорит о том, что Action Cable сейчас не подходит для продакшена в какую-то большую систему, не блог с посещаемостью 100 человек, а реально большую систему с нагрузкой в тысячи и сотни тысяч людей. Это не тот инструмент, который может решить задачу. Тогда возникает вопрос, а какие вообще проблемы может решать Action Cable? Все мы знаем, что все нововведения в Rails появляются ради одного всем известного проекта на букву B. Я проверил, там действительно используется Action Cable, насколько это возможно определить, просто посмотрев логи браузера. Там используется там не тот Action Cable, который сейчас предлагается в рельсе, а, видимо, какая-то его предыдущая версия. А может это вообще не Action Cable? Может быть. По крайней мере, протокол веб сокетов подписан как ActionCable, но в какой сервер он стучится - мы не знаем. Протокол очень похож. К сожалению, инсайдерской информации оттуда нет. Но я не удивлюсь, если на самом деле там работает какой-нибудь сервер, который просто работает по тому же протоколу, может быть общается с рельсой, хотя на самом деле для того, что они делают, это и не нужно делают они буквально два сценария: отправить изменения, которые произошли на странице (кто-то написал комментарий, отправил тудушечку и так далее). Это бродкаст, первый сценарий. И сценарий, который, наоборот, от клиента отправляет информацию серверу о том, что человек делает на страничке. Она передается в несколько зашифрованном виде, но там примерно следующее: перешел на страничку или закрыл вкладку, трекинг активности некоторый. То есть, у них это все используется не очень нагружено? Да. И в этом случае Action Cable хватает. С одной стороны. А с другой стороны возникает вопрос: а зачем тут рельса? Я вижу единственный момент, который точно там используется, это аутентификация. Нам нужно как-то подтвердить право человека подключиться к сокету, подписаться на конкретный канал и так далее. Вот тут они наверное взаимодействуют с приложением. Но не факт, может быть и нет. Все остальное имеет малое отношение к бизнес логике. Я делал нечто подобное, у меня как раз веб сокеты использовались для трекинга активности. Все эти данные не писались в основное приложение, они там вообще не нужны, по крайней мере в сыром виде. Они писались в отдельную систему, там уже обрабатывались и потом вытягивались, когда нужно. В данном контексте не очень понятно: нужен там Action Cable или нет? Используется он или нет? Но раз это квакает как Action Cable, давайте допустим, что это он. Больше я не знаю реальных примеров. И я думаю, пока нет известных проектов, которые используют Action Cable. Наверное, многие хотят его использовать, но вопрос в объемах. Он очень хорош в том, в чем хороши все рельсы - быстро собрать MVP, показать кому-то первую версию проекта. Тебе не нужно ничего тащить, все есть в коробке, набросал realtime и работает. Но когда ты начинаешь это дело развивать, и появляются клиенты, нагрузка и так далее - что делать с Action Cable? Можно, в принципе, плодить инстансы, он выносится отдельно, как какой-нибудь фоновый Sidekiq и прочие побочные сервисы, которые есть у нас в приложении. Но насколько это эффективно - не знаю, пока у меня есть на этот счет большие сомнения. На твой доклад я очень хочу сходить. По моим ожиданиям это будет один из самых клевых докладов. Какие у тебя ожидания от RailsClub’а? Я первый раз ходил на конференцию в прошлом году. Чего-то о прямо очень зацепившего не было. Но были хорошие докладчики, например Claudio Baccigalupo, который говорил про Rails 5. Доклад Koichi Sasada про garbage collector, историю с поколениями, был очень сильный и интересный. Я понимал, наверное, процентов 70, но это было очень круто. Но я думаю, что любая конференция ценна не столько докладами, а тем, что происходит в кулуарах. Поэтому такого общения я и жду, учитывая что у нас приезжают “звезды”. Не знаю, насколько они будут готовы выйти в народ пообщаться, но это интересно. То есть ты бы задал пару вопросов Матцу? Честно говоря, у меня к нему нет вопросов :) Я бы послушал, что он будет отвечать на вопросы других, обычно я делаю так, редко сам спрашиваю. На прошлой конференции я общался с тобой, после доклада о микросервисах (Андреем Дерябиным, ведущим подкаста). И немного общался с Клаудио. Еще на прошлом RailsClub я узнал про Crystal, это довольно интересно, я теперь слежу за этим проектом. Подумываю над тем, чтобы как-нибудь где-нибудь его применить, написать на нем какой-нибудь экстеншен для Ruby, благо есть такая возможность. Какое-нибудь узкое место, может быть даже в проекте, над которым я сейчас работаю. Жду, когда выдастся свободный денек, чтобы разобраться и поиграть с этим делом. Про RailsClub этого года пока не опубликована информация о докладах, есть только люди. Посмотрим, что нас ждет. Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

David Heinemeier Hansson, creator of the Ruby on Rails framework and a partner at the software development company Basecamp, talks to Stefan Tilkov about the state of Ruby on Rails and its suitability for long-term development. He addresses some of its common criticisms, such as perceived usefulness for only simple problems, claimed lack of scalability, and increasing complexity. David also talks about the downsides of building JavaScript-centric, “sophisticated” web UIs, and why he prefers well-structured, “majestic” monoliths to microservices.

本期由彩程设计赞助，彩程设计是著名的 SAAS应用Tower背后的公司，目前他们正在制作新应用知人, 并招远程全职 Rails/iOS程序员，有意向的朋友请发简历到 terry@teahour.fm 本期节目邀请到了 Ash Chan, 和他聊聊远程工作的方方面，如何从头开始，如何接项目，如何找客户等如果要做远程工作必须要面对的问题。 Centax, Inc. Rework Remote 图书馆里的自由枪骑兵 如何开始你的 SOHO 之旅 (1) 如何开始你的 SOHO 之旅 (2) GetFreelancer Elance Upwork Harvest Freshbooks Billings Pro Drop jQuery as a dependency VanillaJS Code Ping Pong with DHH ( http://www.dhh-ping-pong.com 域名过期了！） Turbolinks 5: I Can’t Believe It’s Not Native! Gmail Notifr Dimensions Swift 语言的设计错误 Swifter - Swift 必备 Tips 王巍推特 Turbolinks Berkshire Hathaway 2016 Annual Shareholders Meeting 《硅谷》美女程序员 Tab vs Space Special Guest: Ash Chan.

Новости Няшный вывод от Rspec Вышли Rails 4.0 Новый интерфейс репозиториев в Github Ruby 1.8.7 медленно и печально отошёл в мир воспоминаний Устройство сетевых сервисов от Алексея Махоткина Rubinius в бою docopt.rb — замена OptionParser Изменение поведения scopes в Rails 4 Сеть надежна О цене сложности Обсуждение Гришковец теперь поет с Мгзавреби Ruby 2.0.0-p247 Статья про pgstatstatements и веб-интерфейс к нему от Кира Шатрова Профайл кошки Вафли в Facebook Новые рельсы Russia-doll caching, статья от самого DHH и гем, с которого все началось Turbolinks Стриминг для постоянных соединений Убрали Active Resource, Active Record Observers, action caching. Мануал по апгрейду до Rails 4 Agile Web Development with Rails 4 и Railscast PUT -> PATCH Отключили identity_map пример проблемы Убрали attr_accessible и attr_protected. Теперь вместо них gem protected_attributes

本期由 Terry Tai (http://terrytai.com/) 主持, 并有幸邀请到 Writings.io (http://writings.io/) 的创始人Rei, 他将和我们一起聊聊 Writings.io 这个项目，以及背后的技术细节和设计思想。 新世纪福音战士 (http://zh.wikipedia.org/wiki/新世纪福音战士) 凌波丽 (http://www.baike.com/wiki/%E5%87%8C%E6%B3%A2%E4%B8%BD) CSDN (http://www.csdn.net/) CodeCampo (http://codecampo.com/) Writings.io (http://writings.io/) CSDN (http://www.csdn.net/) Robbin (http://robbinfan.com/) Ruby on Rails (http://rubyonrails.org/) MongoDB (http://www.mongodb.org/) Turbolinks (https://github.com/rails/turbolinks/) PJAX (http://pjax.heroku.com/) Basecamp (http://basecamp.com/) Javascript Web Application (http://shop.oreilly.com/product/0636920018421.do) Twitter Flight (http://twitter.github.io/flight/) Nexus 7 (http://www.google.com/nexus/7/) Kindle Paperwhite (http://www.amazon.com/Kindle-Paperwhite-Touch-light/dp/B007OZNZG0) "Buy it" (http://terrytai.com/articles/a860b125-buy-it) Special Guest: Rei.

Turbolinks can make your Rails app feel faster by using JavaScript to replace the page content when clicking a link. It will be default in new Rails 4.0 applications, but here I show how to use it in Rails 3 and mention some of the gotchas.

Turbolinks can make your Rails app feel faster by using JavaScript to replace the page content when clicking a link. It will be default in new Rails 4.0 applications, but here I show how to use it in Rails 3 and mention some of the gotchas.

Рассказываем про недавно прошедшую конференцию HighLoad++ и обсуждаем гиковские темы, затронутые на мероприятии SECON.Посиделки. В выпуске: - Впечатления от конференции Highload++. - Темы с SECON.Посиделок. Веб-разработка фронтенда. Голоса подкаста: Антон Сергеев (hackPNZ) Слава Федотов (fe.off) Сергей Парамонов (hedin) Антон Копылов (antonkopylov) Ссылки: pushState + ajax = pjax Turbolinks Podsafe: J.1.0 - Frozen Paradise

Новости Given When Then для RSpec Поддержка массивов Postgresql в Rails 4 Новый ruby toolbox и исходный код Всякие фишечки для Ruby Враппер методов класса gem vkontakte_api и статья о его использовании ТЬюнинг Rails, nginx и Ruby Мнение по поводу Sinatra vs Rails Интересная идея как бороться с очевидными ошибками Сканер безопасности для Rails Линейная алгебра в Ruby Немножко функциональщины в Ruby Конкурентность ActiveRecord в Rails4 Обсуждение Скандальное интервью с DHH Message queue as a service Turbolinks