Podcasts about focuster

Jordan Baker is the CEO and lead developer of the Focuster app which is designed to boost your productivity. In addition, he mentors teams so that organizations can realize their visions more quickly with fewer errors and less stress.   Quotes To Remember: "How do you conduct yourself when no one is watching?" "Rank your potential priorities by using a matrix of values." "Only include the things that are the highest level priority." "Your state determines the kinds of results you will get." "There's only one thing you can do in this moment."   What You'll Learn: 10Xing your productivity Turning your day around Subtle things that affect our productivity Dealing with overwhelm Staying focused   Key Links From The Episode: Focuster Content Marketing Success Summit Productivity Virtual Summit Jordan@focuster.com Pzizz Insight Timer App Content Marketing Plaza   Recommended Books: 12 Rules For Life by Jordan Peterson Enlightenment Now by Steven Pinker Content Marketing Secrets by Marc Guberti Podcast Domination by Marc Guberti

In this episode, Kevin interviews Jordan Baker, a personal productivity expert and the creator of Focuster. Focuster is an auto scheduling calendar app for entrepreneurs, freelancers, and professionals. Topics discussed : Jordan's background What got him excited about productivity On reclaiming focus Using distractions before they use you Scheduling your distractions On the Pomodoro technique Getting […] O post FL129: 3 Ways To Crank Up Your Productivity with Jordan Baker of Focuster apareceu primeiro em Freedom Lovin.

Do you want to learn the habits that make us less productive? Are you ready to increase your productivity?  Tune in as Jordan Baker,Founder & CEO Focuster.com share how you can be more productive.  Jordan Baker is a personal productivity expert and the creator of Focuster, an auto-scheduling calendar app for entrepreneurs, freelancers and professionals. Over the last 20 years, first as a freelance software developer and later as the principal at a web development agency, he realized that personal productivity was crucial to professional achievement. He takes a holistic approach, integrating yoga, meditation, productivity systems like GTD, mindset coaching with Tony Robbins, Neuro-Linguistic Programming and more. Jordan shares his unique take on “managing your focus, not just your time” and the practice of time blocking to juggle competing priorities Want a FREE audio book? Go to Audible.com and you can get one. Listen to today’s podcast to find out which book I recommend for you Check out my organizing shop on Amazon which has products to help organize your home and life. Register for my upcoming FREE webinars by clicking this link. --- Send in a voice message: https://anchor.fm/janetmtaylor/message

Introduction with Jordan Baker about his cloud based software entitled Focuster.

“As a freelancer, as an entrepreneur, as a business owner you need to build systems of accountability that will help hold and support you.” Jordan Baker used his expertise in software development to help him create Focuster, a personal productivity tool (aka a scheduling calendar) that helps you manage not only your time but also your focus.  Listen in as Kim and Jordan discuss focus, time, the difference between being productive and being busy, and much more! Get the show notes, transcription and resources mentioned at https://thekimsutton.com/pp432 Highlights: 3:15 How to operate in an optimal state - aka being focused 3:32 How I developed Focuster   6:20 Three ways traditional “to do” lists are broken - 1) don’t account for time, 2) don’t distinguish the urgent from the important and 3) they’re stressful 10:36 Tony Robbins likes to say “If you talk about it, it’s a dream.  But if you schedule it, it’s real.” 11:43 I realized that software can play a role in helping you focus & plan your time 12:50 Work on the right things in the right order because if you’re not doing that, you’re not being productive, you’re being busy 17:04 Time Blocking 25:50 Concentration Meditation 26:07 The reason behind procrastination 27:50 Work Meditation

In today’s episode, we’re going to breakdown a software app platform known as FOCUSTER. I’ve brought in the founder, Jordan Baker, also a fellow Santa Cruzan friend of mine and a Shakapreneur. What the hell is a Shakapreneur, you might be wondering – well, listen in to find out! Jordan Baker is the founder and developer of Focuster, a productivity tool for professionals that helps you manage your focus. Working first as a freelance software developer and later as head honcho at a web development agency, he realized that personal development was key to getting the results he wanted in life and business. To support that, he’s studied wide range of topics from productivity systems such as the popular Getting Things Done, to inner practices like meditation and yoga. Originally from Toronto, Canada, he currently lives in Santa Cruz, CA where he enjoys learning to surf, playing guitar and the sweet sunshine. While the podcast will be presented in an audio format, video versions of certain episodes can be found through our website at www.YourAuthorityBlueprint.com. You’ll also find special links, extra materials, occasional reports and more on our site as well. Subscribe today and follow us on Facebook and Twitter! You can also learn more about your host at www.MichaelNeeley.com and check out our 3-day event coming up in June at Your Authority Blueprint Live!

