POPULARITY
4 episodes with panel there
4 episodes with panel there
3 episodes with panel there
2 episodes with panel there
11 episodes with panel there
Panel: Eric Berry Charles Max Wood Nate Hopkins Special Guest: Paul Smith and Andrew Mason In this episode of Ruby Rogues, the panelists talk with Paul Smith and Andrew Mason! They discuss the platforms Lucky and Crystal. Other topics include: Ruby, Phoenix, Laravel Mix, Thoughtbot, Webpack, compilers, and much more! Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:02 – Chuck: Welcome!! Eric Berry, Nate Hopkins, and myself are the panel - and our special guests are Paul Smith and Andrew Mason. Introduce yourself! 1:41 – Andrew / Guest: I have messed with every type of language, so there’s that! 1:55 – Paul / Guest: I have been here at my current company for 5 years and it’s a consultancy firm. I have been working on Crystal. 2:14 – Chuck: We are lucky to have you! Give people the elevator pitch for Lucky and Crystal? 2:33 – Guest: Let’s talk about Crystal and looks very similar to Ruby! It’s faster and it’s a compound language. It catches a fair amount of things at compile time. The other special features are... 4:17 – Guest mentions compilers. 4:23 – Chuck: Yeah we see this in the typescript. Is it language service – is that what it’s called? Pile and compile and all of this checking are a nice stage for it to run-through. Although the flipside is coding and to not worry about that – that’s nice! 4:56 – Guest: It has changed my approach for sure. 5:43 – Panel: How much slower are you? 5:54 – Guest: I am a lot faster in Crystal than I am in Ruby. 6:51 – Panel: Yeah you have to figure out where you want to save the time. 7:00 – Guest: Someone wrote a blog post and it said...the Rails service is like bolting a shelf on a wall and hoping to hit a stud and it’s not solid. But using Lucky it’s sold although it took a little longer. I think it can be true. You can do bad things with compilers, though. It depends on how you use it. 7:43 – Panelist asks a question. 7:53 – Guest: Every Friday is an investment day. Lucky is my “whatever I want thing.” I am technically getting paid to work on it. 8:33 – Panel: have you had to battle with the framework? 8:51 – Guest: Yes, even though Crystal looks like Ruby (at a high level) if you want to do it well you have to approach it in the Crystal-way. When I came to Crystal I came to it like Rails. The problem with that is I wanted to have type-saved parameters – you can’t do that in Crystal b/c...it doesn’t know when to have a parameter with... 10:48 – Panel: I have heard you talk about Crystal before on another podcast. You talked about templating and I am curious to hear about that. I have used Slim and others and now stick to ERB. 11:25 – Guest: Yes definitely. Let’s back up and talk about WHAT Lucky does! The guest talks about Rails, escaping, and more! 14:37 – Panel: So I imagine Rails partials are slow and expensive to render. I would imagine that this approach with Lucky... 15:00 – Guest: Yes exactly. It’s extremely fast! 15:20 – Panel: How is this for designers? 15:30 – Guest: Yes that was a concern of mine. With Lucky I tried to make it close to a regular HTML structure would look like! 16:32 – Panel: I spun up a Lucky app the other day. It looks like you are using... 16:50 – Guest: I have played around with a bunch of stuff. I landed on Laravel Mix. 18:27 – Panel: Yes webpack is a pain to set up and it’s hard to get it to working the way you want it to work. 18:47 – Guest: Yeah if you want React or whatever it will generate the configuration you need. I don’t like it b/c if you want to... 19:28 – Panel. 19:45 – Guest: I don’t want to maintain it. 19:54 – Panel: There is a Crystal community in Utah. I want to know – are you competing with Amber? Explain the difference between Lucky and Amber? 20:20 – Guest: Yes I did look at Amber but they are approaching it differently than us. The guest talks about the differences between Amber and Lucky. 21:54 – Guest (continues): With Lucky you will have to learn a little bit more but you get more of a pack! 23:23 – Panel: It sounds like Lucky is inspired by Elm – right? 23:32 – Guest: Yeah, I think so. The guest dives into this topic of Elm and Lucky! 24:35 – Panel: How much does the types feel like it’s getting in your way? How explicit is it? When I came to Ruby it was a breath of fresh air. I am a bit reluctant to go back to those days. 25:25 – Guest: I think Lucky does a happy medium. It doesn’t infer instant variables. I like the... 26:28 – Panel: I learned Java very early on in my computer science career. 27:00 – Guest. 27:10 – Panel: “Crystal...it’s not Java!” That should be your slogan! 27:20 – Fresh Books! 28:25 – Panel: A lot of people are moving to Elixir community. Do you see people moving from Ruby to Lucky and Crystal? How does Lucky compare to Phoenix? 28:55 – Guest: Good question! 29:10 – The guest talks about bamboo – see links below!! 29: 29 – Guest: Sure Ruby is fast but sometimes you spend more time on it then you would want to. 31:08 – Guest: Blessing and curse that Crystal looks so much like Ruby. That’s what I thought at first: why would I want to learn this if it’s so similar to Ruby. BUT there are so many benefits to Crystal vs. Ruby. 31:48 – Guest talks about Lucky catching the bugs. 32:00 – Panel: I wonder if that happened with Groovy and Rails? 32:21 – They go back-and-forth. 32:28 – Panel: Thoughtbot has always been on the forefront of Ruby. Can you talk about Thoughbot please? (See links below for Thoughtbot!) 33:15 – Guest: Great question. It’s hard to tell b/c there are different offices. I would say Ruby is our main thing. Ruby is the most mature thing that we use in-terms of web development. Guest: Actually – Rails is pretty nice! 34:54 – Panel: We went through the same thing with CodeFund! I wrote it initially in Python and then I wrote it in Elixir and it became so complex. Now we are moving everything back to Ruby and it’s been a fantastic decision. 36:30 – Chuck: You are talking about the sustainability of open source but there are benefits throughout the company right? There are tons of tangible benefits of doing it, especially when it’s your Friday schedule. You can level-up on things that could help you. I know a lot of companies cannot afford it if they are trying to hustle. 37:42 – Guest: It’s totally not charity through Thoughtbot. It’s a huge help for hiring new people. I know they are okay with letting me work on Lucky b/c it’s bringing on new developers and a good marketing tool, and finally recruiting! 39:07 – Chuck: Yeah, I have been talking about developer freedom and that’s what I am addressing through the DevRev show! It’s my new podcast show. We talk with Chris on Elixir Mix. It lends that credibility if they need to save our bacon. 40:02 – Panel: What’s your goal with Lucky? 40:11 – Guest: I would love to get it to the point where Thoughtbot could start a project and default to Lucky! Start a project and not resting every gem and be confident with launching it. 41:36 – Panelist asks a question. 41:45 – Guest: It’s not 1.0 and that means that the API will break with every release. I think that’s good to tweak stuff but that turns companies off, though. 42:40 – Chuck: Another thing that helps with adoption is Twitter used Rails to build their initial version. This blah, blah company uses important stuff and they are using Crystal and whatnot then that’s good! It sounds like you are waiting for social proof. 43:23 – Guest: Is the next Twitter going to even know about Crystal? 43:40 – Chuck: It literally only takes one enthusiast! 43:52 – Guest. 44:11 – Demo of Flickr Search is mentioned here! 45:13 – Panel: Is there something out there that you could POINT someone to? 45:27 – Guest: Not, yet. I built a small site with it! It is opensource and you can look at it. I want to show people a good example of what Lucky can do! 45:57 – Panel: You have very good docs and I am a visual learner. When I learned Rails I learned on my own and not through school. 46:20 – Panelist asks a question. 46:48 – Guest: What a huge advantage Lucky has through the Thoughtbot platform! Now that platform is kind of dried up. In terms of getting people excited it needs that killer app and they can see that it’s fast and killer! I think it takes a lot of time and finding time to do it so that’s tricky. It’s changing a lot when there is so much change. Getting Lucky to a 1.0 state so people can do videos and make apps. The hard part thing is that Lucky has to be 1.0 when Crystal is 1.0. The Lucky community is great b/c it’s encouraging and to respond in a very kind way. When you are starting something that’s new can be scary. We try to help out as much as we can and we are open and kind about it. 49:13 – Panel: “Paul is nice so Lucky is nice!” 49:19 – Guest: Everyone is super kind. It had to be short and simple. We in the dev community are very lucky – usually great pay/benefits and more w/o a college degree. What another field can you do that?! 51:00 – Panel: Great message and you need to push that! 51:10 – Panel: You were on a past podcast and you talked about how you are donating each month! Panel: Opensource maintainers are getting burned out and you want to support that. 51:40 – Guest: I think opensource sustainability what others need to do to make it sustainable. If you have the means to give we can be apart of that, too. It would be nice if companies did that. If it helps Crystal I am happy. 52:17 – Panel: I have a question about Crystal. 52:52 – Guest: Ruby right now you can do C sections right now. 53:01 – Panel. 53:10 – Guest: I don’t think so – it may but I would guess that you could do it but I don’t know how easy it would be. Note: Rust and C are mentioned. 53:37 – Panel comments. 53:46 – Guest: One thing I would say is to check-out the Lucky docs. We are happy to help! 54:10 – Panel: This is a favorite episode of mine! Both of today’s guests have been my favorite! 54:23 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course The DevRev Podcast Show DevChat TV Ruby Elixir Ruby on Rails Angular Cypress Vue React Jest.io Mocha.js Webpacker-Cli Amber Lucky The Lucky Philosophy The Bike Shed Thoughtbot CodeFund Lucky: Ruby on Rails to Lucky on Crystal... “Crystal is not Ruby Part 1” GitHub: Bamboo Ex_Machina Dialyxir Crystal Mastery Samsung T5 Carbon Copy Cloner iMazing Awesome-Lucky Paul Smith GitHub Sponsors: Sentry CacheFly Fresh Books Picks: Nate Samsung SSD Carbon Copy Cloner Application Eric iMazing HEIC Converter Charles Mastodon Andrew Upcase by Thoughtbot Awesome Lucky Paul Tailwind CSS Phoenix Live HTML Chris McCord Elixir Mix Episodes with Chris McCord
Panel: Lucas Reis Charles Max Wood Justin Bennett Special Guest: Soumyajit Pathak In this episode, the panelists talk with Soumyajit Pathak (India) who is a full-stack developer and cybersecurity enthusiast. The panel and the guest talk about design patterns and designing simpler code for clarity and less confusion. Check out today’s episode! Show Topics: 0:00 – Kendo UI 0:31 – Chuck: Our panelists are and our guest is Soumyajit! Introduce yourself please! Are you doing React on the side? 1:02 – Guest: I am a master’s student and I am doing freelancing. 1:42 – Panel. 1:49 – Guest. 2:10 – Chuck: I am feeling very up-to-date. Woo! Universities are teaching this and that and they are focused on theory. The flipside is that they are going to write real code for real systems. 3:10 – Panel: I like your well-written blog posts. You talk about design patterns. 3:50 – Guest: The design patterns at the university had to do with real JavaScript applications. 4:09 – Chuck: I am curious you are talking about the design patterns – how can people from React find/use it? 4:45 – Panel: It depends on your definition of design patterns. 5:35 – Lucas: Maybe you are using one or two here and reading through the design patterns is like going through your toolbox. You only need a screwdriver but you bought the whole toolbox. Get familiar with it and from time to time solve problems and thing: what tool can help me here? It’s clear to me with this toolbox analogy. I understand now – that tool I saw 2 months ago could help me. 7:00 – Guest: I have an interesting story with this about design patterns. Let me share! 7:36 – Justin: It was a similar thing but I wasn’t in JavaScript at the time. I’ve used a lot of C++ code. Design patterns became very useful. I saw it the same way Lucas! 9:23 – Justin continues: How and why to use a certain tool. That’s important. 10:28 – Chuck: Okay this is the default pattern and that’s where we can go for the fallback. Here is the fallback if this doesn’t work here or there. 10:49 – Lucas: This is important to remember. It’s not how to use the tool but it’s why am I using this tool here or there? 11:57 – Justin: It’s so much information in general. People get information overload and they have to just start! One of the challenges we do is that we over-engineer things. Do what you need to know. Look it up but play with it. 12:40 – Lucas: It’s interesting by another blog post that you wrote Soumyajit – and you are using a render prop. You showed a problem and showed the solution. 13:30 – Guest: Yeah I’ve written a lot of blog posts about this topic. 13:48 – Panel: Often times – it’s hard for people just to dive-in. People need to see you solving a problem and it really helps with the learning process. 15:03 – Chuck: What patterns do you find most useful? 15:11 – Panel: Functional components have changed my world! 16:23 – Guest: Around these functional components... 17:17 – Panel: I will go with the patterns that are not useful. Don’t make your code pattern-oriented. This is my favorite pattern now and going back to basics. 18:53 – Panelists go back-and-forth. 19:01 – Lucas. 19:41 – Chuck: You talk about over-engineering things and that’s what I found myself doing sometimes with my new project. When I figure out how to make it simpler I get excited and it’s easy to follow. 20:15 – Panel: We celebrate the person who deleted the most lines of code. 20:28 – Panel: I am going to steal that idea. 21:04 – Guest: I have an interesting story of over-engineering something – let me share! 21:53 – FreshBooks! 22:59 – Panel: Building too much is b/c I don’t have a clear understanding of what I am doing. I get excited about problems. What’s the more simple way / most naïve way possible! 24:36 – Lucas: If you are going to change something you will be changing it in several different places. 25:50 – Chuck: When I heard the concept, all the codes that change together should be together. 26:08 – Lucas comments. 26:53 – Panel: Keeping things contained in one place. We have our presentational component and higher-level component, so you can see it all. 28:28 – Lucas: Different people working on different technologies. 29:15 – Panel: Can I break this down to smaller parts, which makes sense to me? 29:48 – Guest: Looking for keywords will cause a distraction. Finding a balance is good. 30:04 – Chuck: If you have a large rile there could be a smaller component that is there own concern. That feels like the real answer to me. It has a lot less than the length of the file versus... Chuck: If I cannot follow it then I need to keep the concept simple. 30:51 – Lucas: The quantity of lines and the line count – I think it’s better how many indentations you have. 32:43 – Guest. 32:48 – Lucas: Yes, so in the horizontal scrolling you have to keep things in your mind. 33:41 – Panel: There are so many different metrics that you can use and the different line count or different characters. There are more scientific terms that we could plugin here. If you have a lot of these abstract relations that can...write it 34:23 – Chuck: So true. 34:52 – Chuck: I want to move onto a different problem so it’s an attention thing for me too. 35:06 – Panel: We have to get okay with not always writing the best code in that it just needs to do what it needs to do. 35:30 – Chuck. 35:57 – Panel: We write it once – then it falls apart and then we write it again and learn from the process. Learning is the key here – you see where it works and where it doesn’t work well. 36:31 – Panel. 36:47 – Chuck mentions service-side rendering. Chuck: Should we schedule another episode? 37:11 – Panel: I think it’s own episode b/c it’s a complex problem overall. 39:33 – Lucas: Try to find memory leaks in the file components and server-side rendering. Where we have lost a lot of sleep and a higher level of complication. Sometimes it’s necessary. 41:42 – Chuck: Yeah let’s do another episode on this topic. Sounds like there is a lot to dive into this topic. Soumyajit, how do people find you? 42:10 – Guest: Twitter and GitHub! 42:28 – Picks! 42:30 – Advertisement – Get A Coder Job! End – Cache Fly Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub Get A Coder Job React Patterns on GitHub Calibre Book: Engineering a Safer World Designers’ Secret Source Monster Hunter Guest’s GitHub Guest’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI Picks: Justin https://reactpatterns.com/ Calibre App Lucas Engineering a Safer World Soumyajit Blog Muzli - Chrome Extension Charles Monster Hunters International Series Metabase Stripe Work for DevChat TV
Panel: Eric Berry Charles Max Wood Nate Hopkins Special Guest: Paul Smith and Andrew Mason In this episode of Ruby Rogues, the panelists talk with Paul Smith and Andrew Mason! They discuss the platforms Lucky and Crystal. Other topics include: Ruby, Phoenix, Laravel Mix, Thoughtbot, Webpack, compilers, and much more! Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:02 – Chuck: Welcome!! Eric Berry, Nate Hopkins, and myself are the panel - and our special guests are Paul Smith and Andrew Mason. Introduce yourself! 1:41 – Andrew / Guest: I have messed with every type of language, so there’s that! 1:55 – Paul / Guest: I have been here at my current company for 5 years and it’s a consultancy firm. I have been working on Crystal. 2:14 – Chuck: We are lucky to have you! Give people the elevator pitch for Lucky and Crystal? 2:33 – Guest: Let’s talk about Crystal and looks very similar to Ruby! It’s faster and it’s a compound language. It catches a fair amount of things at compile time. The other special features are... 4:17 – Guest mentions compilers. 4:23 – Chuck: Yeah we see this in the typescript. Is it language service – is that what it’s called? Pile and compile and all of this checking are a nice stage for it to run-through. Although the flipside is coding and to not worry about that – that’s nice! 4:56 – Guest: It has changed my approach for sure. 5:43 – Panel: How much slower are you? 5:54 – Guest: I am a lot faster in Crystal than I am in Ruby. 6:51 – Panel: Yeah you have to figure out where you want to save the time. 7:00 – Guest: Someone wrote a blog post and it said...the Rails service is like bolting a shelf on a wall and hoping to hit a stud and it’s not solid. But using Lucky it’s sold although it took a little longer. I think it can be true. You can do bad things with compilers, though. It depends on how you use it. 7:43 – Panelist asks a question. 7:53 – Guest: Every Friday is an investment day. Lucky is my “whatever I want thing.” I am technically getting paid to work on it. 8:33 – Panel: have you had to battle with the framework? 8:51 – Guest: Yes, even though Crystal looks like Ruby (at a high level) if you want to do it well you have to approach it in the Crystal-way. When I came to Crystal I came to it like Rails. The problem with that is I wanted to have type-saved parameters – you can’t do that in Crystal b/c...it doesn’t know when to have a parameter with... 10:48 – Panel: I have heard you talk about Crystal before on another podcast. You talked about templating and I am curious to hear about that. I have used Slim and others and now stick to ERB. 11:25 – Guest: Yes definitely. Let’s back up and talk about WHAT Lucky does! The guest talks about Rails, escaping, and more! 14:37 – Panel: So I imagine Rails partials are slow and expensive to render. I would imagine that this approach with Lucky... 15:00 – Guest: Yes exactly. It’s extremely fast! 15:20 – Panel: How is this for designers? 15:30 – Guest: Yes that was a concern of mine. With Lucky I tried to make it close to a regular HTML structure would look like! 16:32 – Panel: I spun up a Lucky app the other day. It looks like you are using... 16:50 – Guest: I have played around with a bunch of stuff. I landed on Laravel Mix. 18:27 – Panel: Yes webpack is a pain to set up and it’s hard to get it to working the way you want it to work. 18:47 – Guest: Yeah if you want React or whatever it will generate the configuration you need. I don’t like it b/c if you want to... 19:28 – Panel. 19:45 – Guest: I don’t want to maintain it. 19:54 – Panel: There is a Crystal community in Utah. I want to know – are you competing with Amber? Explain the difference between Lucky and Amber? 20:20 – Guest: Yes I did look at Amber but they are approaching it differently than us. The guest talks about the differences between Amber and Lucky. 21:54 – Guest (continues): With Lucky you will have to learn a little bit more but you get more of a pack! 23:23 – Panel: It sounds like Lucky is inspired by Elm – right? 23:32 – Guest: Yeah, I think so. The guest dives into this topic of Elm and Lucky! 24:35 – Panel: How much does the types feel like it’s getting in your way? How explicit is it? When I came to Ruby it was a breath of fresh air. I am a bit reluctant to go back to those days. 25:25 – Guest: I think Lucky does a happy medium. It doesn’t infer instant variables. I like the... 26:28 – Panel: I learned Java very early on in my computer science career. 27:00 – Guest. 27:10 – Panel: “Crystal...it’s not Java!” That should be your slogan! 27:20 – Fresh Books! 28:25 – Panel: A lot of people are moving to Elixir community. Do you see people moving from Ruby to Lucky and Crystal? How does Lucky compare to Phoenix? 28:55 – Guest: Good question! 29:10 – The guest talks about bamboo – see links below!! 29: 29 – Guest: Sure Ruby is fast but sometimes you spend more time on it then you would want to. 31:08 – Guest: Blessing and curse that Crystal looks so much like Ruby. That’s what I thought at first: why would I want to learn this if it’s so similar to Ruby. BUT there are so many benefits to Crystal vs. Ruby. 31:48 – Guest talks about Lucky catching the bugs. 32:00 – Panel: I wonder if that happened with Groovy and Rails? 32:21 – They go back-and-forth. 32:28 – Panel: Thoughtbot has always been on the forefront of Ruby. Can you talk about Thoughbot please? (See links below for Thoughtbot!) 33:15 – Guest: Great question. It’s hard to tell b/c there are different offices. I would say Ruby is our main thing. Ruby is the most mature thing that we use in-terms of web development. Guest: Actually – Rails is pretty nice! 34:54 – Panel: We went through the same thing with CodeFund! I wrote it initially in Python and then I wrote it in Elixir and it became so complex. Now we are moving everything back to Ruby and it’s been a fantastic decision. 36:30 – Chuck: You are talking about the sustainability of open source but there are benefits throughout the company right? There are tons of tangible benefits of doing it, especially when it’s your Friday schedule. You can level-up on things that could help you. I know a lot of companies cannot afford it if they are trying to hustle. 37:42 – Guest: It’s totally not charity through Thoughtbot. It’s a huge help for hiring new people. I know they are okay with letting me work on Lucky b/c it’s bringing on new developers and a good marketing tool, and finally recruiting! 39:07 – Chuck: Yeah, I have been talking about developer freedom and that’s what I am addressing through the DevRev show! It’s my new podcast show. We talk with Chris on Elixir Mix. It lends that credibility if they need to save our bacon. 40:02 – Panel: What’s your goal with Lucky? 40:11 – Guest: I would love to get it to the point where Thoughtbot could start a project and default to Lucky! Start a project and not resting every gem and be confident with launching it. 41:36 – Panelist asks a question. 41:45 – Guest: It’s not 1.0 and that means that the API will break with every release. I think that’s good to tweak stuff but that turns companies off, though. 42:40 – Chuck: Another thing that helps with adoption is Twitter used Rails to build their initial version. This blah, blah company uses important stuff and they are using Crystal and whatnot then that’s good! It sounds like you are waiting for social proof. 43:23 – Guest: Is the next Twitter going to even know about Crystal? 43:40 – Chuck: It literally only takes one enthusiast! 43:52 – Guest. 44:11 – Demo of Flickr Search is mentioned here! 45:13 – Panel: Is there something out there that you could POINT someone to? 45:27 – Guest: Not, yet. I built a small site with it! It is opensource and you can look at it. I want to show people a good example of what Lucky can do! 45:57 – Panel: You have very good docs and I am a visual learner. When I learned Rails I learned on my own and not through school. 46:20 – Panelist asks a question. 46:48 – Guest: What a huge advantage Lucky has through the Thoughtbot platform! Now that platform is kind of dried up. In terms of getting people excited it needs that killer app and they can see that it’s fast and killer! I think it takes a lot of time and finding time to do it so that’s tricky. It’s changing a lot when there is so much change. Getting Lucky to a 1.0 state so people can do videos and make apps. The hard part thing is that Lucky has to be 1.0 when Crystal is 1.0. The Lucky community is great b/c it’s encouraging and to respond in a very kind way. When you are starting something that’s new can be scary. We try to help out as much as we can and we are open and kind about it. 49:13 – Panel: “Paul is nice so Lucky is nice!” 49:19 – Guest: Everyone is super kind. It had to be short and simple. We in the dev community are very lucky – usually great pay/benefits and more w/o a college degree. What another field can you do that?! 51:00 – Panel: Great message and you need to push that! 51:10 – Panel: You were on a past podcast and you talked about how you are donating each month! Panel: Opensource maintainers are getting burned out and you want to support that. 51:40 – Guest: I think opensource sustainability what others need to do to make it sustainable. If you have the means to give we can be apart of that, too. It would be nice if companies did that. If it helps Crystal I am happy. 52:17 – Panel: I have a question about Crystal. 52:52 – Guest: Ruby right now you can do C sections right now. 53:01 – Panel. 53:10 – Guest: I don’t think so – it may but I would guess that you could do it but I don’t know how easy it would be. Note: Rust and C are mentioned. 53:37 – Panel comments. 53:46 – Guest: One thing I would say is to check-out the Lucky docs. We are happy to help! 54:10 – Panel: This is a favorite episode of mine! Both of today’s guests have been my favorite! 54:23 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course The DevRev Podcast Show DevChat TV Ruby Elixir Ruby on Rails Angular Cypress Vue React Jest.io Mocha.js Webpacker-Cli Amber Lucky The Lucky Philosophy The Bike Shed Thoughtbot CodeFund Lucky: Ruby on Rails to Lucky on Crystal... “Crystal is not Ruby Part 1” GitHub: Bamboo Ex_Machina Dialyxir Crystal Mastery Samsung T5 Carbon Copy Cloner iMazing Awesome-Lucky Paul Smith GitHub Sponsors: Sentry CacheFly Fresh Books Picks: Nate Samsung SSD Carbon Copy Cloner Application Eric iMazing HEIC Converter Charles Mastodon Andrew Upcase by Thoughtbot Awesome Lucky Paul Tailwind CSS Phoenix Live HTML Chris McCord Elixir Mix Episodes with Chris McCord
Panel: Eric Berry Charles Max Wood Nate Hopkins Special Guest: Paul Smith and Andrew Mason In this episode of Ruby Rogues, the panelists talk with Paul Smith and Andrew Mason! They discuss the platforms Lucky and Crystal. Other topics include: Ruby, Phoenix, Laravel Mix, Thoughtbot, Webpack, compilers, and much more! Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:02 – Chuck: Welcome!! Eric Berry, Nate Hopkins, and myself are the panel - and our special guests are Paul Smith and Andrew Mason. Introduce yourself! 1:41 – Andrew / Guest: I have messed with every type of language, so there’s that! 1:55 – Paul / Guest: I have been here at my current company for 5 years and it’s a consultancy firm. I have been working on Crystal. 2:14 – Chuck: We are lucky to have you! Give people the elevator pitch for Lucky and Crystal? 2:33 – Guest: Let’s talk about Crystal and looks very similar to Ruby! It’s faster and it’s a compound language. It catches a fair amount of things at compile time. The other special features are... 4:17 – Guest mentions compilers. 4:23 – Chuck: Yeah we see this in the typescript. Is it language service – is that what it’s called? Pile and compile and all of this checking are a nice stage for it to run-through. Although the flipside is coding and to not worry about that – that’s nice! 4:56 – Guest: It has changed my approach for sure. 5:43 – Panel: How much slower are you? 5:54 – Guest: I am a lot faster in Crystal than I am in Ruby. 6:51 – Panel: Yeah you have to figure out where you want to save the time. 7:00 – Guest: Someone wrote a blog post and it said...the Rails service is like bolting a shelf on a wall and hoping to hit a stud and it’s not solid. But using Lucky it’s sold although it took a little longer. I think it can be true. You can do bad things with compilers, though. It depends on how you use it. 7:43 – Panelist asks a question. 7:53 – Guest: Every Friday is an investment day. Lucky is my “whatever I want thing.” I am technically getting paid to work on it. 8:33 – Panel: have you had to battle with the framework? 8:51 – Guest: Yes, even though Crystal looks like Ruby (at a high level) if you want to do it well you have to approach it in the Crystal-way. When I came to Crystal I came to it like Rails. The problem with that is I wanted to have type-saved parameters – you can’t do that in Crystal b/c...it doesn’t know when to have a parameter with... 10:48 – Panel: I have heard you talk about Crystal before on another podcast. You talked about templating and I am curious to hear about that. I have used Slim and others and now stick to ERB. 11:25 – Guest: Yes definitely. Let’s back up and talk about WHAT Lucky does! The guest talks about Rails, escaping, and more! 14:37 – Panel: So I imagine Rails partials are slow and expensive to render. I would imagine that this approach with Lucky... 15:00 – Guest: Yes exactly. It’s extremely fast! 15:20 – Panel: How is this for designers? 15:30 – Guest: Yes that was a concern of mine. With Lucky I tried to make it close to a regular HTML structure would look like! 16:32 – Panel: I spun up a Lucky app the other day. It looks like you are using... 16:50 – Guest: I have played around with a bunch of stuff. I landed on Laravel Mix. 18:27 – Panel: Yes webpack is a pain to set up and it’s hard to get it to working the way you want it to work. 18:47 – Guest: Yeah if you want React or whatever it will generate the configuration you need. I don’t like it b/c if you want to... 19:28 – Panel. 19:45 – Guest: I don’t want to maintain it. 19:54 – Panel: There is a Crystal community in Utah. I want to know – are you competing with Amber? Explain the difference between Lucky and Amber? 20:20 – Guest: Yes I did look at Amber but they are approaching it differently than us. The guest talks about the differences between Amber and Lucky. 21:54 – Guest (continues): With Lucky you will have to learn a little bit more but you get more of a pack! 23:23 – Panel: It sounds like Lucky is inspired by Elm – right? 23:32 – Guest: Yeah, I think so. The guest dives into this topic of Elm and Lucky! 24:35 – Panel: How much does the types feel like it’s getting in your way? How explicit is it? When I came to Ruby it was a breath of fresh air. I am a bit reluctant to go back to those days. 25:25 – Guest: I think Lucky does a happy medium. It doesn’t infer instant variables. I like the... 26:28 – Panel: I learned Java very early on in my computer science career. 27:00 – Guest. 27:10 – Panel: “Crystal...it’s not Java!” That should be your slogan! 27:20 – Fresh Books! 28:25 – Panel: A lot of people are moving to Elixir community. Do you see people moving from Ruby to Lucky and Crystal? How does Lucky compare to Phoenix? 28:55 – Guest: Good question! 29:10 – The guest talks about bamboo – see links below!! 29: 29 – Guest: Sure Ruby is fast but sometimes you spend more time on it then you would want to. 31:08 – Guest: Blessing and curse that Crystal looks so much like Ruby. That’s what I thought at first: why would I want to learn this if it’s so similar to Ruby. BUT there are so many benefits to Crystal vs. Ruby. 31:48 – Guest talks about Lucky catching the bugs. 32:00 – Panel: I wonder if that happened with Groovy and Rails? 32:21 – They go back-and-forth. 32:28 – Panel: Thoughtbot has always been on the forefront of Ruby. Can you talk about Thoughbot please? (See links below for Thoughtbot!) 33:15 – Guest: Great question. It’s hard to tell b/c there are different offices. I would say Ruby is our main thing. Ruby is the most mature thing that we use in-terms of web development. Guest: Actually – Rails is pretty nice! 34:54 – Panel: We went through the same thing with CodeFund! I wrote it initially in Python and then I wrote it in Elixir and it became so complex. Now we are moving everything back to Ruby and it’s been a fantastic decision. 36:30 – Chuck: You are talking about the sustainability of open source but there are benefits throughout the company right? There are tons of tangible benefits of doing it, especially when it’s your Friday schedule. You can level-up on things that could help you. I know a lot of companies cannot afford it if they are trying to hustle. 37:42 – Guest: It’s totally not charity through Thoughtbot. It’s a huge help for hiring new people. I know they are okay with letting me work on Lucky b/c it’s bringing on new developers and a good marketing tool, and finally recruiting! 39:07 – Chuck: Yeah, I have been talking about developer freedom and that’s what I am addressing through the DevRev show! It’s my new podcast show. We talk with Chris on Elixir Mix. It lends that credibility if they need to save our bacon. 40:02 – Panel: What’s your goal with Lucky? 40:11 – Guest: I would love to get it to the point where Thoughtbot could start a project and default to Lucky! Start a project and not resting every gem and be confident with launching it. 41:36 – Panelist asks a question. 41:45 – Guest: It’s not 1.0 and that means that the API will break with every release. I think that’s good to tweak stuff but that turns companies off, though. 42:40 – Chuck: Another thing that helps with adoption is Twitter used Rails to build their initial version. This blah, blah company uses important stuff and they are using Crystal and whatnot then that’s good! It sounds like you are waiting for social proof. 43:23 – Guest: Is the next Twitter going to even know about Crystal? 43:40 – Chuck: It literally only takes one enthusiast! 43:52 – Guest. 44:11 – Demo of Flickr Search is mentioned here! 45:13 – Panel: Is there something out there that you could POINT someone to? 45:27 – Guest: Not, yet. I built a small site with it! It is opensource and you can look at it. I want to show people a good example of what Lucky can do! 45:57 – Panel: You have very good docs and I am a visual learner. When I learned Rails I learned on my own and not through school. 46:20 – Panelist asks a question. 46:48 – Guest: What a huge advantage Lucky has through the Thoughtbot platform! Now that platform is kind of dried up. In terms of getting people excited it needs that killer app and they can see that it’s fast and killer! I think it takes a lot of time and finding time to do it so that’s tricky. It’s changing a lot when there is so much change. Getting Lucky to a 1.0 state so people can do videos and make apps. The hard part thing is that Lucky has to be 1.0 when Crystal is 1.0. The Lucky community is great b/c it’s encouraging and to respond in a very kind way. When you are starting something that’s new can be scary. We try to help out as much as we can and we are open and kind about it. 49:13 – Panel: “Paul is nice so Lucky is nice!” 49:19 – Guest: Everyone is super kind. It had to be short and simple. We in the dev community are very lucky – usually great pay/benefits and more w/o a college degree. What another field can you do that?! 51:00 – Panel: Great message and you need to push that! 51:10 – Panel: You were on a past podcast and you talked about how you are donating each month! Panel: Opensource maintainers are getting burned out and you want to support that. 51:40 – Guest: I think opensource sustainability what others need to do to make it sustainable. If you have the means to give we can be apart of that, too. It would be nice if companies did that. If it helps Crystal I am happy. 52:17 – Panel: I have a question about Crystal. 52:52 – Guest: Ruby right now you can do C sections right now. 53:01 – Panel. 53:10 – Guest: I don’t think so – it may but I would guess that you could do it but I don’t know how easy it would be. Note: Rust and C are mentioned. 53:37 – Panel comments. 53:46 – Guest: One thing I would say is to check-out the Lucky docs. We are happy to help! 54:10 – Panel: This is a favorite episode of mine! Both of today’s guests have been my favorite! 54:23 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course The DevRev Podcast Show DevChat TV Ruby Elixir Ruby on Rails Angular Cypress Vue React Jest.io Mocha.js Webpacker-Cli Amber Lucky The Lucky Philosophy The Bike Shed Thoughtbot CodeFund Lucky: Ruby on Rails to Lucky on Crystal... “Crystal is not Ruby Part 1” GitHub: Bamboo Ex_Machina Dialyxir Crystal Mastery Samsung T5 Carbon Copy Cloner iMazing Awesome-Lucky Paul Smith GitHub Sponsors: Sentry CacheFly Fresh Books Picks: Nate Samsung SSD Carbon Copy Cloner Application Eric iMazing HEIC Converter Charles Mastodon Andrew Upcase by Thoughtbot Awesome Lucky Paul Tailwind CSS Phoenix Live HTML Chris McCord Elixir Mix Episodes with Chris McCord
Panel: Lucas Reis Charles Max Wood Justin Bennett Special Guest: Soumyajit Pathak In this episode, the panelists talk with Soumyajit Pathak (India) who is a full-stack developer and cybersecurity enthusiast. The panel and the guest talk about design patterns and designing simpler code for clarity and less confusion. Check out today’s episode! Show Topics: 0:00 – Kendo UI 0:31 – Chuck: Our panelists are and our guest is Soumyajit! Introduce yourself please! Are you doing React on the side? 1:02 – Guest: I am a master’s student and I am doing freelancing. 1:42 – Panel. 1:49 – Guest. 2:10 – Chuck: I am feeling very up-to-date. Woo! Universities are teaching this and that and they are focused on theory. The flipside is that they are going to write real code for real systems. 3:10 – Panel: I like your well-written blog posts. You talk about design patterns. 3:50 – Guest: The design patterns at the university had to do with real JavaScript applications. 4:09 – Chuck: I am curious you are talking about the design patterns – how can people from React find/use it? 4:45 – Panel: It depends on your definition of design patterns. 5:35 – Lucas: Maybe you are using one or two here and reading through the design patterns is like going through your toolbox. You only need a screwdriver but you bought the whole toolbox. Get familiar with it and from time to time solve problems and thing: what tool can help me here? It’s clear to me with this toolbox analogy. I understand now – that tool I saw 2 months ago could help me. 7:00 – Guest: I have an interesting story with this about design patterns. Let me share! 7:36 – Justin: It was a similar thing but I wasn’t in JavaScript at the time. I’ve used a lot of C++ code. Design patterns became very useful. I saw it the same way Lucas! 9:23 – Justin continues: How and why to use a certain tool. That’s important. 10:28 – Chuck: Okay this is the default pattern and that’s where we can go for the fallback. Here is the fallback if this doesn’t work here or there. 10:49 – Lucas: This is important to remember. It’s not how to use the tool but it’s why am I using this tool here or there? 11:57 – Justin: It’s so much information in general. People get information overload and they have to just start! One of the challenges we do is that we over-engineer things. Do what you need to know. Look it up but play with it. 12:40 – Lucas: It’s interesting by another blog post that you wrote Soumyajit – and you are using a render prop. You showed a problem and showed the solution. 13:30 – Guest: Yeah I’ve written a lot of blog posts about this topic. 13:48 – Panel: Often times – it’s hard for people just to dive-in. People need to see you solving a problem and it really helps with the learning process. 15:03 – Chuck: What patterns do you find most useful? 15:11 – Panel: Functional components have changed my world! 16:23 – Guest: Around these functional components... 17:17 – Panel: I will go with the patterns that are not useful. Don’t make your code pattern-oriented. This is my favorite pattern now and going back to basics. 18:53 – Panelists go back-and-forth. 19:01 – Lucas. 19:41 – Chuck: You talk about over-engineering things and that’s what I found myself doing sometimes with my new project. When I figure out how to make it simpler I get excited and it’s easy to follow. 20:15 – Panel: We celebrate the person who deleted the most lines of code. 20:28 – Panel: I am going to steal that idea. 21:04 – Guest: I have an interesting story of over-engineering something – let me share! 21:53 – FreshBooks! 22:59 – Panel: Building too much is b/c I don’t have a clear understanding of what I am doing. I get excited about problems. What’s the more simple way / most naïve way possible! 24:36 – Lucas: If you are going to change something you will be changing it in several different places. 25:50 – Chuck: When I heard the concept, all the codes that change together should be together. 26:08 – Lucas comments. 26:53 – Panel: Keeping things contained in one place. We have our presentational component and higher-level component, so you can see it all. 28:28 – Lucas: Different people working on different technologies. 29:15 – Panel: Can I break this down to smaller parts, which makes sense to me? 29:48 – Guest: Looking for keywords will cause a distraction. Finding a balance is good. 30:04 – Chuck: If you have a large rile there could be a smaller component that is there own concern. That feels like the real answer to me. It has a lot less than the length of the file versus... Chuck: If I cannot follow it then I need to keep the concept simple. 30:51 – Lucas: The quantity of lines and the line count – I think it’s better how many indentations you have. 32:43 – Guest. 32:48 – Lucas: Yes, so in the horizontal scrolling you have to keep things in your mind. 33:41 – Panel: There are so many different metrics that you can use and the different line count or different characters. There are more scientific terms that we could plugin here. If you have a lot of these abstract relations that can...write it 34:23 – Chuck: So true. 34:52 – Chuck: I want to move onto a different problem so it’s an attention thing for me too. 35:06 – Panel: We have to get okay with not always writing the best code in that it just needs to do what it needs to do. 35:30 – Chuck. 35:57 – Panel: We write it once – then it falls apart and then we write it again and learn from the process. Learning is the key here – you see where it works and where it doesn’t work well. 36:31 – Panel. 36:47 – Chuck mentions service-side rendering. Chuck: Should we schedule another episode? 37:11 – Panel: I think it’s own episode b/c it’s a complex problem overall. 39:33 – Lucas: Try to find memory leaks in the file components and server-side rendering. Where we have lost a lot of sleep and a higher level of complication. Sometimes it’s necessary. 41:42 – Chuck: Yeah let’s do another episode on this topic. Sounds like there is a lot to dive into this topic. Soumyajit, how do people find you? 42:10 – Guest: Twitter and GitHub! 42:28 – Picks! 42:30 – Advertisement – Get A Coder Job! End – Cache Fly Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub Get A Coder Job React Patterns on GitHub Calibre Book: Engineering a Safer World Designers’ Secret Source Monster Hunter Guest’s GitHub Guest’s Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI Picks: Justin https://reactpatterns.com/ Calibre App Lucas Engineering a Safer World Soumyajit Blog Muzli - Chrome Extension Charles Monster Hunters International Series Metabase Stripe Work for DevChat TV
Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts. 46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App
Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts. 46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App
Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts. 46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App
Panel: Mark Ericksen Nathan (Nate) Hopkins Charles Max Wood Special Guest: Sophie DeBenedetto In this episode of Elixir Mix, the panel talks with Sophie DeBenedetto who is a teacher at the Flatiron School, a software engineer, and creator of Break In. The panelists and Sophie talk about her blog, the Flatiron School, and her background. Check it out! Show Topics: 0:00 – Advertisement: Get A Coder Job! 0:50 – Chuck: Welcome! Our panel is Mark, Nate, and myself. Our special guest, today, is Sophie! Please introduce yourself! 1:32 – Guest: Hi! I am Sophie and I am an engineer who works at the Flatiron School. We are growing and fast and offer a lot of different courses. We are an international school working with Elixir and Phoenix. 2:10 – Chuck: You gave us multiple topics: Joken and Elixir Packages. Give us please some background there. 2:33 – Guest: I will talk about the problems we were trying to resolve with Joken. The Guest goes into detail about this topic. Sophie mentions Rails, Joken, Guardian, Phoenix, and Erlang-Jose. 4:41 – Guest: We found this nice little library that we needed and that was Joken. Initially, we were trying to hit the nail with a racket and all we needed was a hammer. 6:48 – Guest: I am telling the whole Internet our problem we had, and how we resolved it. That’s why I am here today, because you all found my blog. 9:04 – Panel: There is a lot there! Some terms that you mentioned: JWT is referred to as a JOT – for those listeners who don’t know. Panelist asks question. 9:43 – Guest answers the question. 10:52 – Panel: When I used Joken before I did use it with the HMAC algorithm. You are on the fringe of what is mainstream and you can come across those rough spots. You are doing this service of saying yes I found this problem and I will try to help you with this problem. 11:25 – Guest: It’s an interesting feeling to say we solved this problem and then realizing we were wrong about it. I’m glad that happened because it’s real. As a teacher I saw students being reluctant to blog b/c they didn’t want to be wrong, but that’s how you grow! 12:22 – Chuck: We talked about the JWT and the dots. How is this different than Ruby gems and other things? 12:44 – Guest: I think anyone would have thoughts on this. There’s not a lot of resources, and look into the Ruby community. From the Flatiron School our focus has been Ruby, and we ask our students to contribute. We want to find an answer to any problem we are facing through Ruby and Rails. More or less you will find a solution from somebody through the Internet. Elixir is definitely different from this because it’s a newer framework. 14:26 – Panelist asks about the curriculum through the Flatiron School. 14:48 – Guest answers the question. 16:08 – Panel: We have had Kate Travers from Flatiron Schools on our podcast before. What has your path been? 16:30 – Guest: We graduated at the same time and I went to the educational-side, which I did for a year to about a year and a half. I thought I needed to get my hands dirty, though, to be a better teacher. I went to this company...and I recently rejoined the Flatiron School’s faculty. 17:40 – Panel: That’s great. I was with a company for 3 years, left for 2 years, and then I came back. It’s a testament to not burning bridges. There is value to leaving and going to get new and different experiences. You grow in the process, and that’s what happened for me. I like your path and thanks for sharing your story! 18:50 – Fresh Books! 20:00 – Chuck: Do you have any policies on how students (at Flatiron School) need to contribute? 20:06 – Guest: Not so much HOW but we encourage it. The guest goes into detail and mentions Elixir School (see links below). 21:33 – Panel: That is a good suggestion if a newbie wants to contribute and they are afraid to contribute. You can get involved and your suggestion will be reviewed. 22:10 – Guest: Yes! There is a team member, Matt, and he contributed to the code base. He was new to the Elixir community, and showed his thought-process. Contributing to open source is great because it helps the community, and opens a pathway for great feedback and conversation. 23:30 – Panel: I think that’s a healthy way to look at pole requests. I have worked with folks that don’t view it that way, though. They hold their code a little close to their chest and that’s it. I like the dialogue. 24:00 – Chuck: This stuff isn’t staying still b/c the Elixir community is constantly growing. I cannot recommend highly enough to learn something new. It can be just 20-30 minutes a day. If you aren’t doing that then you will fall behind. 24:57 – Panel: Question for Sophie. How did you get involved with Elixir School? 25:18 – Guest: I am definitely not an expert. It’s a group of people who thought that Elixir should be more accessible. I like it because it’s beginner-friendly. Find something to contribute to b/c there are tons of different levels to find what’s good for you. 27:09 – Panel: Has it be re-skinned/re-themed? 27:15 – Guest: Yeah, I think so. Along with the theme-related they have been putting high priority into different languages. 27:38 – Panelist comments about natural languages and translations. 27:52 – Chuck: Was this a project through the school or something else? 28:06 – Guest: It’s not through the school. 28:36 – Chuck: Any other projects through the school? 28:46 – Guest: Yes, the school has a lab and it’s neat to see it grow! 29:38 – Panel: Have you tried those other technologies before (and they didn’t work) or did you just anticipate it was a problem that you couldn’t solve without the Beam. 30:02 – Guest answers. 32:33 – Panel: That makes sense. You were reaching for Erlang when you were on the Ruby Stack. 32:49 – Guest refers to tooling and Rabbit. 33:00 – Chuck: You mentioned Rabbit – what does your typical stack look like? Are you running Phoenix? Or here is a job so here is Elixir? What is your process like? 33:23 – Guest: A Ruby on Rails app it has all the ups-and-downs and it’s kind of old. As we are growing and partnering with new companies/schools we are updating and seeing a need to grow even more. 34:49 – Panel. 34:54 – Guest: The video that Chris McCord put out! 35:03 – Chuck: Check the show notes’ links! 35:15 – Chuck: Picks! 35:23 – Ad: Lootcrate.com END – CacheFly! Links: Ruby Elixir Elm Atom.io Flutter.io JavaScript Visual Studio Code React Guardian Joken Erlang-Jose Flatiron School Flatiron School's Blog Flatiron Labs Elixir School Elixir School EMx 020 Episode Utah Elixir Meetup Blog: How We Built the Learn IDE in Browser Break_In The Great Code Adventure Rabbit Sophie’s Website Sophie’s Twitter Sponsors: Loot Crate Get a Coder Job! Fresh Books CacheFly Picks: Mark Utah Elixir Meetup Nate Racquetball Getting out and doing something Charles repurpose.io Sling TV Fox Sports Sophie Elixir School Learn IDE Blog
Panel: Mark Ericksen Nathan (Nate) Hopkins Charles Max Wood Special Guest: Sophie DeBenedetto In this episode of Elixir Mix, the panel talks with Sophie DeBenedetto who is a teacher at the Flatiron School, a software engineer, and creator of Break In. The panelists and Sophie talk about her blog, the Flatiron School, and her background. Check it out! Show Topics: 0:00 – Advertisement: Get A Coder Job! 0:50 – Chuck: Welcome! Our panel is Mark, Nate, and myself. Our special guest, today, is Sophie! Please introduce yourself! 1:32 – Guest: Hi! I am Sophie and I am an engineer who works at the Flatiron School. We are growing and fast and offer a lot of different courses. We are an international school working with Elixir and Phoenix. 2:10 – Chuck: You gave us multiple topics: Joken and Elixir Packages. Give us please some background there. 2:33 – Guest: I will talk about the problems we were trying to resolve with Joken. The Guest goes into detail about this topic. Sophie mentions Rails, Joken, Guardian, Phoenix, and Erlang-Jose. 4:41 – Guest: We found this nice little library that we needed and that was Joken. Initially, we were trying to hit the nail with a racket and all we needed was a hammer. 6:48 – Guest: I am telling the whole Internet our problem we had, and how we resolved it. That’s why I am here today, because you all found my blog. 9:04 – Panel: There is a lot there! Some terms that you mentioned: JWT is referred to as a JOT – for those listeners who don’t know. Panelist asks question. 9:43 – Guest answers the question. 10:52 – Panel: When I used Joken before I did use it with the HMAC algorithm. You are on the fringe of what is mainstream and you can come across those rough spots. You are doing this service of saying yes I found this problem and I will try to help you with this problem. 11:25 – Guest: It’s an interesting feeling to say we solved this problem and then realizing we were wrong about it. I’m glad that happened because it’s real. As a teacher I saw students being reluctant to blog b/c they didn’t want to be wrong, but that’s how you grow! 12:22 – Chuck: We talked about the JWT and the dots. How is this different than Ruby gems and other things? 12:44 – Guest: I think anyone would have thoughts on this. There’s not a lot of resources, and look into the Ruby community. From the Flatiron School our focus has been Ruby, and we ask our students to contribute. We want to find an answer to any problem we are facing through Ruby and Rails. More or less you will find a solution from somebody through the Internet. Elixir is definitely different from this because it’s a newer framework. 14:26 – Panelist asks about the curriculum through the Flatiron School. 14:48 – Guest answers the question. 16:08 – Panel: We have had Kate Travers from Flatiron Schools on our podcast before. What has your path been? 16:30 – Guest: We graduated at the same time and I went to the educational-side, which I did for a year to about a year and a half. I thought I needed to get my hands dirty, though, to be a better teacher. I went to this company...and I recently rejoined the Flatiron School’s faculty. 17:40 – Panel: That’s great. I was with a company for 3 years, left for 2 years, and then I came back. It’s a testament to not burning bridges. There is value to leaving and going to get new and different experiences. You grow in the process, and that’s what happened for me. I like your path and thanks for sharing your story! 18:50 – Fresh Books! 20:00 – Chuck: Do you have any policies on how students (at Flatiron School) need to contribute? 20:06 – Guest: Not so much HOW but we encourage it. The guest goes into detail and mentions Elixir School (see links below). 21:33 – Panel: That is a good suggestion if a newbie wants to contribute and they are afraid to contribute. You can get involved and your suggestion will be reviewed. 22:10 – Guest: Yes! There is a team member, Matt, and he contributed to the code base. He was new to the Elixir community, and showed his thought-process. Contributing to open source is great because it helps the community, and opens a pathway for great feedback and conversation. 23:30 – Panel: I think that’s a healthy way to look at pole requests. I have worked with folks that don’t view it that way, though. They hold their code a little close to their chest and that’s it. I like the dialogue. 24:00 – Chuck: This stuff isn’t staying still b/c the Elixir community is constantly growing. I cannot recommend highly enough to learn something new. It can be just 20-30 minutes a day. If you aren’t doing that then you will fall behind. 24:57 – Panel: Question for Sophie. How did you get involved with Elixir School? 25:18 – Guest: I am definitely not an expert. It’s a group of people who thought that Elixir should be more accessible. I like it because it’s beginner-friendly. Find something to contribute to b/c there are tons of different levels to find what’s good for you. 27:09 – Panel: Has it be re-skinned/re-themed? 27:15 – Guest: Yeah, I think so. Along with the theme-related they have been putting high priority into different languages. 27:38 – Panelist comments about natural languages and translations. 27:52 – Chuck: Was this a project through the school or something else? 28:06 – Guest: It’s not through the school. 28:36 – Chuck: Any other projects through the school? 28:46 – Guest: Yes, the school has a lab and it’s neat to see it grow! 29:38 – Panel: Have you tried those other technologies before (and they didn’t work) or did you just anticipate it was a problem that you couldn’t solve without the Beam. 30:02 – Guest answers. 32:33 – Panel: That makes sense. You were reaching for Erlang when you were on the Ruby Stack. 32:49 – Guest refers to tooling and Rabbit. 33:00 – Chuck: You mentioned Rabbit – what does your typical stack look like? Are you running Phoenix? Or here is a job so here is Elixir? What is your process like? 33:23 – Guest: A Ruby on Rails app it has all the ups-and-downs and it’s kind of old. As we are growing and partnering with new companies/schools we are updating and seeing a need to grow even more. 34:49 – Panel. 34:54 – Guest: The video that Chris McCord put out! 35:03 – Chuck: Check the show notes’ links! 35:15 – Chuck: Picks! 35:23 – Ad: Lootcrate.com END – CacheFly! Links: Ruby Elixir Elm Atom.io Flutter.io JavaScript Visual Studio Code React Guardian Joken Erlang-Jose Flatiron School Flatiron School's Blog Flatiron Labs Elixir School Elixir School EMx 020 Episode Utah Elixir Meetup Blog: How We Built the Learn IDE in Browser Break_In The Great Code Adventure Rabbit Sophie’s Website Sophie’s Twitter Sponsors: Loot Crate Get a Coder Job! Fresh Books CacheFly Picks: Mark Utah Elixir Meetup Nate Racquetball Getting out and doing something Charles repurpose.io Sling TV Fox Sports Sophie Elixir School Learn IDE Blog
Panel: Dave Kimura Charles (Chuck) Max Wood Nate Hopkins Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Bozhidar Batsov who is the VP of Engineering at Toptal, and an Emacs fanatic. The panel and the guest talk about RubCop, Emacs, and Komodo, among other topics! Check out today’s episode for more details. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck lists the panelists and the special guest. 1:37 – Chuck: Why are you famous? 1:41 – Guest gives his background. 2:13 – Guest: I am passionate about Emacs. 2:55 – Chuck. 2:58 – Panel: I have on a few projects. Do you know RUFO? It’s a bit more opinionated than RuboCop. 3:25 – Guest: I am familiar with RUFO and their approach is similar to JavaScript called Pretty or something like that. 4:45 – Guest: 4:49 – Panel: Can you tell us what RuboCop is and why is it important? 5:00 – Guest: There are a few main things that RuboCop is: 1.) Placement for Ruby minor... 2.) Lint tool 3.) Automatic checker for all the best practices outlined in the community 4.) Formatter for Ruby code – you can feed it ugly code and it will spin out beautiful code 7:30 – Panel: What are the origins of the project? Where you interested in the performance and security aspects of it? 7:49 – Guest. The guest talks about RuboCop in detail. 10:59 – Panel: It’s important to remember that these are just guidelines and they are NOT set in stone. Using single or double quotes. As long as the project is consistent and using decent practices then I am okay with the code. I will disable the...in RuboCop. Today with high-resolution monitors it’s one of those things that are an annoyance to me. It’s just my opinion, though. 12:07 – Guest: Why disable it and not...? 13:36 – Panel: You could use VS code instead of Emacs! I am just kidding. 13:51 – Guest: I hope you are kidding! 13:56 – Chuck: I cannot live without this code... 14:06 – Guest. 14:26 – Panel: I was an early adapter from the beginning and it was hella slow. I tried it from sublime text and I got annoyed so I eventually switched to VS code. Once I got over the brand name, I really like it as my main editor. 15:20 – Panel: Maybe it’s more approachable and it’s easier to dip your toes in. 15:35 – Guest. 16:29 – Panel: I haven’t heard of KOMODO in long time. I remember that was one of the first IDs that I had checked out. I tried that then went to Ruby Mine and then tried Sublime text and then VS. 16:57 – Guest: Komodo was a famous editor. 17:17 – Panel: I am curious on RuboCop that the adaption is driven by teaching idiomatic Ruby to people new to the language? 17:40 – Guest: I don’t think it’s much about the stylistic stuff at this point. I also noticed that the main driver of the group was... Guest goes into great detail about this topic. 22:44 – Guest (continues): RuboCop offers a bunch of different structure. 24:27 – Guest (continues): We are wondering how to approach the issue of performance. The performance aspect tended to be trickier than what we had expected. The majority of developers when given the choice to either secure or make something convenient - they will choose the latter option. 25:47 – Panel: That’s why they get hit with a high AWS bill. 26:00 – Guest. 26:30 – Panel: The things you have learned with RuboCop, is it changing the direction with MRI or the design of the language at all? 26:40 – Guest: I would hope so, but I don’t have hard evidence to prove this. If you give people too many options then it could be a waste of time. I don’t care about the nuances. 30:06 – Ad: RubyMine! 30-day trial! 30:38 – Panel: Would you recommend the Rails style guide if you are building a Rails style project? Should we use that as a baseline and then customize it for your team? 30:55 – Guest: The style guide should be good. For a while I was the only editor. Not a lot of the options that are there aren’t my personal opinion, but it’s the general prescription. If you have strong preferences and you have your team agree on those then it’s okay to be modifying it. At the end of the day it’s better to have consistency within a project. You are doing great! 32:57 – Chuck asks a question. 33:44 – Chuck: Could I modify a rule? 33:53 – Guest: There are varying degrees to the rule. 35:56 – Panel: One of your conference talks you talked about the future of Rails and the future of other Ruby frameworks? 36:18 – Guest: I am worried about the future of Ruby b/c I see people talking about the maturity of the system but there isn’t a clear vision to where we are going. There are some cornerstones for Ruby 3 that he is repeating. 41:05 – Guest (continues): I think we need to commit to the module and the API. 45:42 – Chuck: All of those things make sense to me. Is there any desire for people to fork Ruby or pulling / putting some of this in? 46:00 – Guest. 48:18 – Panel: Transition that to Rails and the future of Rails? 48:27 – Panel: There are big companies that are making changes. 48:51 – Guest. 53:33 – Panel: I think that is a common pattern that most companies move towards. 54:12 – Chuck: We did an episode on ElixirMix with Chris McCord. Check that out! 54:35 – Chuck: Picks! 54:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Komodo Emacs RuboCop RuboCop – GitHub Stimulus reflex Messages: Share Screens Smittybilt Visual Studio Code: Introducing Visual Studio Live Share VRBO Bozhidar’s GitHub Bozhidar’s Twitter Bozhidar’s Patreon Bozhidar’s Open Collective Past EMx Episode 020 with Chris McCord! Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: Dave Tire Plugs VS Live Share Nate Share Screen using Messages on Mac Charles VRBO Find opportunities for R&R Rocket League Bozhidar Documentation for Markdown users Bear App
Panel: Dave Kimura Charles (Chuck) Max Wood Nate Hopkins Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Bozhidar Batsov who is the VP of Engineering at Toptal, and an Emacs fanatic. The panel and the guest talk about RubCop, Emacs, and Komodo, among other topics! Check out today’s episode for more details. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck lists the panelists and the special guest. 1:37 – Chuck: Why are you famous? 1:41 – Guest gives his background. 2:13 – Guest: I am passionate about Emacs. 2:55 – Chuck. 2:58 – Panel: I have on a few projects. Do you know RUFO? It’s a bit more opinionated than RuboCop. 3:25 – Guest: I am familiar with RUFO and their approach is similar to JavaScript called Pretty or something like that. 4:45 – Guest: 4:49 – Panel: Can you tell us what RuboCop is and why is it important? 5:00 – Guest: There are a few main things that RuboCop is: 1.) Placement for Ruby minor... 2.) Lint tool 3.) Automatic checker for all the best practices outlined in the community 4.) Formatter for Ruby code – you can feed it ugly code and it will spin out beautiful code 7:30 – Panel: What are the origins of the project? Where you interested in the performance and security aspects of it? 7:49 – Guest. The guest talks about RuboCop in detail. 10:59 – Panel: It’s important to remember that these are just guidelines and they are NOT set in stone. Using single or double quotes. As long as the project is consistent and using decent practices then I am okay with the code. I will disable the...in RuboCop. Today with high-resolution monitors it’s one of those things that are an annoyance to me. It’s just my opinion, though. 12:07 – Guest: Why disable it and not...? 13:36 – Panel: You could use VS code instead of Emacs! I am just kidding. 13:51 – Guest: I hope you are kidding! 13:56 – Chuck: I cannot live without this code... 14:06 – Guest. 14:26 – Panel: I was an early adapter from the beginning and it was hella slow. I tried it from sublime text and I got annoyed so I eventually switched to VS code. Once I got over the brand name, I really like it as my main editor. 15:20 – Panel: Maybe it’s more approachable and it’s easier to dip your toes in. 15:35 – Guest. 16:29 – Panel: I haven’t heard of KOMODO in long time. I remember that was one of the first IDs that I had checked out. I tried that then went to Ruby Mine and then tried Sublime text and then VS. 16:57 – Guest: Komodo was a famous editor. 17:17 – Panel: I am curious on RuboCop that the adaption is driven by teaching idiomatic Ruby to people new to the language? 17:40 – Guest: I don’t think it’s much about the stylistic stuff at this point. I also noticed that the main driver of the group was... Guest goes into great detail about this topic. 22:44 – Guest (continues): RuboCop offers a bunch of different structure. 24:27 – Guest (continues): We are wondering how to approach the issue of performance. The performance aspect tended to be trickier than what we had expected. The majority of developers when given the choice to either secure or make something convenient - they will choose the latter option. 25:47 – Panel: That’s why they get hit with a high AWS bill. 26:00 – Guest. 26:30 – Panel: The things you have learned with RuboCop, is it changing the direction with MRI or the design of the language at all? 26:40 – Guest: I would hope so, but I don’t have hard evidence to prove this. If you give people too many options then it could be a waste of time. I don’t care about the nuances. 30:06 – Ad: RubyMine! 30-day trial! 30:38 – Panel: Would you recommend the Rails style guide if you are building a Rails style project? Should we use that as a baseline and then customize it for your team? 30:55 – Guest: The style guide should be good. For a while I was the only editor. Not a lot of the options that are there aren’t my personal opinion, but it’s the general prescription. If you have strong preferences and you have your team agree on those then it’s okay to be modifying it. At the end of the day it’s better to have consistency within a project. You are doing great! 32:57 – Chuck asks a question. 33:44 – Chuck: Could I modify a rule? 33:53 – Guest: There are varying degrees to the rule. 35:56 – Panel: One of your conference talks you talked about the future of Rails and the future of other Ruby frameworks? 36:18 – Guest: I am worried about the future of Ruby b/c I see people talking about the maturity of the system but there isn’t a clear vision to where we are going. There are some cornerstones for Ruby 3 that he is repeating. 41:05 – Guest (continues): I think we need to commit to the module and the API. 45:42 – Chuck: All of those things make sense to me. Is there any desire for people to fork Ruby or pulling / putting some of this in? 46:00 – Guest. 48:18 – Panel: Transition that to Rails and the future of Rails? 48:27 – Panel: There are big companies that are making changes. 48:51 – Guest. 53:33 – Panel: I think that is a common pattern that most companies move towards. 54:12 – Chuck: We did an episode on ElixirMix with Chris McCord. Check that out! 54:35 – Chuck: Picks! 54:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Komodo Emacs RuboCop RuboCop – GitHub Stimulus reflex Messages: Share Screens Smittybilt Visual Studio Code: Introducing Visual Studio Live Share VRBO Bozhidar’s GitHub Bozhidar’s Twitter Bozhidar’s Patreon Bozhidar’s Open Collective Past EMx Episode 020 with Chris McCord! Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: Dave Tire Plugs VS Live Share Nate Share Screen using Messages on Mac Charles VRBO Find opportunities for R&R Rocket League Bozhidar Documentation for Markdown users Bear App
Panel: Mark Ericksen Josh Adams Nate Hopkins Charles Max Wood Special Guest: Eric Oestrich In this episode of Elixir Mix, the panel talks with Eric Oestrich who is a web developer who resides in Indianapolis, Indiana. He and the panel talk about ExVenture, Gossip, Cowboy, Raisin, Grapevine, and much more! Listen to today’s episode to hear all about it! Finally, check out Eric’s ElixirConf talk and his blog, too! Show Topics: 0:00 – Advertisement: Get A Coder Job! 0:51 – Charles introduces the panel. 1:14 – Nate talks about his background. 1:27 – Chuck: My first programming job I worked with Nate. Nate also works now with Eric Berry. We have a special guest and that is Eric Oestrich. Tell us who you are, please! 1:55 – Eric: I work for Smart Logic, LLC. We are a consultancy who has moved to Elixir for the last 2 years. 2:14 – Chuck: Tell us what ExVenture is? 2:46 – Eric: Late 80’s to mid-90’s it’s like a MUD tech space game. Eric goes into detail of what ExVenture is. 3:28 – Panel: Familiar with MUDS. 3:36 – Panel: Audience can’t tell that Eric isn’t an old guy. Eric – you aren’t an old gentleman – how did you get into it?! 4:02 – Eric: The concept has fascinated me. It’s pure game mechanics. In school I wrote things in Python and try to make it threaded. Never got it going. After that I wanted to do a MUD but not good enough in C and couldn’t get it working in Ruby neither. But one faithful day (a year ago) I got an echo and chat server and now we have a MUD. 5:02 – Panel: Why should you be interested? I will tell you why. ExVenture is an open source... I encourage everyone to dig into and play with it! It is a game (so that makes it more fun) but you are dealing with game mechanics. I am also curious where you wanted this to go? What made you say: I want to create this and make it open source? 6:37 – Eric: I like it and work has mostly played for it. It’s MIT because of that. Early in the project (between client work) it was a common thread and that’s why it’s open source. 7:27 – Panel: I ran into you at the conference and you were showing me... Talk about getting metrics out of your system, please? 8:20 – Eric answers the question. 9:09 – Panel: When people are trying to get metrics out of their system – what EVEN makes a good metric? 9:21- Eric: I am trying to figure that out myself, actually. I want to know how long it takes for someone to login? Is that someone trying to hack into my system? If you speak at a global channel or something else... Eric goes into more detail. Eric also mentions Prometheus. 10:31 – Panel: You mentioned: What would you want to see on a dashboard? 11:01 – Eric answers the question and mentions Prometheus EX. 12:19 – Panel: As you starting building this you were pulling libraries out of it and making them separate libraries. Are you pretty proud of GOSSIP? 12:37 – Eric: Yes! Gossip is based on web sockets and it’s a cowboy socket. Eric talks about Gossip. 13:10 – Panel: What other clients are you trying to support? 13:15 – Eric: There is a JavaScript client and Node-based game called... There is a bundle system for that. There is also a Python option. The one thing we haven’t done yet is a C client. That is important b/c most of the games that you could connect to are 25-30 years old. 14:26 – Panel asks a question. 14:34 – Eric: That is the C client we are waiting for. 14:43 – Panel: You talked at the conference (see the show notes) you talked about things you learned along the way. Can you talk about your process? What kind of bottlenecks and how did you resolve those issues? 15:10 – Eric answers the question. 16:44 – Panel: Did you run out of processes? 16:47 – Eric: The VM shut-off – it was just done. That was the first go-around. 19:27 – Eric: After the ElixirConf, I wanted to see how far I could push it. Eric continues. 19:51 – Panel: I want to identify some of these principles you just talked about. First, the major block was the gen server is a single process. 20:21 – Panel. 20:24 – Panel: I think that is a common mistake when people come to Elixir in the beginning stages. How did you solve it? 20:50 – Panelist answers the above question. 21:30 – Panel: That’s one of the big things. It’s an architectural issue. Second, you mentioned really LARGE messages. You were sending around really large messages. 22:20 – Eric: For every 100 players was a gigabyte of ram – it was a lot. And that was mostly b/c every copy...when a new character enters the room then that message gets sent out then it gets copied again, and... 23:08 – Panel. 23:24 – Panel: The third one you mentioned was around data base blocking or...? Can you talk about this one a little more, please? 23:33 – Eric answers the question. 24:02 – Panel. 24:30 – Eric: It was always saving...I tricked Echo into saving...There is a lot of things that could be better to save specifically faster. 24:52 – Panel: I think people would hit those 3 points eventually – there is a lot of value to that. 25:09 –Eric: Yes that was near the end of my ElixirConf talk and my blog. 25:23 – Panel. 25:33 – Eric: It came out in May and I figured out that I needed to learn how to cluster in Elixir. That’s what the ElixirConf was a bout from single node to multiple nodes. Eric continues. 28:38 – Panel: When you have a cluster – and I join – when I transfer from one room to another room, I could be passed off to another server or node? 29:01 – Eric: Whatever you mean by “being passed off.” Whatever server you land on that’s the one you will be on. The magic is that... 30:08 – Advertisement: Fresh Books! 31:15 – Panel: I am going through the code base now and I am excited. It’s going to help me get better at Elixir. 31:32 – Eric: That’s the point of ExVenture. 31:48 – Panel: You host a server so people can see what it’s about – and that’s Mid Mud, right? 32:09 – Eric: Yep, the first hour of you playing. There is a town crier, you request, and then combat monsters. Also, it is plugged into Gossip and you can talk to them. 32:44 – Eric: Yep, there you go: player logged-in! 32:55 – Panel: Maybe not b/c it will turn into a new podcast soon. 33:07 – Panel: What if I want to use Gossip, what is involved there? 33:16 – Eric: Gossip.Haus/docs – Go there! Set it up and start sending and receiving events. 34:40 – Panel: When I was trying to understand the Prometheus metrics it helped. And then in downloading it (as a tip), for me, it was easy to use the DOCKER instructions. 35:32 – Eric: Yep, that was done by a community member. 35:40 – Panel: Are you looking for people to contribute? 35:50 – Eric: Yep, I have a public Trello board. There are 2 tags. 36:12 – Panel: Sounds like you have people involved? 36:22 – Eric: Bunch of people came on after the ElixirConf. 36:33 – Panel: If people download it (another tip) in the SEEDS file you will find out the admin username and password. I guess that’s something you can add. Login: ADMIN and Password: PASSWORD. What I thought was fun (playing with it) in the admin screen I got a sense that it’s generic enough that I could create a space game. Like playing with sectors of space. Does that make sense? 37:42 – Eric: I don’t want it to be tied JUST to fantasy b/c that’s what MUD is. Everything should be good for historical/ fantasy/ etc. any genre that you want to do! 38:13 – Panel: I could see a HackFest and the company could create one for their business. You could have a lot of fun with it. 38:38 – Panel. 38:44 – Panel: Hidden things on their websites. 38:50 – Eric: Search TEXT ADVENTURE in Google Search. See show notes below. 39:24 – Panel: There is a whole subculture that people are interested in and I didn’t know that these people existed. I think that is interesting. 39:45 – Eric: There are tons of games out there that are 20+ years old! 39:55 – Panel: What is your favorite old school MUD game? 40:02 – Eric lists his favorite old school games! One of them is Achaea! 40:51 – Panel: I like the status bars are really cool. If you haven’t played it you have a health bar. Also you have these expiring times and it’s very cool – modern MUD. 41:22 – Eric. 42:00 – Panel: You came from a Ruby background – what was your transition to Elixir like for you? How did you come to Elixir? What was that like for you? 42:15 – Eric: Yeah some of my friends were into Elixir from a functional standpoint about 2 years ago. They were reading about Phoenix and such. They wanted to see how it was going to go. 43:06 – Panel: Try by fire. Coming from Ruby to Elixir – what some advice would you give the same person? 43:37 – Eric: It was less of a culture shock b/c Phoenix was still kind of “Railsy.” 44:35 – Panel: When I was first learning ERLANG, and telling them that it was a standard library. 44:59 – Eric: It’s using Cowboys Ranch. 45:19 – Eric: There are a number of people out there that they want people to run to SSH b/c it’s more secure. 45:46 – Eric: I guess if we are on this topic about secure... 46:40 – Chuck. 46:51 – Panel: I think there is a lot of value, Eric, and the lessons you’ve learned and the path you’ve gone down. If you are new to Elixir going to ExVenture is a great way to start. 47:20 – Eric. 47:35 – Panel: Just run the format and we can do it that way. I encourage people to download it and see what it’s like as a user, and play with it as an admin. We have a Meetup coming up this Thursday. Eric is coming in virtually into our Meetup group. 48:29 – Eric: Gossip is open source. Grapevine and Raisin – check these out, too, b/c they are open source, too. 48:58 – Panel: Where can people contact you? 49:05 – Eric: Twitter! GitHub! Mudcoders.com. 49:39 – Picks! 49:44 – Ad: Lootcrate.com Links: Ruby Elixir Elm Atom.io Flutter.io JavaScript Visual Studio Code React Erlang ExVenture Ex_Venture ExVenture’s Trello Board Prometheus Prometheus EX Gossip GitHub: Gossip 2018 – Conference Talk @ Elixir Conf with Eric Oestrich Eric’s Blog Libcluster Raft – GitHub.io – The Raft Consensus Algorithm pg2 MidMUD Gossip/Haus/Docs ExVenture: Docker Environment Google: Text Adventure Achaea Cowboy SSH Grapevine Raisin ASDF Plugins Eric’s GitHub Eric’s Twitter Brooklyn Nine-Nine Elm Packages MetaBase Sponsors: Loot Crate Get a Coder Job! Fresh Books Cache Fly Picks: Eric MUD Coders Elixir LS Mark ASDF Library Josh Brooklyn Nine-Nine Elm UI Nate Mentoring and Paired Programming Metabase Charles Monster Hunters International
Panel: Nader Dabit Lucas Reis Justin Bennett Special Guests: Carly Litchfield In this episode, the panelists talk with Carly Litchfield who is a Full-stack engineer of React and React Native. The panel and Carly talk about frontend and backend developing and the issues that teams could face day-in and day-out. Listen to today’s episode to hear about that and much more! Show Topics: 0:00 – Kendo UI 0:30 – Nader: Welcome! Our panel is Justin, Lucas, myself, and our guest is Carly. Welcome to the show! Thanks for joining us. Introduce yourself please. 0:56 – Carly: I am a fullstack engineer at a company called Zocdoc. I have been there for 4 years, and we use C# framework. 1:17 – Nader: C# interesting! 1:26 – Nader: You can do game development and other stuff. 1:33- Carly: I haven’t gotten into game development at all, just using C# for web development. 1:50 – Nader. 1:55 – Carly. 2:08 – Nader: The topic for today is: being a frontend developer and a team that is mostly focused on backend. Also, other topics with testing if we have time. How did you get into web development? 2:32 – Carly goes into detail about how she got into web development. 5:02 – Carly: I have worked with React Native, too. 5:22 – Nader: That is my favorite thing to work with (React Native). 5:27 – Panel: Everyone was learning about this new domain and this frontend domain. How was the knowledge spread? How was it spread throughout the company? 5:50 – Carly: One of the people someone that was on this 3 – person team (Thomas) and he went around to anyone who knew React. He made a lot of tooling. He made a lot of configuration libraries. You’d have your NPM integration like everyone else. It was cool to hook it into our servers. It was crucial to help with adoption. Those libraries aren’t being well maintained and it’s causing some pain. 7:32 – Panel: I remember this one case when I was working with an engineer and he was working on backend stuff. He was like I don’t understand here is JSS and JavaScript. Did you have those cultural differences? 8:27 – Carly: Yeah, definitely. You will see a thousand two-thousand lines that are written by us and it’s impossible to know how it hooks-up, etc. It’s painful to work with and some of the internal tooling nobody is updating. That served a forcing mechanism b/c we built tons of the frontend that it’s so complicated and we are paralyzed. That served us b/c frontend is hard and we just can’t go plopping around wherever we want. That’s how they tried to use Backbone. We never hired a specific frontend engineer. We just kept hiring backend to learn frontend. It’s harder to hire someone to avoid those mistakes. They will have to learn the hard way, where a Senior Developer can help. Even our Backbone apps were heavy and hard to work with. At that time we thought we were going to go to React. We thought we could hire someone with true frontend experience. We started an interview process and hard to get off the ground. We have gotten a lot better b/c we have Senior and Principle engineers to help. 12:12 – Panel: This isn’t easy and this is hard. Building UIs are extremely difficult. 13:06 – Carly: I have an old manager that posted a quote...that just shows how much things are changing. These are advanced strategies. On the backend you have all of these services and go to AWS. However, on the frontend the problems aren’t solved, yet. WE don’t have a perfect answer. A lot of the dynamics are interesting and the right answers are yet to be found. 14:32 – Panel: I think that in some ways, an application we are finding better ways with static websites and blogs through the WordPress model. We are finding practices to enable people to build intricate things. 15:07 – Panel: I used C++ in the beginning of my career. I use a framework called QT. QT is good to building native UIs, but it’s extremely complicated and difficult. And thinking about that from the idea of building not only a UI, but also...we are essentially using tools that aren’t supposed to be used in the way they were designed. 16:46 – Carly: I agree. When I was using style components at the beginning – after you do it for a while it’s not weird anymore. It’s great not to have to reuse things. I hear a lot of people concerned with these separations, but maybe they were 3 separate concerns. Maybe one component is one concern, if you will. 17:59 – Panel: I agree. If you look at the page model vs. the web model...you want a button to look like THAT button. You want them to look the same, it’s a component or an app. Maybe if you have a Wikipedia page where you have headers and sections, the CSS model makes sense on that particular domain, but with application it’s so complicated. I am a fan of cell components, and... Things are getting better. Another topic – we are in this frontend world and one big problem with the old days was reliability. You talked a lot about testing in the frontend. Let’s talk about testing in your professional life. 19:48 – Carly: I moved slowly into backend, and it’s comfortable that you knew you weren’t going to break anything. This testing stuff is great and I actually love it. We need to figure it out on the frontend, too. I built a bunch of tools that doctors use. We started thinking about what can we do to make the frontend more testable. 21:40 – Panel: I call that: Layer Oriented Design. 21:51 – Carly: When we were on Backbone we used this screen-shot testing framework. We obviously should be focusing on how we made this app rather than how do we test frontend code. But we did it. You could have a Backbone view... 22:43 – Advertisement – FRESH BOOKS! 23:47 – Nader: How would you change the pictures – were you running it through what? 24:02 – Carly: An array of pixel colors. 24:10 – Carly: It was cool! We called it Lena. We used it for a year or so and it caught some bugs and it did other things. We built Percy and Storybook. We are ahead of the game with that. In general that is what we have moved to instead. 25:30 – Panel: What is Percy? 25:37 – Carly: It will render your components, then it will grab...and every time you push code it will compare the old/new screenshot. You can do mobile stuff, too, which is awesome. 26:25 – Panel: When I saw the Percy tests – I thought: this makes a difference! 26:48 – Carly: How do you know if this random stuff matters? 27:15 – Panel: It makes a huge impact. Percy can give it to you and easier to review code that has visual changes. If you added a border and you can see all the red sea of change, so let’s use a border box, etc. It’s really mind-blowing! They have a GitHub hook. If there are changes people have to improve. 28:22 – Panel: You mentioned it supporting a bunch of different browsers? What sort of context does Percy run in? Does it have a specific execution...? 28:44 – Carly: Options in Firefox and Chrome so far. People at Percy talk about cross-browsers and it will have a pipeline. It’s really hard to do. Who knows if it will come but we will see. 29:13 – Panel: How do we ensure that things are continuing to work across the browsers? Did we render anything that is completely broke? How do you do testing across browsers? 29:44 – Carly: Yeah, we use Browser Stack. We run Selenium IO. 31:12 – Nader: It sounds like you have great tools on the frontend. Nader asks a question. 31:28 – Carly: We have a fairly broken-up frontend. If someone changes something... Running all of those tests can get crazy. 32:11 – Panel: Cypress... Why did you decide on Cypress – what has been your experience with that? 32:35 – Carly: I have not yet figured out a good debugging experience, and I don’t know how you guys are doing it? It’s impossible to debug and it’s not a pleasant experience. I saw Cypress’ advertisement and you can see the difference. They highlight the target, etc. I had to try it! In just a little app that I have – I tested it there. I thought it was awesome b/c it will show you where it failed, etc. I had to get everyone on board and tried to persuade my team to use it. I used these slides and presented it, and it worked fine. It didn’t flake at all. People had to work with the tests and work with Cypress to get the feel for it. Everyone decided to use it, too. 35:16 – Panel: The spread of knowledge and it goes back to the beginning. What is this secret group: Frontend Guild? 35:33 – Carly answers the question. 37:04 – Panel: How does knowledge spread happen in other companies? Such different companies and different scales – how does that happen? 37:23 – Panel: As your company grows, communication is definitely a hard thing to accomplish. At ARTSY we try to do different things. One of our principles is...we try to document everything that goes on. Document from a process-level, and other levels, too. We have working practice groups (like the Guild) we talk about frontend issues, and other topics. Lots of meetings and lunch and learns (show and tell). We bring in outsiders in to the company to share their information. 38:57 – Nader: At AWS we have Meetups that are internal and external. We have talks, too. Every week you can find a few dozen talks around AWS and/or Amazon. You can take an hour or two out of your day to check those out. We also have demo-days that can show people what they are working on. 40:06 – Panel: Demo-days sounds very exciting. 40:49 – Panel: Find out what motivates people and go from there. 40:57 – Panel: Security as a healthcare company there is a lot of regulations, paper, and you have to keep up with standards. Can you talk about that? 41:20 – Carly: Yes, GitHub has a great feature... 43:20 – Carly: A Web Package I saw recently, and it’s called NPM / audit resolve. 44:40 – Panel: That audit resolve was purchased by NPM. Yeah, we primarily use... 45:04 – Carly: This stuff was existing out there before, and now we know. 45:12 – Panel: There is s this cognitive load that is just sitting out there. Being aware of what licenses out use and the features that you aren’t actively investing in. Building something is more than just putting JavaScript on the page – there are more concerns. 46:19 – Panel. 46:25 – Panel: Building the product is just the tip of the iceberg. It’s all of the other things you have to do to make the delivery good. 46:49 – Carly: I agree – especially on the performance-side. 48:00 – Panel: I would like to talk about these topics now: Monitoring and CI. How do you set that up? 48:19 – Carly: We have these things called Bundlesize. 49:06 – Panel: What’s the name of the library called? 49:10 – Carly: Bundlesize, I think. 50:41 – Nader: That’s all the time I have for today and thanks for coming on the show, Carly! 51:12 – Panel: Wait! Picks! 51:23 – Advertisement – Get A Coder Job! End – Cache Fly Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub Get A Coder Job Charles Max Wood’s Twitter Lenna Percy.io Percy – GitHub GitHub – Bundlesize NPM – Audit Resolver Meet Libby Backbone React – Blog The Selfish Gene Cypress.io Carly Litchfield LinkedIn Carly Litchfield Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI Picks: Lucas App – Libby Carly Book: The Selfish Gene Justin TestCafé Create React 2.0
Panel: Nader Dabit Lucas Reis Justin Bennett Special Guests: Carly Litchfield In this episode, the panelists talk with Carly Litchfield who is a Full-stack engineer of React and React Native. The panel and Carly talk about frontend and backend developing and the issues that teams could face day-in and day-out. Listen to today’s episode to hear about that and much more! Show Topics: 0:00 – Kendo UI 0:30 – Nader: Welcome! Our panel is Justin, Lucas, myself, and our guest is Carly. Welcome to the show! Thanks for joining us. Introduce yourself please. 0:56 – Carly: I am a fullstack engineer at a company called Zocdoc. I have been there for 4 years, and we use C# framework. 1:17 – Nader: C# interesting! 1:26 – Nader: You can do game development and other stuff. 1:33- Carly: I haven’t gotten into game development at all, just using C# for web development. 1:50 – Nader. 1:55 – Carly. 2:08 – Nader: The topic for today is: being a frontend developer and a team that is mostly focused on backend. Also, other topics with testing if we have time. How did you get into web development? 2:32 – Carly goes into detail about how she got into web development. 5:02 – Carly: I have worked with React Native, too. 5:22 – Nader: That is my favorite thing to work with (React Native). 5:27 – Panel: Everyone was learning about this new domain and this frontend domain. How was the knowledge spread? How was it spread throughout the company? 5:50 – Carly: One of the people someone that was on this 3 – person team (Thomas) and he went around to anyone who knew React. He made a lot of tooling. He made a lot of configuration libraries. You’d have your NPM integration like everyone else. It was cool to hook it into our servers. It was crucial to help with adoption. Those libraries aren’t being well maintained and it’s causing some pain. 7:32 – Panel: I remember this one case when I was working with an engineer and he was working on backend stuff. He was like I don’t understand here is JSS and JavaScript. Did you have those cultural differences? 8:27 – Carly: Yeah, definitely. You will see a thousand two-thousand lines that are written by us and it’s impossible to know how it hooks-up, etc. It’s painful to work with and some of the internal tooling nobody is updating. That served a forcing mechanism b/c we built tons of the frontend that it’s so complicated and we are paralyzed. That served us b/c frontend is hard and we just can’t go plopping around wherever we want. That’s how they tried to use Backbone. We never hired a specific frontend engineer. We just kept hiring backend to learn frontend. It’s harder to hire someone to avoid those mistakes. They will have to learn the hard way, where a Senior Developer can help. Even our Backbone apps were heavy and hard to work with. At that time we thought we were going to go to React. We thought we could hire someone with true frontend experience. We started an interview process and hard to get off the ground. We have gotten a lot better b/c we have Senior and Principle engineers to help. 12:12 – Panel: This isn’t easy and this is hard. Building UIs are extremely difficult. 13:06 – Carly: I have an old manager that posted a quote...that just shows how much things are changing. These are advanced strategies. On the backend you have all of these services and go to AWS. However, on the frontend the problems aren’t solved, yet. WE don’t have a perfect answer. A lot of the dynamics are interesting and the right answers are yet to be found. 14:32 – Panel: I think that in some ways, an application we are finding better ways with static websites and blogs through the WordPress model. We are finding practices to enable people to build intricate things. 15:07 – Panel: I used C++ in the beginning of my career. I use a framework called QT. QT is good to building native UIs, but it’s extremely complicated and difficult. And thinking about that from the idea of building not only a UI, but also...we are essentially using tools that aren’t supposed to be used in the way they were designed. 16:46 – Carly: I agree. When I was using style components at the beginning – after you do it for a while it’s not weird anymore. It’s great not to have to reuse things. I hear a lot of people concerned with these separations, but maybe they were 3 separate concerns. Maybe one component is one concern, if you will. 17:59 – Panel: I agree. If you look at the page model vs. the web model...you want a button to look like THAT button. You want them to look the same, it’s a component or an app. Maybe if you have a Wikipedia page where you have headers and sections, the CSS model makes sense on that particular domain, but with application it’s so complicated. I am a fan of cell components, and... Things are getting better. Another topic – we are in this frontend world and one big problem with the old days was reliability. You talked a lot about testing in the frontend. Let’s talk about testing in your professional life. 19:48 – Carly: I moved slowly into backend, and it’s comfortable that you knew you weren’t going to break anything. This testing stuff is great and I actually love it. We need to figure it out on the frontend, too. I built a bunch of tools that doctors use. We started thinking about what can we do to make the frontend more testable. 21:40 – Panel: I call that: Layer Oriented Design. 21:51 – Carly: When we were on Backbone we used this screen-shot testing framework. We obviously should be focusing on how we made this app rather than how do we test frontend code. But we did it. You could have a Backbone view... 22:43 – Advertisement – FRESH BOOKS! 23:47 – Nader: How would you change the pictures – were you running it through what? 24:02 – Carly: An array of pixel colors. 24:10 – Carly: It was cool! We called it Lena. We used it for a year or so and it caught some bugs and it did other things. We built Percy and Storybook. We are ahead of the game with that. In general that is what we have moved to instead. 25:30 – Panel: What is Percy? 25:37 – Carly: It will render your components, then it will grab...and every time you push code it will compare the old/new screenshot. You can do mobile stuff, too, which is awesome. 26:25 – Panel: When I saw the Percy tests – I thought: this makes a difference! 26:48 – Carly: How do you know if this random stuff matters? 27:15 – Panel: It makes a huge impact. Percy can give it to you and easier to review code that has visual changes. If you added a border and you can see all the red sea of change, so let’s use a border box, etc. It’s really mind-blowing! They have a GitHub hook. If there are changes people have to improve. 28:22 – Panel: You mentioned it supporting a bunch of different browsers? What sort of context does Percy run in? Does it have a specific execution...? 28:44 – Carly: Options in Firefox and Chrome so far. People at Percy talk about cross-browsers and it will have a pipeline. It’s really hard to do. Who knows if it will come but we will see. 29:13 – Panel: How do we ensure that things are continuing to work across the browsers? Did we render anything that is completely broke? How do you do testing across browsers? 29:44 – Carly: Yeah, we use Browser Stack. We run Selenium IO. 31:12 – Nader: It sounds like you have great tools on the frontend. Nader asks a question. 31:28 – Carly: We have a fairly broken-up frontend. If someone changes something... Running all of those tests can get crazy. 32:11 – Panel: Cypress... Why did you decide on Cypress – what has been your experience with that? 32:35 – Carly: I have not yet figured out a good debugging experience, and I don’t know how you guys are doing it? It’s impossible to debug and it’s not a pleasant experience. I saw Cypress’ advertisement and you can see the difference. They highlight the target, etc. I had to try it! In just a little app that I have – I tested it there. I thought it was awesome b/c it will show you where it failed, etc. I had to get everyone on board and tried to persuade my team to use it. I used these slides and presented it, and it worked fine. It didn’t flake at all. People had to work with the tests and work with Cypress to get the feel for it. Everyone decided to use it, too. 35:16 – Panel: The spread of knowledge and it goes back to the beginning. What is this secret group: Frontend Guild? 35:33 – Carly answers the question. 37:04 – Panel: How does knowledge spread happen in other companies? Such different companies and different scales – how does that happen? 37:23 – Panel: As your company grows, communication is definitely a hard thing to accomplish. At ARTSY we try to do different things. One of our principles is...we try to document everything that goes on. Document from a process-level, and other levels, too. We have working practice groups (like the Guild) we talk about frontend issues, and other topics. Lots of meetings and lunch and learns (show and tell). We bring in outsiders in to the company to share their information. 38:57 – Nader: At AWS we have Meetups that are internal and external. We have talks, too. Every week you can find a few dozen talks around AWS and/or Amazon. You can take an hour or two out of your day to check those out. We also have demo-days that can show people what they are working on. 40:06 – Panel: Demo-days sounds very exciting. 40:49 – Panel: Find out what motivates people and go from there. 40:57 – Panel: Security as a healthcare company there is a lot of regulations, paper, and you have to keep up with standards. Can you talk about that? 41:20 – Carly: Yes, GitHub has a great feature... 43:20 – Carly: A Web Package I saw recently, and it’s called NPM / audit resolve. 44:40 – Panel: That audit resolve was purchased by NPM. Yeah, we primarily use... 45:04 – Carly: This stuff was existing out there before, and now we know. 45:12 – Panel: There is s this cognitive load that is just sitting out there. Being aware of what licenses out use and the features that you aren’t actively investing in. Building something is more than just putting JavaScript on the page – there are more concerns. 46:19 – Panel. 46:25 – Panel: Building the product is just the tip of the iceberg. It’s all of the other things you have to do to make the delivery good. 46:49 – Carly: I agree – especially on the performance-side. 48:00 – Panel: I would like to talk about these topics now: Monitoring and CI. How do you set that up? 48:19 – Carly: We have these things called Bundlesize. 49:06 – Panel: What’s the name of the library called? 49:10 – Carly: Bundlesize, I think. 50:41 – Nader: That’s all the time I have for today and thanks for coming on the show, Carly! 51:12 – Panel: Wait! Picks! 51:23 – Advertisement – Get A Coder Job! End – Cache Fly Links: Ruby on Rails Angular JavaScript Elm Phoenix GitHub Get A Coder Job Charles Max Wood’s Twitter Lenna Percy.io Percy – GitHub GitHub – Bundlesize NPM – Audit Resolver Meet Libby Backbone React – Blog The Selfish Gene Cypress.io Carly Litchfield LinkedIn Carly Litchfield Twitter Sponsors: Get a Coder Job Cache Fly Fresh Books Kendo UI Picks: Lucas App – Libby Carly Book: The Selfish Gene Justin TestCafé Create React 2.0
Panel: Mark Ericksen Josh Adams Nate Hopkins Charles Max Wood Special Guest: Eric Oestrich In this episode of Elixir Mix, the panel talks with Eric Oestrich who is a web developer who resides in Indianapolis, Indiana. He and the panel talk about ExVenture, Gossip, Cowboy, Raisin, Grapevine, and much more! Listen to today’s episode to hear all about it! Finally, check out Eric’s ElixirConf talk and his blog, too! Show Topics: 0:00 – Advertisement: Get A Coder Job! 0:51 – Charles introduces the panel. 1:14 – Nate talks about his background. 1:27 – Chuck: My first programming job I worked with Nate. Nate also works now with Eric Berry. We have a special guest and that is Eric Oestrich. Tell us who you are, please! 1:55 – Eric: I work for Smart Logic, LLC. We are a consultancy who has moved to Elixir for the last 2 years. 2:14 – Chuck: Tell us what ExVenture is? 2:46 – Eric: Late 80’s to mid-90’s it’s like a MUD tech space game. Eric goes into detail of what ExVenture is. 3:28 – Panel: Familiar with MUDS. 3:36 – Panel: Audience can’t tell that Eric isn’t an old guy. Eric – you aren’t an old gentleman – how did you get into it?! 4:02 – Eric: The concept has fascinated me. It’s pure game mechanics. In school I wrote things in Python and try to make it threaded. Never got it going. After that I wanted to do a MUD but not good enough in C and couldn’t get it working in Ruby neither. But one faithful day (a year ago) I got an echo and chat server and now we have a MUD. 5:02 – Panel: Why should you be interested? I will tell you why. ExVenture is an open source... I encourage everyone to dig into and play with it! It is a game (so that makes it more fun) but you are dealing with game mechanics. I am also curious where you wanted this to go? What made you say: I want to create this and make it open source? 6:37 – Eric: I like it and work has mostly played for it. It’s MIT because of that. Early in the project (between client work) it was a common thread and that’s why it’s open source. 7:27 – Panel: I ran into you at the conference and you were showing me... Talk about getting metrics out of your system, please? 8:20 – Eric answers the question. 9:09 – Panel: When people are trying to get metrics out of their system – what EVEN makes a good metric? 9:21- Eric: I am trying to figure that out myself, actually. I want to know how long it takes for someone to login? Is that someone trying to hack into my system? If you speak at a global channel or something else... Eric goes into more detail. Eric also mentions Prometheus. 10:31 – Panel: You mentioned: What would you want to see on a dashboard? 11:01 – Eric answers the question and mentions Prometheus EX. 12:19 – Panel: As you starting building this you were pulling libraries out of it and making them separate libraries. Are you pretty proud of GOSSIP? 12:37 – Eric: Yes! Gossip is based on web sockets and it’s a cowboy socket. Eric talks about Gossip. 13:10 – Panel: What other clients are you trying to support? 13:15 – Eric: There is a JavaScript client and Node-based game called... There is a bundle system for that. There is also a Python option. The one thing we haven’t done yet is a C client. That is important b/c most of the games that you could connect to are 25-30 years old. 14:26 – Panel asks a question. 14:34 – Eric: That is the C client we are waiting for. 14:43 – Panel: You talked at the conference (see the show notes) you talked about things you learned along the way. Can you talk about your process? What kind of bottlenecks and how did you resolve those issues? 15:10 – Eric answers the question. 16:44 – Panel: Did you run out of processes? 16:47 – Eric: The VM shut-off – it was just done. That was the first go-around. 19:27 – Eric: After the ElixirConf, I wanted to see how far I could push it. Eric continues. 19:51 – Panel: I want to identify some of these principles you just talked about. First, the major block was the gen server is a single process. 20:21 – Panel. 20:24 – Panel: I think that is a common mistake when people come to Elixir in the beginning stages. How did you solve it? 20:50 – Panelist answers the above question. 21:30 – Panel: That’s one of the big things. It’s an architectural issue. Second, you mentioned really LARGE messages. You were sending around really large messages. 22:20 – Eric: For every 100 players was a gigabyte of ram – it was a lot. And that was mostly b/c every copy...when a new character enters the room then that message gets sent out then it gets copied again, and... 23:08 – Panel. 23:24 – Panel: The third one you mentioned was around data base blocking or...? Can you talk about this one a little more, please? 23:33 – Eric answers the question. 24:02 – Panel. 24:30 – Eric: It was always saving...I tricked Echo into saving...There is a lot of things that could be better to save specifically faster. 24:52 – Panel: I think people would hit those 3 points eventually – there is a lot of value to that. 25:09 –Eric: Yes that was near the end of my ElixirConf talk and my blog. 25:23 – Panel. 25:33 – Eric: It came out in May and I figured out that I needed to learn how to cluster in Elixir. That’s what the ElixirConf was a bout from single node to multiple nodes. Eric continues. 28:38 – Panel: When you have a cluster – and I join – when I transfer from one room to another room, I could be passed off to another server or node? 29:01 – Eric: Whatever you mean by “being passed off.” Whatever server you land on that’s the one you will be on. The magic is that... 30:08 – Advertisement: Fresh Books! 31:15 – Panel: I am going through the code base now and I am excited. It’s going to help me get better at Elixir. 31:32 – Eric: That’s the point of ExVenture. 31:48 – Panel: You host a server so people can see what it’s about – and that’s Mid Mud, right? 32:09 – Eric: Yep, the first hour of you playing. There is a town crier, you request, and then combat monsters. Also, it is plugged into Gossip and you can talk to them. 32:44 – Eric: Yep, there you go: player logged-in! 32:55 – Panel: Maybe not b/c it will turn into a new podcast soon. 33:07 – Panel: What if I want to use Gossip, what is involved there? 33:16 – Eric: Gossip.Haus/docs – Go there! Set it up and start sending and receiving events. 34:40 – Panel: When I was trying to understand the Prometheus metrics it helped. And then in downloading it (as a tip), for me, it was easy to use the DOCKER instructions. 35:32 – Eric: Yep, that was done by a community member. 35:40 – Panel: Are you looking for people to contribute? 35:50 – Eric: Yep, I have a public Trello board. There are 2 tags. 36:12 – Panel: Sounds like you have people involved? 36:22 – Eric: Bunch of people came on after the ElixirConf. 36:33 – Panel: If people download it (another tip) in the SEEDS file you will find out the admin username and password. I guess that’s something you can add. Login: ADMIN and Password: PASSWORD. What I thought was fun (playing with it) in the admin screen I got a sense that it’s generic enough that I could create a space game. Like playing with sectors of space. Does that make sense? 37:42 – Eric: I don’t want it to be tied JUST to fantasy b/c that’s what MUD is. Everything should be good for historical/ fantasy/ etc. any genre that you want to do! 38:13 – Panel: I could see a HackFest and the company could create one for their business. You could have a lot of fun with it. 38:38 – Panel. 38:44 – Panel: Hidden things on their websites. 38:50 – Eric: Search TEXT ADVENTURE in Google Search. See show notes below. 39:24 – Panel: There is a whole subculture that people are interested in and I didn’t know that these people existed. I think that is interesting. 39:45 – Eric: There are tons of games out there that are 20+ years old! 39:55 – Panel: What is your favorite old school MUD game? 40:02 – Eric lists his favorite old school games! One of them is Achaea! 40:51 – Panel: I like the status bars are really cool. If you haven’t played it you have a health bar. Also you have these expiring times and it’s very cool – modern MUD. 41:22 – Eric. 42:00 – Panel: You came from a Ruby background – what was your transition to Elixir like for you? How did you come to Elixir? What was that like for you? 42:15 – Eric: Yeah some of my friends were into Elixir from a functional standpoint about 2 years ago. They were reading about Phoenix and such. They wanted to see how it was going to go. 43:06 – Panel: Try by fire. Coming from Ruby to Elixir – what some advice would you give the same person? 43:37 – Eric: It was less of a culture shock b/c Phoenix was still kind of “Railsy.” 44:35 – Panel: When I was first learning ERLANG, and telling them that it was a standard library. 44:59 – Eric: It’s using Cowboys Ranch. 45:19 – Eric: There are a number of people out there that they want people to run to SSH b/c it’s more secure. 45:46 – Eric: I guess if we are on this topic about secure... 46:40 – Chuck. 46:51 – Panel: I think there is a lot of value, Eric, and the lessons you’ve learned and the path you’ve gone down. If you are new to Elixir going to ExVenture is a great way to start. 47:20 – Eric. 47:35 – Panel: Just run the format and we can do it that way. I encourage people to download it and see what it’s like as a user, and play with it as an admin. We have a Meetup coming up this Thursday. Eric is coming in virtually into our Meetup group. 48:29 – Eric: Gossip is open source. Grapevine and Raisin – check these out, too, b/c they are open source, too. 48:58 – Panel: Where can people contact you? 49:05 – Eric: Twitter! GitHub! Mudcoders.com. 49:39 – Picks! 49:44 – Ad: Lootcrate.com Links: Ruby Elixir Elm Atom.io Flutter.io JavaScript Visual Studio Code React Erlang ExVenture Ex_Venture ExVenture’s Trello Board Prometheus Prometheus EX Gossip GitHub: Gossip 2018 – Conference Talk @ Elixir Conf with Eric Oestrich Eric’s Blog Libcluster Raft – GitHub.io – The Raft Consensus Algorithm pg2 MidMUD Gossip/Haus/Docs ExVenture: Docker Environment Google: Text Adventure Achaea Cowboy SSH Grapevine Raisin ASDF Plugins Eric’s GitHub Eric’s Twitter Brooklyn Nine-Nine Elm Packages MetaBase Sponsors: Loot Crate Get a Coder Job! Fresh Books Cache Fly Picks: Eric MUD Coders Elixir LS Mark ASDF Library Josh Brooklyn Nine-Nine Elm UI Nate Mentoring and Paired Programming Metabase Charles Monster Hunters International
Panel: Dave Kimura Charles (Chuck) Max Wood Nate Hopkins Special Guest: Dan Mayer In this episode of Ruby Rogues, the panel talks with Bozhidar Batsov who is the VP of Engineering at Toptal, and an Emacs fanatic. The panel and the guest talk about RubCop, Emacs, and Komodo, among other topics! Check out today’s episode for more details. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:07 – Chuck lists the panelists and the special guest. 1:37 – Chuck: Why are you famous? 1:41 – Guest gives his background. 2:13 – Guest: I am passionate about Emacs. 2:55 – Chuck. 2:58 – Panel: I have on a few projects. Do you know RUFO? It’s a bit more opinionated than RuboCop. 3:25 – Guest: I am familiar with RUFO and their approach is similar to JavaScript called Pretty or something like that. 4:45 – Guest: 4:49 – Panel: Can you tell us what RuboCop is and why is it important? 5:00 – Guest: There are a few main things that RuboCop is: 1.) Placement for Ruby minor... 2.) Lint tool 3.) Automatic checker for all the best practices outlined in the community 4.) Formatter for Ruby code – you can feed it ugly code and it will spin out beautiful code 7:30 – Panel: What are the origins of the project? Where you interested in the performance and security aspects of it? 7:49 – Guest. The guest talks about RuboCop in detail. 10:59 – Panel: It’s important to remember that these are just guidelines and they are NOT set in stone. Using single or double quotes. As long as the project is consistent and using decent practices then I am okay with the code. I will disable the...in RuboCop. Today with high-resolution monitors it’s one of those things that are an annoyance to me. It’s just my opinion, though. 12:07 – Guest: Why disable it and not...? 13:36 – Panel: You could use VS code instead of Emacs! I am just kidding. 13:51 – Guest: I hope you are kidding! 13:56 – Chuck: I cannot live without this code... 14:06 – Guest. 14:26 – Panel: I was an early adapter from the beginning and it was hella slow. I tried it from sublime text and I got annoyed so I eventually switched to VS code. Once I got over the brand name, I really like it as my main editor. 15:20 – Panel: Maybe it’s more approachable and it’s easier to dip your toes in. 15:35 – Guest. 16:29 – Panel: I haven’t heard of KOMODO in long time. I remember that was one of the first IDs that I had checked out. I tried that then went to Ruby Mine and then tried Sublime text and then VS. 16:57 – Guest: Komodo was a famous editor. 17:17 – Panel: I am curious on RuboCop that the adaption is driven by teaching idiomatic Ruby to people new to the language? 17:40 – Guest: I don’t think it’s much about the stylistic stuff at this point. I also noticed that the main driver of the group was... Guest goes into great detail about this topic. 22:44 – Guest (continues): RuboCop offers a bunch of different structure. 24:27 – Guest (continues): We are wondering how to approach the issue of performance. The performance aspect tended to be trickier than what we had expected. The majority of developers when given the choice to either secure or make something convenient - they will choose the latter option. 25:47 – Panel: That’s why they get hit with a high AWS bill. 26:00 – Guest. 26:30 – Panel: The things you have learned with RuboCop, is it changing the direction with MRI or the design of the language at all? 26:40 – Guest: I would hope so, but I don’t have hard evidence to prove this. If you give people too many options then it could be a waste of time. I don’t care about the nuances. 30:06 – Ad: RubyMine! 30-day trial! 30:38 – Panel: Would you recommend the Rails style guide if you are building a Rails style project? Should we use that as a baseline and then customize it for your team? 30:55 – Guest: The style guide should be good. For a while I was the only editor. Not a lot of the options that are there aren’t my personal opinion, but it’s the general prescription. If you have strong preferences and you have your team agree on those then it’s okay to be modifying it. At the end of the day it’s better to have consistency within a project. You are doing great! 32:57 – Chuck asks a question. 33:44 – Chuck: Could I modify a rule? 33:53 – Guest: There are varying degrees to the rule. 35:56 – Panel: One of your conference talks you talked about the future of Rails and the future of other Ruby frameworks? 36:18 – Guest: I am worried about the future of Ruby b/c I see people talking about the maturity of the system but there isn’t a clear vision to where we are going. There are some cornerstones for Ruby 3 that he is repeating. 41:05 – Guest (continues): I think we need to commit to the module and the API. 45:42 – Chuck: All of those things make sense to me. Is there any desire for people to fork Ruby or pulling / putting some of this in? 46:00 – Guest. 48:18 – Panel: Transition that to Rails and the future of Rails? 48:27 – Panel: There are big companies that are making changes. 48:51 – Guest. 53:33 – Panel: I think that is a common pattern that most companies move towards. 54:12 – Chuck: We did an episode on ElixirMix with Chris McCord. Check that out! 54:35 – Chuck: Picks! 54:40 – Advertisement – Fresh Books! End – Cache Fly! Links: Get a Coder Job Course Ruby Rust Ruby Motion Ruby on Rails Angular Komodo Emacs RuboCop RuboCop – GitHub Stimulus reflex Messages: Share Screens Smittybilt Visual Studio Code: Introducing Visual Studio Live Share VRBO Bozhidar’s GitHub Bozhidar’s Twitter Bozhidar’s Patreon Bozhidar’s Open Collective Past EMx Episode 020 with Chris McCord! Sponsors: Sentry RubyMine Cache Fly Fresh Books Picks: Dave Tire Plugs VS Live Share Nate Share Screen using Messages on Mac Charles VRBO Find opportunities for R&R Rocket League Bozhidar Documentation for Markdown users Bear App
Panel: Aimee Knight Charles Max Wood Joe Eames AJ O’Neil Chris Ferdinandi Special Guests: Charles Lowell (New Mexico) & Taras Mankovski (Toronto) In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, Redux, and much more! Show Topics: 1:20 – Chuck: Let’s talk about microstates – what is that? 1:32 – Guest: My mind is focused on the how and not the what. I will zoom my mind out and let’s talk about the purposes of microstates. It means a few things. 1.) It’s going to work no matter what framework you are using. 2.) You shouldn’t have to be constantly reinventing the wheel. React Roundup – I talked about it there at this conference. Finally, it really needs to feel JavaScript. We didn’t want you to feel like you weren’t using JavaScript. It uses computer properties off of those models. It doesn’t feel like there is anything special that you are doing. There are just a few simple rules. You can’t mutate the state in place. If you work with JavaScript you can use it very easily. Is that a high-level view? 7:13 – Panel: There are a lot of pieces. If I spoke on a few specific things I would say that it enables programming with state machines. 7:42 – Panel: We wanted it to fell like JavaScript – that’s what I heard. 7:49 – Aimee: I heard that, too. 7:59 – Guest. 8:15 – Aimee: Redux feels like JavaScript to me. 8:25 – Guest: It’s actually – a tool – that it feels natural so it’s not contrived. It’s all JavaScript. 8:49 – Panel. 9:28 – Guest: Idiomatic Ember for example. Idiomatic in the sense that it gives you object for you to work with, which are simple objects. 10:12 – Guest: You have your reducers and your...we could do those things but ultimately it’s powerful – and not action names – we use method names; the name of the method. 11:20 – Panel: I was digging through docs, and it feels like NORMAL JavaScript. It doesn’t seem like it’s tied to a certain framework or library platform? 11:45 – Guest: Yes, we felt a lot of time designing the interfaces the API and the implementation. We wanted it to feel natural but a tool that people reach for. (Guest continues to talk about WHY they created microstates.) Guest: We wanted to scale very well what you need when your needs to change. 13:39 – Chuck: I have a lot of friends who get into React and then they put in Redux then they realize they have to do a lot of work – and that makes sense to do less is more. 14:17 – Guest: To define these microstates and build them up incrementally...building smaller microstates out of larger ones. Guest continued: Will we be able to people can distribute React components a sweet array of components ready for me to use – would I be able to do the same for a small piece of state? We call them state machines, but ultimately we have some state that is driving it. Would we be able to distribute and share? 16:15 – Panel: I understand that this is tiny – but why wouldn’t I just use the native features in specific the immutability component to it? 16:42 – Guest: I’m glad you asked that question. We wanted to answer the question... Guest: With microstates you can have strict control and it gives you the benefit of doing sophisticated things very easily. 18:33 – Guest: You mentioned immutability that’s good that you did. It’s important to capture – and capturing the naturalness of JavaScript. It’s easy to build complex structures – and there is an appeal to that. We are building these graphs and these building up these trees. You brought up immutability – why through it away b/c it’s the essence of being a developer. If you have 3-4-5 levels of nesting you have to de-structure – get to the piece of data – change it – and in your state transition 80% of your code is navigating to the change and only 20% to actually make the change. You don’t have to make that tradeoff. 21:25 – Aimee: The one thing I like about the immutability b/c of the way you test it. 21:45 – Guest: There a few things you can test. 23:01 – Aimee: You did a good job of explaining it. 23:15 – Guest: It makes the things usually hard easy! With immutability you can loose control, and if that happens you can get so confused. You don’t have a way to have a way to navigate to clarity. That’s what this does is make it less confusing. It gives you order and structure. It gives you a very clear path to do things you need to do. If there is a property on your object, and if there is a way to change it... 25:29 – Guest: The only constant is change no matter what framework you are working on. 24:46 – Chuck: We are talking about the benefits and philosophy. What if I have an app – and I realize I need state management – how do I put microstates into my app? It’s using Angular or React – how do I get my data into microstates? 26:35 – Guest: I can tell you what the integration looks like for any framework. You take a type and you passed that type and some value to the create function so what you get is a microstate. (The Guest continues diving into his answer.) 28:18 – Guest: That story is very similar to Redux, basically an event emitter. The state changes on the store. Maybe this is a good time to talk about the stability benefits and the lazy benefits because microstates is both of those things. Stability – if I invoke a transition and the result is unchanged – same microstate – it doesn’t emit an event. It recognizes it internally. It will recognize that it’s the same item. Using that in Ember or Redux you’d have to be doing thousands of actions and doing all that computation, but stability at that level. Also, stability in the sense of a tree. If I change one object then that changes it won’t change an element that it doesn’t need to change. 31:33 – Advertisement: Sentry.io 32:29 – Guest: I want to go back to your question, Chuck. Did we answer it? 32:40 – Chuck: Kind of. 32:50 – Guest. 32:59 – Guest: In Angular for example you can essentially turn a microstate... 33:51 – Guest: You could implement a connect, too. Because the primitive is small – there is no limit. 34:18 – Chuck summarizes their answers into his own words. 34:42 – Guest: If you were using a vanilla React component – this dot – I will bind this. You bind all of these features and then you pass them into your template. You can take it as a property...those are those handlers. They will perform the transition, update and what needs to be updated will happen. 35:55 – Chuck: Data and transitions are 2 separate things but you melded them together to feel like 1 thing. This way it keeps clean and fast. 36:16 – Guest: Every framework helps you in each way. Microstates let’s you do a few things: the quality of your data all in one place and you can share. 38:12 – Guest: He made and integrated Microstates with Redux tools. 38:28 – Guest talks about paths, microstates to trees. 39:22 – Chuck. 39:25 – Panel: When I think about state machines I have been half listening / half going through the docs. When I think of state machines I think about discreet operations like a literal machine. Like a robot of many steps it can step through. We have been talking about frontend frameworks like React - is this applicable to the more traditional systems like mechanical control or is it geared towards Vue layered applications? 40:23 – Guest: Absolutely. We have BIG TEST and it has a Vue component. 41:15 – Guest: when you create a microstate from a type you are creating an object that you can work with. 42:11 – Guest: Joe, I know you have experience with Angular I would love to get your insight. 42:33 – Joe: I feel like I have less experience with RX.js. A lot of what we are talking about and I am a traditionalist, and I would like you to introduce you guys to this topic. From my perspective, where would someone start if they haven’t been doing Flux pattern and I hear this podcast. I think this is a great solution – where do I get started? The official documents? Or is it the right solution to that person? 43:50 – Guest: Draw out the state machine that you want to represent in your Vue. These are the states that this can be in and this is the data that is required to get from one thing to the other. It’s a rope process. The arrow corresponds to the method, and... 44:49 – Panel: It reminds me back in the day of rational rows. 44:56 – Guest: My first job we were using rational rows. 45:22 – Panelist: Think through the state transitions – interesting that you are saying that. What about that I am in the middle – do you stop and think through it or no? 46:06 – Guest: I think it’s a Trojan horse in some ways. I think what’s interesting you start to realize how you implement your state transitions. 48:00 – (Guest continues.) 48:45 – Panel: That’s interesting. Do you have that in the docs to that process of stopping and thinking through your state transitions and putting into the microstate? 49:05 – Guest: I talked about this back in 2016. I outlined that process. When this project was in the Ember community. 49:16 – Guest: The next step for us is to make this information accessible. We’ve been shedding a few topics and saying this is how to use microstates in your project. We need to write up those guides to help them benefit in their applications. 50:00 – Chuck: What’s the future look like? 50:03 – Guest: We are working on performance profiling. Essentially you can hook up microstates to a fire hose. The next thing is settling on a pattern for modeling side effects inside microstates. Microstates are STATE and it’s immutable. 52:12 – Guest: Getting documentation. We have good README but we need traditional docs, too. 52:20 – Chuck: Anything else? 52:28 – Guest: If you need help email us and gives us a shot-out. 53:03 – Chuck: Let’s do some picks! 53:05 – Advertisement for Charles Max Wood’s course! Links: Kendo UI Frontside Redux Microstates Microstates with React Taras Mankovski’s Twitter Taras Mankovski’s GitHub Taras Mankovski’s LinkedIn Taras Mankovski’s Frontside Bio Charles Lowell’s Twitter Charles Lowell’s GitHub Charles Lowell’s Frontside Bio Schedule Once Ruby on Rails Angular Get A Coder Job YouTube Talks Email: cowboyd@frontside.io Working with State Machines Twitch TV BigTest Close Brace REEF The Developer Experience YouTube Video Sponsors: Kendo UI Sentry.io – 2 months free – DEVCHAT/code Get A Coder Job Picks: Aimee ShopTalk Episode 327 Professional JavaScript for Web Developers Technical Debt Stripe Taras Twitch Channel Big Test Frontside Charles Lowell Chalkboards Sargent Art Chalk Chris Close Brace LaCroix Water Chris’s Git Hub Joe The Developer Experience Bait and Switch Good Bye Redux Recording Dungeon and Dragons AJ UtahJS Conf Start with Why The Rust Book VanillaJS w/ Chris Zero to One Charles Podwrench.com - beta getacoderjob.com
Panel: Aimee Knight Charles Max Wood Joe Eames AJ O’Neil Chris Ferdinandi Special Guests: Charles Lowell (New Mexico) & Taras Mankovski (Toronto) In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, Redux, and much more! Show Topics: 1:20 – Chuck: Let’s talk about microstates – what is that? 1:32 – Guest: My mind is focused on the how and not the what. I will zoom my mind out and let’s talk about the purposes of microstates. It means a few things. 1.) It’s going to work no matter what framework you are using. 2.) You shouldn’t have to be constantly reinventing the wheel. React Roundup – I talked about it there at this conference. Finally, it really needs to feel JavaScript. We didn’t want you to feel like you weren’t using JavaScript. It uses computer properties off of those models. It doesn’t feel like there is anything special that you are doing. There are just a few simple rules. You can’t mutate the state in place. If you work with JavaScript you can use it very easily. Is that a high-level view? 7:13 – Panel: There are a lot of pieces. If I spoke on a few specific things I would say that it enables programming with state machines. 7:42 – Panel: We wanted it to fell like JavaScript – that’s what I heard. 7:49 – Aimee: I heard that, too. 7:59 – Guest. 8:15 – Aimee: Redux feels like JavaScript to me. 8:25 – Guest: It’s actually – a tool – that it feels natural so it’s not contrived. It’s all JavaScript. 8:49 – Panel. 9:28 – Guest: Idiomatic Ember for example. Idiomatic in the sense that it gives you object for you to work with, which are simple objects. 10:12 – Guest: You have your reducers and your...we could do those things but ultimately it’s powerful – and not action names – we use method names; the name of the method. 11:20 – Panel: I was digging through docs, and it feels like NORMAL JavaScript. It doesn’t seem like it’s tied to a certain framework or library platform? 11:45 – Guest: Yes, we felt a lot of time designing the interfaces the API and the implementation. We wanted it to feel natural but a tool that people reach for. (Guest continues to talk about WHY they created microstates.) Guest: We wanted to scale very well what you need when your needs to change. 13:39 – Chuck: I have a lot of friends who get into React and then they put in Redux then they realize they have to do a lot of work – and that makes sense to do less is more. 14:17 – Guest: To define these microstates and build them up incrementally...building smaller microstates out of larger ones. Guest continued: Will we be able to people can distribute React components a sweet array of components ready for me to use – would I be able to do the same for a small piece of state? We call them state machines, but ultimately we have some state that is driving it. Would we be able to distribute and share? 16:15 – Panel: I understand that this is tiny – but why wouldn’t I just use the native features in specific the immutability component to it? 16:42 – Guest: I’m glad you asked that question. We wanted to answer the question... Guest: With microstates you can have strict control and it gives you the benefit of doing sophisticated things very easily. 18:33 – Guest: You mentioned immutability that’s good that you did. It’s important to capture – and capturing the naturalness of JavaScript. It’s easy to build complex structures – and there is an appeal to that. We are building these graphs and these building up these trees. You brought up immutability – why through it away b/c it’s the essence of being a developer. If you have 3-4-5 levels of nesting you have to de-structure – get to the piece of data – change it – and in your state transition 80% of your code is navigating to the change and only 20% to actually make the change. You don’t have to make that tradeoff. 21:25 – Aimee: The one thing I like about the immutability b/c of the way you test it. 21:45 – Guest: There a few things you can test. 23:01 – Aimee: You did a good job of explaining it. 23:15 – Guest: It makes the things usually hard easy! With immutability you can loose control, and if that happens you can get so confused. You don’t have a way to have a way to navigate to clarity. That’s what this does is make it less confusing. It gives you order and structure. It gives you a very clear path to do things you need to do. If there is a property on your object, and if there is a way to change it... 25:29 – Guest: The only constant is change no matter what framework you are working on. 24:46 – Chuck: We are talking about the benefits and philosophy. What if I have an app – and I realize I need state management – how do I put microstates into my app? It’s using Angular or React – how do I get my data into microstates? 26:35 – Guest: I can tell you what the integration looks like for any framework. You take a type and you passed that type and some value to the create function so what you get is a microstate. (The Guest continues diving into his answer.) 28:18 – Guest: That story is very similar to Redux, basically an event emitter. The state changes on the store. Maybe this is a good time to talk about the stability benefits and the lazy benefits because microstates is both of those things. Stability – if I invoke a transition and the result is unchanged – same microstate – it doesn’t emit an event. It recognizes it internally. It will recognize that it’s the same item. Using that in Ember or Redux you’d have to be doing thousands of actions and doing all that computation, but stability at that level. Also, stability in the sense of a tree. If I change one object then that changes it won’t change an element that it doesn’t need to change. 31:33 – Advertisement: Sentry.io 32:29 – Guest: I want to go back to your question, Chuck. Did we answer it? 32:40 – Chuck: Kind of. 32:50 – Guest. 32:59 – Guest: In Angular for example you can essentially turn a microstate... 33:51 – Guest: You could implement a connect, too. Because the primitive is small – there is no limit. 34:18 – Chuck summarizes their answers into his own words. 34:42 – Guest: If you were using a vanilla React component – this dot – I will bind this. You bind all of these features and then you pass them into your template. You can take it as a property...those are those handlers. They will perform the transition, update and what needs to be updated will happen. 35:55 – Chuck: Data and transitions are 2 separate things but you melded them together to feel like 1 thing. This way it keeps clean and fast. 36:16 – Guest: Every framework helps you in each way. Microstates let’s you do a few things: the quality of your data all in one place and you can share. 38:12 – Guest: He made and integrated Microstates with Redux tools. 38:28 – Guest talks about paths, microstates to trees. 39:22 – Chuck. 39:25 – Panel: When I think about state machines I have been half listening / half going through the docs. When I think of state machines I think about discreet operations like a literal machine. Like a robot of many steps it can step through. We have been talking about frontend frameworks like React - is this applicable to the more traditional systems like mechanical control or is it geared towards Vue layered applications? 40:23 – Guest: Absolutely. We have BIG TEST and it has a Vue component. 41:15 – Guest: when you create a microstate from a type you are creating an object that you can work with. 42:11 – Guest: Joe, I know you have experience with Angular I would love to get your insight. 42:33 – Joe: I feel like I have less experience with RX.js. A lot of what we are talking about and I am a traditionalist, and I would like you to introduce you guys to this topic. From my perspective, where would someone start if they haven’t been doing Flux pattern and I hear this podcast. I think this is a great solution – where do I get started? The official documents? Or is it the right solution to that person? 43:50 – Guest: Draw out the state machine that you want to represent in your Vue. These are the states that this can be in and this is the data that is required to get from one thing to the other. It’s a rope process. The arrow corresponds to the method, and... 44:49 – Panel: It reminds me back in the day of rational rows. 44:56 – Guest: My first job we were using rational rows. 45:22 – Panelist: Think through the state transitions – interesting that you are saying that. What about that I am in the middle – do you stop and think through it or no? 46:06 – Guest: I think it’s a Trojan horse in some ways. I think what’s interesting you start to realize how you implement your state transitions. 48:00 – (Guest continues.) 48:45 – Panel: That’s interesting. Do you have that in the docs to that process of stopping and thinking through your state transitions and putting into the microstate? 49:05 – Guest: I talked about this back in 2016. I outlined that process. When this project was in the Ember community. 49:16 – Guest: The next step for us is to make this information accessible. We’ve been shedding a few topics and saying this is how to use microstates in your project. We need to write up those guides to help them benefit in their applications. 50:00 – Chuck: What’s the future look like? 50:03 – Guest: We are working on performance profiling. Essentially you can hook up microstates to a fire hose. The next thing is settling on a pattern for modeling side effects inside microstates. Microstates are STATE and it’s immutable. 52:12 – Guest: Getting documentation. We have good README but we need traditional docs, too. 52:20 – Chuck: Anything else? 52:28 – Guest: If you need help email us and gives us a shot-out. 53:03 – Chuck: Let’s do some picks! 53:05 – Advertisement for Charles Max Wood’s course! Links: Kendo UI Frontside Redux Microstates Microstates with React Taras Mankovski’s Twitter Taras Mankovski’s GitHub Taras Mankovski’s LinkedIn Taras Mankovski’s Frontside Bio Charles Lowell’s Twitter Charles Lowell’s GitHub Charles Lowell’s Frontside Bio Schedule Once Ruby on Rails Angular Get A Coder Job YouTube Talks Email: cowboyd@frontside.io Working with State Machines Twitch TV BigTest Close Brace REEF The Developer Experience YouTube Video Sponsors: Kendo UI Sentry.io – 2 months free – DEVCHAT/code Get A Coder Job Picks: Aimee ShopTalk Episode 327 Professional JavaScript for Web Developers Technical Debt Stripe Taras Twitch Channel Big Test Frontside Charles Lowell Chalkboards Sargent Art Chalk Chris Close Brace LaCroix Water Chris’s Git Hub Joe The Developer Experience Bait and Switch Good Bye Redux Recording Dungeon and Dragons AJ UtahJS Conf Start with Why The Rust Book VanillaJS w/ Chris Zero to One Charles Podwrench.com - beta getacoderjob.com
Panel: Aimee Knight Charles Max Wood Joe Eames AJ O’Neil Chris Ferdinandi Special Guests: Charles Lowell (New Mexico) & Taras Mankovski (Toronto) In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, Redux, and much more! Show Topics: 1:20 – Chuck: Let’s talk about microstates – what is that? 1:32 – Guest: My mind is focused on the how and not the what. I will zoom my mind out and let’s talk about the purposes of microstates. It means a few things. 1.) It’s going to work no matter what framework you are using. 2.) You shouldn’t have to be constantly reinventing the wheel. React Roundup – I talked about it there at this conference. Finally, it really needs to feel JavaScript. We didn’t want you to feel like you weren’t using JavaScript. It uses computer properties off of those models. It doesn’t feel like there is anything special that you are doing. There are just a few simple rules. You can’t mutate the state in place. If you work with JavaScript you can use it very easily. Is that a high-level view? 7:13 – Panel: There are a lot of pieces. If I spoke on a few specific things I would say that it enables programming with state machines. 7:42 – Panel: We wanted it to fell like JavaScript – that’s what I heard. 7:49 – Aimee: I heard that, too. 7:59 – Guest. 8:15 – Aimee: Redux feels like JavaScript to me. 8:25 – Guest: It’s actually – a tool – that it feels natural so it’s not contrived. It’s all JavaScript. 8:49 – Panel. 9:28 – Guest: Idiomatic Ember for example. Idiomatic in the sense that it gives you object for you to work with, which are simple objects. 10:12 – Guest: You have your reducers and your...we could do those things but ultimately it’s powerful – and not action names – we use method names; the name of the method. 11:20 – Panel: I was digging through docs, and it feels like NORMAL JavaScript. It doesn’t seem like it’s tied to a certain framework or library platform? 11:45 – Guest: Yes, we felt a lot of time designing the interfaces the API and the implementation. We wanted it to feel natural but a tool that people reach for. (Guest continues to talk about WHY they created microstates.) Guest: We wanted to scale very well what you need when your needs to change. 13:39 – Chuck: I have a lot of friends who get into React and then they put in Redux then they realize they have to do a lot of work – and that makes sense to do less is more. 14:17 – Guest: To define these microstates and build them up incrementally...building smaller microstates out of larger ones. Guest continued: Will we be able to people can distribute React components a sweet array of components ready for me to use – would I be able to do the same for a small piece of state? We call them state machines, but ultimately we have some state that is driving it. Would we be able to distribute and share? 16:15 – Panel: I understand that this is tiny – but why wouldn’t I just use the native features in specific the immutability component to it? 16:42 – Guest: I’m glad you asked that question. We wanted to answer the question... Guest: With microstates you can have strict control and it gives you the benefit of doing sophisticated things very easily. 18:33 – Guest: You mentioned immutability that’s good that you did. It’s important to capture – and capturing the naturalness of JavaScript. It’s easy to build complex structures – and there is an appeal to that. We are building these graphs and these building up these trees. You brought up immutability – why through it away b/c it’s the essence of being a developer. If you have 3-4-5 levels of nesting you have to de-structure – get to the piece of data – change it – and in your state transition 80% of your code is navigating to the change and only 20% to actually make the change. You don’t have to make that tradeoff. 21:25 – Aimee: The one thing I like about the immutability b/c of the way you test it. 21:45 – Guest: There a few things you can test. 23:01 – Aimee: You did a good job of explaining it. 23:15 – Guest: It makes the things usually hard easy! With immutability you can loose control, and if that happens you can get so confused. You don’t have a way to have a way to navigate to clarity. That’s what this does is make it less confusing. It gives you order and structure. It gives you a very clear path to do things you need to do. If there is a property on your object, and if there is a way to change it... 25:29 – Guest: The only constant is change no matter what framework you are working on. 24:46 – Chuck: We are talking about the benefits and philosophy. What if I have an app – and I realize I need state management – how do I put microstates into my app? It’s using Angular or React – how do I get my data into microstates? 26:35 – Guest: I can tell you what the integration looks like for any framework. You take a type and you passed that type and some value to the create function so what you get is a microstate. (The Guest continues diving into his answer.) 28:18 – Guest: That story is very similar to Redux, basically an event emitter. The state changes on the store. Maybe this is a good time to talk about the stability benefits and the lazy benefits because microstates is both of those things. Stability – if I invoke a transition and the result is unchanged – same microstate – it doesn’t emit an event. It recognizes it internally. It will recognize that it’s the same item. Using that in Ember or Redux you’d have to be doing thousands of actions and doing all that computation, but stability at that level. Also, stability in the sense of a tree. If I change one object then that changes it won’t change an element that it doesn’t need to change. 31:33 – Advertisement: Sentry.io 32:29 – Guest: I want to go back to your question, Chuck. Did we answer it? 32:40 – Chuck: Kind of. 32:50 – Guest. 32:59 – Guest: In Angular for example you can essentially turn a microstate... 33:51 – Guest: You could implement a connect, too. Because the primitive is small – there is no limit. 34:18 – Chuck summarizes their answers into his own words. 34:42 – Guest: If you were using a vanilla React component – this dot – I will bind this. You bind all of these features and then you pass them into your template. You can take it as a property...those are those handlers. They will perform the transition, update and what needs to be updated will happen. 35:55 – Chuck: Data and transitions are 2 separate things but you melded them together to feel like 1 thing. This way it keeps clean and fast. 36:16 – Guest: Every framework helps you in each way. Microstates let’s you do a few things: the quality of your data all in one place and you can share. 38:12 – Guest: He made and integrated Microstates with Redux tools. 38:28 – Guest talks about paths, microstates to trees. 39:22 – Chuck. 39:25 – Panel: When I think about state machines I have been half listening / half going through the docs. When I think of state machines I think about discreet operations like a literal machine. Like a robot of many steps it can step through. We have been talking about frontend frameworks like React - is this applicable to the more traditional systems like mechanical control or is it geared towards Vue layered applications? 40:23 – Guest: Absolutely. We have BIG TEST and it has a Vue component. 41:15 – Guest: when you create a microstate from a type you are creating an object that you can work with. 42:11 – Guest: Joe, I know you have experience with Angular I would love to get your insight. 42:33 – Joe: I feel like I have less experience with RX.js. A lot of what we are talking about and I am a traditionalist, and I would like you to introduce you guys to this topic. From my perspective, where would someone start if they haven’t been doing Flux pattern and I hear this podcast. I think this is a great solution – where do I get started? The official documents? Or is it the right solution to that person? 43:50 – Guest: Draw out the state machine that you want to represent in your Vue. These are the states that this can be in and this is the data that is required to get from one thing to the other. It’s a rope process. The arrow corresponds to the method, and... 44:49 – Panel: It reminds me back in the day of rational rows. 44:56 – Guest: My first job we were using rational rows. 45:22 – Panelist: Think through the state transitions – interesting that you are saying that. What about that I am in the middle – do you stop and think through it or no? 46:06 – Guest: I think it’s a Trojan horse in some ways. I think what’s interesting you start to realize how you implement your state transitions. 48:00 – (Guest continues.) 48:45 – Panel: That’s interesting. Do you have that in the docs to that process of stopping and thinking through your state transitions and putting into the microstate? 49:05 – Guest: I talked about this back in 2016. I outlined that process. When this project was in the Ember community. 49:16 – Guest: The next step for us is to make this information accessible. We’ve been shedding a few topics and saying this is how to use microstates in your project. We need to write up those guides to help them benefit in their applications. 50:00 – Chuck: What’s the future look like? 50:03 – Guest: We are working on performance profiling. Essentially you can hook up microstates to a fire hose. The next thing is settling on a pattern for modeling side effects inside microstates. Microstates are STATE and it’s immutable. 52:12 – Guest: Getting documentation. We have good README but we need traditional docs, too. 52:20 – Chuck: Anything else? 52:28 – Guest: If you need help email us and gives us a shot-out. 53:03 – Chuck: Let’s do some picks! 53:05 – Advertisement for Charles Max Wood’s course! Links: Kendo UI Frontside Redux Microstates Microstates with React Taras Mankovski’s Twitter Taras Mankovski’s GitHub Taras Mankovski’s LinkedIn Taras Mankovski’s Frontside Bio Charles Lowell’s Twitter Charles Lowell’s GitHub Charles Lowell’s Frontside Bio Schedule Once Ruby on Rails Angular Get A Coder Job YouTube Talks Email: cowboyd@frontside.io Working with State Machines Twitch TV BigTest Close Brace REEF The Developer Experience YouTube Video Sponsors: Kendo UI Sentry.io – 2 months free – DEVCHAT/code Get A Coder Job Picks: Aimee ShopTalk Episode 327 Professional JavaScript for Web Developers Technical Debt Stripe Taras Twitch Channel Big Test Frontside Charles Lowell Chalkboards Sargent Art Chalk Chris Close Brace LaCroix Water Chris’s Git Hub Joe The Developer Experience Bait and Switch Good Bye Redux Recording Dungeon and Dragons AJ UtahJS Conf Start with Why The Rust Book VanillaJS w/ Chris Zero to One Charles Podwrench.com - beta getacoderjob.com
Panel: Dave Kimura Charles Max Wood David Richards Special Guest: Genadi Samokovarov In this episode of Ruby Rogues, the panel talks with Genadi Samokovarov who is a software developer and loves using Ruby. Genadi also likes dance music. You can check out his code at GitHub and his mixes on SoundCloud. Finally, he blogs about technology that he cares about. Check-out his post about a curious Proc.new case in Ruby. If you are interested in his work experience, check out his resume here. Send Genadi an email or follow his social links. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:30 – Chuck: Introduce yourself please. 1:39 – The guest talks about his background and the company he works for. 2:03 – Chuck: Did you build the web console or something else? 2:05 – Guest. 3:20 – Chuck: How do you run Ruby on the web console? 3:40 – Guest answers Chuck’s question. 4:13 – Chuck: The other question is about security concerns – you don’t want to run in production? 4:25 – Guest: No, you don’t want to do that. 4:31 – Chuck: Use at home - don’t use it on your work server. 5:15 – Panel: It’s one of those features that people overlook on Rails. You have to proactively add in a pack to launch in a web console in that particular view. A lot of times people will either throw away rays (ERB) and they are able to get the same thing but you can interact with the page w/o full rendering of the application. What I just mentioned what does a web console has a space for? 6:18 – Guest. 7:23 – Panel: What would happen – if I put a debugging code in my application and it got committed and shipped – what would happen? 7:46 – Guest answers. 8:24 – Chuck: When you deploy a production I don’t even know what this tag is? 8:33 – Guest. 9:10 – Chuck: Can I run it on Sinatra...or the other ones? 9:20 – Guest: If you make a bit of effort... 9:42 – Chuck: How does it pass things to the backend? 9:52 – Guest. 11:22 – Chuck: Let’s say you set this up and you would include the gem in the Rails app – I guess it comes by default. 11:36 – Guest. 11:58 – Panel: And if you want to embed it in a view in Rails? 12:05 – Guest. 12:06 – Chuck: That’s nice. 12:08 – Guest. 12:43 – Panel: I would think that would be the most exciting things. I know the views and how it’s included there is a little bit of a black box for me. I don’t know quite what is going on and that’s after many years of use. Being able to open the web console and see what’s going on and see what I was thinking. Sometimes when I have hard times with my code it’s because I didn’t understand the Rails way and how they organize things. So for me to take a look it dawns on me. 13:33 – Guest. 13:41 – Panel: I learned Rails on a laptop. I went to terminal mode only and I learned it really, really well. 14:21 – Guest. 14:27 – Panel: Can web console do a separate JavaScript app and then you have a Ruby API backend – can you use console any plugin to integrate with that? 15:00 – Guest. 16:20 – Panel: That’s really cool, and good note. When people are developing a gem they keep one type of Ruby or whatever. They don’t take into account that Ruby or the MRI or whatever they are using it’s cool that you are proactive keeping into account the different interpreters and it works across the platform. 16:56 – Guest: It’s a tricky business. 18:39 – Panel: So is this under active development or...? 18:45 – Guest. 18:53 – Chuck: What was the hardest part to put this together? 19:00 – Guest: Getting it to work! 19:09 – Chuck: Nope...just getting it to work. 19:15 – Guest. 20:43 – Panel: That’s something where I have been in situations where it has given back the Rails spec trace. Not the actual application – I have no idea how to debug it. Then I dig in deeper and find it’s in my application part. It is important to have that. 21:13 – Guest. 21:51 – Get A Coder Job! 22:15 – Chuck: Anything else or should we talk about the conference for a minute? 22:30 – Guest. 24:09 – Panel: So you are getting these conferences going – is there a healthy/strong Ruby following in Bulgaria, generally? 24:25 – Guest: We do Meetups. It’s pretty active and a healthy community. It’s not as strong as the States, but it’s strong. 25:26 – Panel: Nice. I find that it’s interesting – I was around with Ruby in 2004, and people have been using Ruby for a while and Rails was new. It’s fun to build an organization around that and empower people to do great things. It’s great to do work that are learning Ruby. 26:08 – Guest. 26:25 – Panel: So that’s one of my coworkers and got him using VS code and show people the light to make the switch. 26:50 – Chuck: I’ve already switched. 27:01 – Panel: We like our tools. 27:17 – Guest: I guess my people like VS code b/c it’s easier to maintain. 27:35 – Panel: Maybe my mind is so feeble-minded. 27:45 – Chuck: I turned on the EMAX for along time and turned on my EMAX in my KS code. I get the nice extras. I don’t feel like there are 10 zillion things to worry about. 28:12 – Guest. 28:21 – Panel: I think the key is the expressiveness – get it the ways I want 28:38 – Chuck: I just want to think of the fact that I am using code – and that’s a good thing. 28:54 – Guest. 29:04 – Panel: How many attendees did you have? 29:08 – Guest. 29:22 – Chuck: The conferences that I like to attend that have an attendance of 150, I like b/c it’s intimate. The larger conferences I feel lost in the crowd. It’s just different for me. 30:17 – Panel: It makes it easy to break into groups if the conference is small. 30:30 – Panel: There are so many things that the experts can teach and show to the beginners. They could teach me something that I didn’t know. It’s powerful b/c you’re talking about projects and get to know each other. 31:39 – Guest. 32:16 – Panel: One thing I like is that the attendees make a Slack channel, and the speaker can address that during the talk. Sometimes they get answered, but just in case. 32:40 – Chuck: Anything you’re working on now? 32:43 – Guest. 32:52 – Panel: Nice. 33:00 – Guest. 33:37 – Chuck: How can people find out about these different conferences? 33:50 – Guest: We have a Twitter account. 33:04 – Chuck: Let’s go to picks! 34:12 – Advertisement – Fresh Books! 41:31 – Cache Fly! Links: Get a Coder Job Course Ruby Ruby Motion Ruby on Rails Angular Ruby Issue Tracking System Libraries.io Balkan Ruby Partial Conf Chaos Group Genadi Samokovarov’s Twitter Genadi Samokovarov’s GitHub Genadi Samokovarov’s Website Sponsors: Sentry Get a Coder Job Course Fresh Books Cache Fly Picks: David Creative Quest by Quest Love The Rhythm in Everything Dave Dewalt Clamps Action Text Charles The Diabetes Code Keto Diet Endorsed Local Providers via Dave Ramsey Genadi Long Walk Freedom
Panel: Dave Kimura Charles Max Wood David Richards Special Guest: Genadi Samokovarov In this episode of Ruby Rogues, the panel talks with Genadi Samokovarov who is a software developer and loves using Ruby. Genadi also likes dance music. You can check out his code at GitHub and his mixes on SoundCloud. Finally, he blogs about technology that he cares about. Check-out his post about a curious Proc.new case in Ruby. If you are interested in his work experience, check out his resume here. Send Genadi an email or follow his social links. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:30 – Chuck: Introduce yourself please. 1:39 – The guest talks about his background and the company he works for. 2:03 – Chuck: Did you build the web console or something else? 2:05 – Guest. 3:20 – Chuck: How do you run Ruby on the web console? 3:40 – Guest answers Chuck’s question. 4:13 – Chuck: The other question is about security concerns – you don’t want to run in production? 4:25 – Guest: No, you don’t want to do that. 4:31 – Chuck: Use at home - don’t use it on your work server. 5:15 – Panel: It’s one of those features that people overlook on Rails. You have to proactively add in a pack to launch in a web console in that particular view. A lot of times people will either throw away rays (ERB) and they are able to get the same thing but you can interact with the page w/o full rendering of the application. What I just mentioned what does a web console has a space for? 6:18 – Guest. 7:23 – Panel: What would happen – if I put a debugging code in my application and it got committed and shipped – what would happen? 7:46 – Guest answers. 8:24 – Chuck: When you deploy a production I don’t even know what this tag is? 8:33 – Guest. 9:10 – Chuck: Can I run it on Sinatra...or the other ones? 9:20 – Guest: If you make a bit of effort... 9:42 – Chuck: How does it pass things to the backend? 9:52 – Guest. 11:22 – Chuck: Let’s say you set this up and you would include the gem in the Rails app – I guess it comes by default. 11:36 – Guest. 11:58 – Panel: And if you want to embed it in a view in Rails? 12:05 – Guest. 12:06 – Chuck: That’s nice. 12:08 – Guest. 12:43 – Panel: I would think that would be the most exciting things. I know the views and how it’s included there is a little bit of a black box for me. I don’t know quite what is going on and that’s after many years of use. Being able to open the web console and see what’s going on and see what I was thinking. Sometimes when I have hard times with my code it’s because I didn’t understand the Rails way and how they organize things. So for me to take a look it dawns on me. 13:33 – Guest. 13:41 – Panel: I learned Rails on a laptop. I went to terminal mode only and I learned it really, really well. 14:21 – Guest. 14:27 – Panel: Can web console do a separate JavaScript app and then you have a Ruby API backend – can you use console any plugin to integrate with that? 15:00 – Guest. 16:20 – Panel: That’s really cool, and good note. When people are developing a gem they keep one type of Ruby or whatever. They don’t take into account that Ruby or the MRI or whatever they are using it’s cool that you are proactive keeping into account the different interpreters and it works across the platform. 16:56 – Guest: It’s a tricky business. 18:39 – Panel: So is this under active development or...? 18:45 – Guest. 18:53 – Chuck: What was the hardest part to put this together? 19:00 – Guest: Getting it to work! 19:09 – Chuck: Nope...just getting it to work. 19:15 – Guest. 20:43 – Panel: That’s something where I have been in situations where it has given back the Rails spec trace. Not the actual application – I have no idea how to debug it. Then I dig in deeper and find it’s in my application part. It is important to have that. 21:13 – Guest. 21:51 – Get A Coder Job! 22:15 – Chuck: Anything else or should we talk about the conference for a minute? 22:30 – Guest. 24:09 – Panel: So you are getting these conferences going – is there a healthy/strong Ruby following in Bulgaria, generally? 24:25 – Guest: We do Meetups. It’s pretty active and a healthy community. It’s not as strong as the States, but it’s strong. 25:26 – Panel: Nice. I find that it’s interesting – I was around with Ruby in 2004, and people have been using Ruby for a while and Rails was new. It’s fun to build an organization around that and empower people to do great things. It’s great to do work that are learning Ruby. 26:08 – Guest. 26:25 – Panel: So that’s one of my coworkers and got him using VS code and show people the light to make the switch. 26:50 – Chuck: I’ve already switched. 27:01 – Panel: We like our tools. 27:17 – Guest: I guess my people like VS code b/c it’s easier to maintain. 27:35 – Panel: Maybe my mind is so feeble-minded. 27:45 – Chuck: I turned on the EMAX for along time and turned on my EMAX in my KS code. I get the nice extras. I don’t feel like there are 10 zillion things to worry about. 28:12 – Guest. 28:21 – Panel: I think the key is the expressiveness – get it the ways I want 28:38 – Chuck: I just want to think of the fact that I am using code – and that’s a good thing. 28:54 – Guest. 29:04 – Panel: How many attendees did you have? 29:08 – Guest. 29:22 – Chuck: The conferences that I like to attend that have an attendance of 150, I like b/c it’s intimate. The larger conferences I feel lost in the crowd. It’s just different for me. 30:17 – Panel: It makes it easy to break into groups if the conference is small. 30:30 – Panel: There are so many things that the experts can teach and show to the beginners. They could teach me something that I didn’t know. It’s powerful b/c you’re talking about projects and get to know each other. 31:39 – Guest. 32:16 – Panel: One thing I like is that the attendees make a Slack channel, and the speaker can address that during the talk. Sometimes they get answered, but just in case. 32:40 – Chuck: Anything you’re working on now? 32:43 – Guest. 32:52 – Panel: Nice. 33:00 – Guest. 33:37 – Chuck: How can people find out about these different conferences? 33:50 – Guest: We have a Twitter account. 33:04 – Chuck: Let’s go to picks! 34:12 – Advertisement – Fresh Books! 41:31 – Cache Fly! Links: Get a Coder Job Course Ruby Ruby Motion Ruby on Rails Angular Ruby Issue Tracking System Libraries.io Balkan Ruby Partial Conf Chaos Group Genadi Samokovarov’s Twitter Genadi Samokovarov’s GitHub Genadi Samokovarov’s Website Sponsors: Sentry Get a Coder Job Course Fresh Books Cache Fly Picks: David Creative Quest by Quest Love The Rhythm in Everything Dave Dewalt Clamps Action Text Charles The Diabetes Code Keto Diet Endorsed Local Providers via Dave Ramsey Genadi Long Walk Freedom
Panel: Dave Kimura Charles Max Wood David Richards Special Guest: Genadi Samokovarov In this episode of Ruby Rogues, the panel talks with Genadi Samokovarov who is a software developer and loves using Ruby. Genadi also likes dance music. You can check out his code at GitHub and his mixes on SoundCloud. Finally, he blogs about technology that he cares about. Check-out his post about a curious Proc.new case in Ruby. If you are interested in his work experience, check out his resume here. Send Genadi an email or follow his social links. Show Topics: 0:00 – Sentry.IO – Advertisement! 1:30 – Chuck: Introduce yourself please. 1:39 – The guest talks about his background and the company he works for. 2:03 – Chuck: Did you build the web console or something else? 2:05 – Guest. 3:20 – Chuck: How do you run Ruby on the web console? 3:40 – Guest answers Chuck’s question. 4:13 – Chuck: The other question is about security concerns – you don’t want to run in production? 4:25 – Guest: No, you don’t want to do that. 4:31 – Chuck: Use at home - don’t use it on your work server. 5:15 – Panel: It’s one of those features that people overlook on Rails. You have to proactively add in a pack to launch in a web console in that particular view. A lot of times people will either throw away rays (ERB) and they are able to get the same thing but you can interact with the page w/o full rendering of the application. What I just mentioned what does a web console has a space for? 6:18 – Guest. 7:23 – Panel: What would happen – if I put a debugging code in my application and it got committed and shipped – what would happen? 7:46 – Guest answers. 8:24 – Chuck: When you deploy a production I don’t even know what this tag is? 8:33 – Guest. 9:10 – Chuck: Can I run it on Sinatra...or the other ones? 9:20 – Guest: If you make a bit of effort... 9:42 – Chuck: How does it pass things to the backend? 9:52 – Guest. 11:22 – Chuck: Let’s say you set this up and you would include the gem in the Rails app – I guess it comes by default. 11:36 – Guest. 11:58 – Panel: And if you want to embed it in a view in Rails? 12:05 – Guest. 12:06 – Chuck: That’s nice. 12:08 – Guest. 12:43 – Panel: I would think that would be the most exciting things. I know the views and how it’s included there is a little bit of a black box for me. I don’t know quite what is going on and that’s after many years of use. Being able to open the web console and see what’s going on and see what I was thinking. Sometimes when I have hard times with my code it’s because I didn’t understand the Rails way and how they organize things. So for me to take a look it dawns on me. 13:33 – Guest. 13:41 – Panel: I learned Rails on a laptop. I went to terminal mode only and I learned it really, really well. 14:21 – Guest. 14:27 – Panel: Can web console do a separate JavaScript app and then you have a Ruby API backend – can you use console any plugin to integrate with that? 15:00 – Guest. 16:20 – Panel: That’s really cool, and good note. When people are developing a gem they keep one type of Ruby or whatever. They don’t take into account that Ruby or the MRI or whatever they are using it’s cool that you are proactive keeping into account the different interpreters and it works across the platform. 16:56 – Guest: It’s a tricky business. 18:39 – Panel: So is this under active development or...? 18:45 – Guest. 18:53 – Chuck: What was the hardest part to put this together? 19:00 – Guest: Getting it to work! 19:09 – Chuck: Nope...just getting it to work. 19:15 – Guest. 20:43 – Panel: That’s something where I have been in situations where it has given back the Rails spec trace. Not the actual application – I have no idea how to debug it. Then I dig in deeper and find it’s in my application part. It is important to have that. 21:13 – Guest. 21:51 – Get A Coder Job! 22:15 – Chuck: Anything else or should we talk about the conference for a minute? 22:30 – Guest. 24:09 – Panel: So you are getting these conferences going – is there a healthy/strong Ruby following in Bulgaria, generally? 24:25 – Guest: We do Meetups. It’s pretty active and a healthy community. It’s not as strong as the States, but it’s strong. 25:26 – Panel: Nice. I find that it’s interesting – I was around with Ruby in 2004, and people have been using Ruby for a while and Rails was new. It’s fun to build an organization around that and empower people to do great things. It’s great to do work that are learning Ruby. 26:08 – Guest. 26:25 – Panel: So that’s one of my coworkers and got him using VS code and show people the light to make the switch. 26:50 – Chuck: I’ve already switched. 27:01 – Panel: We like our tools. 27:17 – Guest: I guess my people like VS code b/c it’s easier to maintain. 27:35 – Panel: Maybe my mind is so feeble-minded. 27:45 – Chuck: I turned on the EMAX for along time and turned on my EMAX in my KS code. I get the nice extras. I don’t feel like there are 10 zillion things to worry about. 28:12 – Guest. 28:21 – Panel: I think the key is the expressiveness – get it the ways I want 28:38 – Chuck: I just want to think of the fact that I am using code – and that’s a good thing. 28:54 – Guest. 29:04 – Panel: How many attendees did you have? 29:08 – Guest. 29:22 – Chuck: The conferences that I like to attend that have an attendance of 150, I like b/c it’s intimate. The larger conferences I feel lost in the crowd. It’s just different for me. 30:17 – Panel: It makes it easy to break into groups if the conference is small. 30:30 – Panel: There are so many things that the experts can teach and show to the beginners. They could teach me something that I didn’t know. It’s powerful b/c you’re talking about projects and get to know each other. 31:39 – Guest. 32:16 – Panel: One thing I like is that the attendees make a Slack channel, and the speaker can address that during the talk. Sometimes they get answered, but just in case. 32:40 – Chuck: Anything you’re working on now? 32:43 – Guest. 32:52 – Panel: Nice. 33:00 – Guest. 33:37 – Chuck: How can people find out about these different conferences? 33:50 – Guest: We have a Twitter account. 33:04 – Chuck: Let’s go to picks! 34:12 – Advertisement – Fresh Books! 41:31 – Cache Fly! Links: Get a Coder Job Course Ruby Ruby Motion Ruby on Rails Angular Ruby Issue Tracking System Libraries.io Balkan Ruby Partial Conf Chaos Group Genadi Samokovarov’s Twitter Genadi Samokovarov’s GitHub Genadi Samokovarov’s Website Sponsors: Sentry Get a Coder Job Course Fresh Books Cache Fly Picks: David Creative Quest by Quest Love The Rhythm in Everything Dave Dewalt Clamps Action Text Charles The Diabetes Code Keto Diet Endorsed Local Providers via Dave Ramsey Genadi Long Walk Freedom
Panel: Charles Max Wood Mark Eriksen Eric Berry Special Guest: Andrew Summers In this episode of Elixir Mix, the panel talks to Andrew Summers who lives in Chicago, currently. Working on Elixir development, and here to talk about how he wrote the dialyzer pretty printer. He is a software engineer for Albert.io, makes cool stuff every day, loves punk music, and Philadelphia sports. The panel talks about the Dialyzer pretty printing, Elixir, code writing, and more! Show Topics: 1:07 – Why are you famous? 1:11 – Andrew: Answers the question. 1:34 – Chuck: Nice. Is the dialyzer printer complete pretty printing or is it more than that? 1:45 – Andrew talks. He mentions the background information on this specific printer, which was written a decade ago. 4:13 – Panel: One thing that is helpful is that it is a static code analysis. In the Elixir we are writing these spec statements. For nothing else than this type is coming out. Then this looks at the code, and your spec says you are returning this, but I can tell that you are also returning X, Y, or Z. So it is helping us see what we are declaring a code to do, and that’s really what the code is doing. 5:28 – Guest: Yes, exactly. To continue that topic here is what else it’s saying... 6:08 – Panel: Our panelist is not here, but he has had to fix code before with that problem. With Dialect Dialyzer – how do we say this library is out-of-date? The code is out-of-date. How do I get my stuff to pass – to clean up my site? 6:54 – Guest: Containing that warning. Guest goes into further detail how to problem-solve this issue. 8:02 – Panel: So you are saying that I can funnel. 8:20 – Panel & Guest go back-and-forth talking about this topic. 9:49 – Panel: I am still diving into the system. Haven’t really used the printer, yet. Panelist asks Guest a question. 10:04 – Guest: At the forefront there are some configurations to help with that. 11:16 – Panel: Why would someone not want to use this? What are the cons? 11:23 – Guest: It would have to do more with CI than anything (one con). 13:06 – Panel: Lots of people are coming to Elixir New. Great. What is the selling point? Why should someone invest his or her time in this project? 13:33 – Guest: I find looking for a type spec is one more piece of information that could help the reader that would tell them what the code should be doing. Any information from the original author to be passed down is great. Having the machine to check that, whenever you push code, it’s an imperfect check (as we were saying). If it can tell you that you did something wrong, then why not? It gives you that extra red flag. There are huge benefits to that. Same reason we write unit tests. 15:20 – Panel: You are learning Elixir right, Chuck? Panelist talks about tech specs, code writing, and learning projects. 16:25 – Panel: Here is a tip to learning. One thing that I did I came to an existing project and writing a sub-system ( as series of modules) Writing the tech specs. As they are interacting with each other, then writing Dial Elixir, and grab the output to the file path to where my code is. Within my own code find where I am inconsistent. Andrew – you could get pages of output, right? Any tips for users? 17:37 – Guest: Isolate portions of your code base. 19:27 – Chuck: I do like the idea of the umbrella. Phoenix app out into an umbrella. A sub apps and they are more centered, smaller sized. Then, yeah. Start with Dialyzer on just that project. Isolate it, and this app in the umbrella. The output is much smaller, and good success with that. Now, one of the new features you added was the language / the code that it reports is an ERLANG term. That is not familiar to most Elixir developers. Especially if you are new to it. If you are turning this into a friendly Elixir thing, then you had to learn other programs. How did you get into this path? 21:00 – Andrew: Whenever there was complicated “something” at work – I was the person to go to. As I started to do it more and more I saw patterns in the output. Things were kind of predictable, and how to format things. It synchronizes weird. What would I do to write this task? Researched. There are 2 tools = LEEX and YECC. If you have 2 files in your source directory... 22:56 – Advertisement – Digital Ocean 23:39 – Panel: It’s cool. 23:58 – Guest: It brought me back to some courses from school. I thought that was funny. They are pretty contained tools. 24:36 – Panel: Part of your motivation was from Jose. 24:49 – Guest: Yes, definitely. 25:39 – Did you have any questions for Jose? 26:35 – Panel: You added the feature of... CREDO is pretty well-known. 27:28 – Guest: Sure, I guess I did skip some of that. Andrew talked about different libraries, ERLANG modules, and so on. 28:38 – Panel: What else are you doing? 28:45 – Getting error messages fixed for version 1.0. Trying to close-up the residual things. 30:18 – Guest keeps talking about support and other bugs. Andrew: If you see something, say something. 31:00 - Panel: There are languages that run on the beam. Something to create something more standard so different languages can depend on. Is there anything like that? To help you with your tooling? 31:40 – Andrew: Good question! Some of the things that happen at the Dialyzer level, stuff just gets dropped. 33:47 – Guest: How this works all together... 35:15 – Chuck: How to contribute to Dialyxir? 35:30 – Guest: Around error messages – is the best place to look. If you have a good editor hand, good place for that. If you are further into the compiler land – might want to play with that. 36:29 – Guest: ERLEX 36:43 – Chuck: What did you learn about building these libraries? 36:55 – Guest: I learned a lot about the construction of Elixir. Guest dives into this more. 38:25 – Chuck: The principle that you cannot bind... 38:51 – Guest: ...this area of my code-base... it would be nice to turn off those features. When I really do need it – I need it, but not so if I don’t need it. 39:39 – Panel: I want to point someone to a resource: TypeSpecs. 39:54 – Guest: I used that so much! Wonderful resource, I learned so much stuff! I stole all the output from that. I didn’t know that language had that?! 40:20 – Panel chimes in about this resource some more. 41:02 – Guest: We really do have a simple language. There are some weird things, but not a lot of constructs under the hood. Only a few data structures. It could have been more complicated. I was worried about that – but that never happened, because... 41:41 – Panel: Thanks for adding that. Very true. 42:51 – Guest talks about other things that are very simple, too. 44:35 – Panel: Are you doing fulltime with Elixir for programming? 44:35 – Guest: Yes, we are using other Elixir and JS App. In another life I used... They all can teach you something. Sometimes the journey of going there and realizing WHY you don’t want to be there is sometimes worth the journey! 45:20 – Panel asks guest a question. 45:25 – Guest answers question. Andrew: We have enjoyed our time in Elixir. It’s nice. 46:27 – Panel: Anything else? 46:33 – Panel: Where can people find you online? 46:40 – Guest: Elixir Slack, Twitter, GitHub. 47:01 – Picks! 47:05 – Advertisement – Code Badges Links: Andrew Summers’ Twitter Credo Erlang Dialyxir LEEX YECC Credo ERLEX TypeSpecs Curated Dev News for Busy Developers EX_JSON_SCHEMA React – Jsonschema – form Announcing Distillery 2.0 Distillery’s documentation! MKDocs EX_Json_Schema Sponsors: Get a Coder Job Digital Ocean Code Badges Cache Fly Picks: Eric Chrome Extension for News Mark Announcing Distillery 2.0 MKdocs https://hexdocs.pm/distillery/home.html. Charles Launch by Jeff Walker Downcast Andrew Ex json Schema React json schema from
Panel: Charles Max Wood Mark Eriksen Eric Berry Special Guest: Andrew Summers In this episode of Elixir Mix, the panel talks to Andrew Summers who lives in Chicago, currently. Working on Elixir development, and here to talk about how he wrote the dialyzer pretty printer. He is a software engineer for Albert.io, makes cool stuff every day, loves punk music, and Philadelphia sports. The panel talks about the Dialyzer pretty printing, Elixir, code writing, and more! Show Topics: 1:07 – Why are you famous? 1:11 – Andrew: Answers the question. 1:34 – Chuck: Nice. Is the dialyzer printer complete pretty printing or is it more than that? 1:45 – Andrew talks. He mentions the background information on this specific printer, which was written a decade ago. 4:13 – Panel: One thing that is helpful is that it is a static code analysis. In the Elixir we are writing these spec statements. For nothing else than this type is coming out. Then this looks at the code, and your spec says you are returning this, but I can tell that you are also returning X, Y, or Z. So it is helping us see what we are declaring a code to do, and that’s really what the code is doing. 5:28 – Guest: Yes, exactly. To continue that topic here is what else it’s saying... 6:08 – Panel: Our panelist is not here, but he has had to fix code before with that problem. With Dialect Dialyzer – how do we say this library is out-of-date? The code is out-of-date. How do I get my stuff to pass – to clean up my site? 6:54 – Guest: Containing that warning. Guest goes into further detail how to problem-solve this issue. 8:02 – Panel: So you are saying that I can funnel. 8:20 – Panel & Guest go back-and-forth talking about this topic. 9:49 – Panel: I am still diving into the system. Haven’t really used the printer, yet. Panelist asks Guest a question. 10:04 – Guest: At the forefront there are some configurations to help with that. 11:16 – Panel: Why would someone not want to use this? What are the cons? 11:23 – Guest: It would have to do more with CI than anything (one con). 13:06 – Panel: Lots of people are coming to Elixir New. Great. What is the selling point? Why should someone invest his or her time in this project? 13:33 – Guest: I find looking for a type spec is one more piece of information that could help the reader that would tell them what the code should be doing. Any information from the original author to be passed down is great. Having the machine to check that, whenever you push code, it’s an imperfect check (as we were saying). If it can tell you that you did something wrong, then why not? It gives you that extra red flag. There are huge benefits to that. Same reason we write unit tests. 15:20 – Panel: You are learning Elixir right, Chuck? Panelist talks about tech specs, code writing, and learning projects. 16:25 – Panel: Here is a tip to learning. One thing that I did I came to an existing project and writing a sub-system ( as series of modules) Writing the tech specs. As they are interacting with each other, then writing Dial Elixir, and grab the output to the file path to where my code is. Within my own code find where I am inconsistent. Andrew – you could get pages of output, right? Any tips for users? 17:37 – Guest: Isolate portions of your code base. 19:27 – Chuck: I do like the idea of the umbrella. Phoenix app out into an umbrella. A sub apps and they are more centered, smaller sized. Then, yeah. Start with Dialyzer on just that project. Isolate it, and this app in the umbrella. The output is much smaller, and good success with that. Now, one of the new features you added was the language / the code that it reports is an ERLANG term. That is not familiar to most Elixir developers. Especially if you are new to it. If you are turning this into a friendly Elixir thing, then you had to learn other programs. How did you get into this path? 21:00 – Andrew: Whenever there was complicated “something” at work – I was the person to go to. As I started to do it more and more I saw patterns in the output. Things were kind of predictable, and how to format things. It synchronizes weird. What would I do to write this task? Researched. There are 2 tools = LEEX and YECC. If you have 2 files in your source directory... 22:56 – Advertisement – Digital Ocean 23:39 – Panel: It’s cool. 23:58 – Guest: It brought me back to some courses from school. I thought that was funny. They are pretty contained tools. 24:36 – Panel: Part of your motivation was from Jose. 24:49 – Guest: Yes, definitely. 25:39 – Did you have any questions for Jose? 26:35 – Panel: You added the feature of... CREDO is pretty well-known. 27:28 – Guest: Sure, I guess I did skip some of that. Andrew talked about different libraries, ERLANG modules, and so on. 28:38 – Panel: What else are you doing? 28:45 – Getting error messages fixed for version 1.0. Trying to close-up the residual things. 30:18 – Guest keeps talking about support and other bugs. Andrew: If you see something, say something. 31:00 - Panel: There are languages that run on the beam. Something to create something more standard so different languages can depend on. Is there anything like that? To help you with your tooling? 31:40 – Andrew: Good question! Some of the things that happen at the Dialyzer level, stuff just gets dropped. 33:47 – Guest: How this works all together... 35:15 – Chuck: How to contribute to Dialyxir? 35:30 – Guest: Around error messages – is the best place to look. If you have a good editor hand, good place for that. If you are further into the compiler land – might want to play with that. 36:29 – Guest: ERLEX 36:43 – Chuck: What did you learn about building these libraries? 36:55 – Guest: I learned a lot about the construction of Elixir. Guest dives into this more. 38:25 – Chuck: The principle that you cannot bind... 38:51 – Guest: ...this area of my code-base... it would be nice to turn off those features. When I really do need it – I need it, but not so if I don’t need it. 39:39 – Panel: I want to point someone to a resource: TypeSpecs. 39:54 – Guest: I used that so much! Wonderful resource, I learned so much stuff! I stole all the output from that. I didn’t know that language had that?! 40:20 – Panel chimes in about this resource some more. 41:02 – Guest: We really do have a simple language. There are some weird things, but not a lot of constructs under the hood. Only a few data structures. It could have been more complicated. I was worried about that – but that never happened, because... 41:41 – Panel: Thanks for adding that. Very true. 42:51 – Guest talks about other things that are very simple, too. 44:35 – Panel: Are you doing fulltime with Elixir for programming? 44:35 – Guest: Yes, we are using other Elixir and JS App. In another life I used... They all can teach you something. Sometimes the journey of going there and realizing WHY you don’t want to be there is sometimes worth the journey! 45:20 – Panel asks guest a question. 45:25 – Guest answers question. Andrew: We have enjoyed our time in Elixir. It’s nice. 46:27 – Panel: Anything else? 46:33 – Panel: Where can people find you online? 46:40 – Guest: Elixir Slack, Twitter, GitHub. 47:01 – Picks! 47:05 – Advertisement – Code Badges Links: Andrew Summers’ Twitter Credo Erlang Dialyxir LEEX YECC Credo ERLEX TypeSpecs Curated Dev News for Busy Developers EX_JSON_SCHEMA React – Jsonschema – form Announcing Distillery 2.0 Distillery’s documentation! MKDocs EX_Json_Schema Sponsors: Get a Coder Job Digital Ocean Code Badges Cache Fly Picks: Eric Chrome Extension for News Mark Announcing Distillery 2.0 MKdocs https://hexdocs.pm/distillery/home.html. Charles Launch by Jeff Walker Downcast Andrew Ex json Schema React json schema from
Panel: Divya Sasidharan Charles Max Wood Joe Eames John Papa Chris Fritz Erik Hanchett Special Guest: Sarah Drasner In this episode, the panel talks with Jacob Schatz and Taylor Murphy who are apart of the GitLab Team. Jake is a staff developer, and Taylor is a manager at GitLab who started off as a data engineer. To find out more about the GitLab Team check them out here! Also, they are looking to hire, so inquire about the position through GitLab, if interested! The panel talks about Vue, Flux, Node, Flask, Python, D3, and much...much more! Show Topics: 1:51 – Chuck: Introduce yourselves, please. 1:55 – Backgrounds of the guests. 2:45 – Chuck. 2:51 – GitLab (GL): We first adapted Vue at the GitLab team for 2 years now. 3:34 – Chuck: What’s your workflow like through Vue? 3:50 – GL: We are using an application that...Using Python and Flask on the background. Vue CLI throughout the development. 4:35 – Panel asks a question. 4:40 – GitLab answers the question. 5:38 – Panel: Tell us about your secret project? 5:49 – GL: The data team at GL we are trying to solve these questions. How to get from resume to hire? There is data there. So that’s what Meltano helps with. Taylor has a Ph.D. in this area so he knows what’s he’s talking about. 7:30 – Taylor dives into this project via GitLab. 8:52 – GL: Super cool thing is that we are figuring out different ways to do things. It’s really cool stuff that we are doing. 9:23 – Panel: I’ve worked on projects when the frontend people and the data people are doing 2 different things. And they don’t know what each other group is doing. It’s interesting to bring the two things together. I see that teams have a hard time working together when it’s too separated. 10:31 – Panel: Can we get a definition of data scientist vs. a data engineer. 10:44 – Panel: Definitions of DATA SCIENCE and DATA ENGINEER are. 11:39 – GL: That is pretty close. Data science means different things to different people. 12:51 – Panel chimes in. 13:00 – Panel asks a question. 13:11 – GL: When I started working on Meltano... 14:26 – Panel: Looker is a visualization tool; I thought: I bet we can make that. I have been recreating something like Looker. We are trying to replace Looker. We are recreating a lot of the functionality of Looker. 15:10 – Panel will this be called...? 15:31 – Meltano analyze it’s apart of Meltano. Cool thing about Looker it has these files that show the whole visualization – drag and drop. With these files we can do version control. It’s built in – and if you drag it’s apart of a database. We took these files and we... 17:37 – Panel: Define Vue for that, please? 17:49 – GL dives into this topic. 18:40 – GL mentions Node. 18:52 – Chuck: What format does your data take? Do you have different reports that get sent? How does that work? 19:13 – GL: It tells a list of measures and dimensions. I setup our database to... 20:13 – Panel: Question. You chose Vue and it’s working. The reality you could have chosen any other tools. Why really did you choose Vue? 20:30 – GL: I know Vue really well. In the early 2000s I had my... If I have to repeat a process I always use Vue, because it’s the thing I am most comfortable with. This is how I program things very quickly. 21:10 – Panel: How has Vue met or exceeded or not met those expectations? 21:20 – GL: It has exceeded my expectations. One of the things is that as I am trying to staff a team I am trying to write Vue so when people see it they don’t think, “why would he do that?” 22:53 – Flux inspired architecture. 23:07 – GitLab continues the talk. 23:21 – Everything is Flux inspired in the sense that it was an idea to start with and then everybody made alterations and built things on top of that. 23:48 – Panel chimes in. 24:35 – Panel: Can you speak on the process of the workflow and process you work in Taylor and the data science and the frontend of it? 24:54 – GL: It’s the same but different. GitLab talks about Meltano some more, and also Taylor. GL: Taylor is trying to solve all these problems through Meltano. Maybe we can build our own tools? 26:05 – Panel: What’s a Lever Extractor?! 26:14 – GL: Answers this question. 26:25 – Panel: So it’s not a technical term...okay. 26:30 – GitLab continues the talk and discusses different tools. 27:18 – Panel: You are grabbing that data and Taylor is doing his magic? Or is it more integrated? 27:32 – GL answers this question. 29:06 – GitLab: In the beginning we are building that extractors for the other team, but later... The cool thing about Meltano is making it like Word Press. We have an extractor, different directories other things will be discovered by Meltano and discovered by the Gooey. If you write it correctly it can hook on to it. 30:00 – Digital Ocean Advertisement 31:38 – Panel: Meltano is a mix between Python and JavaScript or Vue? 30:43 – GL: Yeah... 31:20 – Panel asks question. How are you orchestrating the data? 31:32 – GL: Eventually it will happen with GitLab CUI. We are thinking we can orchestrate other ways. Right now it’s manually. 32:33 – GL: I like finding some sort of language that doesn’t have an extension...and writing... 32:54 – GL: I’m excited to use a tool that does things the right way like loading and transforming data but the frontend can be a joy to use. A previous company that I worked with and thought: It would be a joy to work with and connect to things that make sense, and do things the “right way”. I hope that’s what we can do with Meltano. I’m not a frontend person, but I appreciate it. 34:03 – GL: This is what I’m going to do...we will have these conversations between Taylor, myself, and our teams. 34:53 – Panel: This is a tool that people need to DL, maybe will you guys host this somewhere as a service. 35:10 – GL: We are trying to get this running. Small steps. It’s not out of the question and it’s not out of the question for this to be a service. 35:33 – GL: What do you want to do with the data warehouse? Your data is yours. 36:06 – Panel: Yeah, you don’t want to be in-charge of that. 36:17 – Panel: Have we asked where the name Meltano came from? 36:30 – GL: It sounds like a weird name. Here is the background of the name of “Meltano” came from. First name was from a sperm whale, it’s a unique name: Cachalot. 38:02 – GL: Conversation continues. 38:38 – Panel chimes in. 38:58 – GL: What does this program offering and doing...This was to help me with the name. 39:27 – GL: Acronym for Meltano: Model / Extract / Load / Transform / Analyze / Notebook / Orchestrate 39:47 – GL continues. They talk about notebooks. 40:19 –Sounds like a Daft Punk album! 40:28 – GL: I am trying to get more on the data science side. 40:57 – Panel: Question. Is Meltano super responsive and quick? 41:17 – GL: It depends on the size of the data, of course, but it is very responsive. 42:11 – GL: That job took 7-8 hours to extract everything for that specific project. 42:39 – GL: There are a lot of moving parts, so that could depend on it slowing it down or speeding it up. 43:01 – When you were building Meltano for your team, for the visualization how do you make decisions on what exactly you are visualizing? 43:18 – GL: That is the tricky part...you are one team. We are trying to find at a point where the data team is happy. One thing for example I put out a bar chart. Team member said that bar charts should always be vertical. So I am learning how they work and their wealth of information on visualization. 44:33 – Panel: Chris always does visualization. 44:48 – GL: Emily is on the team, and knows a lot about that. The correct way to visualize data so it doesn’t just look “cool.” You want it to be useful. Chart JS is what I use. 45:32 – Panel: I have used Chart JS before, too. 46:00 – Chris: I really like... 46:37 – Panel continues this conversation. 47:01 – Panel: Keynote will be given by...at this conference. 47:11 – GL continues to talk about this conversation. From nothing to something in a short amount of time. When I showed people: 47:55 – Panel: are you using Vue transitions? 48:09 – GL: Nope not even slightly. My plan was to use Vue transitions but it’s icing on the cake. Just get it working. 48:29 – Panel: A link of how I use... 49:14 – GL: This is a very small amount of code to where you are. It’s not like you had to re-implement triangles or anything like that. 49:36 – Panel: It does take some time but once you get it – you get it. 49:59 – Panel: When working with axis it can get hairy. 50:52 – GL: D3 really does a lot of the math for you and fits right it once you know how it works. You can draw anything with HTML. Check Links. 52:19 – Panel: There are a million different ways to do visualizations. There is math behind... 53:08 – Panel: D3 also helps with de-clustering. 53:25 – Panel: Any recommendations with someone who wants to dive into D3? 53:37 – GL: Tutorials have gotten better over time. 53:57 – Panel continues the conversation. 54:19 – GL: D3 Version 4 and 5 was one big library. You have C3 – what’s your opinion on C3? 55:00 – GL: have no strong opinions. 55:03 – Chuck chimes in. 55:18 – Panel continues this conversation. She talks about how she had a hard time learning D3, and how everything clicked once she learned it. 55:55 – GL: Main reason why I didn’t use D3 because... 56:07 – GL: If you were a “real” developer you’d... 56:35 – Panel: Let’s go to Picks! 56:40 – Advertisement – Code Badges Links: JavaScript Ruby on Rails Angular Digital Ocean Code Badge Notion Vue Meltano Looker Node Flux Taylor Python Chart JS React Chris Fritz – JS Fiddle D3 Chris Lema – Building an Online Course... Vuetify The First Vue.js Spring Vue CLI 3.0 Online Tutorials To Help You Get Ahead Hacker Noon – Finding Creativity in Software Engineer Indiegogo Create Awesome Vue.js Apps With... Data Sketches Vue.js in Action Benjamin Hardy’s Website Data Intensive: Don’t Just Hack It Together Article: How to Pick a Career...By Tim Urban Taylor A. Murphy’s Twitter Email: tmurphy@gitlab.com GitLab – Meet our Team Jacob Schatz’s Twitter Sponsors: Kendo UI Digital Ocean Code Badge Cache Fly Picks: Joe Ben Hardy on Medium Set Goals Chris Vue CLI 3 Vue CLI 3 on Medium Vue Dev Tools Get a new computer John Vuetify Divya Data Sketch One climb Finding Creativity in Software Engineering Erik Create Awesome Vue.js Vue.js in action Charles Get a Coder Job Building an online course Jacob Alma CCS Read source code Allen Kay Taylor Designing Data-Intensive Applications Wait But Why
Panel: Divya Sasidharan Charles Max Wood Joe Eames John Papa Chris Fritz Erik Hanchett Special Guest: Sarah Drasner In this episode, the panel talks with Jacob Schatz and Taylor Murphy who are apart of the GitLab Team. Jake is a staff developer, and Taylor is a manager at GitLab who started off as a data engineer. To find out more about the GitLab Team check them out here! Also, they are looking to hire, so inquire about the position through GitLab, if interested! The panel talks about Vue, Flux, Node, Flask, Python, D3, and much...much more! Show Topics: 1:51 – Chuck: Introduce yourselves, please. 1:55 – Backgrounds of the guests. 2:45 – Chuck. 2:51 – GitLab (GL): We first adapted Vue at the GitLab team for 2 years now. 3:34 – Chuck: What’s your workflow like through Vue? 3:50 – GL: We are using an application that...Using Python and Flask on the background. Vue CLI throughout the development. 4:35 – Panel asks a question. 4:40 – GitLab answers the question. 5:38 – Panel: Tell us about your secret project? 5:49 – GL: The data team at GL we are trying to solve these questions. How to get from resume to hire? There is data there. So that’s what Meltano helps with. Taylor has a Ph.D. in this area so he knows what’s he’s talking about. 7:30 – Taylor dives into this project via GitLab. 8:52 – GL: Super cool thing is that we are figuring out different ways to do things. It’s really cool stuff that we are doing. 9:23 – Panel: I’ve worked on projects when the frontend people and the data people are doing 2 different things. And they don’t know what each other group is doing. It’s interesting to bring the two things together. I see that teams have a hard time working together when it’s too separated. 10:31 – Panel: Can we get a definition of data scientist vs. a data engineer. 10:44 – Panel: Definitions of DATA SCIENCE and DATA ENGINEER are. 11:39 – GL: That is pretty close. Data science means different things to different people. 12:51 – Panel chimes in. 13:00 – Panel asks a question. 13:11 – GL: When I started working on Meltano... 14:26 – Panel: Looker is a visualization tool; I thought: I bet we can make that. I have been recreating something like Looker. We are trying to replace Looker. We are recreating a lot of the functionality of Looker. 15:10 – Panel will this be called...? 15:31 – Meltano analyze it’s apart of Meltano. Cool thing about Looker it has these files that show the whole visualization – drag and drop. With these files we can do version control. It’s built in – and if you drag it’s apart of a database. We took these files and we... 17:37 – Panel: Define Vue for that, please? 17:49 – GL dives into this topic. 18:40 – GL mentions Node. 18:52 – Chuck: What format does your data take? Do you have different reports that get sent? How does that work? 19:13 – GL: It tells a list of measures and dimensions. I setup our database to... 20:13 – Panel: Question. You chose Vue and it’s working. The reality you could have chosen any other tools. Why really did you choose Vue? 20:30 – GL: I know Vue really well. In the early 2000s I had my... If I have to repeat a process I always use Vue, because it’s the thing I am most comfortable with. This is how I program things very quickly. 21:10 – Panel: How has Vue met or exceeded or not met those expectations? 21:20 – GL: It has exceeded my expectations. One of the things is that as I am trying to staff a team I am trying to write Vue so when people see it they don’t think, “why would he do that?” 22:53 – Flux inspired architecture. 23:07 – GitLab continues the talk. 23:21 – Everything is Flux inspired in the sense that it was an idea to start with and then everybody made alterations and built things on top of that. 23:48 – Panel chimes in. 24:35 – Panel: Can you speak on the process of the workflow and process you work in Taylor and the data science and the frontend of it? 24:54 – GL: It’s the same but different. GitLab talks about Meltano some more, and also Taylor. GL: Taylor is trying to solve all these problems through Meltano. Maybe we can build our own tools? 26:05 – Panel: What’s a Lever Extractor?! 26:14 – GL: Answers this question. 26:25 – Panel: So it’s not a technical term...okay. 26:30 – GitLab continues the talk and discusses different tools. 27:18 – Panel: You are grabbing that data and Taylor is doing his magic? Or is it more integrated? 27:32 – GL answers this question. 29:06 – GitLab: In the beginning we are building that extractors for the other team, but later... The cool thing about Meltano is making it like Word Press. We have an extractor, different directories other things will be discovered by Meltano and discovered by the Gooey. If you write it correctly it can hook on to it. 30:00 – Digital Ocean Advertisement 31:38 – Panel: Meltano is a mix between Python and JavaScript or Vue? 30:43 – GL: Yeah... 31:20 – Panel asks question. How are you orchestrating the data? 31:32 – GL: Eventually it will happen with GitLab CUI. We are thinking we can orchestrate other ways. Right now it’s manually. 32:33 – GL: I like finding some sort of language that doesn’t have an extension...and writing... 32:54 – GL: I’m excited to use a tool that does things the right way like loading and transforming data but the frontend can be a joy to use. A previous company that I worked with and thought: It would be a joy to work with and connect to things that make sense, and do things the “right way”. I hope that’s what we can do with Meltano. I’m not a frontend person, but I appreciate it. 34:03 – GL: This is what I’m going to do...we will have these conversations between Taylor, myself, and our teams. 34:53 – Panel: This is a tool that people need to DL, maybe will you guys host this somewhere as a service. 35:10 – GL: We are trying to get this running. Small steps. It’s not out of the question and it’s not out of the question for this to be a service. 35:33 – GL: What do you want to do with the data warehouse? Your data is yours. 36:06 – Panel: Yeah, you don’t want to be in-charge of that. 36:17 – Panel: Have we asked where the name Meltano came from? 36:30 – GL: It sounds like a weird name. Here is the background of the name of “Meltano” came from. First name was from a sperm whale, it’s a unique name: Cachalot. 38:02 – GL: Conversation continues. 38:38 – Panel chimes in. 38:58 – GL: What does this program offering and doing...This was to help me with the name. 39:27 – GL: Acronym for Meltano: Model / Extract / Load / Transform / Analyze / Notebook / Orchestrate 39:47 – GL continues. They talk about notebooks. 40:19 –Sounds like a Daft Punk album! 40:28 – GL: I am trying to get more on the data science side. 40:57 – Panel: Question. Is Meltano super responsive and quick? 41:17 – GL: It depends on the size of the data, of course, but it is very responsive. 42:11 – GL: That job took 7-8 hours to extract everything for that specific project. 42:39 – GL: There are a lot of moving parts, so that could depend on it slowing it down or speeding it up. 43:01 – When you were building Meltano for your team, for the visualization how do you make decisions on what exactly you are visualizing? 43:18 – GL: That is the tricky part...you are one team. We are trying to find at a point where the data team is happy. One thing for example I put out a bar chart. Team member said that bar charts should always be vertical. So I am learning how they work and their wealth of information on visualization. 44:33 – Panel: Chris always does visualization. 44:48 – GL: Emily is on the team, and knows a lot about that. The correct way to visualize data so it doesn’t just look “cool.” You want it to be useful. Chart JS is what I use. 45:32 – Panel: I have used Chart JS before, too. 46:00 – Chris: I really like... 46:37 – Panel continues this conversation. 47:01 – Panel: Keynote will be given by...at this conference. 47:11 – GL continues to talk about this conversation. From nothing to something in a short amount of time. When I showed people: 47:55 – Panel: are you using Vue transitions? 48:09 – GL: Nope not even slightly. My plan was to use Vue transitions but it’s icing on the cake. Just get it working. 48:29 – Panel: A link of how I use... 49:14 – GL: This is a very small amount of code to where you are. It’s not like you had to re-implement triangles or anything like that. 49:36 – Panel: It does take some time but once you get it – you get it. 49:59 – Panel: When working with axis it can get hairy. 50:52 – GL: D3 really does a lot of the math for you and fits right it once you know how it works. You can draw anything with HTML. Check Links. 52:19 – Panel: There are a million different ways to do visualizations. There is math behind... 53:08 – Panel: D3 also helps with de-clustering. 53:25 – Panel: Any recommendations with someone who wants to dive into D3? 53:37 – GL: Tutorials have gotten better over time. 53:57 – Panel continues the conversation. 54:19 – GL: D3 Version 4 and 5 was one big library. You have C3 – what’s your opinion on C3? 55:00 – GL: have no strong opinions. 55:03 – Chuck chimes in. 55:18 – Panel continues this conversation. She talks about how she had a hard time learning D3, and how everything clicked once she learned it. 55:55 – GL: Main reason why I didn’t use D3 because... 56:07 – GL: If you were a “real” developer you’d... 56:35 – Panel: Let’s go to Picks! 56:40 – Advertisement – Code Badges Links: JavaScript Ruby on Rails Angular Digital Ocean Code Badge Notion Vue Meltano Looker Node Flux Taylor Python Chart JS React Chris Fritz – JS Fiddle D3 Chris Lema – Building an Online Course... Vuetify The First Vue.js Spring Vue CLI 3.0 Online Tutorials To Help You Get Ahead Hacker Noon – Finding Creativity in Software Engineer Indiegogo Create Awesome Vue.js Apps With... Data Sketches Vue.js in Action Benjamin Hardy’s Website Data Intensive: Don’t Just Hack It Together Article: How to Pick a Career...By Tim Urban Taylor A. Murphy’s Twitter Email: tmurphy@gitlab.com GitLab – Meet our Team Jacob Schatz’s Twitter Sponsors: Kendo UI Digital Ocean Code Badge Cache Fly Picks: Joe Ben Hardy on Medium Set Goals Chris Vue CLI 3 Vue CLI 3 on Medium Vue Dev Tools Get a new computer John Vuetify Divya Data Sketch One climb Finding Creativity in Software Engineering Erik Create Awesome Vue.js Vue.js in action Charles Get a Coder Job Building an online course Jacob Alma CCS Read source code Allen Kay Taylor Designing Data-Intensive Applications Wait But Why
© 2020-2025 Ivy Podcast Discovery LLC
