Podcasts about pragmatic studio

Neste episódio entrevistamos Leandro Pereira, engenheiro de software sênior na DockYard.  Perfil do Leandro no Linkedin: https://www.linkedin.com/in/leandrocesquini/  DockYard: https://dockyard.com/  Leandro  aborda o uso da linguagem Elixir na DockYard, destacando o projeto Beacon CMS. Leandro compartilha detalhes sobre sua palestra na ElixirConf 2023, "Beacon, a próxima geração de CMS no Phoenix LiveView," e discute outros projetos. Ele destaca o foco da DockYard em Elixir e projetos de pesquisa, como a DockYard Academy e o LiveView Native. Leandro também explora sua carreira, experiências anteriores e sua mudança para o Canadá. Leandro explica o papel da DockYard como consultoria e como o Elixir se encaixa em suas atividades. Ele compartilha seu papel na empresa, liderando o desenvolvimento do Beacon CMS e contribuindo para outros projetos open source. Ele discute a integração de Rust em alguns projetos e suas contribuições para bibliotecas como MDEX. Leandro fala sobre o Beacon CMS, revelando que ainda está em desenvolvimento e não atingiu a versão estável 0.1. Leandro detalha o funcionamento do Beacon, enfatizando a eficiência do LiveView e como o Beacon simplifica a gestão de conteúdo, especialmente para usuários não técnicos. A discussão se estende para conceitos como CMS (Sistema de Gerenciamento de Conteúdo) e LiveView, esclarecendo suas definições e aplicações. Leandro destaca o objetivo do Beacon de oferecer uma solução eficiente para a criação e edição de conteúdo web, eliminando a necessidade de desenvolvimento técnico tradicional. Leandro conta a história do site liveviewdemos.com e compartilha que a inspiração veio das demos que surgiram quando o LiveView foi anunciado. Ele começou a salvar demos interessantes e decidiu criar um site para compartilhar essas criações. Hoje, é um hobby que mantém, destacando a diversidade de projetos LiveView apresentados. Leandro faz recomendações para quem deseja aprender Elixir e LiveView. Ele sugere o livro "Elixir in Action" e cursos, como os do Pragmatic Studio, para LiveView. Ele também recomenda o livro "How to Open Source" para quem deseja se envolver em projetos de código aberto. Links adicionais: BeaconCMS https://github.com/BeaconCMS/beacon MDEx - https://github.com/leandrocp/mdex HEEx formater - https://github.com/feliperenan/heex_formatter Mike Binns - https://github.com/TheFirstAvenger Elixir in Action - https://www.manning.com/books/elixir-in-action-third-edition Curso Build an AI Powered Instagram Clone with LiveView https://johnelmlabs.com/courses Livro Programming Phoenix LiveView https://pragprog.com/titles/liveview/programming-phoenix-liveview/ Curso Phoenix LiveView  https://pragmaticstudio.com/phoenix-liveview Livro Building Table Views with Phoenix LiveView https://pragprog.com/titles/puphoe/building-table-views-with-phoenix-liveview/ Curso Build an MVP with Elixir - https://pjullrich.gumroad.com/l/bmvp Buildit with Phoenix - https://builditwithphoenix.com/ Elixir for Programmers, Second Edition https://codestool.coding-gnome.com/courses/elixir-for-programmers-2 Leandro Bighetti - How to teach Elixir to non-functional developers - Code BEAM Lite Berlin 18 https://www.youtube.com/watch?v=llQmhYHzEQo Livro How to Open Source https://howtoopensource.dev/ ElixirConf 2023 - Leandro Pereira - Beacon: The next generation of CMS in Phoenix LiveView https://youtu.be/5jk0fIJOFuc  Thinking Elixir - Episode 174 - DockYard's BeaconCMS https://podcast.thinkingelixir.com/174  Contribuindo com Elixir e o ecossistema, Leandro Pereira, Vídeo https://codebeambr-homol.vercel.app/video/11  Assista a esta entrevista no YouTube em https://youtu.be/W_UufwMdK3A. Nosso canal é https://www.youtube.com/@ElixirEmFoco Associe-se à Erlang Ecosystem Foundation em⁠ https://bit.ly/3Sl8XTO. O site da fundação é⁠ https://bit.ly/3Jma95g. Nosso site é https://elixiremfoco.com.  Estamos no Twitter em @elixiremfoco https://twitter.com/elixiremfoco.  Nosso email é elixiremfoco@gmail.com. --- Send in a voice message: https://podcasters.spotify.com/pod/show/elixiremfoco/message

