Podcast appearances and mentions of noel rappin

Play Episode Listen Later Oct 1, 2019 40:36

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling. Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things. Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components. Panelists Andrew Mason David Kimura With special guest: Mike Schutte 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 Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

law colorado tools storytelling testing cloud stimulus jest javascript rails panelists cucumbers turing storybook sentry typescript vim schutte andrew mason grumpy old man railsconf thoughtbot sandi metz rspec ruby rogues devchattv rode podcaster noel rappin webpacker tech done right

RR 432: Stop Testing, Start Storytelling with Mike Schutte

Play Episode Listen Later Oct 1, 2019 40:36

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling. Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things. Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components. Panelists Andrew Mason David Kimura With special guest: Mike Schutte 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 Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

law colorado tools storytelling testing cloud stimulus jest javascript rails panelists cucumbers turing storybook sentry typescript vim schutte andrew mason grumpy old man railsconf thoughtbot sandi metz rspec ruby rogues devchattv rode podcaster noel rappin webpacker tech done right

RR 432: Stop Testing, Start Storytelling with Mike Schutte

Technology Leadership Podcast Review

Play Episode Listen Later Oct 1, 2019 40:36

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling. Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things. Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components. Panelists Andrew Mason David Kimura With special guest: Mike Schutte 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 Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

law colorado tools storytelling testing cloud stimulus jest javascript rails panelists cucumbers turing storybook sentry typescript vim schutte andrew mason grumpy old man railsconf thoughtbot sandi metz rspec ruby rogues devchattv rode podcaster noel rappin webpacker tech done right

20. Multi-vitamins and Two-way Doors

Play Episode Listen Later Sep 16, 2019 21:05

Karen Catlin on Retaining WIT, Jonathan Cutrell on Maintainable, Dr. Aneika L. Simmons on Hanselminutes, Sarah Wells on Engineering Culture by InfoQ, and Dave Thomas and Andy Hunt on Tech Done Right by Table XI. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting September 16, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. KAREN CATLIN ON RETAINING WIT The Retaining WIT podcast featured Karen Catlin with hosts Jossie Haines and Jordanna Kwok. Karen, who is a leadership coach and diversity advocate, got interested in tech when she saw an issue of Money magazine with a cover story about successful women with computer science backgrounds and her father pointed out the connection between a career in software and Karen’s love of crafting, puzzle-solving, and mathematics. She started her career in 1985, which was a peak year for women in Computer Science. In that year, 37% of the Computer Science degrees went to women. It dropped to a low of 17% but has started to go up again in recent years. Karen started a coaching practice because she wanted to help women who wanted to grow their careers and stay in tech. She soon realized that, even if she could be the most amazing coach on the planet, her clients would still be facing an uphill battle because they were working in companies that were not the meritocracies they claimed to be. This led Karen to explore an idea: “Instead of trying to fix the women, let’s start fixing the men.” She says there is a role for every man who is working in tech to create a more inclusive workplace on his work team and at his company. Karen says that mentoring programs are a great opportunity for people to pass on advice to someone who hasn’t had the same amount of experience, but there is a trap: studies have shown that most of us mentor people who remind us of our younger self. Karen’s advice is, if you’re doing mentoring, mentor someone who doesn’t look like you. Don’t have a mini-me protégé. Another piece of advice from Karen is to pay attention in meetings. Look out for interruptions. There is research showing that men interrupt women much more than the reverse and that women who are getting interrupted tend to step back and not participate in the rest of the meeting or future meetings. So, when you see people getting interrupted, say something like, “Jordanna was making a great point. I’d like to hear more about that.” Another thing to watch for is what Karen calls “bro-propriation”: a woman says something in a meeting that falls flat and then, later on in the same meeting, a man says the same thing and gets all the credit. An ally can say something like, “Hey, I see that you agree with the point that May was making earlier.” Discussing hiring, Karen says she used to grab old job descriptions and add new requirements to them, reasoning that all the old requirements are still relevant. She says that you should instead try to get your job description down to just five requirements. Research has shown that women apply for jobs when they have all the skills listed in the job description while men apply even if they have little more than half of the listed skills. Karen also says to have objective criteria to use for every single candidate. Ideally, use the same interview questions. She told a story about moving to Silicon Valley with her partner Tim and applying to work at the same company in the same software engineering role. The two of them had interviews the same day. Driving home at the end of the day, Tim related to Karen that his interviews were among the most difficult he had ever had while her own experience was that the interviews had all been easy. The interviewers had dumbed down the questions when interviewing her. They were both offered jobs, but she decided not to take her offer because the company didn’t respect her enough to ask her the same difficult questions they had asked men applying for the same position. She then spoke about the importance of public speaking in gaining visibility and how it can help with both recruiting in the case of giving external talks and with getting your ideas considered. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/karen-catlin-on-being-better-allies/id1458996260?i=1000440710563 Website link: https://www.retainingwit.com/karen-catlin JONATHAN CUTRELL ON MAINTAINABLE The Maintainable podcast featured Jonathan Cutrell with host Robby Russell. Jonathan is the host of the Developer Tea podcast and is a senior engineer at Clearbit. Robby asked Jonathan what he thinks are the characteristics of a healthy and maintainable codebase. Jonathan says testing and having a consistent way of testing is critical to maintainability. He also looks at the size of each concept the code expresses to see if it can fit in a person’s head. Robby asked how Jonathan’s teams have achieved consistent testing. Jonathan says that human beings are pretty good at being about 90% consistent, which is almost worse than being 0% consistent. He says to take the load off the human engineer and, for those times when you still need to put the load on them, have a way to proceduralize things such as by having a checklist or template. Robby asked what Jonathan thinks developers often get wrong when they talk about technical debt. Jonathan says that debt is an easy term to throw around because, in the financial sense, it is a very clear concept. Technical debt does not have so clear a definition. You need to evaluate what your team cares about and what has been costly from a business perspective. Some things that we may think are debt are just emotionally difficult to accept: code that we wish was different but isn’t actually causing any real problems or even forecasted to cause problems. One factor that Jonathan thinks should be consistently considered technical debt is code that is staying around but for which you don’t have any kind of validation. I liked Jonathan’s metaphor for attempting to refactor code that is not under a lot of churn. Picking up code that isn’t changing much and improving its design, he says is like paying off low-interest mortgage debt. There are probably better places to expend our effort. Developers tend to treat decisions around technical debt like one would treat the decision to clean up your house. You have the sense of ownership over your home and, regardless of whether there is risk of future problems, we feel the need to clean things up. They talked about why Jonathan started the Developer Tea podcast. Jonathan wanted a podcast that he could listen to on an afternoon walk for five to ten minutes and learn something new. Most podcasts at the time were much longer and more entertainment-driven, and he wanted something that focused on the more human aspects of the job in a short, inspirational form. He says that the podcast has been one of the most rewarding things he has done in his career. The most rewarding experiences have been when people send him emails about how an episode or series of episodes have shifted the way they think about a topic or even about how they think about their career. They talked about whether there is a correlation between healthy code and healthy teams. Jonathan says there is data around teams in general that says teams that good relationships with their manager and the people they work with have the highest performance and the lowest turnover. These good team dynamics have visible effects on the code. Strong teams, Jonathan says, eradicate fear. These fears are things like fearing that someone is going to judge you poorly when they look at your code. Second, the best teams also know how to come up with the best ideas, which involves one or more team members being able to give up their own idea without attaching a sense of failure to letting that idea go. Third, members of strong teams recognize the humanity of everyone on their team. Robby asked what developers get wrong when evaluating their peers. Jonathan says that people, in general, tend to see everyone around them as inadequate as a way to containerize the rest of the world. This bias helps us to make decisions without being riddled with anxiety about them. The downside of this shows up when we are tasked with evaluating another person. This feeling that everyone else is inadequate combines in a bad way with our natural loss aversion when we try to make sense of things. Most failures are the result of factors that could not be controlled or predicted. With hindsight, when a project is late, we try to think of why it was late and we often come up with a reason, rightly or wrongly. We don’t often come to the conclusion that the project failed because something random happened. As a result, performance reviews tend towards the negative side unless we actively bias away from that. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear/id1459893010?i=1000447238745 Website link: https://maintainable.fm/episodes/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear-LgRTt32R DR. ANEIKA L. SIMMONS ON HANSELMINUTES The Hanselminutes podcast featured Dr. Aneika L. Simmons with host Scott Hanselman. Scott asked Aneika about the talk she gave with her husband Anjuan, “Managing The Burnout Burndown” at the Lead Dev conference: https://www.youtube.com/watch?v=e2dgOfedI3A. She talked about burnout having multiple dimensions including emotional exhaustion and depersonalization. When you are burned out, the people you work with start to lose, in your eyes, their personhood. Scott asked about how having a culture that depersonalized employees, such as by referring to them as “resources”, might lead to burnout. Aneika talked about how having a culture that values the highly-engaged software developer counter-intuitively increases rather than decreases burnout. She talked about managing burnout with the help of your relationships. When Aneika is looking burned out, Anjuan will often say, “Aneika, let’s go for a walk.” She talked about the American notion of the “protestant work ethic” and how the work itself is valued and makes the worker feel important and gives them a sense of meaning. Those that are not working are made to feel like they are not contributing. Scott connected this to how many Americans do not take all of their vacation days. Aneika talked about the difficulty of achieving work-life balance when pleasing your boss means disappointing your family and vice versa and she described how stress is the cause of many illnesses, telling her own story about getting a sore jaw while working on her dissertation because the stress caused her to start grinding her teeth. Aneika suggested building relationships with your boss and your team so that they see you as a person and not just as a contributor. When they see you as a person, they are less likely to attempt to make you feel small when you need to take time for yourself. Here's Aneika on the relationship between engagement and burnout. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/managing-the-burnout-burndown-with-dr-aneika-simmons/id117488860?i=1000447003518 Website link: https://hanselminutes.simplecast.com/episodes/managing-the-burnout-burndown-with-dr-aneika-simmons-1caMsclq SARAH WELLS ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Sarah Wells with host Shane Hastie. Sarah is the technical director of operations and reliability at The Financial Times. When Sarah joined FT in 2011, the company was full of smart people, but they were hampered by a frustrating set of processes. During the last eight years, they adopted a DevOps culture with a focus on automation. When she joined, it took an average of 120 days to provision a new server. They stopped tracking the improvement when they got it down to minutes. They moved from 12 releases a year to many thousand releases a year. This required pushing decision-making down to the individuals making the changes. Shane asked about how to achieve a culture of safety and experimentation. Sarah says it has to come down from the top. You cannot have a CIO or CTO is saying, “What went wrong? Who did this?” You optimize for the speed of release and for speed of fixing. You do incident reviews, but their goal is to improve things for next time, not lay blame. If you drop a database in production as a developer, that is not your fault. The fault is that it is too easy to do that. Shane asked what a culture of experimentation looks like at “the coal face.” Sarah referenced Linda Rising in saying that it is not an experiment if there is not a hypothesis and if it can’t fail. As soon as something costs a certain amount of money, very few organizations are willing to write it off, so if you’re going to experiment, it has to be something cheap and quick. Sarah gave an example of an experiment to test a design change in which they would show the star-rating on the list of film reviews. The thinking was that this would increase engagement. The experiment showed that engagement went down instead because people were less likely to click to see the full review once they had the star-rating. Shane asked about how Sarah limits the blast radius of changes. Sarah says that by releasing small amounts of code frequently and having an architecture like micro-services to keep components extremely decoupled, you are better able to understand the code you are releasing and the change is localized and less likely to affect distant parts of the product. You can also design your website to have graceful degradation when a particular service is not returning results. Shane asked about Sarah’s preference to buy rather than build. Sarah referenced Simon Wardley’s value-chain mapping and establishing the core thing a business does. For FT, the core business is news, so something like doing their own container orchestration is not part of that. Originally, they did their own container orchestration, but once Kubernetes was available, they moved to it. In discussing the sunk cost fallacy, Sarah says you always have to fight to invest in the technical stuff, so you need a good relationship between the tech leads and the product people to explain the benefits of particular technical decisions. You also need to accept that things change and you won’t always get it right. The flip side of moving fast is that sometimes you get it wrong. She related a quote from Jeff Bezos in a letter to shareholders about one-way door and two-way door decisions. For decisions that are likely a one-way door, invest time in getting them right, but for most decisions, you should just decide, commit, and revisit. Shane asked how the listeners who are working on monoliths that release once a month can get to where FT is at today. Sarah says that you need a continuous delivery pipeline so it takes no time at all to get a release out. The second thing is architectural changes. Get to zero-downtime deployments. The cultural aspects are things like process. Reduce anything that requires permission from an external team. It has to be possible for a team to just get going. She referenced Accelerate by Forsgren about the research that says not to have change approval boards. Architects get embedded in the individual teams instead. You want your engineers to be T-shaped, having one specialty but also having some skill in all areas. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/sarah-wells-on-fts-transition-to-devops/id1161431874?i=1000446732957 Website link: https://soundcloud.com/infoq-engineering-culture/sarah-wells-on-fts-transition-to-devops DAVE THOMAS AND ANDY HUNT ON TECH DONE RIGHT The Tech Done Right podcast featured Dave Thomas and Andy Hunt with host Noel Rappin. I realize that this is the third time in as many weeks that I have included a podcast episode featuring Dave and Andy talking about the 20th anniversary of The Pragmatic Programmer, but they keep saying different and interesting things on each podcast they visit that I keep wanting to share it. In this podcast, Dave described what being pragmatic means to him. He says that being pragmatic means doing what works, but nobody knows what works. The cool thing about software, which is also the scary thing about software, is that we are constantly reinventing the entire field. Every project is new: it has new circumstances, new technologies, and new requirements. When you don't know what to do, being pragmatic means exploring as much as you can to find out what works, having in place a system of feedback to tell you whether it is working or not, and taking steps that are reversible so that, if you make a mistake, you can go back and fix it. This, Dave says, is the essence of the book. Noel added a fourth variable, the team, that is different every time, and asked what the pragmatic approach is for how a team works. Dave says that a team is a voluntary collection of individuals. You don’t have a team that you put people into; you start with a group of people and try to turn them into a team. The book dedicates a chapter to teams that echos the previous chapters on individuals because teams need to know all the things that individuals need to know: they need to realize that they are going to make mistakes, they need to figure out when they’ve made a mistake, and they need to know how to fix those mistakes and minimize them in the future. As a programmer, your job is not to write perfect code; your job is to create something that does what the customer wants. If there are bugs along the way, that is not an exception; it just the way it is. The same applies to teams. When teams adopt that approach, they lose the incentive to blame people for things and they take on collective ownership. Andy says that the one thing that is unique to teams is an underlying trust of each other member of the team. You are much better off with relatively small, stable teams. Every time you add someone to or remove someone from a team, it is a new team and you need to start over building relationships, building trust, and learning to work with each other. Noel asked how they would compare The Pragmatic Programmer with the Agile Manifesto since they were involved in the creation of both. Dave suggested thinking of Agile methodologies like XP as a roadmap and The Pragmatic Programmer as your car. Noel said that, in re-reading The Pragmatic Programmer, he was struck by the emphasis on taking small steps and “not getting in front of your headlights”. Andy says that is critical idea because we fall into the trap of taking on too much at once all the time. Small steps, Dave added, also mean you can more easily undo and you are less likely to fall victim to the sunk cost fallacy because your sunk costs are smaller. Noel asked if the way in which developers learn has changed in the last twenty years. In reference to books versus StackOverflow searches and watching videos, Dave made the point that the distinguishing aspect of a book is that the content is curated; putting it together was difficult; it took a long time for the author to organize their thinking to make it clear and approachable and to produce something authoritative and easy to read as a whole. Noel asked Dave about the pragmatic value of automated testing. Dave says that when he gets too comfortable doing something, he tries to stop using it so that he doesn’t get stuck in a rut and so that he doesn’t start to believe something religiously simply because he has been doing it a long time. He had been telling people for years that it is good to test and he had never done the experiment of not testing. He decided not to test for a period and was surprised by the result. He kept an eye on bug rates and it was just as buggy as ever, his productivity went up a little bit, and his designs were just as flexible as before. His explanation is that, having done the requisite ten thousand hours, it is now so ingrained that he doesn’t have to test to get the benefits of testing. He still feels that tests are useful when working with others and as a regression barrier. He sees his experiment with not testing as another example that nothing is sacred: if you’re truly being pragmatic, you should always be experimenting. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-68-pragmatic-programmer-at-20-dave-thomas-andy/id1195695341?i=1000446898661 Website link: https://www.techdoneright.io/68 LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