Jordan Baker is a personal productivity expert and the creator of Focuster, an auto-scheduling calendar app for professionals that helps you manage your focus. Over the last 20 years, first as a freelance software developer and later as the principal at a web development agency, he realized that personal productivity was crucial to achievement. He integrates yoga and meditation, productivity systems like GTD and others, coaching with Tony Robbins, Neuro-Linguistic Programming and more. Jordan will share his unique take on managing your focus, not just your time and the practice of time blocking to juggle competing priorities.   Where you can find Jordan online: Facebook Twitter (Focuster App) Twitter (Personal) Focuster Blog   What did you think of this episode? I want to know. Go to MarkStruczewski.com/jordan and leave a comment.   To leave feedback about the podcast or give suggestions for ideas for future episodes (including guests you'd like to hear me interview), go to MarkStruczewski.com/mypodcast or email feedback@markstruczewski.com. If you are looking to take your productivity to the next level or if you are interested in bringing me in to speak at your event, visit MarkStruczewski.com. Follow me on LinkedIn, Facebook, Twitter and Instagram. Subscribe to my weekly Next Level Productivity Digest. If you love the show, share it with a friend on Apple Podcasts.

In this Productivity Academy podcast episode I'm talking with Jordan Baker about staying productive with someone who has used tools and experience to help so many others. Jordan Baker is the founder of Focuster. He has been creating web and mobile applications for startups and established corporations for over 15 years. Resources Mentioned: 12 Rules For Life - https://productivity.academy/12rulesforlife Willpower Doesn’t Work - https://productivity.academy/willpowerdoesntwork Stealing Fire - https://productivity.academy/stealingfire Obstacle Is The Way - https://productivity.academy/obstacleistheway Stay up to date, take your productivity, processes, and time management to the next level by joining me here: https://productivity.academy/more Check out the full post and more here: https://productivity.academy/podcast/episode-11-building-productive-future-jordan-baker-focuster/ --- Send in a voice message: https://anchor.fm/productivityacademy/message Support this podcast: https://anchor.fm/productivityacademy/support

MJS 033: Dylan Schiemann Today's episode is a My JavaScript Story with Dylan Schiemann. Dylan talked about his contributions to the JavaScript community to what JavaScript is back in 2004. Listen to learn more about Dylan! [01:10] – Introduction to Dylan Schiemann Dylan was on episode 62 of JavaScript Jabber, which was about 4 years ago. We had him on to talk about the Dojo Toolkit. [02:00] – How did you get into programming? When Dylan was 7 or 8 years old, he and his father took basic programming class together. In Junior high, probably mid-1980’s, he received his first Commodore 64 computer. He picked up the Programmer’s Reference Guide, toppled on Assembly, and tried to write data to a tape drive. It got updated to a floppy drive. And then in high school, he took some Pascal classes. He learned the basics - ranging from BASIC, Pascal, and to Assembly. [03:00] – How did you get into JavaScript? As an undergraduate, Dylan studied Chemistry and Mathematics. He did some basic HTML and discovered the web roughly when he was a junior year in college. And then, he went to graduate school and studied Physical Chemistry at UCLA. He was studying the topology and reality of quasi-two-dimensional phone. If you imagine a bunch of beer bubbles at the top of a glass, and you spin it around really quickly, you watch how the bubbles rearrange as force is applied to it. He wanted to put his experiments on the web so he started learning this new language that had just been invented called JavaScript. So, he dropped out of graduate school a few years later. Eight years after that point in time, it was possible to show his experiments with Dojo and SVG. [04:25] – How did you get into Dojo and the other technologies? SitePen Right after grad school, Dylan helped start a company called SitePen. That let him really learn how JavaScript works. He started doing some consulting work. And he started working with Alex Russell, who had a project called netWindows at the time, which is a predecessor to any JavaScript framework that most people have worked with. Dojo Dylan got together and decided to create a next generation version of the HTML toolkit, which ended up becoming Dojo back in 2004. Things that they created back then are now part of the language - asynchronous patterns such as Promises, or even modules, widgets, which led to the web components pack. Over the years, they’ve built on that and done various utilities for testing and optimizing applications. [06:20] – Ideas that stood the test of time A lot of the things that Dylan and his team did in Dojo were on the right path but first versions ended up iterating before they’ve met their way into the language. Other things are timing. They were there very early and but to tell people in 2005 and 2006 that you need to architect the front-end application met some confusion of why you would want to do that. According to him, they never created Dojo to say that they want to create the world’s leading framework. [07:45] – JavaScript Dylan no longer answers the question of, “Oh, JavaScript, you mean, Java?” The expectations of 2004 were the hope of making something that might work in a browser. The expectation today is we are competing against every platform and trying to create the best possible software in the world, and do it in a way that’s distributable everywhere in the browser. The capabilities have grown. There are audio, video and real-time capabilities. They were ways to do those things but they were brutal and fragile. And now, we have real engineering solutions to many of those things but there are still going to be ways to do this. There were few people who are interested in this and maybe this wasn’t even their day job. But now, literally hundreds and thousands of engineers who write code in JavaScript every day. Picks Dylan Schiemann JavaScript user groups JavaScript conferences SeattleJS Phoenix TypeScript Meet-up London HalfStack Charles Max Wood Focuster BusyCal Asana Trello

MJS 033: Dylan Schiemann Today's episode is a My JavaScript Story with Dylan Schiemann. Dylan talked about his contributions to the JavaScript community to what JavaScript is back in 2004. Listen to learn more about Dylan! [01:10] – Introduction to Dylan Schiemann Dylan was on episode 62 of JavaScript Jabber, which was about 4 years ago. We had him on to talk about the Dojo Toolkit. [02:00] – How did you get into programming? When Dylan was 7 or 8 years old, he and his father took basic programming class together. In Junior high, probably mid-1980’s, he received his first Commodore 64 computer. He picked up the Programmer’s Reference Guide, toppled on Assembly, and tried to write data to a tape drive. It got updated to a floppy drive. And then in high school, he took some Pascal classes. He learned the basics - ranging from BASIC, Pascal, and to Assembly. [03:00] – How did you get into JavaScript? As an undergraduate, Dylan studied Chemistry and Mathematics. He did some basic HTML and discovered the web roughly when he was a junior year in college. And then, he went to graduate school and studied Physical Chemistry at UCLA. He was studying the topology and reality of quasi-two-dimensional phone. If you imagine a bunch of beer bubbles at the top of a glass, and you spin it around really quickly, you watch how the bubbles rearrange as force is applied to it. He wanted to put his experiments on the web so he started learning this new language that had just been invented called JavaScript. So, he dropped out of graduate school a few years later. Eight years after that point in time, it was possible to show his experiments with Dojo and SVG. [04:25] – How did you get into Dojo and the other technologies? SitePen Right after grad school, Dylan helped start a company called SitePen. That let him really learn how JavaScript works. He started doing some consulting work. And he started working with Alex Russell, who had a project called netWindows at the time, which is a predecessor to any JavaScript framework that most people have worked with. Dojo Dylan got together and decided to create a next generation version of the HTML toolkit, which ended up becoming Dojo back in 2004. Things that they created back then are now part of the language - asynchronous patterns such as Promises, or even modules, widgets, which led to the web components pack. Over the years, they’ve built on that and done various utilities for testing and optimizing applications. [06:20] – Ideas that stood the test of time A lot of the things that Dylan and his team did in Dojo were on the right path but first versions ended up iterating before they’ve met their way into the language. Other things are timing. They were there very early and but to tell people in 2005 and 2006 that you need to architect the front-end application met some confusion of why you would want to do that. According to him, they never created Dojo to say that they want to create the world’s leading framework. [07:45] – JavaScript Dylan no longer answers the question of, “Oh, JavaScript, you mean, Java?” The expectations of 2004 were the hope of making something that might work in a browser. The expectation today is we are competing against every platform and trying to create the best possible software in the world, and do it in a way that’s distributable everywhere in the browser. The capabilities have grown. There are audio, video and real-time capabilities. They were ways to do those things but they were brutal and fragile. And now, we have real engineering solutions to many of those things but there are still going to be ways to do this. There were few people who are interested in this and maybe this wasn’t even their day job. But now, literally hundreds and thousands of engineers who write code in JavaScript every day. Picks Dylan Schiemann JavaScript user groups JavaScript conferences SeattleJS Phoenix TypeScript Meet-up London HalfStack Charles Max Wood Focuster BusyCal Asana Trello

MJS 033: Dylan Schiemann Today's episode is a My JavaScript Story with Dylan Schiemann. Dylan talked about his contributions to the JavaScript community to what JavaScript is back in 2004. Listen to learn more about Dylan! [01:10] – Introduction to Dylan Schiemann Dylan was on episode 62 of JavaScript Jabber, which was about 4 years ago. We had him on to talk about the Dojo Toolkit. [02:00] – How did you get into programming? When Dylan was 7 or 8 years old, he and his father took basic programming class together. In Junior high, probably mid-1980’s, he received his first Commodore 64 computer. He picked up the Programmer’s Reference Guide, toppled on Assembly, and tried to write data to a tape drive. It got updated to a floppy drive. And then in high school, he took some Pascal classes. He learned the basics - ranging from BASIC, Pascal, and to Assembly. [03:00] – How did you get into JavaScript? As an undergraduate, Dylan studied Chemistry and Mathematics. He did some basic HTML and discovered the web roughly when he was a junior year in college. And then, he went to graduate school and studied Physical Chemistry at UCLA. He was studying the topology and reality of quasi-two-dimensional phone. If you imagine a bunch of beer bubbles at the top of a glass, and you spin it around really quickly, you watch how the bubbles rearrange as force is applied to it. He wanted to put his experiments on the web so he started learning this new language that had just been invented called JavaScript. So, he dropped out of graduate school a few years later. Eight years after that point in time, it was possible to show his experiments with Dojo and SVG. [04:25] – How did you get into Dojo and the other technologies? SitePen Right after grad school, Dylan helped start a company called SitePen. That let him really learn how JavaScript works. He started doing some consulting work. And he started working with Alex Russell, who had a project called netWindows at the time, which is a predecessor to any JavaScript framework that most people have worked with. Dojo Dylan got together and decided to create a next generation version of the HTML toolkit, which ended up becoming Dojo back in 2004. Things that they created back then are now part of the language - asynchronous patterns such as Promises, or even modules, widgets, which led to the web components pack. Over the years, they’ve built on that and done various utilities for testing and optimizing applications. [06:20] – Ideas that stood the test of time A lot of the things that Dylan and his team did in Dojo were on the right path but first versions ended up iterating before they’ve met their way into the language. Other things are timing. They were there very early and but to tell people in 2005 and 2006 that you need to architect the front-end application met some confusion of why you would want to do that. According to him, they never created Dojo to say that they want to create the world’s leading framework. [07:45] – JavaScript Dylan no longer answers the question of, “Oh, JavaScript, you mean, Java?” The expectations of 2004 were the hope of making something that might work in a browser. The expectation today is we are competing against every platform and trying to create the best possible software in the world, and do it in a way that’s distributable everywhere in the browser. The capabilities have grown. There are audio, video and real-time capabilities. They were ways to do those things but they were brutal and fragile. And now, we have real engineering solutions to many of those things but there are still going to be ways to do this. There were few people who are interested in this and maybe this wasn’t even their day job. But now, literally hundreds and thousands of engineers who write code in JavaScript every day. Picks Dylan Schiemann JavaScript user groups JavaScript conferences SeattleJS Phoenix TypeScript Meet-up London HalfStack Charles Max Wood Focuster BusyCal Asana Trello

Jordan Baker is the Founder of Focuster, a software and app solution to help you better manage your time and organize your day. I personally use this software and it's made a big difference in my productivity so I'm really excited for you to learn more about how to better manage your time. In this broadcast, Jordan Baker and I talk about: What is Focuster and why did Jordan create it? Jordan’s tips for managing your time the most effectively Jordan’s advice for reclaiming your focus Why properly prioritizing your tasks is critical Why multitasking actually does more harm than good How Jordan utilizes the Pomodoro Technique How to connect with Jordan Baker online: Focuster @hexsprite Click to tweet: “Traditional to-do lists are broken.” - @hexsprite If you enjoyed today’s podcast, please leave a review on iTunes here. Thanks so much in advance for your support.

RR 318 Metaprogramming with Jordan Hudgens Today's Ruby Rogues podcast features Metaprogramming with Jordan Hudgens. We have panelists Jerome Hardaway, Brian Hogan, Dave Kimura and Charles Max Wood. Tune in and learn more about metaprogramming! [00:02:00] – Introduction to Jordan Hudgens Jordan is the Lead Instructor at Bottega. Bottega has locations in Salt Lake City, Utah and in Phoenix, Arizona. They’re a full-stack development code school. [00:02:55] – Metaprogramming Metaprogramming was one of those scary concepts. At the code school, when the students learn about metaprogramming and how it works, you can tell that it’s definitely a pretty exciting thing. Its formal definition is it’s a code that writes code. It can dynamically, at run-time, render other methods available to the program. [00:04:10] – Use cases for metaprogramming The best use case that Jordan has ever seen is implemented in Rails and that’s code that can run database queries such as User.find_by_email. By passing the email, it will go and find the user with that particular email. Now, there is no method in active record or in the user model that is called find_by_email. That’s something that is created at run-time. Another one is something that Jordan has implemented and that’s a phone parser gem. It essentially parses and validates a phone number. It also has a country code lookup. With all the countries in the world, that would be very time-consuming. But within 8 lines of code, it could do what a hundred lines could do without metaprogramming. [00:06:50] – Performance implications Jordan never had performance issues because the generation of methods is not something that’s incredibly memory intensive. You might run into that but it would be a poor choice to do in terms of readability. In Brian’s experience, it comes down to the type of metaprogramming you do. If you have a bunch of logic somewhere and method_missing, that’s going to be a performance bottleneck. And if you’re generating a bunch of methods when the application starts up, it might increase the start-up time of the application. But after that, the performance of the application seems to not have any fluctuation at all. There are 2 main types Jordan works with. First is method_missing. Method_missing could have a little bit of performance hit because of how Ruby works. The system is going to look at every single method. The second type is define_method. In define_method, you’re really just creating a large dynamic set of methods at runtime. When you start up the Rails server, it’s going to build all those methods but it’s not going to be when you’re calling it. Whereas in method_missing, it has a different type of lookup process.  [00:11:55] – Method collisions on monkey patching That’s one of the reasons why monkey patching can have a bad reputation. You don’t know who else may be overriding those set of methods or opening up that class. Jordan’s personal approach is trying to separate things out as much as humanly possible. If there’s something that can be done in the lib directory, you can place that functionality inside of a separate module. And if you’re creating a gem, you have to be sensitive to other gems in that space or even the Rails core. [00:17:25] – How to be good citizens to other developers Metaprogramming has a lot of potentials to do great things but it also has a potential to cause a number of problems in the application. For Jordan’s students, what he usually does is walk them through some examples of metaprogramming where it can be done poorly. But then, he will follow it up with showing exactly when this is done right. He shows examples of poorly written classes that have dozen nearly identical methods. And then, he also shows how they could take all those methods, put the names in an array, and show how to leverage things like define_method to generate them. He also shows them how doing monkey patching can cause issues, how they can actually open up the string class and change one of the basic functionalities. Show that when they override that, that affects the entire rest of the application. [00:24:45] – Worst examples of metaprogramming Jordan ran into this hive of metaprogramming. When he opened up one of its classes, he had no idea what that class did. It was method_missing all over the place. Usually, there are 4 or 5 lines of code inside of that. It’s relatively straightforward and makes logical sense when you read it. This was nothing like that. They had multiple conditionals inside of the method_missing. One other hard thing about it is it does not have any test whatsoever. You need some test to make sure you’re capturing that functionality and to check if changes broke anything. You can’t also decipher what the inputs and outputs are. [00:28:35] – Testing Follow as much as real world examples. For example, in the phone parser gem, you can see some tests in there for that. You can also pass in the input that you plan to give. See if that matches the output. Jordan tells his students that respond_to_missing is as important to putting method_missing in there [00:35:25] – Resources to get started Paolo Perrotta’s book Metaprogramming Ruby is one of the standards for metaprogramming in Ruby. He also gave some fantastic examples. He created a story about a new developer who goes into a company and learns how to implement metaprogramming from senior devs. It’s very entertaining and it also covers all the different aspects to think of metaprogramming, when to use it and when it could be a very bad idea to use it. Picks Jerome Hardaway Don’t Know Metaprogramming in Ruby? By Gavin Morrice Dave Kimura Sherlock TV Series on BBC Brian Hogan iOS application: Workflow Overwatch Charles Max Wood Ruby Dev Summit Angular Dev Summit Focuster Jordan Hudgens Petergate Comprehensive Ruby Programming by Jordan Hudgens Twitter @jordanhudgens Instagram @jordanhudgens Blog crondose.com

RR 318 Metaprogramming with Jordan Hudgens Today's Ruby Rogues podcast features Metaprogramming with Jordan Hudgens. We have panelists Jerome Hardaway, Brian Hogan, Dave Kimura and Charles Max Wood. Tune in and learn more about metaprogramming! [00:02:00] – Introduction to Jordan Hudgens Jordan is the Lead Instructor at Bottega. Bottega has locations in Salt Lake City, Utah and in Phoenix, Arizona. They’re a full-stack development code school. [00:02:55] – Metaprogramming Metaprogramming was one of those scary concepts. At the code school, when the students learn about metaprogramming and how it works, you can tell that it’s definitely a pretty exciting thing. Its formal definition is it’s a code that writes code. It can dynamically, at run-time, render other methods available to the program. [00:04:10] – Use cases for metaprogramming The best use case that Jordan has ever seen is implemented in Rails and that’s code that can run database queries such as User.find_by_email. By passing the email, it will go and find the user with that particular email. Now, there is no method in active record or in the user model that is called find_by_email. That’s something that is created at run-time. Another one is something that Jordan has implemented and that’s a phone parser gem. It essentially parses and validates a phone number. It also has a country code lookup. With all the countries in the world, that would be very time-consuming. But within 8 lines of code, it could do what a hundred lines could do without metaprogramming. [00:06:50] – Performance implications Jordan never had performance issues because the generation of methods is not something that’s incredibly memory intensive. You might run into that but it would be a poor choice to do in terms of readability. In Brian’s experience, it comes down to the type of metaprogramming you do. If you have a bunch of logic somewhere and method_missing, that’s going to be a performance bottleneck. And if you’re generating a bunch of methods when the application starts up, it might increase the start-up time of the application. But after that, the performance of the application seems to not have any fluctuation at all. There are 2 main types Jordan works with. First is method_missing. Method_missing could have a little bit of performance hit because of how Ruby works. The system is going to look at every single method. The second type is define_method. In define_method, you’re really just creating a large dynamic set of methods at runtime. When you start up the Rails server, it’s going to build all those methods but it’s not going to be when you’re calling it. Whereas in method_missing, it has a different type of lookup process.  [00:11:55] – Method collisions on monkey patching That’s one of the reasons why monkey patching can have a bad reputation. You don’t know who else may be overriding those set of methods or opening up that class. Jordan’s personal approach is trying to separate things out as much as humanly possible. If there’s something that can be done in the lib directory, you can place that functionality inside of a separate module. And if you’re creating a gem, you have to be sensitive to other gems in that space or even the Rails core. [00:17:25] – How to be good citizens to other developers Metaprogramming has a lot of potentials to do great things but it also has a potential to cause a number of problems in the application. For Jordan’s students, what he usually does is walk them through some examples of metaprogramming where it can be done poorly. But then, he will follow it up with showing exactly when this is done right. He shows examples of poorly written classes that have dozen nearly identical methods. And then, he also shows how they could take all those methods, put the names in an array, and show how to leverage things like define_method to generate them. He also shows them how doing monkey patching can cause issues, how they can actually open up the string class and change one of the basic functionalities. Show that when they override that, that affects the entire rest of the application. [00:24:45] – Worst examples of metaprogramming Jordan ran into this hive of metaprogramming. When he opened up one of its classes, he had no idea what that class did. It was method_missing all over the place. Usually, there are 4 or 5 lines of code inside of that. It’s relatively straightforward and makes logical sense when you read it. This was nothing like that. They had multiple conditionals inside of the method_missing. One other hard thing about it is it does not have any test whatsoever. You need some test to make sure you’re capturing that functionality and to check if changes broke anything. You can’t also decipher what the inputs and outputs are. [00:28:35] – Testing Follow as much as real world examples. For example, in the phone parser gem, you can see some tests in there for that. You can also pass in the input that you plan to give. See if that matches the output. Jordan tells his students that respond_to_missing is as important to putting method_missing in there [00:35:25] – Resources to get started Paolo Perrotta’s book Metaprogramming Ruby is one of the standards for metaprogramming in Ruby. He also gave some fantastic examples. He created a story about a new developer who goes into a company and learns how to implement metaprogramming from senior devs. It’s very entertaining and it also covers all the different aspects to think of metaprogramming, when to use it and when it could be a very bad idea to use it. Picks Jerome Hardaway Don’t Know Metaprogramming in Ruby? By Gavin Morrice Dave Kimura Sherlock TV Series on BBC Brian Hogan iOS application: Workflow Overwatch Charles Max Wood Ruby Dev Summit Angular Dev Summit Focuster Jordan Hudgens Petergate Comprehensive Ruby Programming by Jordan Hudgens Twitter @jordanhudgens Instagram @jordanhudgens Blog crondose.com

RR 318 Metaprogramming with Jordan Hudgens Today's Ruby Rogues podcast features Metaprogramming with Jordan Hudgens. We have panelists Jerome Hardaway, Brian Hogan, Dave Kimura and Charles Max Wood. Tune in and learn more about metaprogramming! [00:02:00] – Introduction to Jordan Hudgens Jordan is the Lead Instructor at Bottega. Bottega has locations in Salt Lake City, Utah and in Phoenix, Arizona. They’re a full-stack development code school. [00:02:55] – Metaprogramming Metaprogramming was one of those scary concepts. At the code school, when the students learn about metaprogramming and how it works, you can tell that it’s definitely a pretty exciting thing. Its formal definition is it’s a code that writes code. It can dynamically, at run-time, render other methods available to the program. [00:04:10] – Use cases for metaprogramming The best use case that Jordan has ever seen is implemented in Rails and that’s code that can run database queries such as User.find_by_email. By passing the email, it will go and find the user with that particular email. Now, there is no method in active record or in the user model that is called find_by_email. That’s something that is created at run-time. Another one is something that Jordan has implemented and that’s a phone parser gem. It essentially parses and validates a phone number. It also has a country code lookup. With all the countries in the world, that would be very time-consuming. But within 8 lines of code, it could do what a hundred lines could do without metaprogramming. [00:06:50] – Performance implications Jordan never had performance issues because the generation of methods is not something that’s incredibly memory intensive. You might run into that but it would be a poor choice to do in terms of readability. In Brian’s experience, it comes down to the type of metaprogramming you do. If you have a bunch of logic somewhere and method_missing, that’s going to be a performance bottleneck. And if you’re generating a bunch of methods when the application starts up, it might increase the start-up time of the application. But after that, the performance of the application seems to not have any fluctuation at all. There are 2 main types Jordan works with. First is method_missing. Method_missing could have a little bit of performance hit because of how Ruby works. The system is going to look at every single method. The second type is define_method. In define_method, you’re really just creating a large dynamic set of methods at runtime. When you start up the Rails server, it’s going to build all those methods but it’s not going to be when you’re calling it. Whereas in method_missing, it has a different type of lookup process.  [00:11:55] – Method collisions on monkey patching That’s one of the reasons why monkey patching can have a bad reputation. You don’t know who else may be overriding those set of methods or opening up that class. Jordan’s personal approach is trying to separate things out as much as humanly possible. If there’s something that can be done in the lib directory, you can place that functionality inside of a separate module. And if you’re creating a gem, you have to be sensitive to other gems in that space or even the Rails core. [00:17:25] – How to be good citizens to other developers Metaprogramming has a lot of potentials to do great things but it also has a potential to cause a number of problems in the application. For Jordan’s students, what he usually does is walk them through some examples of metaprogramming where it can be done poorly. But then, he will follow it up with showing exactly when this is done right. He shows examples of poorly written classes that have dozen nearly identical methods. And then, he also shows how they could take all those methods, put the names in an array, and show how to leverage things like define_method to generate them. He also shows them how doing monkey patching can cause issues, how they can actually open up the string class and change one of the basic functionalities. Show that when they override that, that affects the entire rest of the application. [00:24:45] – Worst examples of metaprogramming Jordan ran into this hive of metaprogramming. When he opened up one of its classes, he had no idea what that class did. It was method_missing all over the place. Usually, there are 4 or 5 lines of code inside of that. It’s relatively straightforward and makes logical sense when you read it. This was nothing like that. They had multiple conditionals inside of the method_missing. One other hard thing about it is it does not have any test whatsoever. You need some test to make sure you’re capturing that functionality and to check if changes broke anything. You can’t also decipher what the inputs and outputs are. [00:28:35] – Testing Follow as much as real world examples. For example, in the phone parser gem, you can see some tests in there for that. You can also pass in the input that you plan to give. See if that matches the output. Jordan tells his students that respond_to_missing is as important to putting method_missing in there [00:35:25] – Resources to get started Paolo Perrotta’s book Metaprogramming Ruby is one of the standards for metaprogramming in Ruby. He also gave some fantastic examples. He created a story about a new developer who goes into a company and learns how to implement metaprogramming from senior devs. It’s very entertaining and it also covers all the different aspects to think of metaprogramming, when to use it and when it could be a very bad idea to use it. Picks Jerome Hardaway Don’t Know Metaprogramming in Ruby? By Gavin Morrice Dave Kimura Sherlock TV Series on BBC Brian Hogan iOS application: Workflow Overwatch Charles Max Wood Ruby Dev Summit Angular Dev Summit Focuster Jordan Hudgens Petergate Comprehensive Ruby Programming by Jordan Hudgens Twitter @jordanhudgens Instagram @jordanhudgens Blog crondose.com

Episode Show Notes jeffsanders.com/202 Learn More About the Show The 5 AM Miracle Podcast Free Productivity Resources Join The 5 AM Club! Connect on Social Media Facebook Group • Instagram • Twitter • LinkedIn Episode Summary Wouldn't it be nice to feel incredibly accomplished at the end of the day? In this week's episode of The 5 AM Miracle Podcast I discuss the productive power of batching and theme days. These strategies can dramatically boost your productivity and creativity while helping you block distractions at the same time! In the Tip of the Week segment I share a great task manager for ultimate focus. Resources Mentioned in the Show Join The Rockin’ Productivity Academy [Get more done and dominate your day!] How to Consistently Achieve Your Ideal Week [episode #065] 17 Lessons from Rory Vadenís Procrastinate on Purpose [episode #161] Focuster [Focus management for entrepreneurs]

On this episode we talk about how to become a better and more productive entrepreneur. Resources mentioned on the episode: - 80/20 Sales and Marketing: https://www.amazon.com/80-20-Sales-Marketing-Definitive/dp/1599185059 - Focuster: http://www.focuster.com - Outsource Kingpin: https://outsourcekingpin.com/main - Productivity Academy: http://www.productivity.academy - Eat that Frog: https://www.amazon.com/Eat-That-Frog-Great-Procrastinating/dp/1576754227 Ask your next SEO question here: www.semanticmastery.com/humpday More SEO Goodness and Tutorials at www.semanticmastery.com/humpday Music: Gramatik - The Anthem All rights reserved