In this Episode we talk with Chase Granberry of Supabase discussing the role of Elixir and other languages at the company. Upcoming developments and potential directions that the company may take. Sponsors Top End Devs (https://topenddevs.com/) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Demo Site (https://multiplayer.dev/) GitHub: Supabase / realtime-js (https://github.com/supabase/realtime-js) stressgrid.com (https://stressgrid.com/blog/100k_cps_with_elixir/) Logflare (https://logflare.app/) Supabase (https://supabase.com/) Picks Allen - Phoenix LiveView on The Pragmatic Studio (https://pragmaticstudio.com/phoenix-liveview) Chase - Stressgrid Blog (https://stressgrid.com/blog/) Chase - ElixirConf 2021 Mark Ericksen - Globally Distributed Elixir Apps on Fly.io (https://www.youtube.com/watch?v=IqnZnFpxLjI) Special Guest: Chase Granberry.

Sascha Wolf joins the mix to talk about how to test behaviors in your Phoenix apps by using tools like Mox and Knigge. Panel Adi Iyenger Allen Wyma Charles Max Wood Eric Bolikowski Guest Sascha Wolf Sponsors Dev Influencers Accelerator Links Twitter: Sascha Wolf ( @wolf4earth ) Picks Adi- Testing Elixir by Andrea Leopardi and Jeffrey Matthias Adi- GitHub | gleam-lang/gleam Allen- The Pragmatic Studio Charles- Flying High with Flutter Charles- Premium | Devchat.tv Charles- Ruby Rogues | Devchat.tv Charles- Back Market Eric- Grokking Simplicity by Eric Normand Sascha- Humans vs Computers

Sascha Wolf joins the mix to talk about how to test behaviors in your Phoenix apps by using tools like Mox and Knigge. Panel Adi Iyenger Allen Wyma Charles Max Wood Eric Bolikowski Guest Sascha Wolf Sponsors Dev Influencers Accelerator Links Twitter: Sascha Wolf ( @wolf4earth ) Picks Adi- Testing Elixir by Andrea Leopardi and Jeffrey Matthias Adi- GitHub | gleam-lang/gleam Allen- The Pragmatic Studio Charles- Flying High with Flutter Charles- Premium | Devchat.tv Charles- Ruby Rogues | Devchat.tv Charles- Back Market Eric- Grokking Simplicity by Eric Normand Sascha- Humans vs Computers

My guest today is Mastering Engineering Joe Caithness. Joe has worked on mastering the soundtrack music for games such as Borderlands, and Doom, the soundtracks for the Netflix movie Close, bands such as Don Martin 3 and Palooka 5 and he does it all from the comfort of his mastering studio located in his backyard in Nottingham, England.  In this episode, we discuss: Shakespeare Early PC Recording Clutter Being An Audio Introvert Forums GateKeeper Mentality Online Mentors Gear Poverty Inverse Financial Curves Pragmatic Studio Building Transfer Equipment Test Pressings Mastering QC Process Meta Data Professionalism Office Hours Back Issues Being Debt Free Matt's Rant: Patience Links and Show Notes Joe’s site: joecaithnessmastering.com WCA on Instagram: @working_class_audio Go Ad-Free! https://glow.fm/workingclassaudio/ Connect with Matt on Linkedin: https://www.linkedin.com/in/mattboudreau/ Current sponsors & promos: https://bit.ly/2WmKbFw Working Class Audio Journal: https://amzn.to/2GN67TP Credits: Guest: Joe Caithness Host: Matt Boudreau  WCA Theme Music: Cliff Truesdell  Announcer: Chuck Smith Editing: Anne-Marie Pleau & Matt Boudreau Additional Music: The License Lab

The culture of your programming community directly impacts your professional success. As Thunderbolt Labs Founder Randall Thomas explains in this episode, a community that practices openness and which warmly welcomes its newer members leads to greater career happiness. We open our chat with Randall by exploring his start in coding and how he discovered Elixir. He shares some of the teething problems that he had moving from Ruby to Elixir before we touch on how learning other languages expands your ability to both appreciate and code in languages that you’re already fluent in. Following this, Randall explodes the myth of the genius polyglot programmer by sharing his take on why all coders are polyglots. As the Thunderbolt CEO, we ask Randall how his company adopted Elixir. He provides listeners with insights into how they introduced Elixir into their practice without affecting existing projects. After highlighting the efficiency of Elixir and how community affects the feel of a language, we compare the culture and challenges of Ruby, JavaScript, and Elixir. Near the end of the episode, Randall reflects on why experts make for poor teachers. For Randall, Elixir gives his company a competitive advantage. Tune in to hear Randall’s perspective on why community matters and for his top advice on teaching your team Elixir. Key Points From This Episode: Introducing Thunderbolt Labs Founder and CEO, Randall Thomas. Randall shares how he discovered coding and engineering. Hear how Randall first heard about Elixir and how he picked up the language. Exploring common challenges moving from Ruby to Elixir. How learning new languages can deepen your understanding of languages that you already know. Why there’s no such thing as the ‘genius polyglot programmer.’ Details on why Randall’s company began gravitating towards Elixir. How communities affect the ‘feel’ of a language. Why no one actually writes in JavaScript anymore. Randall gives his take on why Elixir is a god-send for certain programmers. Insights into how Randall integrated Elixir into his company. The challenge of learning Elixir versus the ease of learning JavaScript. How Randall sold his clients on Elixir and the benefits of having clients that trust you. Randall’s top tips on helping your developers learn Elixir. Why Elixir gives Randall’s a strategic advantage. The importance of having non-experts explain things to you. How your coding community can impact your happiness and career success. Links Mentioned in Today’s Episode: SmartLogic — https://smartlogic.io/ Randall Thomas on LinkedIn — https://www.linkedin.com/in/randall-j-thomas/ Randall Thomas on Twitter — https://twitter.com/daksis Thunderbolt Labs — https://www.thunderboltlabs.com/ Episode with Miki Rezentes — https://smartlogic.io/podcast/elixir-wizards/s4e16-rezentes/ Gödel, Escher, Bach on Amazon — https://www.amazon.com/B6del-Escher-Bach-Eternal-Golden/dp/0465026567 Stephen Hawking — https://www.biography.com/scientist/stephen-hawking William James — https://plato.stanford.edu/entries/james/ Bertrand Russell — https://plato.stanford.edu/entries/russell/ Barcelona Ruby Conference — https://twitter.com/baruco José Valim — https://twitter.com/josevalim Programming Elixir on Amazon — https://www.amazon.com/Programming-Elixir-1-6-Functional-Concurrent/dp/1680502999 Dave Thomas — https://pragdave.me/ ElixirConf — https://2020.elixirconf.com/ ‘(UN)Learning Elixir’ — https://www.youtube.com/watch?v=o54EurlzK8o Bruce Tate — https://www.linkedin.com/in/bruce-tate-a836b/ Grox.io — https://grox.io/ Eric S. Raymond — http://www.catb.org/~esr/ Stack Overflow — https://stackoverflow.com/ Medium — https://medium.com/ Engine Yard — https://www.engineyard.com/ Douglas Crockford — https://www.crockford.com/about.html Yehuda Katz — https://www.linkedin.com/in/yehudakatz/ Blake Mizerany — https://www.linkedin.com/in/bmizerany/ The Pragmatic Studio — https://pragmaticstudio.com/ Stuff Goes Bad: Erlang in Anger on Amazon — https://www.erlang-in-anger.com/ Frederic Trottier-Hebert — https://www.linkedin.com/in/fredth/ Stu Holloway — https://www.linkedin.com/in/stu-holloway-linvio/ Paul Graham — http://www.paulgraham.com/ Hackers and Painters on Amazon — https://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/dp/1449389554 Lonestar Elixir — https://lonestarelixir.com/ Turing.io — https://turing.io/ Sundi Myint on Twitter — https://twitter.com/sundikhin Justus Eapen on Twitter— https://twitter.com/JustusEapen Eric Oestrich on Twitter — https://twitter.com/ericoestrich Special Guests: Randall Thomas and Sundi Myint.

Panel: Mark Ericksen Eric Berry Josh Adams Nathan Hopkins Special Guest: Andrew Dryga In this episode of Elixir Mix, the panel talks with Andrew Dryga who is a software engineer (full-stack), entrepreneur, blockchain architect, and consultant. He currently works for Hammer and previous employers include Contractbook, Nebo #15, BEST Money Transfers among others. He studied at the National Technical University of Ukraine. Check out today’s episode where the panel and guest talk about Sagas and Sage. Show Topics: 1:52 – Our guest today is Andrew Dryga. Why are you into Elixir? 2:04 – Andrew: I have worked in Elixir for a few years. I worked on one of the biggest opensource projects for a while now. 2:42 – Let’s talk about Sage! 2:49 – Andrew: I felt like I was doing the same thing over, and over again. Andrew talks about how he was on a mission to solve a problem that he was having. 3:48 – Panelist: I have run into this problem before, and I am looking forward We have distribution systems and anything that is external for us (Stripe), and one of the solutions was to create a multi. Let’s create a user, register theses different pieces, and then... Then we realized that this request was taking too long. Our transaction is timing out. The other connection went to the other server. We had database records removed from the other side. People aren’t aware that they have these distribution problems. I think Stripe is a good example of that. I started with my multi... 5:24 – Andrew: I am trying to be very programmatic. I don’t want to do that, so write now the project is multi. It’s doable if you know what you are doing. If you are dealing with just one it’s simple. But if you can monitor them (Sage Read Me)... 56:16 – Let’s talk about Sagas! 6:19 – Andrew talks about what Sagas are. 8:20 – You are right it is a new mental model. That’s why I love the Sage library because it is simple. It gives structure to that mental model. The idea that I will take step one and create a user, step two another entry, step three now an external entry. It can fail for any reason. Then these compensating functions are saying: what is the undo for this? It could be just delete this specific entry. But do I have that right? 9:53 – Andrew gives his comments on those comments. 10:26 – Andrew continues his ideas. 11:09 – When you start with a new team, you don’t bring Sage right off the back? What is your strategy to figure out that pain? 11:32 – Andrew: I don’t have a plan – how do I feel about THAT coder. After about 2 services and 1 call it’s time to use Sage or it will be too complex. Integration is the case. So if you try to integrate substitution then... 12:29 – Question to Andrew. 12:35 – Andrew: Figure it out by judgment and it varies by situation. I enjoy working with them but I’m not like them. I use my best judgment. 12:59 – You talked at Code Beam and talked about Sagas and Sage. I think that’s a good resource to defend you case. To talk about the sequence of events, something goes wrong, and then rollback the changes. What feedback have you received? 13:46 – Andrew: Yes, good feedback. There some people will say that there are problems, but I know there are companies that are actively using it. People say that it simplifies their projects. I think the presentation slides can definitely help. 14:39 – Yes, check out the show notes links. 14:45 – Are you a consultant or are you fulltime? 14:53 – Andrew: I used to be fulltime and do large projects for companies. Andrew talks about those projects in detail. Andrew: Those projects we used Elixir (see above). I do a lot of opensource, too. Last time I check it was... 16:04 – That’s a good number. 16:08 – Andrew: I am trying to participate in conversations, but if I had more times I would work more in Sage and opensource; to have a persistent nature behind Sage. I think it can be done a much better way. 16:55 – How do you envision doing that? Configuring it to a repo or something else? 17:07 – Andrew: I want to solve the problem of... 17:56 – That’s cool. 18:03 – Andrew: Yeah, everything I find a new application built in. 18:17 – Andrew and panelist go back-and-forth. 18:32 – Andrew continues talking about Sage and models. 18:43 – Proxy channel – I think I want to do a Mud. Anyway... 18:59 – Question. 19:11 – There is a WX library that is built into Erlang which was talked about at the conference. That one looked interesting. How they built the debugger and the widgets. It looked that there was more there than I thought. 19:47 – Great to have out of the box. 19:56 – Andrew comments. Andrew: I saw the talk from Canada and... 20:08 – It’s early to work with. Someone tweeted about it and now I’m rambling.    20:08 – Andrew: Someone made the keyboard while on the plane. 21:04 – I hope we are going that route eventually. 21:12 – Panel and Andrew go back-and-forth. 21:39 – What other applications have you found that Saga would work for? 21:50 – Stripe. 21:56 – Panelist: When I make an authorization request, capture the funds. Even when I am dealing with one of their services there are multi-interactions. 22:03 – Andrew comments. 23:32 – I have an app that I would prefer using Saga because of the... 23:44 – Loot Crate! Check out their deal! 24:37 – Andrew talks about the core team, Elixir and Sage. 26:03 – Panelist: To solve a problem with SAGA let’s talk about the pros and cons. I had an umbrella application and one of the applications was supposed to be the interface to that service. It could be like a payment service and other payment gateways. I am going to make my request to this app, and it’s going to track the app. The main thing continues and talks to the bank and/or Stripe. Depending on the problems but you still have THAT problem because maybe the account wasn’t set up properly. Now we’ve talked to the bank, medium intervention, and let’s run this. I like SAGE and SAGAS because I don’t’ have to go to that level to break out the proxies. I just need to talk with the sales force or something. I need a reliable system when it can recover when something goes wrong. It might be over engineered but I don’t know. 28:17 – Andrew comments about that particular example (see above). 29:03 – With Sagas you can loose them... 29:09 – I haven’t played with Rabbit, yet. The one that is built into AWS? There’s Simple Q and there is something else. Rabbit is built with Erlang. What’s that like for you? 29:40 – Andrew: It’s pretty painful. Andrew mentions MPP. 30:37 – Interesting; I haven’t gotten that far, yet. 30:45 – My first Elixir application had...behind it. That was the worst part. I feel those pains. 31:00 – Andrew: That’s the case. 31:51 – The other service I was thinking of was... 31:56 – Question for Andrew. 31:59 – Andrew answers. 32:39 – That is the problem we are having at work because of older code. How can we resend them out? That probably will be a good fit for us. 33:18 – Andrew.  34:31 – Andrew: Once you’ve found the bug... 35:16 – When you are coming to a new language, it could be React or...the first few things will be pretty awful. What has this path been like for you, Nathan? 35:40 – Nathan: Yeah I am very early days. Yesterday, I had a set of code that I was creating to try just to function and it was really ugly. But I was okay with that because I was just trying to solve the issue. 36:05 – You have to be okay with that. The idea that: You are trying to just make it work. When you come to Elixir and being fresh and thinking I don’t even know what to do. 36:32 – I have a buddy with that now saying: How do I even start with this?! 36:40 – Andrew: It takes time to break your head and a different way to rethink the code. Once I have the basic concepts then it makes me feel super efficient. 37:24 – I am curious what languages have you had experience with? 37:38 – Andrew: I started commercial projects in my teenage years. I built websites for them. I have some JavaScript knowledge and that was good going to Elixir. 39:04 – I favor that side, too. It’s not hard to build solutions with the things that are in the box (Erlang). I don’t like to bring in all of these libraries that people are creating. It’s great but, at the same time, I have been burned by Rails and JavaScript where you bring in all of these different libraries, and it becomes really nasty. I could have solved it more natively. 39:55 – Andrew: In Elixir you can... 40:28 – Oh, that’s all I needed – those 2 lines. 40:40 – Andrew. 40:46 – That’s an interesting dynamic. 41:09 – Andrew comments talks about Elixir and Hex. 41:23 – Andrew: I think it’s a good thing. I think there needs to be work in Hex because it’s underdeveloped. To name a few... 43:08 – Part of the keynote this year that it won’t be merged, or they aren’t promising to merge it. 43:29 – Andrew. 44:08 – I haven’t used 3, yet. 44:10 – Andrew. 44:55 – They are talking about the Read Me. I didn’t know there was an Ecto Mnesia? 45:20 – Andrew: Yeah I helped build it and the plan was... 45:50 – Yeah I can see the issue there, do I maintain it or...? 46:02 – Andrew comments and talks about the community and different codes. 46:36 – Andrew, anything else that you want to talk about? 46:48 – There are tons of notes in our chat, which the listeners can’t see. 46:58 – Advertisement – Fresh Books’ Advertisement! 30-Day Trial! Links: Ruby Elixir JavaScript React Erlang – Disk Log Erlang WX Railway Oriented Programming Nebo 15 GitHub – Scenic Kafka Rabbit MQ AWS AWS – Kinesis GitHub – Firenest XHTTP GitHub – Ecto GitHub – Ecto Mnesia Saga and Medium Introducing Sage Andrew Dryga’s Website Andrew Dryga’s Medium Andrew Dryga’s GitHub Andrew Dryga’s LinkedIn Andrew Dryga’s Twitter Andrew Dryga’s FB Andrew’s YouTube Channel Andrew’s Sagas of Elixir Video Sponsors: Loot Crate Fresh Books Cache Fly Picks: Mark Mark of the Ninja Josh A Sneak Peek at Ecto 3.0: Breaking Changes Nate Pragmatic Studio Eric Looking of Elixir Developers Metabase.com Polymail Andrew Tide of History

Panel: Mark Ericksen Eric Berry Josh Adams Nathan Hopkins Special Guest: Andrew Dryga In this episode of Elixir Mix, the panel talks with Andrew Dryga who is a software engineer (full-stack), entrepreneur, blockchain architect, and consultant. He currently works for Hammer and previous employers include Contractbook, Nebo #15, BEST Money Transfers among others. He studied at the National Technical University of Ukraine. Check out today’s episode where the panel and guest talk about Sagas and Sage. Show Topics: 1:52 – Our guest today is Andrew Dryga. Why are you into Elixir? 2:04 – Andrew: I have worked in Elixir for a few years. I worked on one of the biggest opensource projects for a while now. 2:42 – Let’s talk about Sage! 2:49 – Andrew: I felt like I was doing the same thing over, and over again. Andrew talks about how he was on a mission to solve a problem that he was having. 3:48 – Panelist: I have run into this problem before, and I am looking forward We have distribution systems and anything that is external for us (Stripe), and one of the solutions was to create a multi. Let’s create a user, register theses different pieces, and then... Then we realized that this request was taking too long. Our transaction is timing out. The other connection went to the other server. We had database records removed from the other side. People aren’t aware that they have these distribution problems. I think Stripe is a good example of that. I started with my multi... 5:24 – Andrew: I am trying to be very programmatic. I don’t want to do that, so write now the project is multi. It’s doable if you know what you are doing. If you are dealing with just one it’s simple. But if you can monitor them (Sage Read Me)... 56:16 – Let’s talk about Sagas! 6:19 – Andrew talks about what Sagas are. 8:20 – You are right it is a new mental model. That’s why I love the Sage library because it is simple. It gives structure to that mental model. The idea that I will take step one and create a user, step two another entry, step three now an external entry. It can fail for any reason. Then these compensating functions are saying: what is the undo for this? It could be just delete this specific entry. But do I have that right? 9:53 – Andrew gives his comments on those comments. 10:26 – Andrew continues his ideas. 11:09 – When you start with a new team, you don’t bring Sage right off the back? What is your strategy to figure out that pain? 11:32 – Andrew: I don’t have a plan – how do I feel about THAT coder. After about 2 services and 1 call it’s time to use Sage or it will be too complex. Integration is the case. So if you try to integrate substitution then... 12:29 – Question to Andrew. 12:35 – Andrew: Figure it out by judgment and it varies by situation. I enjoy working with them but I’m not like them. I use my best judgment. 12:59 – You talked at Code Beam and talked about Sagas and Sage. I think that’s a good resource to defend you case. To talk about the sequence of events, something goes wrong, and then rollback the changes. What feedback have you received? 13:46 – Andrew: Yes, good feedback. There some people will say that there are problems, but I know there are companies that are actively using it. People say that it simplifies their projects. I think the presentation slides can definitely help. 14:39 – Yes, check out the show notes links. 14:45 – Are you a consultant or are you fulltime? 14:53 – Andrew: I used to be fulltime and do large projects for companies. Andrew talks about those projects in detail. Andrew: Those projects we used Elixir (see above). I do a lot of opensource, too. Last time I check it was... 16:04 – That’s a good number. 16:08 – Andrew: I am trying to participate in conversations, but if I had more times I would work more in Sage and opensource; to have a persistent nature behind Sage. I think it can be done a much better way. 16:55 – How do you envision doing that? Configuring it to a repo or something else? 17:07 – Andrew: I want to solve the problem of... 17:56 – That’s cool. 18:03 – Andrew: Yeah, everything I find a new application built in. 18:17 – Andrew and panelist go back-and-forth. 18:32 – Andrew continues talking about Sage and models. 18:43 – Proxy channel – I think I want to do a Mud. Anyway... 18:59 – Question. 19:11 – There is a WX library that is built into Erlang which was talked about at the conference. That one looked interesting. How they built the debugger and the widgets. It looked that there was more there than I thought. 19:47 – Great to have out of the box. 19:56 – Andrew comments. Andrew: I saw the talk from Canada and... 20:08 – It’s early to work with. Someone tweeted about it and now I’m rambling.    20:08 – Andrew: Someone made the keyboard while on the plane. 21:04 – I hope we are going that route eventually. 21:12 – Panel and Andrew go back-and-forth. 21:39 – What other applications have you found that Saga would work for? 21:50 – Stripe. 21:56 – Panelist: When I make an authorization request, capture the funds. Even when I am dealing with one of their services there are multi-interactions. 22:03 – Andrew comments. 23:32 – I have an app that I would prefer using Saga because of the... 23:44 – Loot Crate! Check out their deal! 24:37 – Andrew talks about the core team, Elixir and Sage. 26:03 – Panelist: To solve a problem with SAGA let’s talk about the pros and cons. I had an umbrella application and one of the applications was supposed to be the interface to that service. It could be like a payment service and other payment gateways. I am going to make my request to this app, and it’s going to track the app. The main thing continues and talks to the bank and/or Stripe. Depending on the problems but you still have THAT problem because maybe the account wasn’t set up properly. Now we’ve talked to the bank, medium intervention, and let’s run this. I like SAGE and SAGAS because I don’t’ have to go to that level to break out the proxies. I just need to talk with the sales force or something. I need a reliable system when it can recover when something goes wrong. It might be over engineered but I don’t know. 28:17 – Andrew comments about that particular example (see above). 29:03 – With Sagas you can loose them... 29:09 – I haven’t played with Rabbit, yet. The one that is built into AWS? There’s Simple Q and there is something else. Rabbit is built with Erlang. What’s that like for you? 29:40 – Andrew: It’s pretty painful. Andrew mentions MPP. 30:37 – Interesting; I haven’t gotten that far, yet. 30:45 – My first Elixir application had...behind it. That was the worst part. I feel those pains. 31:00 – Andrew: That’s the case. 31:51 – The other service I was thinking of was... 31:56 – Question for Andrew. 31:59 – Andrew answers. 32:39 – That is the problem we are having at work because of older code. How can we resend them out? That probably will be a good fit for us. 33:18 – Andrew.  34:31 – Andrew: Once you’ve found the bug... 35:16 – When you are coming to a new language, it could be React or...the first few things will be pretty awful. What has this path been like for you, Nathan? 35:40 – Nathan: Yeah I am very early days. Yesterday, I had a set of code that I was creating to try just to function and it was really ugly. But I was okay with that because I was just trying to solve the issue. 36:05 – You have to be okay with that. The idea that: You are trying to just make it work. When you come to Elixir and being fresh and thinking I don’t even know what to do. 36:32 – I have a buddy with that now saying: How do I even start with this?! 36:40 – Andrew: It takes time to break your head and a different way to rethink the code. Once I have the basic concepts then it makes me feel super efficient. 37:24 – I am curious what languages have you had experience with? 37:38 – Andrew: I started commercial projects in my teenage years. I built websites for them. I have some JavaScript knowledge and that was good going to Elixir. 39:04 – I favor that side, too. It’s not hard to build solutions with the things that are in the box (Erlang). I don’t like to bring in all of these libraries that people are creating. It’s great but, at the same time, I have been burned by Rails and JavaScript where you bring in all of these different libraries, and it becomes really nasty. I could have solved it more natively. 39:55 – Andrew: In Elixir you can... 40:28 – Oh, that’s all I needed – those 2 lines. 40:40 – Andrew. 40:46 – That’s an interesting dynamic. 41:09 – Andrew comments talks about Elixir and Hex. 41:23 – Andrew: I think it’s a good thing. I think there needs to be work in Hex because it’s underdeveloped. To name a few... 43:08 – Part of the keynote this year that it won’t be merged, or they aren’t promising to merge it. 43:29 – Andrew. 44:08 – I haven’t used 3, yet. 44:10 – Andrew. 44:55 – They are talking about the Read Me. I didn’t know there was an Ecto Mnesia? 45:20 – Andrew: Yeah I helped build it and the plan was... 45:50 – Yeah I can see the issue there, do I maintain it or...? 46:02 – Andrew comments and talks about the community and different codes. 46:36 – Andrew, anything else that you want to talk about? 46:48 – There are tons of notes in our chat, which the listeners can’t see. 46:58 – Advertisement – Fresh Books’ Advertisement! 30-Day Trial! Links: Ruby Elixir JavaScript React Erlang – Disk Log Erlang WX Railway Oriented Programming Nebo 15 GitHub – Scenic Kafka Rabbit MQ AWS AWS – Kinesis GitHub – Firenest XHTTP GitHub – Ecto GitHub – Ecto Mnesia Saga and Medium Introducing Sage Andrew Dryga’s Website Andrew Dryga’s Medium Andrew Dryga’s GitHub Andrew Dryga’s LinkedIn Andrew Dryga’s Twitter Andrew Dryga’s FB Andrew’s YouTube Channel Andrew’s Sagas of Elixir Video Sponsors: Loot Crate Fresh Books Cache Fly Picks: Mark Mark of the Ninja Josh A Sneak Peek at Ecto 3.0: Breaking Changes Nate Pragmatic Studio Eric Looking of Elixir Developers Metabase.com Polymail Andrew Tide of History

Panel: Charles Max Wood Guest: Jerome Hardaway This week on My Ruby Story, Charles speaks with Jerome Hardaway. Jerome used to be a panelist on Ruby Rogues and loved the ability to share his knowledge and interact with so many people from the community. He first got into programming by accident when he couldn’t find a job after becoming a veteran. He saw a commercial about job opportunities in coding, ended up finding a book on SQL and taught himself how to program. They talk about where he ran across Ruby on Rails, what he has worked on that he is particularly proud of, what he is doing currently, and more! In particular, we dive pretty deep on: Jerome’s experience being a panelist on Ruby Rogues Loves being able to reach his goals in a speedy manner Ruby Rogues Episode 279 JavaScript Jabber Episode 239 How did you first get into programming? In the military during the recession and had trouble finding a job Saw a commercial about coding Taught himself SQL Wordpress Focusing on making Vets Who Code better People would go for products over projects any day Chose Ruby on Rails Setting himself apart by picking to focus on Ruby on Rails Where did you come across Ruby on Rails? From PHP to Ruby on Rails Ruby Have you found the learning curve has gotten steeper for Rails? Keeping up with the JavaScript community What have you done on Ruby in Rails that you are proud of? Being the right person for the job when you don’t look like it on paper What are you working on now? And much, much more! Links: Ruby Rogues Episode 279 JavaScript Jabber Episode 239 Vets Who Code Ruby Rogues Wordpress Ruby on Rails Ruby JavaScript @JeromeHardaway Vets Who Code blog Jerome’s GitHub Sponsors: Loot Crate FreshBooks Picks Charles Take some time with the people you care about Mattermost Jerome Brian Holt Frontend Masters Pragmatic Studio

Panel: Charles Max Wood Guest: Jerome Hardaway This week on My Ruby Story, Charles speaks with Jerome Hardaway. Jerome used to be a panelist on Ruby Rogues and loved the ability to share his knowledge and interact with so many people from the community. He first got into programming by accident when he couldn’t find a job after becoming a veteran. He saw a commercial about job opportunities in coding, ended up finding a book on SQL and taught himself how to program. They talk about where he ran across Ruby on Rails, what he has worked on that he is particularly proud of, what he is doing currently, and more! In particular, we dive pretty deep on: Jerome’s experience being a panelist on Ruby Rogues Loves being able to reach his goals in a speedy manner Ruby Rogues Episode 279 JavaScript Jabber Episode 239 How did you first get into programming? In the military during the recession and had trouble finding a job Saw a commercial about coding Taught himself SQL Wordpress Focusing on making Vets Who Code better People would go for products over projects any day Chose Ruby on Rails Setting himself apart by picking to focus on Ruby on Rails Where did you come across Ruby on Rails? From PHP to Ruby on Rails Ruby Have you found the learning curve has gotten steeper for Rails? Keeping up with the JavaScript community What have you done on Ruby in Rails that you are proud of? Being the right person for the job when you don’t look like it on paper What are you working on now? And much, much more! Links: Ruby Rogues Episode 279 JavaScript Jabber Episode 239 Vets Who Code Ruby Rogues Wordpress Ruby on Rails Ruby JavaScript @JeromeHardaway Vets Who Code blog Jerome’s GitHub Sponsors: Loot Crate FreshBooks Picks Charles Take some time with the people you care about Mattermost Jerome Brian Holt Frontend Masters Pragmatic Studio

Panel: Charles Max Wood Guest: Jerome Hardaway This week on My Ruby Story, Charles speaks with Jerome Hardaway. Jerome used to be a panelist on Ruby Rogues and loved the ability to share his knowledge and interact with so many people from the community. He first got into programming by accident when he couldn’t find a job after becoming a veteran. He saw a commercial about job opportunities in coding, ended up finding a book on SQL and taught himself how to program. They talk about where he ran across Ruby on Rails, what he has worked on that he is particularly proud of, what he is doing currently, and more! In particular, we dive pretty deep on: Jerome’s experience being a panelist on Ruby Rogues Loves being able to reach his goals in a speedy manner Ruby Rogues Episode 279 JavaScript Jabber Episode 239 How did you first get into programming? In the military during the recession and had trouble finding a job Saw a commercial about coding Taught himself SQL Wordpress Focusing on making Vets Who Code better People would go for products over projects any day Chose Ruby on Rails Setting himself apart by picking to focus on Ruby on Rails Where did you come across Ruby on Rails? From PHP to Ruby on Rails Ruby Have you found the learning curve has gotten steeper for Rails? Keeping up with the JavaScript community What have you done on Ruby in Rails that you are proud of? Being the right person for the job when you don’t look like it on paper What are you working on now? And much, much more! Links: Ruby Rogues Episode 279 JavaScript Jabber Episode 239 Vets Who Code Ruby Rogues Wordpress Ruby on Rails Ruby JavaScript @JeromeHardaway Vets Who Code blog Jerome’s GitHub Sponsors: Loot Crate FreshBooks Picks Charles Take some time with the people you care about Mattermost Jerome Brian Holt Frontend Masters Pragmatic Studio

  Panel: Charles Max Wood   Guest: Jerome Hardaway   This week on My JavaScript Story, Charles speaks with Jerome Hardaway. Jerome used to be a panelist on Ruby Rogues and loved the ability to share his knowledge and interact with so many people from the community. He first got into programming by accident when he couldn’t find a job after becoming a veteran. He saw a commercial about job opportunities in coding, ended up finding a book on SQL and taught himself how to program. They talk about where he ran across Ruby on Rails, what he has worked on that he is particularly proud of, what he is doing currently, and more! In particular, we dive pretty deep on: Jerome’s experience being a panelist on Ruby Rogues Loves being able to reach his goals in a speedy manner Ruby Rogues Episode 279 JavaScript Jabber Episode 239 How did you first get into programming? In the military during the recession and had trouble finding a job Saw a commercial about coding Taught himself SQL Wordpress Focusing on making Vets Who Code better People would go for products over projects any day Chose Ruby on Rails  Setting himself apart by picking to focus on Ruby on Rails Where did you come across Ruby on Rails? From PHP to Ruby on Rails Ruby Have you found the learning curve has gotten steeper for Rails? Keeping up with the JavaScript community What have you done on Ruby in Rails that you are proud of? Being the right person for the job when you don’t look like it on paper What are you working on now? And much, much more!   Links:  Ruby Rogues Episode 279 JavaScript Jabber Episode 239 Vets Who Code Ruby Rogues Wordpress Ruby on Rails Ruby JavaScript @JeromeHardaway Vets Who Code blog Jerome’s GitHub   Sponsors:  Loot Crate FreshBooks Picks Charles  Take some time with the people you care about Mattermost Jerome Brian Holt Frontend Masters Pragmatic Studio

  Panel: Charles Max Wood   Guest: Jerome Hardaway   This week on My JavaScript Story, Charles speaks with Jerome Hardaway. Jerome used to be a panelist on Ruby Rogues and loved the ability to share his knowledge and interact with so many people from the community. He first got into programming by accident when he couldn’t find a job after becoming a veteran. He saw a commercial about job opportunities in coding, ended up finding a book on SQL and taught himself how to program. They talk about where he ran across Ruby on Rails, what he has worked on that he is particularly proud of, what he is doing currently, and more! In particular, we dive pretty deep on: Jerome’s experience being a panelist on Ruby Rogues Loves being able to reach his goals in a speedy manner Ruby Rogues Episode 279 JavaScript Jabber Episode 239 How did you first get into programming? In the military during the recession and had trouble finding a job Saw a commercial about coding Taught himself SQL Wordpress Focusing on making Vets Who Code better People would go for products over projects any day Chose Ruby on Rails  Setting himself apart by picking to focus on Ruby on Rails Where did you come across Ruby on Rails? From PHP to Ruby on Rails Ruby Have you found the learning curve has gotten steeper for Rails? Keeping up with the JavaScript community What have you done on Ruby in Rails that you are proud of? Being the right person for the job when you don’t look like it on paper What are you working on now? And much, much more!   Links:  Ruby Rogues Episode 279 JavaScript Jabber Episode 239 Vets Who Code Ruby Rogues Wordpress Ruby on Rails Ruby JavaScript @JeromeHardaway Vets Who Code blog Jerome’s GitHub   Sponsors:  Loot Crate FreshBooks Picks Charles  Take some time with the people you care about Mattermost Jerome Brian Holt Frontend Masters Pragmatic Studio

  Panel: Charles Max Wood   Guest: Jerome Hardaway   This week on My JavaScript Story, Charles speaks with Jerome Hardaway. Jerome used to be a panelist on Ruby Rogues and loved the ability to share his knowledge and interact with so many people from the community. He first got into programming by accident when he couldn’t find a job after becoming a veteran. He saw a commercial about job opportunities in coding, ended up finding a book on SQL and taught himself how to program. They talk about where he ran across Ruby on Rails, what he has worked on that he is particularly proud of, what he is doing currently, and more! In particular, we dive pretty deep on: Jerome’s experience being a panelist on Ruby Rogues Loves being able to reach his goals in a speedy manner Ruby Rogues Episode 279 JavaScript Jabber Episode 239 How did you first get into programming? In the military during the recession and had trouble finding a job Saw a commercial about coding Taught himself SQL Wordpress Focusing on making Vets Who Code better People would go for products over projects any day Chose Ruby on Rails  Setting himself apart by picking to focus on Ruby on Rails Where did you come across Ruby on Rails? From PHP to Ruby on Rails Ruby Have you found the learning curve has gotten steeper for Rails? Keeping up with the JavaScript community What have you done on Ruby in Rails that you are proud of? Being the right person for the job when you don’t look like it on paper What are you working on now? And much, much more!   Links:  Ruby Rogues Episode 279 JavaScript Jabber Episode 239 Vets Who Code Ruby Rogues Wordpress Ruby on Rails Ruby JavaScript @JeromeHardaway Vets Who Code blog Jerome’s GitHub   Sponsors:  Loot Crate FreshBooks Picks Charles  Take some time with the people you care about Mattermost Jerome Brian Holt Frontend Masters Pragmatic Studio

In this podcast, I try to document the process of becoming a web programmer. If you how frustrating it can be to get your head around basic ideas when everyone else seems to know what they are talking about and you still have no clue, then this podcast is for you. At the time of the first episode, I use Laravel, PHP, MYSQL, Docker, Linux and Swift. Please expect this podcast to be very opinionated and recognise that there are many ways to achieve an expected result in the programming world. Podcast notes: Pragmatic Studio: https://pragmaticstudio.com/ruby Laravel Valet: https://laravel.com/docs/5.6/valet Laravel Framework: https://laravel.com/

Philip Poots @pootsbook | GitHub Show Notes: 00:53 - What is Elm? 03:45 - The Essence of User Interface 07:59 - “Messages” 08:31 - Scalability 14:04 - Error Handling 18:47 - The Business Case 22:35 - Where is Elm on the curve of scalability? 28:36 - Learning From Elm 32:32 - “Whole Meal Solutions” Resources: Philip Poots: Elmber @ Wicked Good Ember 2016 Cycle.js Functional Reactive Programming Evan Czaplicki Test-driven Development (TDD) NoRedInk The Elm Mailing List Try Elm Elm Guide elmtutorial.org Elm For Beginners by James Moore Transcript: CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 56. I am Charles Lowell, a developer here at The Frontside. With me is Jeffrey Cherewaty, also a developer here at The Frontside. JEFFREY: Hey-o! CHARLES: We're going to be talking today with Philip Poots, who is a fantastic individual, who I have known over the Twitters, over the e-mails, interacted with at conferences, seen him speak on at least one occasion and today we're actually going to be talking about the thing that I saw him speak at Wicked Good Ember last June. It was actually one of my favorite talks from that conference. It was on Elm for Ember developers. Thank you very much for being on the show, Philip. Why don't you tell us a little bit about what Elm is and how you came to find out about it and really kind of dive deeply into it? PHILIP: Yeah, sure. First of all, pleasure to be on the show. The Frontside is one of my favorite podcast, if not my favorite, given a cross-section of the Dadcast, the love of programming and balancing that with the business of programming. That's right, I'm an independent developer. I started off with Rails then got into the Ember quite early on. Last year, I think around January, that's when I started really investigating Elm in detail. It's actually a funny story how I came about because I was at Ember Amsterdam and it was a night where we had three members of the core team: we had Erik Bryn, he gave a talk, Alex Matchneer, gave a talk and Igor also came over because he's based in Europe. Alex always loves to investigate new things and one of the things he was getting into was Observables. I'd never heard about Observables at all so after the talk, I kind of pulled him aside and I asked him some very stupid questions. He was gracious enough to bear with me and to dive a little deeper into this stuff. Alex is kind of a quiet member of the core team, unless he's got his drum sticks but he's the guy that rewrote the [inaudible]. That was no mean feat because I got into Ember just before that moment and the way he managed to make that incredibly easy was fantastic so I kind of had an extra ear open to what he had to say. I went on this Observables talk. You know, you start off with React that was the framework that was using Observables the most. That brought me to Cycle.js -- CHARLES: Cycle.js? I haven't heard of that. Is Cycle.js a framework built on top of Observables? PHILIP: It is. There's a guy called André Staltz or André Medeiros but he uses Staltz as his name. It's largely based off the same principles as React. Cycle, basically one of his inspirations or at least one of the things which cycle is most like was the Elm architecture. He calls it Model-View-Intent. We have Model-View-Controller and Elm was model update view but essentially, the same principles. You know, I'm the kind of guy that likes to get stuck in, to go deep and where I started with Observables then I ended up at Elm. I started playing around with that, I started looking into it and I loved what I saw. The thing above all that really attracted me to it was the pure simplicity of what was going on. It was almost like they boiled down the UI paradigm to its essence and removed all the extra cruft and you just saw what you meant what you wanted and it gave you these, what I thought at the time, composable way to put things together. CHARLES: Can we unpack that just a little bit? I really love that idea of it boiled down to the essence of UI. I assume there are certain coordinating mechanisms that Elm employs. It's interesting to hear you say that Cycle.js has used Elm as an inspiration. I also understand that Redux is inspired also by the Elm architecture. I'm very curious, what are those kind of essential mechanics that drew your attention? PHILIP: I think you can look at it from two points of view. The first is, which I didn't actually learn until later but the first is essentially boiling down functional programming. You're decoupled, you're using functions and not only functional programming and there's a lot of arguments over this term but functional reactive programming. The idea of functional programming is stateless. Therefore, time is kind of the beast that you have to deal with. But FRP, then essentially boils time into the concept of values that can change over time so you have a reference to one value but in JavaScript that's an Observable. In Elm, in the beginning, when I was getting into it, that was signals. That's not all kind of hidden underneath so you don't really need to get over that conceptual hurdle anymore. Then the boiling down to the essence, I guess that's more from a code point of view with Ember. Especially at the beginning, there were a ton of different concepts that were thrown at you to begin with. It was billed as an MVC framework. It was sold as an MVC framework but you had helpers in there, you had components, you had views model controller. You had this cluster of things. You could see MVC in there but there were enough things surrounding it to kind of think, "Where does this piece of code go? Where does that piece of code go? Where should I do this?" CHARLES: There are a lot of blog posts trying to explain what exactly is the view, is the template the view? Is the controller the view? What's the difference between a view and a controller? PHILIP: The way I think about frameworks is they give you buckets to put your code. The buckets are kind of all connected together. I'm thinking at a really simplistic level. I need to write this feature, I need this bit of code, I need this bit of logic, where do I stick it? A framework says you should stick it here or you should stick it there. It's solves the need of having to think about the broader architecture and how things interact because those things have been solved for you. Now with Elm, it was just so straightforward to say, "This goes here: all the data, the model. It lives in this record, which is equivalent to a JavaScript object, we can say on a simple level. Anything you need to do with state, happens there. Then you've got the view and the view is simply a function, which takes that data structure and then you tell it how to render it to HTML and then all of the action, everything that happens in your application is also defined in one place in your update function. That's it, like no more than you need and no less than you need. CHARLES: Yeah, I love that. I feel like it is very much as 'data down, actions up' kind of boiled down to the essence. It's almost better at that paradigm than Ember is in itself, with having your view as just a function. Your state transition or your update is just a function. Then your model is just unadorned data. That's all it is. PHILIP: The type system as well in Elm, also made it really straightforward. My model is a record. That's it. My view is HTML in the beginning but then it moves to HTML, which contains messages. Essentially, I've got HTML and in the HTML, there are events or actions and those actions will send messages and really straight forward. Then the update function, I take in the current model, I take in the message and I decide via pattern matching what I want to do. There are a few extra bits and pieces around there but that's the essence of it. CHARLES: Now, when you say messages, I'm thinking this is a way of declaring what actions you will take when certain HTML elements, like events happen, like you declaratively mapping an event to the dispatch of an action. PHILIP: That's correct, with any extra data so a message is itself. Like the actions hash in Ember essentially and along with the parameters for that action, which would passing through the HTML. CHARLES: Some might argue that if something is simple to get something working, I can have a pure function that's a view, I can have a simple data structure which is my model. I can have a pure function which is my update or my state transition, how I change my data or affect changes to the model. Some might say, "That's very simple," but simple is great for simple cases. But then there's the question of scalability. As my application becomes more complex and has the interactions become more complex, does that simple paradigm actually scale? What has been your experience there? PHILIP: Straightforward answer -- it's a learning curve to scale. Why? Because it's so new and also because the things that you would have reached for in the past aren't available to you. When I think of Ember scaling, the scale is built into the framework. You need another component, you just add another component. You need another model, you add another model. There's a clear story or there's a clear way that you deliver a new feature. I think that's a fantastic aspect of Ember that you also say no. I can remember being at Wicked Good Ember and just realizing how many of the people that were speaking and how many of the people that I was talking to work for bigger companies -- Heroku Dashboard, you had LinkedIn and the fact that Ember scales across a large team size, it's a real testament to Ember, which is slightly different for the reason why I got into Ember. Also you know I had a few issues just on a side project with a friend, the pace of Elm's change meant that when you only have a limited time to devote to the project, then you don't want to be spending that time for going out where you should be in terms of the upgrade process, etcetera. That's a known path and I think that's a really clear advantage of Ember over Elm. The path in Elm is not as well-fleshed out and there's a bit of tension between Elm as a single page application and then Elm as an application that you stick on every page of your server generated app, for example. The main people who use Elm NoRedInk could employ Evan Czaplicki, the creator of Elm, there up at the minute is a Rails up. I think in Elm up for every page, I believe that certainly was the case, whether that's [inaudible], I don't know. It's not an area where it's like here's the path, go for it because the scalability of Elm, everyone came into Elm thinking, "I know react. I know Ember, the components system, 'data down, actions up'," and in React, you're really encouraged to make a component for the smallest thing on the page as a component. Then you have container components, you make your way out of the onion skin and hope you don't cry on the way. [Laughter] PHILIP: But the thing about Elm was everyone jumped in and tried to do it this way. I certainly got the impression when I was beginning that the Elm architecture was infinitely Nestable Russian dolls. It is in a way but the difficulty is then passing into component communication between parent and child and people had been figuring it on a weird ways with signals to do it but then became obsolete. The main encouragement is basically go so far with a single component that you can and then once you had problems, try not to create new components or new bits of UI but to extract the bits you need into modules. This is actually one of the things that really attracted me to Elm is that you're encouraged to lean on your programming skill set, rather than learning a whole new frameworks way of doing things so that the things that work in functional programming will work in Elm. But that's also a down side because all of a sudden, you have to exercise your programming chops. Let's be honest, a lot of the stuff we're building we're like gluing things together. We're not thinking up new architectures or ways of doing things. That's definitely a learning curve and that's definitely a struggle or something that I find difficult. CHARLES: Yeah, I feel like that touches a lot on the messages you get from the FP community. I know certainly in the interactions I've had with the Clojure community, they're very big on that and it's like, "Let's have very powerful primitives." They have that term 'decomplecting', like let's get at the core. It's like understand that essence so if we can compose and we can enable composition of these low level functions and allow you to compose the data, then you don't have to worry so much about everything else. There will be a way. I think the counterpoint to that is that you end up with a lot of different ways because there are a lot of different ways that you can compose a very small set of primitives. PHILIP: Yes, that's right. But I think one of the advantages of Elm over maybe other FP languages and this is where the similarity with Ember comes in as well. It tries very much to cement simple convention but not only by convention but actually baked into the language so people that are coming from more powerful functional programming languages often come to Elm and think, "Why can't I do that? Why do I have to write all this boilerplate code," and the reason is because then it's not going to be simple enough anymore for people to use it. Also the goal of Elm, which is this long term maintainability of large code bases, you kind of shoot yourself in the foot a bit just like you said, Charles. CHARLES: Yeah, I think that's actually a great point. It's actually one of the things that was most memorable, I think about your talk at Wicked Good was -- just a quick anecdote. I remember in 2007, when iPhone came out, I had an iPhone and my father in law came over from Finland and this is a guy who was a Nokia partisan. I mean, part of Finnish pride was everybody own -- JEFFREY: National phone of Finland. CHARLES: Yeah, exactly. Everybody owned the Nokia mobile phone. He came over, He visited me and I had an iPhone and he was like, "Can I see it?" He took it, he had the swipe to unlock and he swiped it and it unlocked and all the app icons just kind of came right into the screen and he was like, "I want one." [Laughter] CHARLES: That was all it took. I've never seen a sales process so utterly complete and so rapid in its realization. For me, I think that moment when I saw you talk was when you made a mistake like where you were trying to match against an improper attribute on the model inside the update function. The first thing that happened was that Elm caught it before you could even compile your program and the error was just beautiful. It put its finger right on and it's like you need to fix this right here so there's much tied up into that because I feel like it addresses a lot of the learning curve problems that we have in Ember. PHILIP: I don't think that's Ember specific -- CHARLES: No, it's not, it's -- PHILIP: That's the JavaScript thing, isn't it? CHARLES: Yeah. PHILIP: In many ways, I think of JavaScript as a very low level substrate. It's like sand, it's very granular and it's very hard to put together well without falling apart, whereas in Elm gives you bigger blocks, so to speak but it also defines a way through the type system where if you don't put those blocks together in the right way, it's going to tell you. That's why despite some of the ignorance of how best to do Elm apps, that's why people continue to use it because it gives them this delightful experience. CHARLES: Yeah, it was fantastic where when you fail, it picks you up, dust you off and sets you right back on the right track. I think one, that's just a freaking awesome feature and I think also two, the thing that struck me when I saw that was like, "Wow, this community has a different focus than other FP communities that I've come into contact with because I have encountered that exact same error message in Haskell and it left me puzzling and wondering what to do. It's like, "No instance for type class blah-blah-blah for class blah." Then if you're an experienced Haskeller, it does point right to the problem in the same way that like you've learn the parse Perl stack traces. You know, you see a Perl stack trace and you understand it. But they could have gone that way with Elm but the other thing that it demonstrated, it has kind of a different focus there. PHILIP: Absolutely and that really comes down to Evan Czaplicki, the creator of Elm. I was able to get over to London in October a couple of years ago or a year and a half ago now to do a workshop with him at the Code Mesh Conference. You know, just seeing him teach this stuff and saying go into this and talk about the things in a bit more detail, it was very clear. First of all that he'd had a negative experience picking up Haskell, I think it was and he just thought, it doesn't have to be this hard. The things aren't actually that hard. It's the way that we're explaining them that makes it hard. The things that are actually under the surface is really simple. He has a blanket ban on this kind of technical jargon. In the Elm community, he prefers to get things really straightforward names. I think he said to me that one of his thesis advisors or his university professor said, "Evan, that's what you get when you put a usability specialist into a programming language creator's shoes," that he does have this focus where he understands the benefits of static-type systems but he also deeply cares about the experience of not only picking up the language and learning it but also the day you solve it and that's something that just shines through. I think even if Elm never makes it into the pantheon of great programming languages like that in itself and the influence of that had already on other communities, this is fantastic. It's the tide that lifts all boats in many ways and we all benefit from that. JEFFREY: We kind of touch on this a little bit earlier. We've been talking about the ergonomics of being an engineer working with Elm or Ember. What about the business case? We've mentioned how Ember has prevent a scale fairly well in large organizations. What's Elm's path to being able to do that and where is the niche to that it fits in right now? PHILIP: I definitely think Ember comes out of Apple, I believe with sprite core. That's where it started and it's interesting to see that that's also where it's gone in terms of the focuses and making it easy to build these rich applications. I think also that Elm has a similar genesis in the sense that Evan, I believe he did an internship at Microsoft and one at Google and I think there's a conference talk as well from large JS or elm lock or something, millions of lines of code. It's definitely gunning for the CM area which is applications which are large and hairy and trying to make the maintainability a lot better by bringing the strengths of the static type system to bear and bring the simplicity that that enables. That means that the learning curve maybe is a little sharper at the beginning, in a similar way, also that Ember was and is. But then you should reach this point where the maintainability of the app outweighs the time spent in learning. I think about it a bit like test driven development. I remember back when I was doing Rails and DHH had baked TDD into the Rails itself and there was the years of the testing discussions whether to test all the time, test everything, 100% coverage or even full circle tests are a waste of time. but it's a similar philosophy in that if the tests are doing what they should be doing, which is giving you great feedback, the time it takes to get up to speed in testing, the time it takes to set up testing, the time it takes to write the tests, they pay off further down the line and that's not music to the ears of the people who want to get something into production immediately. But it's definitely music to the ears of people who will be spending a long time on maintenance in an application. That NoRedInk application is huge. They have millions of users. They've build software for teaching grammar and skills in the US and they talk all the time about the benefits of Elm. Mainly, in the sense of confidence, I have the confidence to go in and change this code. All of bits or majorities of our code bits, which are things that we've rather not like to touch. We kind of section them off. If a feature request comes in and instead of saying, "Yeah, we can do that," you try and slowly push it out the door. Elm is supposed to give you then the confidence to be able to go to any part of your code base and to change it without the fear that you're going to break something or break everything because the type system, the compiler will tell you, "You change this type, you change the signature of this function, here's where it's broken and as soon as you fix the compiler errors, functionally it works, you'd probably have a few tests to test the actual business logic of it." Probably not so with technical stuff but it's a huge time saver. That's where we want to be as developers and our relationship with our tools. We don't want to be fearing our tools. We don't want to be anxious every time we open our editor. We don't want to fear the feature requests coming in. We want to be in control of our environment and we want to be able to deliver the business value. I think that's certainly the promise of Elm. That's certainly where it wants to be. CHARLES: I love that. It sounds like that is where they want to shoot for is these big applications and they do want to scale massively. Let me ask the question then. Where is Elm do you think right now today on that curve of scalability? PHILIP: To put it in Ember terms, that's maybe the best way I can describe it. If anyone remembers the early days of Ember, I definitely feel that they're in 0.9 approaching one rather than later than that. One of the things as well, I think it's important to note is that Evan is not rushed. It just blew my mind when I heard him speak about it and it wasn't anything big or anything but just the whole kind of tenor of the conversation of the way he was teaching of how he was talking about Elm was so in contrast to the JavaScript type machine. In contrast to a new framework every month, he was like, "If Elm is going to be around in 10 years, then this is the decision that I'm going to make." In that sense, where is Elm in that journey. I'd say it's still pretty early on. I'd say also, Evan is really focused on use cases so if there's not a use case for something, there's no reason to add it. This is actually quite frustrating maybe for people who are coming out of JavaScript ecosystem and they think of a feature that they want and they submit a pull request and it just gets closed or it get set, is there use case for this? Why do you need it? Is this generalizable to everyone? Will it make sense to add this to the language? Can you do it in a library? Then figured out later, can you do it in JavaScript with port, instead of having to bring it into Elm? He's definitely building it very slowly but that may sound like a down side right now but the upside is we're going to come up with something at the end, hopefully that is battle-tested, that fits the use case and a good example of that was the URL handling at the navigation. It didn't live in Elm. Do we actually need it because he's building single page applications? Can you give me your experiences? There are a couple of libraries also built. Then the things from those libraries were then taken a little bit like Ember as well, where you use the add-on ecosystem to try new things and then things may get brought into core or make it kind of the official stamp of approval. But it's a lot slower and not as committee-based. Evan is the benevolent dictator for life. CHARLES: I really like that approach. I don't withhold my opinion from the benevolent dictator versus kind of the oligarchy that you see elsewhere. But I was thinking as you were describing it that maybe the framework really, and this is me, I'm kind of a little bit of a tree nerd, mostly in and around the trees that grow in central Texas but I love trees. Unfortunately, it sounds like oak or maybe redwood would have been like a more appropriate name because those are very slow growing, have a very hard wood, whereas in Elm, it's actually fairly short lived and has a softer wood. JEFFREY: And you also don't want cedar because that will come back and bite you -- highly allergic and toxic to humans. [Laughter] CHARLES: Right. Named Elm but slow growing hardwood that you can build a house out of. But I like that. It's so important to get things right the first time because that's where you realize exponential gains. Unfortunately, there is no substitute for exponential gains, rather than deep thought. At least that's been my experience. You can realize gigantic short term gains with taking cut corners but in terms of long term exponential, ultimately those will taper off. PHILIP: I think as well, what we've seen in Ember's experience is the decisions that you take to open up a private API or not to make something private. They limit you because all of a sudden, everyone starts using those APIs. A year down the line, you realize, "Oh, hang on. We don't want to design it in this way. We want to do it in that way," but given the commitment that Ember has to stability, you have to deal with that. Sometimes, the dealing with that actually takes more energy, more time, more effort in education, in actual code, in maintaining two branches, all of that kind of stuff then actually takes away from the time that you could have had to think up better solutions and it's a danger, you know? It's almost like as soon as you throw this into the water that it becomes firm. As soon as you throw it into the crowd, the crowd will take it and they will use it and your chance to change it or mold it will have gone. Evan talks a lot with language designers and at least I got that impression that he opens up channels of communication with people who've done this before and he thinks very deeply. He's not closed off to the idea of adding more powerful features to Elm but he would only do it when it's right to do it. It's not just is this feature right but is this the right time for this feature? That as well is just the kind of mind blowing like who thinks about this stuff, who cares about this stuff? CHARLES: Yeah, because certain features become accessible once other features are in place. I feel like it would have been as feasible to have an entire compiled language as an acceptable option before people started transpiling CoffeeScript and then with Babel, transpiling future versions of JavaScript back into JavaScript. If those intermediate steps happened, if CoffeeScript and Babel would have happened, would people be as receptive to things like Elm or things like PureScript? it's definitely there is kind of the zeitgeist of the development community really informs what features are even possible or appropriate tomorrow, even though they might have some ejectively sound qualities out to them. JEFFREY: They want to make sure they're not too far ahead of their time. CHARLES: Right, exactly. Folks got to be ready for it. Then the other thing that I wanted to ask was given the trajectory of where Elm is, some people are using it in production. You said it was around like a 0.9, 1.0. if we are actually quite happy with our current code bases, whether we're using Ember, whether using React, whether using some other framework, what are things that you can learn from Elm that you can bring home with you to your own town, wherever that is to use and make your own life better, as you develop code, to kind of increase that confidence, as you say? PHILIP: This is very relevant to my suggestion because in the past couple of months, I haven't had a chance to do any Elm but what I find is after kind of my deep dive, I've come out the other end and I feel like I've come out a better programmer. I feel like Elm is simple enough conceptually to learn quicker, faster, at least the basics more than maybe even to JavaScript framework. I think that the things that you will learn in that process are tremendously beneficial, even if you don't ever end up using Elm in a professional capacity. The thing I think that grabbed me most is because of the way the type system is, you have to deal with every error and this is something when writing Ruby or when writing Ember, you always focus on the happy path. Then once you've got the happy path in place, often the business will say, "That's done. Let's move on." Your better instincts say, "No, we haven't actually made this robust enough." But sometimes the value is also not the great in kind of shoring up all those cases. But what Elm does because of the way it's build is it forces you to deal with failure. The classic no runtime errors in production, the reason that is it may have taken you a bit longer to write your code in Elm. But you come out of it with a confidence that if something explodes, it's either something incredibly rare or it was JavaScript and not Elm. Just the forcing like, "How can I think better about how this code can fail," means a bit of extra mental effort when you do it in a language that's not Elm but it's definitely something that's worth doing, if you want to build good software. Another thing related to the failure stuff is maybe the idea of what's called an abstract data type or a union type or an enum, like the fact that you can encode different states in one object, that you deal with all of those states in a cohesive way. One of the things actually, I think it was Jack Franklin of JavaScript Playground who brought this back from Elm into Java Script was when you have a screen, you want to load some data via Ajax or Fetch, instead of just loading the page, sending off the request, getting the request back, deciding what to do with it, it's like, "Why don't we encode those states in our code." We have the waiting state, we have the find state but we have find but it was an error, we have find and it worked, we have find and it actually has no values. Instead of just dealing with those on the fly, if statements like why don't you create an object that encodes the states that your UI can be in and then you react and the UI will know what to do and you write the code to do that. But in some ways, at least to me that's a lot better than kind of hit and hope when we got an error. That's, "If do this, if do that, let's nest some callbacks or let's chance some promises." The sheer act of taking a step back and this is something Elm forces you to do because the way it is, like thinking about the domain and thinking about how best to model the domain. To be honest, it's probably just good programming practice but how often do we not do it? CHARLES: Absolutely. It seems so obvious, except it's only obvious when you're put into a system that you can't slide on it. What you're describing reminds me of this concept that I came across in the Haskell community. They talk about wholemeal solutions versus piecemeal solutions. Most of the time, they talk about wholemeal solutions as kind of finding the most general set of abstractions that solve a problem for all cases. But I hadn't applied it to this concept of that all the potential states kind of envisioning your application. As you execute your code, you'll only come across one state of the time but kind of thinking of your code as all of these sort of quantum states of your application existing at once and you need to account for them all and draw that whole picture. PHILIP: This is a really stupid analogy but I don't know if anyone's played Age of Empires or any other kind of war-based game where you have a map, you've got the fog of war and you can only see a few meters around you and you have to send out your scouts and you need to find them -- CHARLES: Yeah, yeah. PHILIP: -- Different tactics. You shore up your base and you concentrate on where you are, you send your scouts into the far ends of the map. In terms of seeking out of the unknown, I feel like Elm forces you to know the map where is when I'm programming in JavaScript or in Ruby, it's more like, "I'm here. I need to do this. I do it," and you don't necessarily force yourself to think of all the potential states or all the potential things that can happen, the events that can happen, whereas with Elm, if you don't have those, then it will tell you that those things in place. [Laughter] CHARLES: Yeah, I love that analogy. Like actually sent out your scouts to know the map. PHILIP: Yep and I think as a person, and this is maybe why it appeals to me it's like I like the feeling that I haven't left a stone unturned. I like shipping something that I'm confident in and I know it won't bite me or if it does bite me, it's purely because it was an unknown-unknown. It's like doing your due diligence. As I'm saying this, Elm is not the silver bullet. Elm is not the panacea. Elm will not solve all of your problems. But speaking in terms of contrast with JavaScript or Ruby and more dynamic languages than Elm, these are the things that happen. I think that kind of leads me on to another point which is Evan in the mailing list conversations and the decisions that he takes with Elm, I don't know if this are stages of maturity as a developer but you find your tool, you love it, it's the only thing that can do the job and then you realize other people are doing jobs pretty well, doing their other stuff, I guess each to their own. But I feel like there's another stage where it's like what are the tradeoffs involved in taking this decision or using this tool and what are the tradeoffs involved in taking this decision or using that tool. Just the way of thinking in terms of tradeoffs, instead of absolutes I find really, really valuable and that's definitely something that I've been able to apply and what are the benefits of this decision. Not only from a code point of view but from an organizational point of view, from a team point of view, from a long term point of view, from a short term point of view, having a wider arena to make those decisions, it has been really helpful for me, valuable on both side of them. CHARLES: I can see it. I believe you and I think we're coming to the end of our time here, I think I'm going to make the same recommendation that I made to everybody last week when we were talking with Toran about Redux and that is you should go out and you should try Elm. It's really easy to get started and it will guide you. The guides are excellent. The air handling is excellent and yes it is quirky and weird but it supports you. There's going to be some big functional programming boulders thrown at you but it gives you a [inaudible] to deal with them. JEFFREY: I think you need a suit of armor so we can stick with the Age of Empires metaphors. [Laughter] CHARLES: Yeah. Go out there, try it and experience the things that Philip is talking about because I feel like they are very real and they will have a good effect on you, whatever it is that you do the next day or the next week or the next month. PHILIP: They'll challenge the way you think, they'll give you new perspective and they'll give you a good counterpoint as well. You know, elm is not for everyone but only if you try it will you understand that. I think that's one of Evan and everyone in the Elm community is try it yourself. I'm not going to say Elm is right for you, Elm is right for your business. Rewrite everything in Elm, not at all, try it out, try it on a side project, try it to just having fun hacking around. If you do want to make the jump to using it in your company or whatever, don't take a decision to rewrite everything. Take one very small part of your app and do it in Elm and see how it goes. If you don't like it, you can take it out. If it works, you can build another small thing. This kind of gradual approach were far too quick to jump on a bandwagon: trash the old thing, do the new thing. Especially now, when we are building applications that are going to be maintained, when we are building applications that are going to be around for a few years, it's also just not feasible and sometimes it's not right. You just got to make that decision maturely rather than I want to use this or I want to use that, which can be tough. But ultimately, you want to deliver the value. Try Elm at Elm-lang.org/Try. You can try on the browser and see how you go. The official guide is really good. There's also Elm-Tutorial.org, which is kind of a complement to the official guide. Pragmatic Studio have released recently an updated course for learning Elm. James Moore at KnowThen.com. He has a couple of Elm courses, one is free introductory and then there's a paid course, which goes into deeper topics, whether text or whether video, whatever your thing is, there's resources available to get you to the point where you'll be able to make a decent decision. CHARLES: Well, fantastic. I'm certainly excited. I haven't dip my toes in Elm for a while and I'm actually, after this conversation pretty stoked to get it on again. I hope everybody else does. Thank you so much, Philip for coming on to the podcast. This was just a fantastic and enlightening conversation. PHILIP: Not at all. It's been an absolute pleasure. Thank you. CHARLES: All right. That's it from The Frontside. Remember to get in touch with us at Frontside.io, if you're interested in UI that is engineered to make your UX dreams come true.

Panel Brandon Alexander (twitter github blog) Pete Hodgson (twitter github blog) Jaim Zuber (twitter Sharp Five Software) Andrew Madsen (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:19 - Brandon Alexander Introduction Black Pixel Pro iOS 5 Tools: Xcode, Instruments and Build Tools by Brandon Alexander 02:00 - Performance Tooling & User Experience 04:30 - Reproducibility with Experiments 07:50 - Measuring Frame Rate 09:31 - CPU vs GPU 12:56 - Tools Frames Per Second Time Profiler 16:24 - OpenGL ES 17:35 - Performance Tuning for Memory-Bound Applications 19:26 - Memory Allocation 28:16 - Network Requests “ns run loop modes” NSURLConnection 36:14 - Visual Changes in iOS 7 and Performance Tuning 39:05 - Mocking and Stubbing 41:15 - Battery Life 45:24 - Profiling CPU-Bound Stuff Picks mmap (Jaim) appledoc (Andrew) CocoaDocs (Andrew) Cocoanetics (Andrew) Wil Shipley: Pimp My Code, Part 15: The Greatest Bug of All (Andrew) WWDC Videos (Pete) Having a "device lab": picking your supported devices, and test on them (Pete) Instapaper (Pete) Network Link Conditioner (Pete) FormatterKit (Rod) The Mathematical Hacker (Rod) Pivotal Tracker (Chuck) Redmine (Chuck) Xcode (Brandon) Dash (Brandon) Kaleidoscope (Brandon) LLDB Python Reference (Brandon) Next Week Software Craftsmanship with Ken Auer Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces fit together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 17 of The iPhreaks Show! This week on our panel, we have Pete Hodgson. PETE: Hello, hello from San Francisco! CHUCK: Jaim Zuber. JAIM: Hello from Minneapolis! CHUCK: Andrew Madsen. ANDREW: Hi from Salt Lake City! CHUCK: Rod Schimdt. ROD: Hello, hello from Salt Lake! CHUCK: I'm Charles Max Wood from DevChat.tv. This week we have a special guest, and that is Brandon Alexander. BRANDON: Hello! I'm coming from Atlanta, Georgia. CHUCK: Since you haven't been on the show before, do you want to give us a brief introduction, let us know who you are? BRANDON: I'm currently a iOS and hopefully Mac developer for Black Pixel. I do a lot of the client development work and test as much as I can a lot of our products. I'm also an author, a conference speaker, and I've also done a training video to appear soon. CHUCK: Nice! Sounds like fun! What book did you write? I'm curious… BRANDON: The book I wrote is called “Pro iOS 5 Tools”. It's a couple of versions of iOS old, but the techniques in the book are still completely valid today. CHUCK: Very nice. Alright, we'll tell people to go check it out. We brought you on the show to talk about “Performance Tuning” for your iOS app. I think it's interesting; we're talking about a resource-constrained environment. Is it about the user's experience? Or, are there other concerns as well that we're trying to optimize for? BRANDON: Ultimately, it's about the user experience. If you try to implement something and the user doesn't have a good experience with it, or it does something over the phone like battery life, you might want to rethink that feature or rethink the assumptions of your application.

Panel Brandon Alexander (twitter github blog) Pete Hodgson (twitter github blog) Jaim Zuber (twitter Sharp Five Software) Andrew Madsen (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:19 - Brandon Alexander Introduction Black Pixel Pro iOS 5 Tools: Xcode, Instruments and Build Tools by Brandon Alexander 02:00 - Performance Tooling & User Experience 04:30 - Reproducibility with Experiments 07:50 - Measuring Frame Rate 09:31 - CPU vs GPU 12:56 - Tools Frames Per Second Time Profiler 16:24 - OpenGL ES 17:35 - Performance Tuning for Memory-Bound Applications 19:26 - Memory Allocation 28:16 - Network Requests “ns run loop modes” NSURLConnection 36:14 - Visual Changes in iOS 7 and Performance Tuning 39:05 - Mocking and Stubbing 41:15 - Battery Life 45:24 - Profiling CPU-Bound Stuff Picks mmap (Jaim) appledoc (Andrew) CocoaDocs (Andrew) Cocoanetics (Andrew) Wil Shipley: Pimp My Code, Part 15: The Greatest Bug of All (Andrew) WWDC Videos (Pete) Having a "device lab": picking your supported devices, and test on them (Pete) Instapaper (Pete) Network Link Conditioner (Pete) FormatterKit (Rod) The Mathematical Hacker (Rod) Pivotal Tracker (Chuck) Redmine (Chuck) Xcode (Brandon) Dash (Brandon) Kaleidoscope (Brandon) LLDB Python Reference (Brandon) Next Week Software Craftsmanship with Ken Auer Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces fit together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 17 of The iPhreaks Show! This week on our panel, we have Pete Hodgson. PETE: Hello, hello from San Francisco! CHUCK: Jaim Zuber. JAIM: Hello from Minneapolis! CHUCK: Andrew Madsen. ANDREW: Hi from Salt Lake City! CHUCK: Rod Schimdt. ROD: Hello, hello from Salt Lake! CHUCK: I’m Charles Max Wood from DevChat.tv. This week we have a special guest, and that is Brandon Alexander. BRANDON: Hello! I’m coming from Atlanta, Georgia. CHUCK: Since you haven’t been on the show before, do you want to give us a brief introduction, let us know who you are? BRANDON: I’m currently a iOS and hopefully Mac developer for Black Pixel. I do a lot of the client development work and test as much as I can a lot of our products. I’m also an author, a conference speaker, and I’ve also done a training video to appear soon. CHUCK: Nice! Sounds like fun! What book did you write? I’m curious… BRANDON: The book I wrote is called “Pro iOS 5 Tools”. It’s a couple of versions of iOS old, but the techniques in the book are still completely valid today. CHUCK: Very nice. Alright, we’ll tell people to go check it out. We brought you on the show to talk about “Performance Tuning” for your iOS app. I think it’s interesting; we’re talking about a resource-constrained environment. Is it about the user’s experience? Or, are there other concerns as well that we’re trying to optimize for? BRANDON: Ultimately, it’s about the user experience. If you try to implement something and the user doesn’t have a good experience with it, or it does something over the phone like battery life, you might want to rethink that feature or rethink the assumptions of your application.

Panel Andrew Madsen (twitter github blog) Pete Hodgson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Ben Scheirman (twitter github blog NSSreencast) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:33 - The Apple Developer Portal 01:57 - When the portal goes down 05:35 - What the Portal Does iBooks System Status 07:20 - Certificates and Provisioning Profiles Wildcard Certificate nomad cupertino shenzhen venice 17:50 - Managing the Device List 21:45 - Clients and Developer Accounts 23:00 - NDA 27:04 - Submitting Apps to the App Store 29:04 - iTunes Connect 34:24 - Rejecting Apps 37:46 - Apps on Particular Devices Version Requirements 44:05 - Entitlements 44:44 - TSIs Picks FontAwesome-for-iOS (Rod) When to use -retainCount? (Andrew) Strange Loop (Pete) Boxen (Pete) Homebrew (Pete) The Changelog (Pete) Brian Gorby - AppResigner: Easily re-sign iOS apps (Ben) Apple - Support - iPhone - Enterprise (Ben) Average App Store Review Times (Ben) Brian Stevens / Data Porters (Chuck) Canvas by Instructure (Chuck) Wistia (Chuck) Next Week Performance Tuning with Brandon Alexander Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 16 of the iPhreaks Show! This week on our panel, we have Andrew Madsen. ANDREW: Hi from Salt Lake City! CHUCK: Pete Hodgson. PETE: Hello from San Francisco where BART is not striking here. BEN: [Chuckles] CHUCK: Where what is not striking? BEN: BART. CHUCK: BART. PETE: Bay Area Rapid Transit. CHUCK: Rod! ROD: Hello from Salt Lake City! CHUCK: And we also have Ben Scheirman. BEN: Hello from Houston where it's 180 degrees! [Laughter] CHUCK: I'm Charles Max Wood from DevChat.tv. Real quickly, one of the reasons that I do this show is so that I can get work. So if you need backend work for your iPhone application and you're interested in using Ruby on Rails, I am available for hire! Alright, well let's get to the show! This week, we were talking about and having a discussion on the "Apple Developer Portal", when it's working. [Chuckles] ANDREW: Which is, sort of mostly right now. BEN: Yeah. We'll be back soon [laughs]. CHUCK: Yup. PETE: Except not soon. [Laughter] PETE: For some definition to see. CHUCK: Yeah. ANDREW: Oh, man! BEN: Yeah. They have a very loose definition of soon, I think. PETE: [Chuckles] BEN: Do we want to start off by just talking about what happened there? I don't know if anybody has any like behind the scenes info on the portal being down, but from what I heard, they detected some sort of hack attempt. And then shortly there after, this, I think he was an Israeli hacker, or I shouldn't say hacker, security researcher, came out and said -- CHUCK: [Laughs] BEN: "I successfully exploited this thing, and I told you about it and filed a radar. I just wanted to see how deep it went," so he pulled out, I don't remember how many users' contact info from the Dev Portal, and he posted a little screencast on the type of data he got and the level. I don't know if that -- they seem to be related because it was like around the exact same time.

Panel Andrew Madsen (twitter github blog) Pete Hodgson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Ben Scheirman (twitter github blog NSSreencast) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:33 - The Apple Developer Portal 01:57 - When the portal goes down 05:35 - What the Portal Does iBooks System Status 07:20 - Certificates and Provisioning Profiles Wildcard Certificate nomad cupertino shenzhen venice 17:50 - Managing the Device List 21:45 - Clients and Developer Accounts 23:00 - NDA 27:04 - Submitting Apps to the App Store 29:04 - iTunes Connect 34:24 - Rejecting Apps 37:46 - Apps on Particular Devices Version Requirements 44:05 - Entitlements 44:44 - TSIs Picks FontAwesome-for-iOS (Rod) When to use -retainCount? (Andrew) Strange Loop (Pete) Boxen (Pete) Homebrew (Pete) The Changelog (Pete) Brian Gorby - AppResigner: Easily re-sign iOS apps (Ben) Apple - Support - iPhone - Enterprise (Ben) Average App Store Review Times (Ben) Brian Stevens / Data Porters (Chuck) Canvas by Instructure (Chuck) Wistia (Chuck) Next Week Performance Tuning with Brandon Alexander Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 16 of the iPhreaks Show! This week on our panel, we have Andrew Madsen. ANDREW: Hi from Salt Lake City! CHUCK: Pete Hodgson. PETE: Hello from San Francisco where BART is not striking here. BEN: [Chuckles] CHUCK: Where what is not striking? BEN: BART. CHUCK: BART. PETE: Bay Area Rapid Transit. CHUCK: Rod! ROD: Hello from Salt Lake City! CHUCK: And we also have Ben Scheirman. BEN: Hello from Houston where it's 180 degrees! [Laughter] CHUCK: I'm Charles Max Wood from DevChat.tv. Real quickly, one of the reasons that I do this show is so that I can get work. So if you need backend work for your iPhone application and you're interested in using Ruby on Rails, I am available for hire! Alright, well let's get to the show! This week, we were talking about and having a discussion on the "Apple Developer Portal", when it's working. [Chuckles] ANDREW: Which is, sort of mostly right now. BEN: Yeah. We'll be back soon [laughs]. CHUCK: Yup. PETE: Except not soon. [Laughter] PETE: For some definition to see. CHUCK: Yeah. ANDREW: Oh, man! BEN: Yeah. They have a very loose definition of soon, I think. PETE: [Chuckles] BEN: Do we want to start off by just talking about what happened there? I don't know if anybody has any like behind the scenes info on the portal being down, but from what I heard, they detected some sort of hack attempt. And then shortly there after, this, I think he was an Israeli hacker, or I shouldn't say hacker, security researcher, came out and said -- CHUCK: [Laughs] BEN: "I successfully exploited this thing, and I told you about it and filed a radar. I just wanted to see how deep it went," so he pulled out, I don't remember how many users' contact info from the Dev Portal, and he posted a little screencast on the type of data he got and the level. I don't know if that -- they seem to be related because it was like around the exact same time.

Panel Jaim Zuber (twitter Sharp Five Software) Ben Scheirman (twitter github blog NSSreencast) Rod Schmidt (twitter github infiniteNIL) Andrew Madsen (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:10 - Jaim Zuber Introduction 02:15 - Integrating somebody else's code into your project without using Cocoapods Dragging & dropping source files Static Library Approach Frameworks Circumventing 10:38 - Cocoapods Libraries Cocoa Controls 12:37 - Frequently Used Pods AFNetworking RestKit ocmock Kiwi SVProgressHUD BlocksKit 15:29 - Getting a Pod into a Library or Application Versioning Multiple Targets Specifying a Path to a Repository Handling Multiple Platforms 28:07 - RubyMotion and Cocoapods motion-cocoapods 29:29 - Using Cocoapods on Client Work 30:08 - Testing 32:17 - Creating Your Own Pods Hosting Dependencies Picks Objective-C Modules (Andrew) UTAsync (Jaim) CocoaPods Xcode Plugin (Rod) VVDocumenter (Rod) CocoaDocs (Ben) cocoapods-xcode-plugin (Ben) Getting Things Done by David Allen (Chuck) Omnifocus (Chuck) Next Week The Developer Portal Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 15 of the iPhreaks Show! This week on our panel, we have Ben Scheirman. BEN: Hello from Houston! CHUCK: We have Rod Schmidt. ROD: Hello from Salt Lake! CHUCK: Andrew Madsen. ANDREW: Hello also from Salt Lake! CHUCK: And we have a new guest panelist, that is Jaim Zuber. JAIM: Hello from Minneapolis! CHUCK: Do you want to introduce yourself really quickly since you're new to the show? JAIM: Sure, happy to! Independent consultants, I've been doing iOS stuff for about 2-3 years; before that, I did some kind of .NET stuff. Way before that, I did a lot of C++ and C stuff in kind of the past life. But, yeah, I'm doing iOS right now, mobile stuff, and enjoying it! CHUCK: Sounds good! I'm Charles Max Wood from DevChat.tv. This week, we're going to talk about "CocoaPods". BEN: Yay! CHUCK: [Laughs] ROD: [Chuckles] JAIM: I'm cuckoo for CocoaPods. CHUCK: There we go. JAIM: [Laughs] BEN: I'm a super fan of CocoaPods. I wonder if we have any haters in the audience, or on the panel. ANDREW: Yeah, I'm the hater. BEN: [Inaudible] ANDREW: Not really. BEN: Okay [laughs]. ANDREW: I just don't use it. BEN: You say you're the dissenting opinion? ANDREW: I can do that, sure. CHUCK: I've had people basically say, "Well, it's just like having bundler - bundlers of utility in Ruby for iOS!" I was like, "Oh! That sounds nice." But that doesn't really tell me necessarily how it works. BEN: So can we start off by maybe describing what it takes to integrate somebody else's code into your project without something like CocoaPods? ROD: [Chuckles] CHUCK: Yes. Yes, let's frame the public. BEN: Anybody want to describe this for like, say, a moderately complex library? ANDREW: It depends on how complicated the library is. But at its simplest, you can just drag source code from their project into yours and add it to your project, and that's it. But I think,

Panel Jaim Zuber (twitter Sharp Five Software) Ben Scheirman (twitter github blog NSSreencast) Rod Schmidt (twitter github infiniteNIL) Andrew Madsen (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:10 - Jaim Zuber Introduction 02:15 - Integrating somebody else’s code into your project without using Cocoapods Dragging & dropping source files Static Library Approach Frameworks Circumventing 10:38 - Cocoapods Libraries Cocoa Controls 12:37 - Frequently Used Pods AFNetworking RestKit ocmock Kiwi SVProgressHUD BlocksKit 15:29 - Getting a Pod into a Library or Application Versioning Multiple Targets Specifying a Path to a Repository Handling Multiple Platforms 28:07 - RubyMotion and Cocoapods motion-cocoapods 29:29 - Using Cocoapods on Client Work 30:08 - Testing 32:17 - Creating Your Own Pods Hosting Dependencies Picks Objective-C Modules (Andrew) UTAsync (Jaim) CocoaPods Xcode Plugin (Rod) VVDocumenter (Rod) CocoaDocs (Ben) cocoapods-xcode-plugin (Ben) Getting Things Done by David Allen (Chuck) Omnifocus (Chuck) Next Week The Developer Portal Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 15 of the iPhreaks Show! This week on our panel, we have Ben Scheirman. BEN: Hello from Houston! CHUCK: We have Rod Schmidt. ROD: Hello from Salt Lake! CHUCK: Andrew Madsen. ANDREW: Hello also from Salt Lake! CHUCK: And we have a new guest panelist, that is Jaim Zuber. JAIM: Hello from Minneapolis! CHUCK: Do you want to introduce yourself really quickly since you're new to the show? JAIM: Sure, happy to! Independent consultants, I've been doing iOS stuff for about 2-3 years; before that, I did some kind of .NET stuff. Way before that, I did a lot of C++ and C stuff in kind of the past life. But, yeah, I'm doing iOS right now, mobile stuff, and enjoying it! CHUCK: Sounds good! I'm Charles Max Wood from DevChat.tv. This week, we're going to talk about "CocoaPods". BEN: Yay! CHUCK: [Laughs] ROD: [Chuckles] JAIM: I'm cuckoo for CocoaPods. CHUCK: There we go. JAIM: [Laughs] BEN: I'm a super fan of CocoaPods. I wonder if we have any haters in the audience, or on the panel. ANDREW: Yeah, I'm the hater. BEN: [Inaudible] ANDREW: Not really. BEN: Okay [laughs]. ANDREW: I just don't use it. BEN: You say you're the dissenting opinion? ANDREW: I can do that, sure. CHUCK: I've had people basically say, "Well, it's just like having bundler - bundlers of utility in Ruby for iOS!" I was like, "Oh! That sounds nice." But that doesn't really tell me necessarily how it works. BEN: So can we start off by maybe describing what it takes to integrate somebody else's code into your project without something like CocoaPods? ROD: [Chuckles] CHUCK: Yes. Yes, let's frame the public. BEN: Anybody want to describe this for like, say, a moderately complex library? ANDREW: It depends on how complicated the library is. But at its simplest, you can just drag source code from their project into yours and add it to your project, and that's it. But I think,

Panel Ben Scheirman (twitter github blog NSSreencast) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:09 - Backend Experience 01:49 - Connecting to APIs & Synchronization Windows Azure Mobile Services iCloud Wasabi Sync TICoreDataSync Buoy Explorer 07:10 - Third-party APIs OAuth Instragram Stripe 11:57 - Parsing NSXMLParser NSXMLDocument Cocoa with Love: Using libxml2 for XML parsing and XPath queries in Cocoa libxml 18:18 - JSON RestKit 22:38 - Libraries AFNetworking 31:02 - Building Backends for iOS Applications DeliRadio 35:05 - Security SSL Pinning Charles API Keys Secrets 41:28 - Support Caching NSURLCache 45:34 - Charles Picks objc.io (Rod) Mackie | Onyx Blackjack 2x2 USB Interface (Ben) Runscope (Ben) Daring Fireball: Markdown Syntax Documentation (Chuck) Next Week Debugging Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 13 of the iPhreaks Show! This week on our panel, we have Ben Scheirman. BEN: Hello from Houston! CHUCK: We also have Rod Schmidt. ROD: Hello from Salt Lake! CHUCK: I'm Charles Max Wood from DevChat.tv. This week, we're going to be talking about "Connecting to Backend APIs and just Backend Systems" in general. I'm curious, how much of this kind of thing have you guys done in the past? BEN: That's pretty much the central part of any app that we develop. Most apps aren't really self-contained; it's a functionality. A lot of them required data that's accessible somewhere else. Or, even if you generate the data on the device, usually, people want to access that data elsewhere as well. So sometimes, you can consider things like iCloud, but that's more of an Apple-centric solution if you're billing it out for the web or for multiple platforms, and maybe you would consider building your own API and synchronizing with that. CHUCK: When you're talking about building your own API, I know that there are these syncing services out there that you send data to it and it does something with it, do you know under what circumstances that would be a good idea versus building your own API that does specific things with the data on the backend? BEN: It really depends on where, how much focus you have, how much time do you have to build something and where your skill set lies. For folks who aren't server-side developers, building an API is actually a tall order, and there are plenty of solutions out there that will do that for you at the cost of, sometimes flexibility, sometimes data portability, and you're sort of at the whim of the interface that they provide for you. But there's systems like Windows Add/Removal services, which allow you to just focus on your part - the mobile client portion of it. But they have support for saving data and sending push notifications, that sort of thing. There's also parse and there's just a bunch of others out there that can synchronize data. Some of them are focused purely on synchronizing Core Data models. So there's iCloud Core Data, which receives some sort of a lot of negative press,

Panel Ben Scheirman (twitter github blog NSSreencast) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:09 - Backend Experience 01:49 - Connecting to APIs & Synchronization Windows Azure Mobile Services iCloud Wasabi Sync TICoreDataSync Buoy Explorer 07:10 - Third-party APIs OAuth Instragram Stripe 11:57 - Parsing NSXMLParser NSXMLDocument Cocoa with Love: Using libxml2 for XML parsing and XPath queries in Cocoa libxml 18:18 - JSON RestKit 22:38 - Libraries AFNetworking 31:02 - Building Backends for iOS Applications DeliRadio 35:05 - Security SSL Pinning Charles API Keys Secrets 41:28 - Support Caching NSURLCache 45:34 - Charles Picks objc.io (Rod) Mackie | Onyx Blackjack 2x2 USB Interface (Ben) Runscope (Ben) Daring Fireball: Markdown Syntax Documentation (Chuck) Next Week Debugging Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 13 of the iPhreaks Show! This week on our panel, we have Ben Scheirman. BEN: Hello from Houston! CHUCK: We also have Rod Schmidt. ROD: Hello from Salt Lake! CHUCK: I'm Charles Max Wood from DevChat.tv. This week, we're going to be talking about "Connecting to Backend APIs and just Backend Systems" in general. I'm curious, how much of this kind of thing have you guys done in the past? BEN: That's pretty much the central part of any app that we develop. Most apps aren't really self-contained; it's a functionality. A lot of them required data that's accessible somewhere else. Or, even if you generate the data on the device, usually, people want to access that data elsewhere as well. So sometimes, you can consider things like iCloud, but that's more of an Apple-centric solution if you're billing it out for the web or for multiple platforms, and maybe you would consider building your own API and synchronizing with that. CHUCK: When you're talking about building your own API, I know that there are these syncing services out there that you send data to it and it does something with it, do you know under what circumstances that would be a good idea versus building your own API that does specific things with the data on the backend? BEN: It really depends on where, how much focus you have, how much time do you have to build something and where your skill set lies. For folks who aren't server-side developers, building an API is actually a tall order, and there are plenty of solutions out there that will do that for you at the cost of, sometimes flexibility, sometimes data portability, and you're sort of at the whim of the interface that they provide for you. But there's systems like Windows Add/Removal services, which allow you to just focus on your part - the mobile client portion of it. But they have support for saving data and sending push notifications, that sort of thing. There's also parse and there's just a bunch of others out there that can synchronize data. Some of them are focused purely on synchronizing Core Data models. So there's iCloud Core Data, which receives some sort of a lot of negative press,

Panel Sam Soffes (twitter github blog) Pete Hodgson (twitter github blog) Ben Scheirman (twitter github blog NSSreencast) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:13 - Sam Soffes Introduction Seesaw/@Seesaw 01:46 - Roon.io/@roon_app Drew Wilson Octopress 03:03 - Open Source in iOS Writing Tests Flurry TestFlight PLCrashReporter 09:00 - Open Sourcing Projects cheddar-ios Licensing 13:19 - Shared code between iOS and Mac 004 iPhreaks Show - Mac Development with Josh Abernathy Categories 17:48 - Contributions, Pull Requests & Bug Fixes 20:15 - Open Source Libraries CocoaPods 28:40 - Finding Reliable Libraries Rating Activity READMEs Cocoa Controls 32:44 - Contributing to Open Source Projects Consistency (tabs vs spaces) Testing Squashing Commits Submitting Code/Changes 38:09 - Cleaning Up Pull Requests 41:08 - Open Source at Seesaw SEEActivityIndicatorView Picks semver.org (Ben) Anker Astro3E Portable External Battery Pack (Ben) Cards Against Humanity (Ben) Travis CI (Pete) Pete Hodgson: Using Travis CI and xctool to build and test iOS apps (Pete) Reading Application Licenses (Pete) AppCoreKit (Rod) WatchESPN AppleTV App (Rod) Put Objective-C Back On The Map (Ben) David Siteman Garland: Create Awesome Online Courses (Chuck) How to Write a Nonfiction eBook in 21 Days by Steve Scott (Chuck) Amazon Prime (Chuck) Kickoff App (Sam) redcarpet (Sam) Next Week Backends Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 12 of iPhreaks! This week on our panel, we have Pete Hodgson. PETE: Buongiorno from rainy San Francisco this morning! CHUCK: Ben Scheirman. BEN: I can give you a very jet lagged hello from Houston! CHUCK: Rod Schimdt. ROD: Hello from Salt Lake City! CHUCK: I'm Charles Max Wood from DevChat.tv. This week, we have a special guest and that's Sam Soffes. Alright! SAM: Hello! CHUCK: Do you want to introduce yourself real quick? SAM: Sure! I live in Kentucky right now. I work in a company called "Seesaw". I'm working on a bunch of little projects; Roon had been my main side project right now. CHUCK: Awesome. BEN: That's Roon, R-O-O-N.io, right? SAM: You got it! BEN: Yeah, I'm primed I've got the best username. All I need to do now is blog a little bit. [Laughter] BEN: So Roon is like a blogging platform. What makes it kind of compelling in comparison to some of the other things that are out there? SAM: It's a product I did with Drew Wilson. If you're not familiar with his work, he's a spectacular designer. I always wanted it that makes it really simple that we wanted to use, and hopefully other people wanted to use, too, so he just made something really simple that's really beautiful, and there's also a native iPhone app. The iPad app is like the universal, it's almost done; I'm submitting it, hopefully, this week. And we have a Mac app in the Pipeline. It's just like we wanted to make a really good writing experience that's simple and pretty and hopefully people like it. CHUCK: Awesome. BEN: Yeah,

Panel Sam Soffes (twitter github blog) Pete Hodgson (twitter github blog) Ben Scheirman (twitter github blog NSSreencast) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:13 - Sam Soffes Introduction Seesaw/@Seesaw 01:46 - Roon.io/@roon_app Drew Wilson Octopress 03:03 - Open Source in iOS Writing Tests Flurry TestFlight PLCrashReporter 09:00 - Open Sourcing Projects cheddar-ios Licensing 13:19 - Shared code between iOS and Mac 004 iPhreaks Show - Mac Development with Josh Abernathy Categories 17:48 - Contributions, Pull Requests & Bug Fixes 20:15 - Open Source Libraries CocoaPods 28:40 - Finding Reliable Libraries Rating Activity READMEs Cocoa Controls 32:44 - Contributing to Open Source Projects Consistency (tabs vs spaces) Testing Squashing Commits Submitting Code/Changes 38:09 - Cleaning Up Pull Requests 41:08 - Open Source at Seesaw SEEActivityIndicatorView Picks semver.org (Ben) Anker Astro3E Portable External Battery Pack (Ben) Cards Against Humanity (Ben) Travis CI (Pete) Pete Hodgson: Using Travis CI and xctool to build and test iOS apps (Pete) Reading Application Licenses (Pete) AppCoreKit (Rod) WatchESPN AppleTV App (Rod) Put Objective-C Back On The Map (Ben) David Siteman Garland: Create Awesome Online Courses (Chuck) How to Write a Nonfiction eBook in 21 Days by Steve Scott (Chuck) Amazon Prime (Chuck) Kickoff App (Sam) redcarpet (Sam) Next Week Backends Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 12 of iPhreaks! This week on our panel, we have Pete Hodgson. PETE: Buongiorno from rainy San Francisco this morning! CHUCK: Ben Scheirman. BEN: I can give you a very jet lagged hello from Houston! CHUCK: Rod Schimdt. ROD: Hello from Salt Lake City! CHUCK: I'm Charles Max Wood from DevChat.tv. This week, we have a special guest and that's Sam Soffes. Alright! SAM: Hello! CHUCK: Do you want to introduce yourself real quick? SAM: Sure! I live in Kentucky right now. I work in a company called "Seesaw". I'm working on a bunch of little projects; Roon had been my main side project right now. CHUCK: Awesome. BEN: That's Roon, R-O-O-N.io, right? SAM: You got it! BEN: Yeah, I'm primed I've got the best username. All I need to do now is blog a little bit. [Laughter] BEN: So Roon is like a blogging platform. What makes it kind of compelling in comparison to some of the other things that are out there? SAM: It's a product I did with Drew Wilson. If you're not familiar with his work, he's a spectacular designer. I always wanted it that makes it really simple that we wanted to use, and hopefully other people wanted to use, too, so he just made something really simple that's really beautiful, and there's also a native iPhone app. The iPad app is like the universal, it's almost done; I'm submitting it, hopefully, this week. And we have a Mac app in the Pipeline. It's just like we wanted to make a really good writing experience that's simple and pretty and hopefully people like it. CHUCK: Awesome. BEN: Yeah,

Panel Pete Hodgson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:06 - Web Apps vs Native Apps HTML UIWebView Platform Coverage vs User Experience 04:48 - Uncanny Valley Effect 06:18 - Frameworks Sencha Touch Appcelerator Titanium SDK PhoneGap Kony 08:37 - Mobile vs Web Experience 13:15 - Uncanny Valley Effect Toy Story vs Polar Express 15:20 - Scrolling of Web Views 17:04 - Making Smart Technology Choices Platform Reach 22:13 - Access PhoneGap Calatrava 25:29 - Focus 28:18 - Exposure and Discoverability 30:20 - Cross-Platform Tradeoffs 32:21 - Offline Access HTML5 App Cache Every Time Zone 35:45 - HTML Presentation Frameworks jQuery Mobile 059 JSJ jQuery Mobile with Todd Parker Picks Calatrava (Pete) Iain Banks (Pete) Elixir (Rod) The Power Formula for LinkedIn Success: Kick-start Your Business, Brand, and Job Search by Wayne Breitbarth (Chuck) Twitter Bootstrap (Chuck) HTML5 Rocks (Chuck) Next Week iPhreaks Show: Open Source with Sam Soffes Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 11 of iPhreaks! This week on our panel, we have Pete Hodgson. PETE: Good morning! CHUCK: Rod Schmidt. ROD: Good morning! CHUCK: I'm Charles Max Wood from DevChat.tv. This week we're going to be talking about the tradeoffs between "Web Apps and Native Apps". One of the things that kind of made me want to talk about this was that I remember a while ago, 37signals came out and basically said, "We're not going to write iPhone Apps or Android Apps for our products. We're just going to make mobile versions of the websites and people could just use that," and I thought that was really interesting. So I'm curious with you guys, what you see as the tradeoffs between one or the other. ROD: Well, since they've changed a little bit, they're now using RubyMotion for their Basecamp App mixed with some web technology, so now they're kind of hybrid. PETE: I think that's a really good point. When I talk about this stuff to clients, I say like the question of Web versus Native, the answer is "Yes". And really it's not like, "Should I do Web? Or, should I do Native?" It's "Where should I sit on the spectrum between Fully-Native and Fully-HTML?" Actually, not that many people go to [Inaudible], so there's not that many products that don't have any installed app or tool, and there's not that many products that don't use the web at some point inside of their, even if it's a Native App, a lot of apps still have webby stuff inside of them; that's sometimes surprising. CHUCK: What do you mean by webby stuff? Are you talking about -- PETE: Even just something as simple as HTML, an HTML View. Let's say you're doing legal disclaimer as the classic example they always use, you're doing legal disclaimers for your app, you could do the layout and mock up and stuff in code. Or, you could just write some simple HTML, shove it in the UIWebView, and embed it in your app. That's normally about a way to go. CHUCK: Yeah, that was what I was wondering; it's if they were using UIWebView,

Panel Pete Hodgson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:06 - Web Apps vs Native Apps HTML UIWebView Platform Coverage vs User Experience 04:48 - Uncanny Valley Effect 06:18 - Frameworks Sencha Touch Appcelerator Titanium SDK PhoneGap Kony 08:37 - Mobile vs Web Experience 13:15 - Uncanny Valley Effect Toy Story vs Polar Express 15:20 - Scrolling of Web Views 17:04 - Making Smart Technology Choices Platform Reach 22:13 - Access PhoneGap Calatrava 25:29 - Focus 28:18 - Exposure and Discoverability 30:20 - Cross-Platform Tradeoffs 32:21 - Offline Access HTML5 App Cache Every Time Zone 35:45 - HTML Presentation Frameworks jQuery Mobile 059 JSJ jQuery Mobile with Todd Parker Picks Calatrava (Pete) Iain Banks (Pete) Elixir (Rod) The Power Formula for LinkedIn Success: Kick-start Your Business, Brand, and Job Search by Wayne Breitbarth (Chuck) Twitter Bootstrap (Chuck) HTML5 Rocks (Chuck) Next Week iPhreaks Show: Open Source with Sam Soffes Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 11 of iPhreaks! This week on our panel, we have Pete Hodgson. PETE: Good morning! CHUCK: Rod Schmidt. ROD: Good morning! CHUCK: I'm Charles Max Wood from DevChat.tv. This week we're going to be talking about the tradeoffs between "Web Apps and Native Apps". One of the things that kind of made me want to talk about this was that I remember a while ago, 37signals came out and basically said, "We're not going to write iPhone Apps or Android Apps for our products. We're just going to make mobile versions of the websites and people could just use that," and I thought that was really interesting. So I'm curious with you guys, what you see as the tradeoffs between one or the other. ROD: Well, since they've changed a little bit, they're now using RubyMotion for their Basecamp App mixed with some web technology, so now they're kind of hybrid. PETE: I think that's a really good point. When I talk about this stuff to clients, I say like the question of Web versus Native, the answer is "Yes". And really it's not like, "Should I do Web? Or, should I do Native?" It's "Where should I sit on the spectrum between Fully-Native and Fully-HTML?" Actually, not that many people go to [Inaudible], so there's not that many products that don't have any installed app or tool, and there's not that many products that don't use the web at some point inside of their, even if it's a Native App, a lot of apps still have webby stuff inside of them; that's sometimes surprising. CHUCK: What do you mean by webby stuff? Are you talking about -- PETE: Even just something as simple as HTML, an HTML View. Let's say you're doing legal disclaimer as the classic example they always use, you're doing legal disclaimers for your app, you could do the layout and mock up and stuff in code. Or, you could just write some simple HTML, shove it in the UIWebView, and embed it in your app. That's normally about a way to go. CHUCK: Yeah, that was what I was wondering; it's if they were using UIWebView,

Panel Ben Scheirman (twitter github blog NSSreencast) Rod Schmidt (twitter github infiniteNIL) Pete Hodgson (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:22 - Launching a UIWebView and pointing it to a remote URL Autoplay Streaming over 3G or LTE 03:01 - HTTP Live Streaming AVPlayer MPMoviePlayerController MPMoviePlayerViewController Microsoft Silverlight AV Foundation 11:24 - AVPlayer Asynchronous Key Loading Protocol AVURLAsset Learning Core Audio: A Hands-On Guide to Audio Programming for Mac and iOS by Chris Adamson Key-Value Observing (KVO) Deli Radio AVAudioPlayer 19:42 - Use Cases System Sound Audio Categories Playback Control AVQueuePlayer 32:21 - Core Audio Learning Core Audio: A Hands-On Guide to Audio Programming for Mac and iOS by Chris Adamson Adding effects to audio and video AV Audio Mix Echo 38:51 - Interruption 42:04 - Network Connections Network Link Conditioner in Lion - Matt Gemmell 44:07 - .MP3, .CAF, .AIFF, .AAC 45:32 - Transcoding Zencoder M3U Picks Audacity (Rod) Customers (Rod) The Little Redis Book by Karl Seguin (Ben) MMDrawerController (Ben) MacBuildServer (Ben) OpenEmu (Ben) Reveal App (Pete) Snap CI (Pete) Buildozer (Pete) ThinkGeek (Pete) Commit (Chuck) Candy Crush Saga (Chuck) Mini Golf MatchUp (Chuck) Portal (Chuck) Next Week Web Apps & HTML5 vs Native Apps Transcript ROD: I'd get my Dad a Darth Vader helmet...because he's my father. BEN: Yeah, I got it. [laughter] [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 10 of iPhreaks! That's right, we're on the double digits now! This week on our panel, we have Ben Scheirman. BEN: Hello from NSScreencast.com! CHUCK: Rod Schmidt. ROD: Hello from Salt Lake! CHUCK: Pete Hodgson. PETE: Hello from thepete.net! [Ben laughs] CHUCK: And I'm Charles Max Wood from DevChat.tv! This week we are going to be talking about "Audio and Video" in your apps. BEN: So this is where you just launch a UIWebView and point it to remote URL and then you're done? PETE: I did that once. CHUCK: All the games that I play, I have to turn the sound off on them. PETE: I actually did do that once, Ben. BEN: Yes, it's the quick and easy way to do it. PETE: Yup, it was surprisingly good. I discovered, we're going to jump straight into rearcane pit of noise, but didn't let you do "Autoplay" on video; Apple doesn't want you to do that. Can you still not do that if you're using native video? BEN: You can do whatever you want with the native stuff. PETE: Okay. So for the web one, you can't. But this -- BEN: I think it's just kind of the Safari limitation... PETE: Yeah [chuckles]. CHUCK: Every browser should do that. That rise me asked, too. PETE: I think they say it's a battery issue more than anything else like they don't want you firing up the radio to download like 50 maybe, to start offering conserve concept. BEN: Yeah, they have gotten a little bit more strict on the rules for that, and I don't remember the exact numbers off the top of my head.

Panel Ben Scheirman (twitter github blog NSSreencast) Rod Schmidt (twitter github infiniteNIL) Pete Hodgson (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:22 - Launching a UIWebView and pointing it to a remote URL Autoplay Streaming over 3G or LTE 03:01 - HTTP Live Streaming AVPlayer MPMoviePlayerController MPMoviePlayerViewController Microsoft Silverlight AV Foundation 11:24 - AVPlayer Asynchronous Key Loading Protocol AVURLAsset Learning Core Audio: A Hands-On Guide to Audio Programming for Mac and iOS by Chris Adamson Key-Value Observing (KVO) Deli Radio AVAudioPlayer 19:42 - Use Cases System Sound Audio Categories Playback Control AVQueuePlayer 32:21 - Core Audio Learning Core Audio: A Hands-On Guide to Audio Programming for Mac and iOS by Chris Adamson Adding effects to audio and video AV Audio Mix Echo 38:51 - Interruption 42:04 - Network Connections Network Link Conditioner in Lion - Matt Gemmell 44:07 - .MP3, .CAF, .AIFF, .AAC 45:32 - Transcoding Zencoder M3U Picks Audacity (Rod) Customers (Rod) The Little Redis Book by Karl Seguin (Ben) MMDrawerController (Ben) MacBuildServer (Ben) OpenEmu (Ben) Reveal App (Pete) Snap CI (Pete) Buildozer (Pete) ThinkGeek (Pete) Commit (Chuck) Candy Crush Saga (Chuck) Mini Golf MatchUp (Chuck) Portal (Chuck) Next Week Web Apps & HTML5 vs Native Apps Transcript ROD: I'd get my Dad a Darth Vader helmet...because he's my father. BEN: Yeah, I got it. [laughter] [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 10 of iPhreaks! That's right, we're on the double digits now! This week on our panel, we have Ben Scheirman. BEN: Hello from NSScreencast.com! CHUCK: Rod Schmidt. ROD: Hello from Salt Lake! CHUCK: Pete Hodgson. PETE: Hello from thepete.net! [Ben laughs] CHUCK: And I'm Charles Max Wood from DevChat.tv! This week we are going to be talking about "Audio and Video" in your apps. BEN: So this is where you just launch a UIWebView and point it to remote URL and then you're done? PETE: I did that once. CHUCK: All the games that I play, I have to turn the sound off on them. PETE: I actually did do that once, Ben. BEN: Yes, it's the quick and easy way to do it. PETE: Yup, it was surprisingly good. I discovered, we're going to jump straight into rearcane pit of noise, but didn't let you do "Autoplay" on video; Apple doesn't want you to do that. Can you still not do that if you're using native video? BEN: You can do whatever you want with the native stuff. PETE: Okay. So for the web one, you can't. But this -- BEN: I think it's just kind of the Safari limitation... PETE: Yeah [chuckles]. CHUCK: Every browser should do that. That rise me asked, too. PETE: I think they say it's a battery issue more than anything else like they don't want you firing up the radio to download like 50 maybe, to start offering conserve concept. BEN: Yeah, they have gotten a little bit more strict on the rules for that, and I don't remember the exact numbers off the top of my head.

Panel Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:18 - Interface Builder 01:55 - Custom-designed interfaces 02:32 - Tips and Tricks 03:04 - Interface Builder Buttons and Functions File’s Owner First Responder The Responder Chain Events/Actions Objects Elements Views Outlet Storyboards Segues/Segways 09:39 - Cons of Using Interface Builder Team Environments 13:13 - Custom Work Writing a custom UI 14:52 - Controllers GLKit Table View 19:09 - Static Cells and Storyboards 21:23 - Dynamic Prototypes and Prototype Cells 23:23 - Getting a Table View Cell into the Table View 24:48 - Rod’s Apps Numerology Numerology Baby Namer 25:29 - Rejection from the App Store 27:50 - Gestures 30:19 - Calendar View Picks NSBrief: Episode #97: Jon Reid (Rod) Ember.js (Rod) Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement by Jim R. Wilson (Chuck) Eventbrite (Chuck) Next Week Audio and Video in Apps Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 9 of iPhreaks! This week on our panel, we have Rod Schimdt. ROD: Hello from Salt Lake City! CHUCK: And I'm Charles Max Wood from DevChat.tv. And due to a little bit of a scheduling snafu, it's just the two of us today! So, you get to hear more from us. ROD: Yeah, if I ain't got a chance to talk. CHUCK: Yeah. I think Pete and Ben and I all suffer from the same "we like to hear ourselves talk" and we always have something to say [laughs]. ROD: [chuckles] Alright! CHUCK: Anyway, let's get this started. Our scheduled topic today is "Interface Builder and Storyboards", which is something that I've actually played with a little bit - all the time. ROD: And do you have questions about it? Or, issues you want to talk about it? CHUCK: Not really. I mean I haven't done anything too complicated with it. And for the most part, you drag the Elements out there; you link them up with the actions on your ViewController, and it just kind of works! ROD: Okay. So you just want to talk about how they work and what you can do with them? CHUCK: Yeah, I'm sure I'll have questions. I guess one question right off the bat is what if you have some kind of like custom-designed interface? Can you do that with Storyboards or Interface Builder? ROD: Not really. Interface Builder are designed for most of the built-in controls. When you want to do custom work, you basically just put a View out there, set its class, and then you have to write all the custom code for that class. CHUCK: Oh, interesting. ROD: There the step on how you do it. So, if you're doing a lot of custom work, it's mostly good for just laying out the basic structure of your user interface, and then you go from there. CHUCK: Nice. I'm looking at it here; I actually pulled it up so I could actually look at it and ask you questions about it. But before we get into that, are there any tricks that you use to make it easier to reason with? ROD: What do you mean by reason with? CHUCK: Well just, are there any things that make Interface Builder easier to use that you do? ROD: No.

Panel Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:18 - Interface Builder 01:55 - Custom-designed interfaces 02:32 - Tips and Tricks 03:04 - Interface Builder Buttons and Functions File's Owner First Responder The Responder Chain Events/Actions Objects Elements Views Outlet Storyboards Segues/Segways 09:39 - Cons of Using Interface Builder Team Environments 13:13 - Custom Work Writing a custom UI 14:52 - Controllers GLKit Table View 19:09 - Static Cells and Storyboards 21:23 - Dynamic Prototypes and Prototype Cells 23:23 - Getting a Table View Cell into the Table View 24:48 - Rod's Apps Numerology Numerology Baby Namer 25:29 - Rejection from the App Store 27:50 - Gestures 30:19 - Calendar View Picks NSBrief: Episode #97: Jon Reid (Rod) Ember.js (Rod) Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement by Jim R. Wilson (Chuck) Eventbrite (Chuck) Next Week Audio and Video in Apps Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 9 of iPhreaks! This week on our panel, we have Rod Schimdt. ROD: Hello from Salt Lake City! CHUCK: And I'm Charles Max Wood from DevChat.tv. And due to a little bit of a scheduling snafu, it's just the two of us today! So, you get to hear more from us. ROD: Yeah, if I ain't got a chance to talk. CHUCK: Yeah. I think Pete and Ben and I all suffer from the same "we like to hear ourselves talk" and we always have something to say [laughs]. ROD: [chuckles] Alright! CHUCK: Anyway, let's get this started. Our scheduled topic today is "Interface Builder and Storyboards", which is something that I've actually played with a little bit - all the time. ROD: And do you have questions about it? Or, issues you want to talk about it? CHUCK: Not really. I mean I haven't done anything too complicated with it. And for the most part, you drag the Elements out there; you link them up with the actions on your ViewController, and it just kind of works! ROD: Okay. So you just want to talk about how they work and what you can do with them? CHUCK: Yeah, I'm sure I'll have questions. I guess one question right off the bat is what if you have some kind of like custom-designed interface? Can you do that with Storyboards or Interface Builder? ROD: Not really. Interface Builder are designed for most of the built-in controls. When you want to do custom work, you basically just put a View out there, set its class, and then you have to write all the custom code for that class. CHUCK: Oh, interesting. ROD: There the step on how you do it. So, if you're doing a lot of custom work, it's mostly good for just laying out the basic structure of your user interface, and then you go from there. CHUCK: Nice. I'm looking at it here; I actually pulled it up so I could actually look at it and ask you questions about it. But before we get into that, are there any tricks that you use to make it easier to reason with? ROD: What do you mean by reason with? CHUCK: Well just, are there any things that make Interface Builder easier to use that you do? ROD: No.

Panel Ben Lachman (twitter blog) Pete Hodgson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Ben Scheirman (twitter github blog NSSreencast) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:30 - Ben Lachman Introduction Acacia Tree Software Nice Mohawk SousChef Ita 03:12 - Prototyping and Mockup Tools Adobe Photoshop Pen and Paper Forecast Interface Builder Balsamiq Mockingbird Keynote Kung-Fu Graffletopia: OmniGraffle Stencils Prototypes 15:25 - What makes a good prototype 18:04 - Building a good prototype Make a prototype; not a concept Start with pen and paper 19:39 - Issues that prototyping helps you identify Discoverability Features Visibility Features 20:11 - Solving issues and sharing prototypes with clients Usability Testing Screenshots Briefs 2 27:52 - Laying out your application Code Spikes 32:43 - Prototyping for Clients 35:29 - Building Prototypes in HTML Briefs 2 37:34 - Using iPads/etc. instead of pen and paper Paper SketchBook Pro 39:09 - Buttons Picks iPhone Stencil Kit (Ben) Play by Play: Neven Mrgan | PeepCode Screencasts (Ben) Skala Preview (Ben) Xscope (Ben) UI Stencils - iPhone Sketch Pad (Rod) Screen Time (Rod) iPhone Stamp for UI Sketching - The Russians Used a Pencil (Pete) POP - Prototyping on Paper (Pete) PocketCasts (Pete) Spaced (Pete) iOctocat (Chuck) ioctocat on GitHub (Chuck) Briefs 2 (Ben L) Coworking (Ben L) Paint Code (Ben L) Bow Truss (Ben L) Next Week Interface Builder Transcript PETE: I’m trying to decide who I would rather work for... [Chuck laughs] PETE: That mob would be more interesting, but probably a little bit more scary. [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 8 of iPhreaks! This week on our panel, we have Pete Hodgson. PETE: Hello! I'm so impressed with Charles Max Wood newest episode with or without any thinking, well done! CHUCK: I looked it up beforehand. [Pete chuckles] CHUCK: Rod Schimdt. ROD: Hello from Salt Lake! CHUCK: Ben Scheirman. BEN: Hello from hot and humid Houston! CHUCK: I'm Charles Max Wood from DevChat.tv. And we have a special guest today, and that's Ben, is it Lachman? BEN L: Yes, it is! And hello from Athens, Ohio, which is also hot and humid! Probably not as hot as Houston.. CHUCK: So you want to introduce yourself really quickly? BEN L: Yeah! I've been around the Mac and iOS dev world for about 10 or 12 years at this point; actually, I guess that would be before the iOS dev world really was around. And I write software for a couple of companies of my own. One is "Acacia Tree Software", and the other is newer and I started with a business partner in Cleveland, Ohio named Bob Cantoni and it's called "Nice Mohawk". So yeah, we write some iOS software, some Mac software, and we do contract work as well. CHUCK: Awesome. I'm a little curious before we get into what we're going to talk about, how much iOS and Mac stuff do you write as products that you sell versus client stuff that you do for other people? BEN L: We've done a fairly good job, for like a two-man shop,

Panel Ben Lachman (twitter blog) Pete Hodgson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Ben Scheirman (twitter github blog NSSreencast) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:30 - Ben Lachman Introduction Acacia Tree Software Nice Mohawk SousChef Ita 03:12 - Prototyping and Mockup Tools Adobe Photoshop Pen and Paper Forecast Interface Builder Balsamiq Mockingbird Keynote Kung-Fu Graffletopia: OmniGraffle Stencils Prototypes 15:25 - What makes a good prototype 18:04 - Building a good prototype Make a prototype; not a concept Start with pen and paper 19:39 - Issues that prototyping helps you identify Discoverability Features Visibility Features 20:11 - Solving issues and sharing prototypes with clients Usability Testing Screenshots Briefs 2 27:52 - Laying out your application Code Spikes 32:43 - Prototyping for Clients 35:29 - Building Prototypes in HTML Briefs 2 37:34 - Using iPads/etc. instead of pen and paper Paper SketchBook Pro 39:09 - Buttons Picks iPhone Stencil Kit (Ben) Play by Play: Neven Mrgan | PeepCode Screencasts (Ben) Skala Preview (Ben) Xscope (Ben) UI Stencils - iPhone Sketch Pad (Rod) Screen Time (Rod) iPhone Stamp for UI Sketching - The Russians Used a Pencil (Pete) POP - Prototyping on Paper (Pete) PocketCasts (Pete) Spaced (Pete) iOctocat (Chuck) ioctocat on GitHub (Chuck) Briefs 2 (Ben L) Coworking (Ben L) Paint Code (Ben L) Bow Truss (Ben L) Next Week Interface Builder Transcript PETE: I'm trying to decide who I would rather work for... [Chuck laughs] PETE: That mob would be more interesting, but probably a little bit more scary. [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.] CHUCK: Hey everybody and welcome to Episode 8 of iPhreaks! This week on our panel, we have Pete Hodgson. PETE: Hello! I'm so impressed with Charles Max Wood newest episode with or without any thinking, well done! CHUCK: I looked it up beforehand. [Pete chuckles] CHUCK: Rod Schimdt. ROD: Hello from Salt Lake! CHUCK: Ben Scheirman. BEN: Hello from hot and humid Houston! CHUCK: I'm Charles Max Wood from DevChat.tv. And we have a special guest today, and that's Ben, is it Lachman? BEN L: Yes, it is! And hello from Athens, Ohio, which is also hot and humid! Probably not as hot as Houston.. CHUCK: So you want to introduce yourself really quickly? BEN L: Yeah! I've been around the Mac and iOS dev world for about 10 or 12 years at this point; actually, I guess that would be before the iOS dev world really was around. And I write software for a couple of companies of my own. One is "Acacia Tree Software", and the other is newer and I started with a business partner in Cleveland, Ohio named Bob Cantoni and it's called "Nice Mohawk". So yeah, we write some iOS software, some Mac software, and we do contract work as well. CHUCK: Awesome. I'm a little curious before we get into what we're going to talk about, how much iOS and Mac stuff do you write as products that you sell versus client stuff that you do for other people? BEN L: We've done a fairly good job, for like a two-man shop,

In this episode, Chad discusses how he broke out of a comfortable job as a forklift operator, which ultimately led to him becoming a programmer. He discusses his job, Ruby Central, and the Pragmatic Studio as contributions he makes to the community. We also discuss the ebb and flow of passion for programming and how to avoid burnout on the things that we love. He has actually put a ban on himself for travel so he can spend time on the things that are important. Chad told me that he espouses the Test Driven Development mindset, Continuous Integration, and Agile or dynamic methodologies. We discuss task automation, Puppet, Chef, etc. The important things in software development boil down to quality. If you can automate your common, important tasks and make it easy for the person who needs it to kick off the process on their own. Chad also had some great suggestions for new developers. First, read code. Second, write tests for the areas of code that don't have tests. This will force you to refactor the code and make it better. To get involved in the community, you can start or organize a conference, create open source projects, help software maintainers meet Ruby 1.9 compatibility issues, join a mailing list, and so much more… Download this Episode

Mike and I talk about the Rails Edge and some of the other conferences that he is involved with.  Not only does he run a great conference he participated in several of the talks and is a Rails Developer himself.  This was my first Ruby/Rails specific event and it will not be the last.This was the last of a series of recordings that I made at Rails Edge.  I will be releasing the others over time.You can get more information at http://pragmaticstudio.com/therailsedge/See you at RailsConf...-bob