american money americans research driving silicon valley doors picking jeff bezos reduce developers architects technical cto simmons computer science vitamins financial times cio agile accelerate devops xp kubernetes stack overflow two way dave thomas agile manifesto scott hanselman clearbit sarah wells infoq andy hunt engineering culture karen catlin simon wardley linda rising hanselminutes noel rappin developer tea shane hastie jonathan cutrell table xi jordanna kwok tech done right

Episode 0: Introduction to Meetings Done Right

Meetings Done Right

Play Episode Listen Later Aug 6, 2019 7:56

Welcome to Meetings Done Right, a 12 episode podcast about meetings inspired by the Table XI Inclusion Meeting Cards. In this introduction, hosts Ashley Quinto Powell and Noel Rappin explain the series and talk about their best and worst meeting experiences.

meetings done right noel rappin

Episode 144: Inconsistent at Best

This Agile Life

Play Episode Listen Later Jul 18, 2019 60:57

In this thrilling episode of This Agile Life, Jason asks for advice from Craig, Amos and Lee on what kind of metrics development teams can provide so there is some level of predictability as to new when features will be available to users or potential customers. Craig I Estimate this Talk will be 20 Minutes Long, Give or Take 10 Minutes by Noel Rappin, https://www.youtube.com/watch?v=jBMwT53oGsM Concolic testing, https://en.wikipedia.org/wiki/Concolic_testing * Concolic = concrete + symbolic Lee #NoEstimates Project Planning Using Monte Carlo Simulation, https://www.infoq.com/articles/noestimates-monte-carlo/ ActionableAgile, https://actionableagile.com/ Amos Agile and Beyond - Tom Churchwell, http://agileandbeyond.com Code Craftsman Saturdays - Bob Allen, http://codecraftsmansaturdays.blogspot.com Ford Agile Coaches - They are hiring agile craftsman who want to pair and do TDD email Fadi at fkhoury@ford.com Give and Take - Adam Grant, https://www.adamgrant.net/give-and-take Jason Book - Lynn Cazaly - Visual Mojo – Learn how drawing can be easy and fun & Agile 2019 keynote speaker - https://www.amazon.com/Visual-Mojo-Express-Lynne-Cazaly/dp/0987462911 Video - Brene Brown – Netflix Special: Call to Courage – Learn how shame and vulnerability impact you and your team and what you can do about it – https://www.netflix.com/title/81010166 Event - Agile Midwest Call For Papers Round Two (Sept 25/26 in St. Louis, MO) – Congrats to our first round selections but it’s not too late to submit your idea to share OR improve your submission if you weren’t selected – www.agilemidwest.org

talk agile inconsistent mccauley tice tdd fadi mckie noel rappin take adam grant

002 - Stimulus and Webpacker with Noel Rappin

Rails with Jason

Play Episode Listen Later May 1, 2019 32:06

In today's episode, I talk to developer and author Noel Rappin about Webpack, Webpacker, and Stimulus.

stimulus rails webpack noel rappin webpacker

07. Incremental Bumps and Swiss Army Knife Approaches

Technology Leadership Podcast Review

Play Episode Listen Later Mar 29, 2019 11:17

Mary and Tom Poppendieck on The Modern Agile Show, Daniel Mezick on Agile Uprising, Jennifer Tu, Zee Spencer, Thayer Prime, and Matt Patterson on Tech Done Right, James Colgan on This Is Product Management, and Matt Kaplan on Build by Drift. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting March 18, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. MARY AND TOP POPPENDIECK ON THE MODERN AGILE SHOW The Modern Agile Show podcast featured Mary and Tom Poppendieck with host Joshua Kerievsky. Recorded at the ScanAgile 2018 conference in Helsinki, Mary and Tom talked about their keynote on proxies and permissions. Inspired by Bret Victor’s statement that creators need an immediate connection to what they create, Tom and Mary presented on how the most effective teams are autonomous, asynchronous teams that are free of the proxies and permissions that separate creators from their creations. This led to a discussion of lean thinking and Mary pointed out that the interesting thing about lean is that fast and safe go together. She gave the example of a construction site where nothing slows things down more than the occurrence of an accident. Mary talked about how Jeff Bezos is a good early example of someone who understood that if you want to get really, really big, you need to have autonomous agents acting independently and thinking for themselves. iTunes link: https://itunes.apple.com/ca/podcast/interview-with-mary-and-tom-poppendieck/id1326918248?i=1000407584120&mt=2 Website link: https://github.com/modernagile/podcast/blob/master/ModernAgileShow_26_Interview_with_Mary_and_Tom_Poppendieck.mp3 DANIEL MEZICK ON AGILE UPRISING The Agile Uprising podcast featured Daniel Mezick with hosts Jay Hrcsko and Brad Stokes. Daniel told the story of how the OpenSpace Agility movement was born from ideas he brought to a Scrum Gathering in Paris in 2013 under the name Open Agile Adoption. He described Open Space as an invitational, all-hands meeting format in which there is an important issue, no one person has the answer, and there is an urgency to reach a decision. The Open Space format then creates the conditions for high performance through self-organization. Brad brought up that he imagines that OpenSpace Agility can be terrifying to some leaders. Daniel noted that the fear is due to the fact that we have failed the executive leadership of the largest organizations. In the name of “meeting them where they’re at,” we’ve traded away our principles and values and haven’t taught them anything in exchange. Daniel says, “Self-management scales. Not the framework.” This echoes Mary Poppendieck’s comments from the Modern Agile Show on how self-managing, autonomous, asynchronous agents are the only way to scale. Using Scrum as an example, Daniel said that, for the Product Owner to be successful, everyone in the organization must respect his or her decisions. If you do that, he says, you will immediately get culture change because you’ve refactored the authority distribution schema. iTunes link: https://itunes.apple.com/ca/podcast/openspace-agility-with-daniel-mezick/id1163230424?i=1000430511928&mt=2 Website link: https://agileuprising.libsyn.com/podcast/openspace-agility-with-daniel-mezick JENNIFER TU, ZEE SPENCER, THAYER PRIME, AND MATT PATTERSON ON TECH DONE RIGHT FROM TABLE XI The Tech Done Right podcast featured Jennifer Tu, Zee Spencer, Thayer Prime, and Matt Patterson with host Noel Rappin. Noel started by asking the guests what they thought the biggest mistake people make when trying to hire developers is. Thayer said, “One of the biggest mistakes anybody makes in hiring is hiring people they like and that they want to work with because they’re nice as opposed to hiring against a spec of what the worker is supposed to be doing.” This comment matches my own experience because this practice was rampant on previous teams of mine. Jennifer asked Matt how his company attracts candidates and he described using their current employee’s networks. Thayer called this the number one diversity mistake that all companies make. Noel asked about what to do at the end of the process where you need to go from multiple opinions you need to turn into a single yes/no decision. Jennifer has everyone write down their impressions before they talk to anyone else and write down specifically what they observed to support the conclusion you come to. This is how I always do it, but I’m always surprised at how few teams practice this. Noel asked about good and bad uses of interview time. I loved Jennifer’s example of what a bad use of time it is to say, “Tell me about yourself.” Sometimes I have candidates jump into providing this kind of information even though I hadn’t asked. Such people steer the interview into a well-prepared speech of all their best qualities that doesn’t give you a full picture of the candidate. Thayer then made a comment about the tendency of interviewers to try to make the candidates sweat. I agree with Thayer that this is usually the exact opposite of what you want if you’re trying to make the interview as much like the actual job experience as possible. iTunes link: https://itunes.apple.com/ca/podcast/episode-56-developer-hiring/id1195695341?i=1000430735771&mt=2 Website link: https://www.techdoneright.io/56 JAMES COLGAN ON THIS IS PRODUCT MANAGEMENT The This Is Product Management podcast featured James Colgan with host Mike Fishbein. James is a product manager for Outlook Mobile, which has 100 million monthly active users. James talked about his strategy for user growth being to make a product that is trusted by IT and loved by users. This led to their measures of success, such as usage and love for the product, measured by things like app store rating. James gave a great example of doing user research to create a product that is loved globally rather just in certain geographies. They did research in Asia and found drastic differences in the relationship between personal time and work time. They found North Americans and Europeans kept a strong delineation between work and personal time, but they found significant overlap between personal and work time among Asian customers. The data-driven nature of the product decisions payed dividends in both choosing the right features to work on and avoiding the wrong ones. They got the idea that they wanted to improve the ease of composing emails, but after looking at their instrumentation, they found that the average session length was 22 seconds. So instead they focused on consumption of emails over composition. iTunes link: https://itunes.apple.com/ca/podcast/188-listening-to-users-at-scale-is-product-management/id975284403?i=1000430581654&mt=2 Website link: https://www.thisisproductmanagement.com/episodes/listening-to-users-at-scale/ MATT KAPLAN ON BUILD BY DRIFT The Build by Drift podcast featured Matt Kaplan with host Maggie Crowley. Matt talked about how the book Creativity Inc. by Pixar founder Ed Catmull inspired him to see the similarities between creating products and telling stories. He says that every great story has a protagonist (the target user), starts with tension (the problem the product is trying to solve), has an end state (the vision for solving the user’s problem), has a core belief (the product differentiators), and consists of a sequence of events to get to that end state (the work we need to do to get the users from the tension to the end state). Maggie asked what the benefits are of thinking about products in this way and he explained that product management is about solving problems and telling stories. Stories could be used to convince salespeople that you’re doing the right thing, to tell engineers about what they’re going to build, or to tell customers about what your team has built. iTunes link: https://itunes.apple.com/ca/podcast/build-19-how-great-products-are-like-great-stories/id1445050691?i=1000430866513&mt=2 Website link: https://www.youtube.com/watch?v=swz0TnLwbrA&list=PL_sQbSaZtRqCn6JJSkjma79c8c4bLdaJH&index=4&t=0s FEEDBACK Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/channel/UCysPayr8nXwJJ8-hqnzMFjw Website:

stories interview european asian jeff bezos pixar north american approaches drift helsinki bumps incremental open space product owners swiss army knife thayer ed catmull creativity inc matt patterson matt kaplan bret victor joshua kerievsky tom poppendieck noel rappin outlook mobile mary poppendieck scrum gathering maggie crowley daniel mezick feedback ask agile uprising jennifer tu tech done right jay hrcsko

Episode 52: Small, Sharp Developer Tools With Brian Hogan

Play Episode Listen Later Jan 2, 2019 41:30

Small, Sharp Developer Tools With Brian Hogan TableXI offers training for developers and product teams! For more info, visit http://tablexi.com.workshops or email workshops@tablexi.com. Guest Brian P. Hogan (https://twitter.com/bphogan): Editorial Manager for DigitalOcean (https://digitalocean.com), Author of Small, Sharp, Software Tools: Harness the Combinatoric Power of Command-Line Tools and Utilities (https://pragprog.com/book/bhcldev/small-sharp-software-tools), teacher, student, and musician. More info at bphogan.com (https://bphogan.com/). Summary Developers use a variety of tools other than their programming language to get their jobs done. This week, we talk about those tools with Brian Hogan, an Editorial Manager for DigitalOcean. Brian's a prolific technical educator, writer, and editor and he's currently the author of the book Small, Sharp, Software Tools (https://pragprog.com/book/bhcldev/small-sharp-software-tools) from the Pragmatic Press. We talk about why command line tools in particular are important, what command line tools do well, and why some people including myself often find them opaque and confusing. We talk about our favorite tools and about customizing your workflow to fit your needs. Notes 02:33 - Benefits to being comfortable on the Command Line Interface (CLI) Small, Sharp, Software Tools (https://pragprog.com/book/bhcldev/small-sharp-software-tools) Brad Urani, The Ruby Developer's Command Line Toolkit (http://confreaks.tv/videos/rubyconf2018-the-ruby-developer-s-command-line-toolkit) Noel Rappin, The Developers Toolkit (http://confreaks.tv/videos/rubyconf2018-the-developer-s-toolkit-everything-we-use-but-ruby) Developer's Toolkit Cheat Sheet (https://medium.com/@noelrap/developers-toolkit-cheat-sheet-82d98d34fde7) Create React App (https://github.com/facebook/create-react-app) A command that shows commonly used commands (https://twitter.com/samphippen/status/1017738991012114433) 09:43 - Concepts that people struggle with and don’t internalize 11:13 - ‘awk’ and ‘sed’ defined - awk (https://en.wikipedia.org/wiki/AWK) - sed (https://en.wikipedia.org/wiki/Sed) - Elixir (https://elixir-lang.org) - F# (https://fsharp.org) 14:48 - The Ethos of Cargo Culting Information - Z Shell (https://en.wikipedia.org/wiki/Z_shell) - Oh My Zsh (https://ohmyz.sh) - Makefile (https://en.wikipedia.org/wiki/Makefile) - Deckset (https://www.deckset.com/) - Noel's Deckset Editor (https://github.com/noelrappin/deckset_editor) 20:02 - Reminding Yourself to Use Tools and Shortcuts - Z Shell History Substring Search (https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins/history-substring-search) - TextMate (https://macromates.com) 27:31 - Benefit to Setup/Cost Ratio - Bash prompt generator (http://ezprompt.net) - RB command line (https://github.com/thisredone/rb) 30:28 - Differences in Tools on Different Machines and Operating Systems 32:52 - Tools You Should Know Better - Rubular (http://rubular.com/) - regex101 (https://regex101.com/) - regex-railroad-diagram (https://atom.io/packages/regex-railroad-diagram) - entr (http://eradman.com/entrproject/) 37:29 - Practice as Continuous Improvement - Exercises for Programmers (https://pragprog.com/book/bhwb/exercises-for-programmers) Special Guest: Brian Hogan.

practice benefits tools differences benefit sharp concepts rb hogan ethos utilities programmers digital ocean software tools developer tools awk brian hogan editorial manager textmate create react app oh my zsh noel rappin brian p hogan

Noel Rappin from Tech Done Right

From the Beginning

Play Episode Listen Later Oct 18, 2018 30:47

In this episode we’re talking with Noel Rappin, Principal Software Engineer at TableXI and host of Tech Done Right, which is Table XI’s podcast about building software to develop better careers, companies, and communities.

entrepreneur podcasting storytelling principal software engineer noel rappin table xi tech done right

089: Something Something Agile with Noel Rappin

Greater Than Code

Play Episode Listen Later Jul 18, 2018 57:31

Greater Than Code Episode 001: Taking Payments on the Web with Noel Rappin (https://www.greaterthancode.com/2016/09/28/episode-001-noel-rappin-2/) 02:58 – Noel’s Superpower: Extrapolating and Explaining Consequences of Tech Decisions to Others 06:24 – Cultural Patterns of How Organizations Develop Software; Should this process be standardized? 16:07 – Agile Adoption: Pros and Cons The Leprechauns of Software Engineering: How folklore turns into fact and what to do about it by Laurent Bossavit (https://leanpub.com/leprechauns) The Journal of Irreproducible Results (http://www.jir.com/) 26:40 – Making Decisions Without No Scientific Evidence 32:05 – Metaphors for Software Engineering and Legitimizing the Profession 38:33 – Trust-Driven Development 44:12 – Decision Making Among Teams Reflections: Rein: We are working with systems that we can’t fully define and the idea that we’re acting on systems that we’re a part of. Therefore, it changes the observer effect. Jessica: Getting the ships to all go in the same direction. Coraline: The understanding of our place in a given context. Noel: Aligning process, values, culture, and goals, and doing that to make teams work better. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guest: Noel Rappin.

amazon journal llc web slack agile metaphors software engineering something something legitimizing noel rappin laurent bossavit devreps

MRS 014 My Ruby Story Noel Rappin

Play Episode Listen Later Aug 2, 2017 26:20

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

time chicago college books barack obama bear poland computer science api python java georgia tech computing javascript rails django elixir trs ruby on rails texas instruments react native take my money audio hijack charles max wood michael feathers software craftsmanship pragmatic bookshelf noel rappin table xi atom editor mighty mug master space test prescriptions tech done right

MRS 014 My Ruby Story Noel Rappin

Play Episode Listen Later Aug 2, 2017 26:20

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

time chicago college books barack obama bear poland computer science api python java georgia tech computing javascript rails django elixir trs ruby on rails texas instruments react native take my money audio hijack charles max wood michael feathers software craftsmanship pragmatic bookshelf noel rappin table xi atom editor mighty mug master space test prescriptions tech done right

MRS 014 My Ruby Story Noel Rappin

My Ruby Story

Play Episode Listen Later Aug 2, 2017 26:20

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

time chicago college books barack obama bear poland computer science api python java georgia tech computing javascript rails django elixir trs ruby on rails texas instruments react native take my money audio hijack charles max wood michael feathers software craftsmanship pragmatic bookshelf noel rappin table xi atom editor mighty mug master space test prescriptions tech done right

Episode 15: Agile Teams and Escaping Velocity with Doc Norton and Claire Podulka

Frontmatter: The Leanpub Author Stories Podcast

Play Episode Listen Later Jul 12, 2017 44:35

Agile Teams and Escaping Velocity with Doc Norton and Claire Podulka Follow us on Twitter! @techdoneright (https://twitter.com/tech_done_right), leave us a review on iTunes, and please sign up for our newsletter (http://www.techdoneright.io/newsletter)! Guests Doc Norton (https://twitter.com/DocOnDev): Co-Founder and CEO of CTO2 (http://www.wearecto2.com). Claire Podulka (https://twitter.com/cpodulka): Project Manager at Table XI (http://www.tablexi.com/). Summary How can you tell whether an agile software team is successful? Many teams use a single measure: velocity. Doc Norton, author of Escape Velocity, and Claire Podulka join the show to discuss why velocity is not a useful measure: it doesn't explain the problems with an unsuccessful team, and successful teams probably don't need it. We discuss the problems with velocity, what to use instead, and get on soapboxes for our least favorite agile anti-patterns. Notes 02:48 - Metrics for Agile Teams: Velocity - Escape Velocity: Better Metrics for Scrum Teams by Doc Norton (https://leanpub.com/escapevelocity) - Trust Driven Development by Noel Rappin (https://leanpub.com/trustdrivendevelopment) 06:15 - Using Velocity 07:49 - Problems When Relying Solely on Velocity and Estimation 12:35 - Theory of Flow 15:17 - Body Weight Analogy 17:17 - Assessing Team Health 18:37 - Team Temperature (Joy) 21:51 - Lead Time and Cycle Time 30:04 - Managing Estimation and Team Metrics When Teams and Scope Change 33:17 - Using Metrics: Large Organizations vs Small Organizations 39:18 - Breaking Down Team Velocity at the Individual Level Special Guests: Claire Podulka and Doc Norton.

ceo theory metrics project managers velocity escape velocity agile teams scrum teams lead time noel rappin doc norton table xi cto2 escaping velocity

Noel Rappin, Author of Trust-Driven Development

Play Episode Listen Later May 19, 2017 48:24

trust technology books development driven publishing self publishing leanpub noel rappin

Episode 10: Design Sprints with Kai Haley and Zeke Binion

Play Episode Listen Later May 10, 2017 44:43

Design Sprints with Kai Haley and Zeke Binion Follow us on Twitter! @techdoneright or leave us a review on iTunes and sign up for our newsletter (http://www.techdoneright.io/newsletter)! Guests Kai Haley (https://twitter.com/kaihaley): Interaction Designer on Google’s Design Relations Team, leads the Sprint Master Academy (http://www.teacuplab.com/blog/get-to-know-the-google-sprint-master-academy/) Zeke Binion (https://twitter.com/ebinion): Former Director of Design for Table XI (http://www.tablexi.com/) and runs Code for Designers (http://codefordesigners.com/) Summary Do you have a product that needs improvement, or a process to define? Is your team looking for a way to generate and test new ideas quickly? The Design Sprint process, created at Google, is a structured way to explore a problem, create a solution, and get user feedback, all in five days or less. Join Kai Haley (https://twitter.com/kaihaley), who teaches sprint facilitation at Google, and Zeke Binion (https://twitter.com/ebinion), who has run many sprints, as they show Noel Rappin (https://www.twitter.com/noelrap) how to use Design Sprints. Notes 01:24 - What is a “Design Sprint?” Who should use them? What are they good for? 04:08 - The Sprint Book: Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp, with John Zeratsky, Braden Kowitz from Google Ventures (http://www.thesprintbook.com/) Design Sprint Kit (https://designsprintkit.withgoogle.com/) 06:49 - Implementing Sprints Into a Team and High-level Goals How to Conduct Your Own Google Design Sprint (https://www.fastcodesign.com/1672887/how-to-conduct-your-own-google-design-sprint) From Google Ventures, The 6 Ingredients You Need To Run A Design Sprint (https://www.fastcodesign.com/1672889/from-google-ventures-the-6-ingredients-you-need-to-run-a-design-sprint) 10:47 - Facilitating Design Sprints; or “Being a Sprint Master” 16:40 - “How Might We…?” Brainstorming Sessions 19:32 - Journey Mapping and User Experience Mapping 23:45 - Success Metrics 25:18 - Sketching, Comparison, and Presenting Ideas “Crazy Eights” Sketching Sessions (https://www.iamnotmypixels.com/how-to-use-crazy-8s-to-generate-design-ideas/) 32:12 - The Deciding Stage: aka Prototyping 36:29 - User Interviews / Usability Studies 40:36 - Learning to Facilitate Design Sprints Special Guests: Kai Haley and Zeke Binion.

learning google design team code comparison designers former director sketching google ventures design sprints jake knapp john zeratsky journey mapping binion interaction designer test new ideas just five days braden kowitz noel rappin table xi

Episode 9: Conference Speaking and Diverse Perspectives with Carina C. Zona and Mark Yoon

Play Episode Listen Later Apr 26, 2017 46:40

Conference Speaking and Diverse Perspectives with Carina C. Zona and Mark Yoon Summary Want to start speaking at conferences? We go over how to get your first conference acceptance, then how to become a better speaker over time. For conference organizers, we also discuss how to find the best speakers from a diverse set of backgrounds and experiences. Carina C. Zona (@cczona) and Mark Yoon (@wimyoon) join Noel Rappin (@noelrap) on this episode of Tech Done Right. Notes Follow us on Twitter! @techdoneright (http://www.twitter.com/tech_done_right) or leave us a review on iTunes! Carina C. Zona (https://twitter.com/cczona): Longtime developer and advocate in the tech community, certified sex educator, founder of @CallbackWomen (https://twitter.com/CallbackWomen) Mark Yoon (https://twitter.com/wimyoon): Developer and Director of Talent at Table XI (http://www.tablexi.com/) 01:12 - @CallbackWomen (https://twitter.com/CallbackWomen): What it is and How it Came to Be Website with More Information (http://www.callbackwomen.com/) DevChix (http://www.devchix.com/) 05:45 - Questions You Should Ask as a First-time Speaker and Speaker Outreach 10:06 - The Goal and Mission of @CallbackWomen On BritRuby (Avdi Grimm’s Blog Post Re: Diversity at Conferences) (http://www.virtuouscode.com/2012/11/19/on-britruby/) Carina’s Talk: Schemas for the Real World (http://confreaks.tv/videos/gogaruco2012-schemas-for-the-real-world) 15:24 - Advice for Conference Organizers to Make Conferences Accessible to Everyone; Internal and External Barriers for Potential Speakers 23:29 - Everyone Has Something Valuable to Contribute and Talk About: Approaching Talk Proposals - Nadia Odunayo: The Guest: A Guide To Code Hospitality (https://youtu.be/hHzWG1FltaE) 32:28 - Getting a Talk Accepted - Nickolas Means: How to Crash an Airplane @ RubyConf 2015 (https://www.youtube.com/watch?v=S2FUSr3WlPk) 38:38 - Benefits and Impacts of Speaking at a Conference Special Guests: Carina C. Zona and Mark Yoon.

director mission advice speaking benefits speaker conference talent goal crash impacts internal developers longtime real world conferences zona yoon more information diverse perspectives noel rappin table xi carina c zona tech done right callbackwomen

Software, Open Source, and Rails With Eileen Uchitelle and Andrew Horner

Play Episode Listen Later Mar 29, 2017 42:13

Episode 007: Software, Open Source, and Rails with Eileen Uchitelle and Andrew Horner Follow us on Twitter! @techdoneright (http://www.twitter.com/tech_done_right) or leave us a review on iTunes (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341)! Notes How does the Rails core team work? How are new features planned and implemented? How can I contribute? What should I do if I find a security issue in Rails? Our guest is the newest Rails core team member Eileen Uchitelle (@eileencodes) joins Table Xi senior developer Andrew Horner and host Noel Rappin (@noelrap) to discuss Rails, the new testing features in Rails 5.1, and the Rails Core Team. Guests Eileen Uchitelle (https://twitter.com/eileencodes): Senior Systems Engineer at GitHub on the Platform Systems Team; Member of The Rails Core Team (http://rubyonrails.org/community/) and the Rails Security Team Andrew Horner: Senior Developer at TableXI (http://www.tablexi.com/) Summary 01:12 - Eileen: Getting Started as a Developer and Getting Involved with The Rails Core Team - CRUD! What to do When Active Record, MySQL, and Your Data Betray You (https://www.youtube.com/watch?v=lOpVcqiAIiI) 03:29 - How Rails Governs Itself Internally 05:52 - The Role of the Release Manager 07:32 - Feature Discussions and Prioritization 08:46 - Requesting Features and Raising Issues as a Non-core Team Member - HackerOne (https://www.hackerone.com/) 17:52 - Backporting 21:44 - System Testing 27:13 - Potential Future Features in 5.1 - Security is Broken: Understanding Common Vulnerabilties (https://speakerdeck.com/eileencodes/security-is-broken-understanding-common-vulnerabilties) 32:12 - User Expectations - RailsConf 2017: Building Rails ActionDispatch::SystemTestCase Framework (https://railsconf.com/program#session-87) 36:12 - Getting Involved in Rails - RailsConf 2015 - Breaking Down the Barrier: Demystifying Contributing to Rails (https://www.youtube.com/watch?v=7zoD6NZy6vY) - Aaron Patterson: I am a puts debugger (https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debuggerer.html) Special Guests: Andrew Horner and Eileen M. Uchitelle .

security software member breaking down developers open source github rails horner getting involved mysql senior systems engineer noel rappin table xi eileen uchitelle eileen m uchitelle

Ep. 131 - Take My Money (Noel Rappin)

CodeNewbie

Play Episode Listen Later Mar 12, 2017 45:35

If you plan on getting a job as a developer, chances are, you’ll deal with the technical side of accepting online payments. It might be as easy as plugging in a tool like Stripe or Braintree, but it can quickly get complicated. In this more technical episode, Noel takes us through some of those thorny situations and how a newbie can navigate the complex world of money. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Code Complete Apple IIe Zork The Pragmatic Programmer The Money Gem Shopify IRB Floating Point VCR gem AJAX Stripe Codeland Conf Codeland 2019

stripe mongodb braintree heroku take my money noel rappin

JavaScript: Islands, Sprinkles, and Frameworks with Zach Briggs and David Copeland

Play Episode Listen Later Mar 8, 2017 42:52

Episode 005: JavaScript: Islands, Sprinkles, and Frameworks Follow us on Twitter! @techdoneright (http://www.twitter.com/tech_done_right) or leave us a review on iTunes (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341)! Summary Dave Copleand (@davetron5000 (http://www.twitter.com/davetron5000)) and Zach Briggs (@theotherzach (http://www.twitter.com/theotherzach)) join Noel Rappin (@noelrap (http://www.twitter.com/noelrap)) for a Tech Done Right discussion of JavaScript practices. When does it makes sense to build single page JavaScript app? How can your JavaScript and Rails interact? Is it an island of interactivity or a sprinkle of JavaScript? Which frameworks are handling community management well (hint: not Angular)? And how do you test any of this? Guests Dave Copeland (https://twitter.com/davetron5000): Author of Rails, Angular, Postgres, and Bootstrap (https://pragprog.com/book/dcbang/rails-angular-postgres-and-bootstrap) Zach Briggs (https://twitter.com/TheOtherZach): JavaScript Practice Lead at Table XI (http://www.tablexi.com/) Show Notes 02:15 - Reasons to Build a Single-Page App (https://en.wikipedia.org/wiki/Single-page_application) - Conway’s Law (https://en.wikipedia.org/wiki/Conway's_law) 09:37 - The Ease of Building Web Over Single-Page Apps 11:30 - Tooling; Navigating Good Choices vs Bad Choices 14:31 - Setup - Bower (https://bower.io/) - webpack (https://webpack.github.io/) - Browserify (http://browserify.org/) - Broccoli (http://broccolijs.com/) - Yarn (https://yarnpkg.com) - The Asset Pipeline (http://guides.rubyonrails.org/asset_pipeline.html) 16:30 - Combining a Rails App and a JavaScript App 18:34 - AngularJS; 1 vs 2 - Angular (https://angularjs.org) - React (https://facebook.github.io/react/) - Vue.js (https://vuejs.org/) 33:05 - Testing - jasmine-rails gem (https://github.com/searls/jasmine-rails) - Test Double (http://testdouble.com/) 35:35 - TypeScript (https://www.typescriptlang.org/) - Elm (http://elm-lang.org/) Tips & Resources: Dave: Check out Test Double (http://testdouble.com/). Zach: As a developer, don’t feel forced into choosing between a single-page app and a non-single-page app on the first day of development. There are infinite points in between when it comes to interactivity. Noel: Read about frameworkless JavaScript in Noel’s book Master Space and Time With JavaScript (http://www.noelrappin.com/mstwjs/). Special Guests: Dave Copeland and Zach Briggs.

law tips single testing ease react islands conway javascript rails frameworks copeland broccoli elm yarn bootstrap vue angular sprinkles typescript tooling postgres angularjs test double browserify noel rappin table xi master space tech done right

Episode 004: In The Testing Weeds With Sam Phippen and Justin Searls

Play Episode Listen Later Feb 22, 2017 49:16

Episode 004: Testing Summary Sam Phippen, Justin Searls, and Noel Rappin spend this episode talking about the value of test-driven development (TDD) as well as its cost. They discuss the kinds of problems that developers are likely to have after they learn TDD and attempt to apply it to a large application. Learn why Rails is both great and terrible for automated testing, and how testing can influence the structure of your code. Guests Sam Phippen (https://twitter.com/samphippen): Engineer at Digital Ocean (https://www.digitalocean.com/) and member of the RSpec (https://github.com/rspec) Core Team Justin Searls (https://twitter.com/searls): Writes bad code effortlessly and cofounder of Test Double (http://testdouble.com/). Maintainer of several testing tools, and frequent speaker on test related topics. Show Notes 01:30 - Intermediate Level Problems in Testing 04:58 - The Value of Testing Boundaries by Gary Bernhardt (https://www.youtube.com/watch?v=yTkzNHF6rMs) 15:15 - Isolated Unit Tests 17:52 - Structuring Applications 23:13 - Test-Driven Development (TDD) (https://en.wikipedia.org/wiki/Test-driven_development) Growing Object-Oriented Software, Guided by Tests (https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627) 33:22 - TDD in a Smalltalk (https://en.wikipedia.org/wiki/Smalltalk) Environment 35:00 - Isolating Tests in a Rails Environment Rake Without Rails (http://blog.testdouble.com/posts/2016-12-15-rake-without-rails.html) 36:54 - Test Tools minitest (https://github.com/seattlerb/minitest) Dan North: Introducing BDD (https://dannorth.net/introducing-bdd/) teenytest (https://github.com/testdouble/teenytest) RSpec (https://github.com/rspec) Tips & Resources: Sam: Sandi Metz: The Magic Tricks of Testing @ Rails Conf 2013 (https://www.youtube.com/watch?v=URSWYvyc42M) Test Smells (https://github.com/testdouble/test-smells#test-smells) Justin Searls: How to Stop Hating Your Test Suite @ RubyConf 2015 (https://www.youtube.com/watch?v=VD51AkG8EZw) Justin: Find some little problem and instead of implementing it in a Rails app, type bundle.gem and then make up a name and then practice and invent your own way of organizing code and tests so you can break things down. Noel: JUnit Test Infected: Programmers Love Writing Tests (http://junit.sourceforge.net/doc/testinfected/testing.htm) As you’re trying to test stuff, really try to focus on going back and forth between the tests and the code more rapidly than you’re probably doing so right now. Special Guests: Justin Searls and Penelope Phippen.

tips testing engineers tests guided weeds small talk writes rails digital ocean tdd maintainer test driven development tdd test double justin searls rspec gary bernhardt noel rappin sam phippen

58: Noel Rappin - Fixing Common Payment Handling Mistakes

Full Stack Radio

Play Episode Listen Later Feb 8, 2017 40:21

In this episode, I talk to Noel Rappin about common mistakes developers make when handling payments on the web and how to fix them. As I mention in the show, if you've been thinking about checking out Test-Driven Laravel, the course is still available at the early access price for the next few weeks: Learn more about Test-Driven Laravel Early Access Sponsors: Rollbar, sign up at https://rollbar.com/fullstackradio to try their Bootstrap Plan free for 90 days Hired, sign up at https://www.hired.com/fullstackradio to double your signing bonus to $2000 if you get a job through Hired Links: Test-Driven Laravel, Adam's TDD course Noel's blog Rails 4 Test Prescriptions, Noel's book on testing Take My Money, Noel's book on payment handling Noel's screencast on floating point precision RubyMoney gem ngrok vcr gem

mistakes fixing payments noel rappin test prescriptions

290 RR Deployment

Play Episode Listen Later Dec 14, 2016 65:34

00:45 - What deployments have we used? 3:22 - Heroku 5:10 - Dev/prod parity 10:30 - Deployment stories 11:50 - Continuous deployment CircleCI SnapCI 15:55 - Working with clients that are anti-testing and writing tests 28:50 - Server setup Docker Chef 34:05 - Nginx and Passenger 39:35 - Handling caching issues and increasing server space 44:25 - Methods for deploying 46:30 - Team size and deployment Capistrano 49:40 - Monitoring tools Code Climate Honey Badger Zabbix NewRelic TrackJS JSJ 138 with Todd Gardner Picks: Dinosaur Odyssey by Scott Sampson (Jason) Shadows of Forgotten Ancestors by Carl Sagan (Jason) Rails Solutions: Ruby on Rails Made Easy by Justin Williams (Jerome) Take My Money: Accepting Payments on the Web by Noel Rappin (Brian) Deploying with JRuby by Joe Kutner (Brian) RR Episode 281 with Noel Rappin RR 150 with Joe Kutner Echo Dot (Charles) The Life-Changing Magic of Tidying Up by Marie Kondo (Brian) Getting Things Done by David Allen (Charles)

team chefs web ps shadows methods monitoring continuous passenger server marie kondo dev deployment rr getting things done david allen docker deploying tidying up honey badger life changing magic amazon echo dot heroku new relic nginx capistrano circleci zabbix jruby jsj todd gardner fy17 code climate noel rappin trackjs rr episode

290 RR Deployment

Play Episode Listen Later Dec 14, 2016 65:34

00:45 - What deployments have we used? 3:22 - Heroku 5:10 - Dev/prod parity 10:30 - Deployment stories 11:50 - Continuous deployment CircleCI SnapCI 15:55 - Working with clients that are anti-testing and writing tests 28:50 - Server setup Docker Chef 34:05 - Nginx and Passenger 39:35 - Handling caching issues and increasing server space 44:25 - Methods for deploying 46:30 - Team size and deployment Capistrano 49:40 - Monitoring tools Code Climate Honey Badger Zabbix NewRelic TrackJS JSJ 138 with Todd Gardner Picks: Dinosaur Odyssey by Scott Sampson (Jason) Shadows of Forgotten Ancestors by Carl Sagan (Jason) Rails Solutions: Ruby on Rails Made Easy by Justin Williams (Jerome) Take My Money: Accepting Payments on the Web by Noel Rappin (Brian) Deploying with JRuby by Joe Kutner (Brian) RR Episode 281 with Noel Rappin RR 150 with Joe Kutner Echo Dot (Charles) The Life-Changing Magic of Tidying Up by Marie Kondo (Brian) Getting Things Done by David Allen (Charles)

290 RR Deployment

Play Episode Listen Later Dec 14, 2016 65:34

00:45 - What deployments have we used? 3:22 - Heroku 5:10 - Dev/prod parity 10:30 - Deployment stories 11:50 - Continuous deployment CircleCI SnapCI 15:55 - Working with clients that are anti-testing and writing tests 28:50 - Server setup Docker Chef 34:05 - Nginx and Passenger 39:35 - Handling caching issues and increasing server space 44:25 - Methods for deploying 46:30 - Team size and deployment Capistrano 49:40 - Monitoring tools Code Climate Honey Badger Zabbix NewRelic TrackJS JSJ 138 with Todd Gardner Picks: Dinosaur Odyssey by Scott Sampson (Jason) Shadows of Forgotten Ancestors by Carl Sagan (Jason) Rails Solutions: Ruby on Rails Made Easy by Justin Williams (Jerome) Take My Money: Accepting Payments on the Web by Noel Rappin (Brian) Deploying with JRuby by Joe Kutner (Brian) RR Episode 281 with Noel Rappin RR 150 with Joe Kutner Echo Dot (Charles) The Life-Changing Magic of Tidying Up by Marie Kondo (Brian) Getting Things Done by David Allen (Charles)

047: Taking Payments on the Web with Noel Rappin

The Frontside Podcast

Play Episode Listen Later Nov 22, 2016 34:20

In this episode, Noel Rappin, developer at Table XI, comes on the show to talk about his new book, Take My Money: Accepting Payment on the Web. Noel Rappin: @noelrap | blog | GitHub Transcript: CHARLES: Hello everybody and welcome to the Frontside Podcast Episode 47. I'm Charles Lowell and with me today is Noel Rappin. Before we get into who you are, because I know that a lot of people know you already and you need no introduction, you're actually calling in from Chicago today, right? NOEL: That's true, yes I am. CHARLES: Did anyone actually show up for work today? NOEL: Yeah, people did actually show up for work a little bit later. So, this is being recorded the day after the Cubs won the World Series last night. I will say that my commute in the parking lot at the commuter rail station in the suburbs was surprisingly empty this morning. The people were a little bit slow to come in. The game didn't end till about midnight last night. CHARLES: I'm neither a Cleveland nor a Chicago Cubs fan but it was a harrowing game. It almost gave me a heart attack. NOEL: Oh, man. CHARLES: I can't even imagine what it was like. NOEL: A Cubbie Blue since I was a kid. So yeah, it was something. CHARLES: So, you're from Chicago? NOEL: Yeah, I grew up in Chicago. I grew up in the Chicago suburbs. I went away for school and I worked in Boston for a while, but came back about 12 years ago. CHARLES: Okay. So, that kind of leads me into the perfect setup for one of our questions is how did you get into development? I've known about you since I got into the Ruby community, probably back in 2010 or something like that. How did you come to be there? NOEL: I was one of those kids who was a developer at a certain age, I guess and I had an Apple II. I started programming Applesoft BASIC in the mid-80's, I guess, and eventually decided that I enjoyed it enough and got pretty over-educated at that and that's just a very traditional background. I went and worked at what we would now call web consulting company around 2000, my first professional job was '98 - 2000. I had done a lot of different languages as a student. That job was mostly in Cold Fusion and then eventually bounced around doing a bunch of different web development solutions. At some point along the way, I picked up the Ruby Pickaxe book and then eventually came to Rails. I started Rails as a hobbyist, either pre-1.0 or very early 1.0. I used it to build some task tracker for my team and a couple of other little tools like that. And relatively shortly thereafter, I started doing it professionally. CHARLES: I think you're kind of the same generation that I am. I call this [inaudible] from that early 2000's web development background where it's kind of fueled by [inaudible] network. NOEL: Yeah, a little bit. My first professional job was at a company that is a very, very small consulting company based in Miami and Boston and they were not developers who run the company. They've been documentary film makers and there's like a whole 90's technology trajectory here because they were documentary film makers and then they were documentary CD makers and then they were asked to add interactive stuff to the CDs that they were putting out and then they became web developers as a sort of a natural extension. And suddenly, it was like 1998, every company in the universe wanted to be on the web and they were like, "Oh, this seems like a good business to be in." And they started trying to hire actual programmers who knew what they were doing even though I was just out of grad school and didn't know what I was doing but it was convincingly put in. We did all the stuff then that would be like the first application that I worked there, the production server lived under my desk and was also the staging server and the development server. We didn't use, at that point, search control although eventually we did. There were no established conventions on what was the good thing to do. CHARLES: Yeah. The production server under the desk: a more elegant weapon for a more civilized age. NOEL: [Chuckles] Certainly old. CHARLES: That was a while back but you've obviously been doing a lot more structured, a lot more formal development over the course of your career. So, most of us, myself included, were kind of content to write the software, maybe blog about it every once in a while, give the occasional conference talk, but you've really, really delved in to those activities and really kind of taken the time to really, for the topics that you're interested in, really kind of research them very thoroughly to the point where you've actually written several books. When I think about the concept of writing a book, it sounds like, "Oh, my goodness! That sounds terrible. That sounds like a hundred of my teeth pulled out," or something like that. But you've done it multiple times. I'm curious, did you experience that kind of fear and uncertainty and what was kind of the decision making process that led up to, "No, this is something that I've got to do. I'm going to sign up for this. I'm going to do this. And I'm going to make this commitment." NOEL: Fear and uncertainty is a different question. I've always written things. I was a writer in some ways even before I was a programmer. So, being able to combine the two is something that I really enjoy doing. And I've always really enjoyed teaching. The more cynical way to doing that is I enjoy explaining things in a way that makes me sound smart. But I've always enjoyed doing it in whatever context. So, when I'm not writing, I've always often been involved in training at the places that I work or other things like that. And I've always been a little bit of a theater background and a little bit of a performance background and conference talks are a way to still scratch that itch a bit. CHARLES: You mentioned that you have a graduate degree. NOEL: No, my graduate degree isn't Computer Science but I did a lot of amateur theater things in high school and college. It's not something that I have a whole lot of other outlet for other than talking about development. CHARLES: [Chuckles] You wouldn't think that it's a natural thing but I think the best talks and the best walks. What's it like to have that element of theatricality to them? NOEL: I try in the books to give them a little bit of a voice. Sometimes you get interesting responses when you try to make a technical book a little bit funny. Some people really don't like it and other people really respond to it. I do it sometimes just as a way to maintain my own interest in the 14th page of this chapter or something. As far as fear and uncertainty, that never really goes away. I have a book out that I'm writing now about payments which is a very serious topic. And as much as I've done work in that and as much as I've done research on that, there are obviously people out there who have done more work and know more certainly about individual pieces of it. And there are a lot of people who are going to take anything that I write and implement it that way. They're going to take it as the way that things are done. So, that does introduce a tremendous amount of unsettling. CHARLES: Yeah, you're on the hook. They're like, "But Noel told me that this is the way to do it and I ran out of business." NOEL: Yeah. Actually, the payment book which is called 'Take My Money' is actually only a second book in the history of Pragramatic Programmers to have a legal disclaimer at the beginning which I'm very proud of. I think that the thing that is the most worrying especially when writing something long is not so much factual errors because I can check facts. Facts can be checked. Emphasis is much, much harder to check and the cultural community practices are much, much harder to check. And so, I'm often much more worried about the idea that I might spend a lot of time on something that nobody really is interested in or that I might not spend time on a really important thing just because it's a part of the world that I don't know as well as other people in there, and therefore, I miss something. Factual errors, I worry about them too. But factual errors are relatively easy to catch often, not always. Many, many years ago, I wrote for Rock's Beginner Rails book which was purchased by approximately nobody. But it's got one of those beautiful rocks black and white cover pictures of the author on it looking terrible. At that point, I had worked in Rails professionally but only for a very, very short time and there were certainly people who had a lot more experience than I did. But for whatever reasons, I had the book contract. In that context, there's a lot of uncertainty around not being sure that I know what the newest tools are or what the best practices are. CHARLES: How do you mitigate that? How do you address that? NOEL: Research is one way. There are pluses and minuses to not being the greatest expert or something when you're writing a book like this. One of the pluses is that your experience is a little bit more immediate and it's a little bit easier for you to make it relevant to somebody coming to it for the first time. But then a lot of times, you wind up doing the kinds of things that you might do if you were actually trying to learn it. But then I am a pretty good researcher and then I can compress that down into something that took me 4 or 5 hours to Google or research, or days to figure out the best practice, or talk to some experts sometimes and then I can hopefully distill that down to something so that you don't have to go on that entire journey. You can just cut the chase a little bit. It's researching. It's finding the people who do seem to be prominent in a particular technology or a particular skill and finding out what they're doing. Sometimes, it's getting it wrong, hopefully not very often. And sometimes, it's just like this is the best I can do and I have to like, "I can't solve every problem." CHARLES: Right, just being satisfied with that. NOEL: Yeah. CHARLES: I get it. That makes a lot of sense. You mentioned that the book you just wrote, the one about taking payments on the web, I saw that. I looked at it and I was like, "Oh, that totally needs to be this book. This book totally needs to exist." And thanks that it actually got written. But in hindsight, it's obvious that there wasn't really anything that like it treated web payments as this holistic topic that needed to be addressed and yet, when I look at the last 5 years or the last 10 years, this is a body of knowledge. It's been part of 90% of the applications that I've developed and it's been something inter-rolling like they've been patterns and stuff developed around it but I've never really thought about it, "We need to draw this circle around this practice." And this needs to be researched and there needs to be at least some guide on how to do this. And so, I think from my perspective looking in hindsight, seeing why it was published, "Oh yeah, that's totally obvious that that should have existed." But being on the other end, looking into the future of, given the infinite number of things that I could write about or I could research, I need to go about kind of the selection process and say, "This is something that really ought to exist." NOEL: This came about kind of interesting to me, I guess. The purpose of the book states it out pretty clearly. I, a few years ago, started working on - not a large web project by any means, but certainly one that had a fair amount of complicated business logic around their payments. And we inherited it with the payment gateway in place and I kind of thought that, "Oh, the payment gateway is there. That's the hard part." We just basically sat and pretty quickly learned that that was not the case. As I was really looking for best practices, things people who had delved to more problems on the assumption that a lot of people had to solve some more problems. One thing in particular that I was looking at was handling the failure case where I have to do something in my database and I have to process the credit card and they can't happen simultaneously but the failure of one affects how I process the other. I'm just looking around for how other people had solved that and really being surprised how little information I found about something like that. I kind of filed that away. About a little over a year ago, I had this weird idea that I was going to start doing some self-publishing again and sooner writing about this or thought about writing this as part of that, writing about payments and data modeling and something like that. And as I started getting into it, I was like, "I had enough issues here. This is longer than like a blog post and this longer than a magazine article. There's kind of a lot here." I worked with Pragmatic, so I know the editors there and I sent them a proposal and they pushed back a little bit on the idea of, "Aside from the documentation, what else do you need?" And I was like there are all these issues here. They know, Dave, they run their own web store, they wrote their own code and I actually was - part of when I got the contract because I got to interview Dave Thomas about how the Pragmatic store works which was great. It was really neat. CHARLES: Did that material actually make it into the book itself? NOEL: Not as such because I was a little reluctant to directly quote him about the internals of the Pragmatic store, but some of the principles Dave talked about. It was actually kind of reassuring that about 85% of it agreed with stuff I already thought I knew, and about 15% of it sort of went beyond that. They have some problems that are -- because they're actually managing physical inventory which a lot, not all web stores do, which introduces a whole host of other problems. It became a combination of I actually really do think I've worked on a lot of these problems and they're interesting. And a lot of people seem to have similar problems and there's now a whole lot here, and so it seemed like a book was a way for me to go on that. Other people might have gone a different direction. I am getting kind of an interesting reaction from people. I get a lot people who are saying, "Well, I really could have used that book two years ago." And not a lot of people say, "I really need to buy this book right now," which indicates maybe the marketing needs to be tweaked a little bit. I'm pretty sure it will. It's not even fully out yet, so it will find its audience. But it's interesting how I think people still even seeing the book is there assume that they know more about what they're getting into when they start doing payments. And then they come out the other end a couple of years later and they're like, "Oh wow! I really wished I had the guide on that." CHARLES: So, what you need to do when marketing this, you need something along the lines of 'you don't need this book two years from now' or like 'don't be the person who wishes they read this two years from now, read it now'. NOEL: If I had this book when we started, I would have saved so much time and not made so many mistakes. CHARLES: Yeah. It's always interesting to me the interplay between kind of the patterns evolving and documenting the patterns and how eventually that kind of precipitates code that makes those patterns automatic. But it feels like there's always this kind of knitting edge where you have to kind of explore the problems phase and do the research and then eventually you can kind of turn and digest and write little pieces of it, but eventually it becomes like code. Have there been actual code like plug-ins or stuff that has fallen out of this, or that people can reference directly? NOEL: Yeah. Not as such. There's a reference application in the book, but I submitted a couple of patch requests to a couple of gems along the way but nothing significant. It's pretty unusual for me to co-model a book like this with a lot of new open source tools. I'm usually more about using the things that are already there. But the book definitely has an opinionated set of thoughts about how you design a Rails application and it's pretty upfront about that. We're going to put all our workflow logic in their own objects and we're going to not put a lot of stuff in the active record models and we're going to do it for these reasons. The first chapter of the book actually is not even payments. It's just shopping carts and a way to talk about the data model and the design because ultimately, money has some word aspect but a lot of it is just principles of doing good software design, encapsulated software design, and the way you will deal with any big external 3rd party dependency. But then on top of that, you have the specific pieces of money is weird, like money has real world implications and has legal implications and things like that. CHARLES: Yeah, definitely. Whenever you're dealing with money, there's an elevated level of pressure that seems like it's put on. And I know personally when I think of -- lately, I was writing my very first payment system. We actually maintained for a while the stripe-rails gem which had moderate popularity but we don't maintain it anymore. But it was that project where we did that where I kind of became an information recorder. And it kind of started me on this journey of never destroying information, kind of that immutability and like functional programming and stuff like that because I was so worried about over-writing any information about the payments coming in. I was like, let's capture it from the web hook and write it to the database and replicate it and back it up and let's never throw away a fact. NOEL: The specific advice in the book is save as little of your user's personal information as you can and as much of the transaction information as you possibly can. It definitely recommends saving the entire response in the payment gateway. It recommends making sure that you store all of the pieces of your partial price calculation so that you can recreate it even if the logic changes because that is something that has specifically bitten me in actual world. CHARLES: Can you elaborate on that when you say partial price information? NOEL: Yeah. The application that I work on, it sells tickets. And it has a processing fee. Originally, the processing fee was whatever the processing fee was and I hard-coded it as a constant in the code base because I thought I do not need to write this processing fee to the database for every individual transaction because I was wrong. And eventually of course, they changed the processing fee which would be fine if you never had to look backwards at all and try to run a report of old transactions and try to validate that the prices on old transactions still held. So, they changed the transaction fee and then they started running reports and all of the reports are off by whatever the changed amount was. CHARLES: Right, I see. So you could still maybe store that constant in the code base but you have to at least write out what it was at that point when you did the transaction. NOEL: Yes. Not all of this has managed to make its way back to the legacy code mass that I'm actually dealing with. But what I would recommend is saving all of the individual pieces. Unit price, any processing fees, any shipping fees, any tax fees, any discounts, saving all those as they were calculated as part of the transaction so that you always have them and they're not dependent on the code or the logic staying the same because all of that logic will change. CHARLES: I'm all about the information hoarding. I think it's useful stuff. [Chuckles] NOEL: I even started recommending originally a failed transaction was in a database transaction so it would go away. But I think that it's a bad idea. I think that you need to save -- whether you actually save a partially failed transaction in your database or whether you log something, the information of those failed transactions is really important and you want to make sure that you hold on to that stuff and you can go back and look at it. The idea that a bunch of transactions are always failing and you don't know about it, that's problematic. CHARLES: It sounds like you're still working on this application which [inaudible] the book. NOEL: Although I'm a lot more critical of the code now that I've gone through -- the book made me sort of think about this stuff a little more systematically that I had and made me make a lot of things concrete that weren't quite in the original application. So, the code in the book is actually better than the code in the application. CHARLES: Of course. NOEL: It's also a lot simpler. CHARLES: Exactly. [Laughs] Because it doesn't actually have to do the real work, it just has to capture the principles. NOEL: It just has to be a good enough façade to show the ideas. CHARLES: Right. So, you're still working in this application that kind of service [inaudible] for the book. But I'm curious then how you manage that because for me, writing a blog post is hugely time consuming. Writing a book must be even more so. Do you just have it dialed in that well that you can just bang it out or do you mix doing the book writing with working on the application because obviously, it sounds like both are kind of crucial to each other. You've already said, "The fact that I wrote the book is actually informing the way that I structured the code that made me write the book in the first place." And so, how do you interleave those activities to make a continuous workflow? NOEL: There's a separation there because the book is the thing I do not at work, it's my side project effectively. I'm not ever mixing them in the sense that I'm really going back and forth between one thing and the other. The application is the thing I do at work; the book is the thing I do at home. They inform each other, obviously, but separating them is not usually a problem. They're not the thing I do at the same time, so they don't relate to each other that directly. CHARLES: I see. NOEL: It's time consuming but it's what I do instead of maintaining an open source project or doing some other community thing in what would be side project kind of work. CHARLES: So you just do it on your spare time. NOEL: Usually, the book is written between 10 and midnight for people who are reading between 10 and midnight. CHARLES: [Laughs] I like that conception. Do you think it would work at all if say, with your job there were some amount of time allocated for writing the book because I think there's some interplay and hopefully, it's [inaudible] interplay between the two activities. NOEL: The way my work job is structured right now, I actually do a certain amount of time for blogging but that's company blogging. It wouldn't necessarily cover working on the book. It would certainly go faster if I had time because certainly trying to squeeze some parts of this into my allegedly spare time becomes challenging. Writing a book like this is not just writing a book. You're actually writing to some extent an application and it's not a fully featured application but it does have to work and the tests have to pass and things like that. It has to work well enough so that if somebody were to copy it, it would run. That can be frustrating when to come to writing the book and find out that, "Some gem is updated and now, there's some weird test failure in my book," is sometimes a little frustrating. CHARLES: Yeah, I know. I can imagine. You said that the book, most of the examples are in Ruby on Rails. Would you see it being valuable to someone who was not doing Rails development at all, maybe he was doing something in Python or Clojure? NOEL: Some of it is in JavaScript because the client-side Stripe library is in JavaScript. That's kind of the central part of it especially for security purposes. Some of the code would carry because the Stripe API is actually pretty similar across a lot of these languages. I think some of the principles would still hold. Some of the tools are a little bit Rails specific but some of the basic ideas of separating things in the background jobs, the way that you need to think about the administration, handling failure, like some of that I think would have some value outside of the Rails world. CHARLES: Were you explicitly thinking of how the developers with the web payment problem in general is your audience or were you really thinking this is more for Rails people or where did the kind of needle fall there? NOEL: The tricky part here is that it becomes very, very hard to write a book simultaneously using the Rails API and the Python API. It's very confusing. It's a 300-page book as it is and you have to make some decisions there. While I would like it to be valuable to anybody who's doing web payments as sort of a practical matter, Rails and the Ruby API are the ones I know best and that's where the examples are because they have to be in something and they can't be in everything. CHARLES: I remember a lot of those books that I read that used Java kind of as the one [inaudible] of the system that they were talking about. But it really was like, you're right, there's a line that we have to tread there because you can't just wave your hands and talk in one piece abstract principles that have no ground in reality. But at the same time, by giving concrete examples, you may limit the potential audience. I do think there is a path in there where your examples are accessible to people from different backgrounds. NOEL: Examples are really hard, actually. It's a very tricky thing to have an example that is complicated enough to get the point across but not so complicated to get buried in extraneous details. It's really a problem actually when you try to write about testing because almost any problem that is simple enough to be an example in a book is not complicated enough to show why test-driven development is a good idea. [Inaudible] has the same issue a lot of times like you start bringing these relatively robust methodologies to this little toy problems and it's hard to get across why they're valuable when you're working on a toy problem. Not impossible. There are people who do it. CHARLES: If I can count the number of tutorials that were like modeling cats and dogs and people, it's like I've never written a single class that even remotely resembled any of that stuff. NOEL: You're bringing in more complicated problems but then you become so sensitively dependent on the weird crooks of whatever problem you've chosen which can be difficult if you make it feel like it's less universal. If the idea is that these techniques or these tools are going to help you manage the complexity in your application, then you need to show an example that actually has enough complexity for them to sort of work. It can be really challenging. CHARLES: You mentioned also the examples [inaudible] some of them are in Ruby that you're actually opinionated about making sure that the main logic is captured in objects which I think actually furthers that goal where you're not really bound so much to the Rails APIs. But then you said obviously, the other stuff is in JavaScript just because the client side Stripe library is implemented in JavaScript. You wrote a book on JavaScript a few years back. So clearly, it factors into your development story. I like to often kind of try and tell people like we are all JavaScript developers, whether you know or not. Do you have any advice for people who were approaching JavaScript from outside the core of [inaudible]? What's the best way to make your [inaudible] approach? NOEL: I have opinions on this. The problem is that I don't do big single page JavaScript apps, for the most part. It's just not part of my nutritional background at the moment. Mostly the JavaScript I'm doing is relatively at the kind of thing they sort of derive as sprinkles of JavaScript. CHARLES: Like I said, I think it's a far larger attempt than anyone cares to acknowledge. NOEL: I feel like my decision to try very hard to stay out of the JavaScript ecosystem battles has paid off for me tremendously in most ways. At the same time, I don't have really strong opinions about JavaScript build tools because I hadn't really had a whole lot of occasion to use them. I very strongly recommend that people coming into JavaScript now that you use some of the ES6 features especially things like classes and stuff that like to give you a better structure. Structure in JavaScript gets a little bit more consistent than what you see in other programming languages. A lot of those changes were I think pretty beneficial to how I work with the language. One thing that I like to do when I am doing something that is smaller, too small to really bring in a framework because I'm still doing mostly kind of jQuery, is I have a style where I really do try to isolate the jQuery in the DOM from the logic in a way that they don't always see people do on the theory that the DOM is a big 3rd party dependency in a way that on the server side, the database is a big 3rd party dependency. And in both of those cases, we kind of pretend that they're not big 3rd party dependencies because it's easier to integrate them, but eventually that kind of hurts. And I find raw jQuery and raw JavaScript is very hard to read and hard to understand. So, I think it does a little bit better if you start burying it behind some stuff that has some more semantic [inaudible] and things like that. And then we get to the point where you need a framework that actually has data binding even if it's a small framework like Vue.js or something like that, then you have some habits that will help you as you start building them. CHARLES: I think it's been interesting. Obviously, you did JavaScript a lot here but having that separation in kind of a mental model of what is my representation of the data and how am I actually presenting that to the user. It's kind of scary how universal that concept is and how well it will serve you as you grow from the simplest little one liner JavaScript thing to a whole full-fledged single page application using whatever framework you choose. If you abide by those principles, it may not be easy but it's going to be a lot more tractable. NOEL: Your transition to using one of those tools is going to be a lot easier if you already in habit of separating out your display logic from your actual logic. CHARLES: Yeah. Believe me, I'm not looking to like draw you into any kind of controversy here with JavaScript or Rails. But in the last several Ruby conferences that I've been to, there's been a lot of talks and a lot of discussions about 'where's the Rails community headed', 'where's the Ruby community headed'. How does it fit into this kind of new ecosystems that are emerging and what's the role that it's going to play down the road? And so, I'm just kind of curious to get your take on that as someone who operates in a bunch of different environments. Is Rails something, if you're starting an application from scratch, you would pick up again? NOEL: Yeah, I still pick up Rails for new applications. I think that, especially because the ecosystem is still so far ahead of all the newer tools ecosystems, I still think it's still the best way for a small team to act like a big team. We're definitely investigating other stuff, other tools. All of our Table XI developers are trying to pick a framework that they don't use everyday ideally in a language that they use every day and build a common app in it just to try out some new muscles and get a sense of what the strengths and weaknesses of some of these other tools are. We're starting to bring them in slowly to our server and client side repertoires where they're appropriate. I think that Rails is great but it's not perfect which leads the possibility that there will be something better eventually. I think it will take a while for something like Phoenix and Elixir to build up the ecosystem and the number of 3rd party tools that the Rails community has. CHARLES: We've been playing around with a bunch of different tools here. I actually started a side project and I was using Rails and I was blown away. I was like, "Oh, I forgot how easy it actually was." And that actually can't be discounted and things like speed and things like this lightweight feeling, you can [inaudible] for the lack of an ecosystem. I certainly made that mistake with Node.js. NPM installs at the very beginning were super fast and that was the reason that you weren't installing anything at all. [Laughs] NOEL: Rails still prioritizes a certain kind of developer experience in a way that is really great for projects up to a certain size. I think there's a significant dispute of where that certain size is. I have a coworker who did a Rails project recently after also having done a bunch of JavaScript projects and had a very similar reaction, "I forgot how easy some of the stuff actually can be." Eventually, you get to a size where some of that easy search could be less [inaudible] in terms of something a little more structured. But there's still a lot of value there. I find the Node ecosystem honestly really complicated and confusing relative to the Ruby ecosystem. And some of that is just my lack of experience with it. CHARLES: We're [inaudible] everyday and it's complicated. It's just that it's huge. It's just mammoth compared to the Ruby ecosystem and I don't think it started out that way, but it certainly is like that today. NOEL: Rails is at least somewhat focused on a particular size problem. And I think that that makes the ecosystem a little bit more manageable. I think the JavaScript tools are trying to solve a lot of different problems for a lot of different people sort of under the same umbrella and it gets very hard to do that. CHARLES: Well, that's about it for our time. Thank you so much for coming and talking with us. NOEL: Thanks for having me. CHARLES: Yeah. The name of the book that you're currently writing is? NOEL: It's 'Take My Money: Accepting Payments on the Web'. It is available at PragProg.com. And then you can find anything I'm doing at NoelRappin.com. Keep an eye out there because there's going to be a new project that hopefully will start by the end of the year. I'm a little less confident that it's going to than I was, but I'm still hoping. Also you can find me on Twitter @noelrap. CHARLES: All right, fantastic. Bye everybody!

chicago google rock miami writing cleveland web cd world series structure dom payments chicago cubs cds computer science python java emphasis stripe javascript rails elixir node pragmatic vue factual ruby on rails dave thomas jquery npm apple ii cold fusion inaudible clojure es6 noel rappin table xi charles lowell charles you rails api

281 RR Take My Money with Noel Rappin

Play Episode Listen Later Oct 12, 2016 41:38

00:30 - Introducing Noel Rappin Take My Money: Accepting Payments on the Web by Noel Rappin (Ebook only) Take My Money: Accepting Payments on the Web by Noel Rappin, (physical copy pre-order link) Website Twitter 1:00 - Paid gateways for apps 6:05 - Why write Take My Money? 8:45 - Getting tripped up on simple arithmetic 11:55 - Troubleshooting gateway system failures Runscope 21:45 - Managing administrative roles Paper Trail 25:55 - Reporting 29:00 - Techniques for testing your system 33:25 - Overarching themes in Take My Money Picks: The Fifth Season and The Obelisk Gate by N.K. Jemisin (Noel) Flash Forward podcast by Rose Eveleth (Noel) Police officers (Charles) Webinar Jam (Charles)

managing police web paid ebooks reporting troubleshooting flash forward paper trails overarching take my money webinarjam noel rappin runscope

281 RR Take My Money with Noel Rappin

Play Episode Listen Later Oct 12, 2016 41:38

00:30 - Introducing Noel Rappin Take My Money: Accepting Payments on the Web by Noel Rappin (Ebook only) Take My Money: Accepting Payments on the Web by Noel Rappin, (physical copy pre-order link) Website Twitter 1:00 - Paid gateways for apps 6:05 - Why write Take My Money? 8:45 - Getting tripped up on simple arithmetic 11:55 - Troubleshooting gateway system failures Runscope 21:45 - Managing administrative roles Paper Trail 25:55 - Reporting 29:00 - Techniques for testing your system 33:25 - Overarching themes in Take My Money Picks: The Fifth Season and The Obelisk Gate by N.K. Jemisin (Noel) Flash Forward podcast by Rose Eveleth (Noel) Police officers (Charles) Webinar Jam (Charles)

managing police web paid ebooks reporting troubleshooting flash forward paper trails overarching take my money webinarjam noel rappin runscope

281 RR Take My Money with Noel Rappin

Play Episode Listen Later Oct 12, 2016 41:38

00:30 - Introducing Noel Rappin Take My Money: Accepting Payments on the Web by Noel Rappin (Ebook only) Take My Money: Accepting Payments on the Web by Noel Rappin, (physical copy pre-order link) Website Twitter 1:00 - Paid gateways for apps 6:05 - Why write Take My Money? 8:45 - Getting tripped up on simple arithmetic 11:55 - Troubleshooting gateway system failures Runscope 21:45 - Managing administrative roles Paper Trail 25:55 - Reporting 29:00 - Techniques for testing your system 33:25 - Overarching themes in Take My Money Picks: The Fifth Season and The Obelisk Gate by N.K. Jemisin (Noel) Flash Forward podcast by Rose Eveleth (Noel) Police officers (Charles) Webinar Jam (Charles)

managing police web paid ebooks reporting troubleshooting flash forward paper trails overarching take my money webinarjam noel rappin runscope

Episode 001: Taking Payments on the Web with Noel Rappin

Greater Than Code

Play Episode Listen Later Sep 28, 2016 50:06

00:18 - Welcome to "Dread Coder Roberts!" ...we mean, "Greater Than Code!" 01:30 - Noel Rappin's Introduction (Spoiler alert! He's got a Ph.D.!) 04:31 - Take My Money: Accepting Payments on the Web (https://pragprog.com/book/nrwebpay/take-my-money) 08:30 - Code Paths and Tracking Failures 10:59 - What is the quickest path to accepting payments online? Are there drawbacks to getting something up fast? (~ David Bock) 13:17 - Testing Payment Issues 14:29 - Design Patterns and Missing Layers Between Controllers and Models 17:49 - Business Logic and Database Constraints (aka, "Why did he write the book?!") 20:14 - I Was A Developer Running HR For A Year: AMA by Noel Rappin at Madison+ Ruby: Epilogue 2016 (https://www.youtube.com/watch?v=nOy1rWdL-HE) 24:02 - Practices, Problems, and Potential Solutions for Human Resources 29:34 - Team Diversity and Inclusion *Listener Call to Action: * Team retrospectives and demonstrating that it is safe to fail. Noel: The impact of our applications and how they work in real-world context. David: How can we help introverts feel comfortable? Quiet: The Power of Introverts in a World That Can't Stop Talking by Susan Cain (https://www.amazon.com/Quiet-Power-Introverts-World-Talking/dp/0307352153) Coraline: Inspiration to look at teams, meetings, and discussions and see if they are leaving room for everyone to participate equally. Jessica: We started out talking about accepting payments on the web and we found something greater than code. Jay: If we want to try to work with the hard stuff, the hardest problems to solve are the things that are greater than code. Sam: Being, as Jay said, "not just allies, but accomplices." This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guest: Noel Rappin.

amazon llc web practices payments introverts slack stop talking susan cain world that can quiet the power design patterns potential solutions action team business logic quiet power introverts world talking noel rappin greater than code devreps

Ep. 14 - On Testing (Noel Rappin)

CodeNewbie

Play Episode Listen Later Dec 13, 2014 50:32

You've probably heard of this idea of testing. Or maybe you've just heard of test driven development and you're not really sure what it is or whether or not you should learn about it. In this episode, Noel Rappin, developer and author of the new book "Rails 4 Test Prescriptions" gives us a newbie-friendly explanation of the world of testing. We talk about different types of tests, we walk through an example of how you can approach something with tests first, and why test driven development can be a great tool for planning and organizing your code, especially as a code newbie. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Test Driven Development By Example Extreme Programming Explained RSpec Selenium Behavior Driven Development Spike Codeland Conf Codeland 2019

testing rails mongodb heroku noel rappin test prescriptions

185 RR Rails 4 Test Prescriptions with Noel Rappin

Play Episode Listen Later Dec 10, 2014 72:53

The Rogues talk about Noel Rappin's book, Rails 4 Test Prescriptions and TDD.

rails rogues tdd noel rappin test prescriptions

185 RR Rails 4 Test Prescriptions with Noel Rappin

Play Episode Listen Later Dec 10, 2014 72:53

The Rogues talk about Noel Rappin's book, Rails 4 Test Prescriptions and TDD.

rails rogues tdd noel rappin test prescriptions

185 RR Rails 4 Test Prescriptions with Noel Rappin

Play Episode Listen Later Dec 10, 2014 72:53

The Rogues talk about Noel Rappin's book, Rails 4 Test Prescriptions and TDD.

rails rogues tdd noel rappin test prescriptions

030 JSJ Learning & Teaching JavaScript with Noel Rappin

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Oct 4, 2012 51:54

Panel Noel Rappin (twitter github blog) Jamison Dance (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Intro to CoffeeScript) AJ O’Neal (twitter github blog) Discussion 00:52 - Works in training and talent development for Groupon 00:56 - Author of Rails Test Prescriptions and upcoming Master Space and Time with JavaScript 01:21 - Writing a book about JavaScript 02:33 - Focus of the book Part 1: Jasmine and jQuery and the JavaScript Object Model Part 2: Extended examples of jQuery Part 3: Backbone Part 4: Ember 03:46 - Self-published authors 05:15 - Approaches and mindsets to learning JavaScript 06:04 - “Gotchas!” and bad features in Javascript 09:17 - Modeling JavaScript for beginners 11:23 - (AJ joins the podcast) 11:42 - Resources/Classes for learning JavaScript Good Parts Book: Douglas Crockford JavaScript Patterns: Stoyan Stefanov Eloquent JavaScript: A Modern Introduction to Programming: Marijn Haverbeke Maintainable JavaScript: Nicholas C. Zakas 13:54 - Hiring people with JavaScript experience at Groupon 15:12 - Training workshops 17:00 - Getting new hires up to speed quickly Pairing Mentoring Lectures Workshops 21:38 - Book Learning You can learn at your own pace But it’s hard to ask questions to a book 22:51 - How Noel gained expertise in JavaScript 24:38 - Code reading and learning to program a language 26:18 - Teaching people JavaScript as their very first language 31:55 - Classroom layout 33:42 - Online training Kahn Academy Computer Science Code Academy Starter League 40:00 - Finding a mentor Stack Overflow Picks Shrines by Purity Ring (Jamison) Learnable Programming: Bret Victor (Jamison) Mob Software: Richard P. Gabriel & Ron Goldman (Jamison) Monoprice.com (AJ) ZREO: Zelda Reorchestrated (AJ) The Official Twitter App (Chuck) Fluid App (Chuck) Try Jasmine! (Noel) Justin Searls (Noel) The Atrocity Archives: Charles Stross (Noel) Futurity: A Musical by The Lisps (Noel) Transcript NOEL: I’m trying to figure out where the chat is in this stupid Skype interface. JAMISON: Just imagine the worst place it could possibly be and that’s where it is. [This episode is sponsored by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to wijmo.com and check them out.] [Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to Episode 30 of the JavaScript Jabber show! This week on our panel we have, Jamison Dance. JAMISON: Hey guys! CHUCK: I’m Charles Max Wood from devchat.tv and this week, we have a special guest and that’s Noel Rappin! NOEL: Hey everybody! CHUCK: For the people who don’t know who you are, you want to introduce yourself, Noel? NOEL: Sure. I currently work in training and talent development for Groupon. And I am the author of previously “Rails Test Prescriptions” and currently a self-published book called “Master Time and Space with JavaScript”, which you can get at noelrappin.com. I need to spell that out, right? N-o-e-l-r-a-p-p-i-n.com CHUCK: So I’m little curious, before we get into the topic which is learning and teaching JavaScript, how did you get into writing a book about JavaScript? What’s your background there? NOEL: You know, it actually relates to teaching and learning JavaScript. I think, I was like… a lot of long time web devs. I spent my first round as a web consultant in around, turn of the century 2000’s. I spent time trying to talk clients out of JavaScript stuff because it was such a pain in the neck. And I kind of got away from it for awhile and came back a couple of years ago to realize that basically, everything had changed and they were actually usable tools now. And last summer, I was working with a… at that time,

time learning space training writing teaching focus code hiring skype classroom hosting approaches ui javascript extended groupon jquery charles max wood javascript jabber noel rappin jamison dance chuck for nicholas c zakas master space wijmo chuck hey

030 JSJ Learning & Teaching JavaScript with Noel Rappin

JavaScript Jabber

Play Episode Listen Later Oct 4, 2012 51:54

Panel Noel Rappin (twitter github blog) Jamison Dance (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Intro to CoffeeScript) AJ O’Neal (twitter github blog) Discussion 00:52 - Works in training and talent development for Groupon 00:56 - Author of Rails Test Prescriptions and upcoming Master Space and Time with JavaScript 01:21 - Writing a book about JavaScript 02:33 - Focus of the book Part 1: Jasmine and jQuery and the JavaScript Object Model Part 2: Extended examples of jQuery Part 3: Backbone Part 4: Ember 03:46 - Self-published authors 05:15 - Approaches and mindsets to learning JavaScript 06:04 - “Gotchas!” and bad features in Javascript 09:17 - Modeling JavaScript for beginners 11:23 - (AJ joins the podcast) 11:42 - Resources/Classes for learning JavaScript Good Parts Book: Douglas Crockford JavaScript Patterns: Stoyan Stefanov Eloquent JavaScript: A Modern Introduction to Programming: Marijn Haverbeke Maintainable JavaScript: Nicholas C. Zakas 13:54 - Hiring people with JavaScript experience at Groupon 15:12 - Training workshops 17:00 - Getting new hires up to speed quickly Pairing Mentoring Lectures Workshops 21:38 - Book Learning You can learn at your own pace But it’s hard to ask questions to a book 22:51 - How Noel gained expertise in JavaScript 24:38 - Code reading and learning to program a language 26:18 - Teaching people JavaScript as their very first language 31:55 - Classroom layout 33:42 - Online training Kahn Academy Computer Science Code Academy Starter League 40:00 - Finding a mentor Stack Overflow Picks Shrines by Purity Ring (Jamison) Learnable Programming: Bret Victor (Jamison) Mob Software: Richard P. Gabriel & Ron Goldman (Jamison) Monoprice.com (AJ) ZREO: Zelda Reorchestrated (AJ) The Official Twitter App (Chuck) Fluid App (Chuck) Try Jasmine! (Noel) Justin Searls (Noel) The Atrocity Archives: Charles Stross (Noel) Futurity: A Musical by The Lisps (Noel) Transcript NOEL: I’m trying to figure out where the chat is in this stupid Skype interface. JAMISON: Just imagine the worst place it could possibly be and that’s where it is. [This episode is sponsored by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to wijmo.com and check them out.] [Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to Episode 30 of the JavaScript Jabber show! This week on our panel we have, Jamison Dance. JAMISON: Hey guys! CHUCK: I’m Charles Max Wood from devchat.tv and this week, we have a special guest and that’s Noel Rappin! NOEL: Hey everybody! CHUCK: For the people who don’t know who you are, you want to introduce yourself, Noel? NOEL: Sure. I currently work in training and talent development for Groupon. And I am the author of previously “Rails Test Prescriptions” and currently a self-published book called “Master Time and Space with JavaScript”, which you can get at noelrappin.com. I need to spell that out, right? N-o-e-l-r-a-p-p-i-n.com CHUCK: So I’m little curious, before we get into the topic which is learning and teaching JavaScript, how did you get into writing a book about JavaScript? What’s your background there? NOEL: You know, it actually relates to teaching and learning JavaScript. I think, I was like… a lot of long time web devs. I spent my first round as a web consultant in around, turn of the century 2000’s. I spent time trying to talk clients out of JavaScript stuff because it was such a pain in the neck. And I kind of got away from it for awhile and came back a couple of years ago to realize that basically, everything had changed and they were actually usable tools now. And last summer, I was working with a… at that time,

time learning space training writing teaching focus code hiring skype classroom hosting approaches ui javascript extended groupon jquery charles max wood javascript jabber noel rappin jamison dance chuck for nicholas c zakas master space wijmo chuck hey

030 JSJ Learning & Teaching JavaScript with Noel Rappin

Play Episode Listen Later Oct 4, 2012 51:54

Panel Noel Rappin (twitter github blog) Jamison Dance (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Intro to CoffeeScript) AJ O’Neal (twitter github blog) Discussion 00:52 - Works in training and talent development for Groupon 00:56 - Author of Rails Test Prescriptions and upcoming Master Space and Time with JavaScript 01:21 - Writing a book about JavaScript 02:33 - Focus of the book Part 1: Jasmine and jQuery and the JavaScript Object Model Part 2: Extended examples of jQuery Part 3: Backbone Part 4: Ember 03:46 - Self-published authors 05:15 - Approaches and mindsets to learning JavaScript 06:04 - “Gotchas!” and bad features in Javascript 09:17 - Modeling JavaScript for beginners 11:23 - (AJ joins the podcast) 11:42 - Resources/Classes for learning JavaScript Good Parts Book: Douglas Crockford JavaScript Patterns: Stoyan Stefanov Eloquent JavaScript: A Modern Introduction to Programming: Marijn Haverbeke Maintainable JavaScript: Nicholas C. Zakas 13:54 - Hiring people with JavaScript experience at Groupon 15:12 - Training workshops 17:00 - Getting new hires up to speed quickly Pairing Mentoring Lectures Workshops 21:38 - Book Learning You can learn at your own pace But it’s hard to ask questions to a book 22:51 - How Noel gained expertise in JavaScript 24:38 - Code reading and learning to program a language 26:18 - Teaching people JavaScript as their very first language 31:55 - Classroom layout 33:42 - Online training Kahn Academy Computer Science Code Academy Starter League 40:00 - Finding a mentor Stack Overflow Picks Shrines by Purity Ring (Jamison) Learnable Programming: Bret Victor (Jamison) Mob Software: Richard P. Gabriel & Ron Goldman (Jamison) Monoprice.com (AJ) ZREO: Zelda Reorchestrated (AJ) The Official Twitter App (Chuck) Fluid App (Chuck) Try Jasmine! (Noel) Justin Searls (Noel) The Atrocity Archives: Charles Stross (Noel) Futurity: A Musical by The Lisps (Noel) Transcript NOEL: I’m trying to figure out where the chat is in this stupid Skype interface. JAMISON: Just imagine the worst place it could possibly be and that’s where it is. [This episode is sponsored by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to wijmo.com and check them out.] [Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to Episode 30 of the JavaScript Jabber show! This week on our panel we have, Jamison Dance. JAMISON: Hey guys! CHUCK: I’m Charles Max Wood from devchat.tv and this week, we have a special guest and that’s Noel Rappin! NOEL: Hey everybody! CHUCK: For the people who don’t know who you are, you want to introduce yourself, Noel? NOEL: Sure. I currently work in training and talent development for Groupon. And I am the author of previously “Rails Test Prescriptions” and currently a self-published book called “Master Time and Space with JavaScript”, which you can get at noelrappin.com. I need to spell that out, right? N-o-e-l-r-a-p-p-i-n.com CHUCK: So I’m little curious, before we get into the topic which is learning and teaching JavaScript, how did you get into writing a book about JavaScript? What’s your background there? NOEL: You know, it actually relates to teaching and learning JavaScript. I think, I was like… a lot of long time web devs. I spent my first round as a web consultant in around, turn of the century 2000’s. I spent time trying to talk clients out of JavaScript stuff because it was such a pain in the neck. And I kind of got away from it for awhile and came back a couple of years ago to realize that basically, everything had changed and they were actually usable tools now. And last summer, I was working with a… at that time,

time learning space training writing teaching focus code hiring skype classroom hosting approaches ui javascript extended groupon jquery charles max wood javascript jabber noel rappin jamison dance chuck for nicholas c zakas master space wijmo chuck hey

030 RR Software Craftsmanship with Noel Rappin

Play Episode Listen Later Nov 24, 2011 65:00

The Rogues talk to Noel Rappin about software craftsmanship.

rogues software craftsmanship noel rappin

030 RR Software Craftsmanship with Noel Rappin

Play Episode Listen Later Nov 24, 2011 65:00

The Rogues talk to Noel Rappin about software craftsmanship.

rogues software craftsmanship noel rappin

030 RR Software Craftsmanship with Noel Rappin