Cover image of All Ruby Podcasts by Devchat.tv
(43)

Rank #160 in How To category

Education
How To
News
Tech News

All Ruby Podcasts by Devchat.tv

Updated 4 days ago

Rank #160 in How To category

Education
How To
News
Tech News
Read more

All ruby related podcasts from Devchat.tv, including: - Ruby Rogues - My Ruby Story - Ruby Rants

Read more

All ruby related podcasts from Devchat.tv, including: - Ruby Rogues - My Ruby Story - Ruby Rants

iTunes Ratings

43 Ratings
Average Ratings
37
2
0
2
2

Quality

By Dudedudedude111 - Dec 22 2013
Read more
Smart people sharing great ideas.

Awesome

By No-one-else-has-this-nickname - Sep 22 2013
Read more
Kept me entertained while driving across the country.

iTunes Ratings

43 Ratings
Average Ratings
37
2
0
2
2

Quality

By Dudedudedude111 - Dec 22 2013
Read more
Smart people sharing great ideas.

Awesome

By No-one-else-has-this-nickname - Sep 22 2013
Read more
Kept me entertained while driving across the country.
Cover image of All Ruby Podcasts by Devchat.tv

All Ruby Podcasts by Devchat.tv

Latest release on Jan 21, 2020

Read more

All ruby related podcasts from Devchat.tv, including: - Ruby Rogues - My Ruby Story - Ruby Rants

Rank #1: RR 371: The Modular Monolith: Rails Architecture with Dan Manges

Podcast cover
Read more

Panel:

  • David Richards
  • Dave Kimura
  • Catherine Meyers

Special Guests: Dan Manges

In this episode of Ruby Rogues, the panel talks to Dan Manges about his blog post entitled The Modular Monolith: Rails Architecture. Dan is the CTO of Root, which is a car insurance carrier in Columbus, Ohio. They started the company a few years ago because they felt that the prices people pay for car insurance should be based primarily on diving behavior and not demographics. They talk about how he built the architecture of the app for his company, what a Modular Monolith is, their different gems, and more!

In particular, we dive pretty deep on:

  • Dan intro
  • CTO and Co-Founder of Root
  • Tracking driving habits of users to determine rate
  • Ruby on Rails
  • Architecture of the app
  • Back-end platform in Rails
  • Mobile as the primary interface
  • See the app in the Google Play and iTunes stores
  • Current direction for the company
  • Identify good architectural boundaries in the code base
  • Monoliths
  • What is Modular Monolith?
  • Why did you decide not to go the microservices route?
  • Microservices introduce tradeoffs in your efficiency of making changes
  • Not having a too fragmented back-end platform
  • Do you have one large schema?
  • Maintaining productivity
  • Engines
  • Separate integration tests
  • Integration tests between various components
  • Their rating engine
  • Deployments
  • His article: The Modular Monolith: Rails Architecture
  • Highly recommends their modular monolith
  • Everything is in one codebase
  • And much, much more!

Links:

Sponsors

Picks:

Dave

David

Catherine

Dan

Jul 17 2018

59mins

Play

Rank #2: 212 RR Elm with Richard Feldman and Evan Czaplicki

Podcast cover
Read more

Get your Ruby Remote Conf tickets and check out the @rubyremoteconf Twitter feed for exciting updates about the conference.

03:09 - Evan Czaplicki Introduction

03:15 - Richard Feldman Introduction

03:42 - Elm

04:18 - Elm vs JavaScript

06:52 - Reactivity

07:28 - Functional Principles

09:42 - “Side Effects” (Reactivity Cont’d)

24:19 - Syntax and Semantics

30:45 - Testing

34:49 - Debugging

42:12 - Next Release?

46:00 - Use Cases/Getting Started Resources

48:45 - Why should Ruby devs care about Elm?

Picks

The Expanse (Avdi)
Git LFS (Jessica)
The City & The City by China Miéville (Jessica)
Patterns (Coraline)
Ruby Remote Conf (Chuck)
Find a change of pace (Chuck)
Listen to other people’s views (Chuck)
Richard Feldman: Functional Frontend Frontier (Richard)
EconTalk (Evan)
elm-architecture-tutorial (Evan)

Jun 17 2015

1hr 2mins

Play

Rank #3: RR 316 Learning Rails 5 with Mark Locklear

Podcast cover
Read more

RR 316 Learning Rails 5 with Mark Locklear

On today’s episode, we have Learning Rails 5 with Mark Locklear. Mark works for Extension.org. The discussion ranges from the introduction of Learning Rails 5 to the strategies that most successful students have for learning Rails. Stay tuned!

[00:01:30] – Introduction to Mark Locklear

Mark Locklear works for Extension.org, a USDA-funded or government-funded organization. He serves the Cooperative Extension Service but a lot of people know about 4-H Youth Group. They got a handful of websites that they maintain that are mostly Ruby on Rails-based.

He has been with Extension.org for about 3 years. He is also a staff at a community college mostly doing Rails and IT things. He is also an adjunct instructor at the same community college. He was mostly doing quality assurance and testing work but moved into development work in the last 7-8 years.

Questions for Mark Locklear

[00:03:00] – You authored Learning Rails 5?

It was an actually an update on an existing book – Learning Rails 3. Mark is an adjunct instructor and used that book. He contacted the developers or the original authors in O’Reilly so he can update the book. He updated a lot of the syntax and rewrote a couple of chapters. He also wrote the authentication chapter from scratch.

[00:04:15] – What’s unique about your book?

For Mark, there are all kinds of learners out there. There’s nothing necessarily unique about this book. It approaches Rails from a standpoint of having really no development skill at all. The only assumption would be that reader knows some HTML and basic things like for loops and conditional statements.

[00:05:30] – Has Rails gotten more complicated?

That was one of the challenges with this book. The original version of the book didn’t have any API stuff, any Action Cables, or anything like that. But now, we’re looking on adding chapters on those things. Mark doesn’t think Rails is hard to learn now. It’s been pretty backward compatible over the years. It looks very much like it did 5 or 10 years ago.

Dave thinks Rails started to standardize a lot of things and with Convention over Configuration, a lot of it is taking care of it for you. The also added a lot of new features like Active Job (Rails 4), Action Cable (Rails 5), Webpack (Rails 5.1). He think that when someone gets accustomed to it, it’s almost second nature. Thanks to Convention over Configuration and the support for the community.

According to DHH, Rails is not for beginners. It is a toolkit for professional web developers to get stuff done. But Brian disagrees that it’s not for beginners. It’s not so much that it’s harder to learn but it’s just a little harder to get started with. There’s just lots of different ways you can do in a Rails application by using RSpec, Cucumber, etc.

[00:12:20] - What are the core fundamental things to know in order to write Rails apps?

Mark spends a week on testing in his class. He focuses more on the Model View Controller paradigm. He also used RSpec and the basics of CRUD. Those things are transferable across whatever framework that they choose to work in. He also want to hit testing, sessions in cookies and user authentication.

[00:18:30] - Is there an approach for people to enhance their experience as they learn Rails?

Jerome believes in the “just keep it simple” methodology. When it comes to Rails, just learn Rails. Just focus on CRUD apps. Focus on the entirety of the framework, and not only on Rails, focus more on Ruby.

Another suggestion from Brian is to start cracking open the Ruby source code, Rails source code and see how things work under the hood. Look at things and see if you can reproduce them or write your own implementations as you learn.

[00:24:30] – What are the strategies of your most successful students that you’ve had for learning Rails?

In Mark’s class, they have final projects with very strict requirements, basically going back and incorporating everything that they’ve learned. The app has to have a user authentication. It has to have sessions and cookies. And students who are most successful want to solve some problems and have the passion.

One of the things that Brian have always seen that separates people who are high performers from the rest is that they’re doing a lot of practice. Spend a lot of time practicing and building apps.

Dave encourages the listeners to work on some personal projects that they are passionate about. Deal with someone else and get some experience with some peer programming. Try to see what it’s like working with other developers on the same application, you’ll find that your codes much cleaner because you have to take into account multiple users working around the same code set.

Jerome suggests to find a mentor, someone who’s willing to spend time to help with your programs. The students who are talking to their mentors every week usually come to be the strongest. And mentoring is a rewarding two-way street.

[00:40:05] – Are there any other aspects of learning or teaching Rails that we should dive into?

Mark says you should be uncomfortable every once in a while in implementing new technology. It puts you in the same mindset as your students becomes sometimes it’s becoming incredible overwhelming. And when teaching, Brian does not start with complex examples.  He starts with simple ones.

A faculty mentor has to observe Brian in his teaching. The mentor will say, “Just a reminder. You are the guide on the side, not the sage of the stage. You’re not there to tell them everything. You’re not there to make everyone think that you’re the coolest person up there. It’s your job to guide someone to the solution.”

[00:49:25] – If I’m a Rails 3 developer, how do I learn Rails 5?           

Mark thinks that the approach is probably the same if you’re doing Rails 3 to Rails 4. The questions you will start asking yourself is, “Okay, what areas do you want to dig deeper? Do I have to use Active Job or something like that? What are my mailers? Are there additions to the framework?”

Whenever Rails releases a new version, Dave reads the blog which highlights the new features that were added in. Pinpoint those features, do a little bit of independent research and think how you could incorporate them into your application. Use them as guiding tools to upgrade your older Rails application to a more current version.

[00:52:15] – Two Writing Assignments for New Programmers

Mark wrote a Medium article entitled “Two Writing Assignments for New Programmers.” In his class, they have two writing assignments. One of it is on diversity and technology. They also use Moodle as the learning management system where they can post questions.

He got some push back from students but his explanation was that, part of being a developer is to be an effective communicator. Brian agreed and said, “Your job as a software developer is 20% coding, 80% dealing with people, their problems and their requests.” You have emails to read. You have emails to write. Brian always asks, “What are the most important skills you want our students to have?” The top 3 are always soft skills like communication, work ethics, etc.

Mark adds that if you can’t do writing, if you can’t show up to work on time and communicate with your colleagues, then, none of your technical skills matter. However, if you can’t past the technical hurdle, you’ll never get a chance to use your soft skills. Dave also adds that if he can’t get out of these people what they’re envisioning, then, they’re going nto develop the wrong things.

Picks

Dave Kimura

Brian Hogan

Jerome Hardaway

Charles Max Wood

Mark Locklear

  • Grammarly
  • History of Pi by Petr Beckmann
  • Sierra Nevada’s West Coast Stout
  • Github @marklocklear
  • Site locklear.me

Jun 27 2017

1hr 10mins

Play

Rank #4: RR 392: Crystal and Lucky with Paul Smith & Andrew Mason

Podcast cover
Read more

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:

Sponsors:

Picks:

Nate

Eric

Charles

Andrew

Paul

Dec 11 2018

1hr 2mins

Play

Rank #5: RR 385: “Ruby/Rails Testing” with Jason Swett

Podcast cover
Read more

Panel:

  • Dave Kimura
  • Eric Berry
  • Nathan Hopkins
  • David Richards

Special Guest: Jason Swett

In this episode of Ruby Rogues, the panel talks with Jason Swett who is a host of the podcast show, Ruby Testing! Jason also teaches Rails testing at CodeWithJason.com. He currently resides in the Michigan area and works for Ben Franklin Labs. Check-out today’s episode where the panelists and the guest discuss testing topics.

Show Topics:

0:00 – Sentry.IO – Advertisement!

Check out the code: DEVCHAT @ Sentry.io.

1:07 – I am David Kimura and here is the panel! Tell us what is going on?

1:38 – Jason: I started my own podcast, and have been doing that for the past few months. That’s one thing. I started a new site with CodeWithJason.com.

2:04 – You released a course?

2:10 – Jason: Total flop and it doesn’t exist, but I am doing something else.

2:24 – I bet you learned a lot by creating the course?

2:34 – Jason: The endeavor of TEACHING it has helped me a lot.

2:50 – Tell us why we should drink the Koolaid?

3:02 – Jason: What IS testing? Good question. Whether is it is manual testing or automated testing. We might was well automate it.

3:25 – If we are testing our code what does that look like?

3:34 – Jason: Not sure what you mean, but I am doing tests at a fine grain vs. coarser grain.

4:00 – Show of hands who has...?

4:19 – What different tests are there?

4:20 – Jason: Good question. One term that one person uses is different to a different person. Let’s start with unit tests vs. integration tests.

Jason dives into the similarities and differences between these 2 tests (see above).

There are different tests, such as: featured tests, acceptance tests, etc.

5:45 – What tests are THE best?

5:50 – Jason: Good question. The kind of tests you are writing depends on what type of coverage you are going for.

If I had a sign-up page for a user, I would...

7:36 – What anti-patterns are you seeing? What is your narrative in teaching people how to use them?

8:07 – Jason talks first about his background and his interaction with one of his colleagues.

8:58 – Question.

9:00 – Jason continues with his answers from 8:07.

9:32 – Jason: Feel free to chime-in. What have you done?

9:42 – I often ignore it until I feel bad and then I say: wait-a-minute I am a professional. Then I realize I ignored the problem because I was acting cowardly.

10:29 – For me it depends on the test that it is.

One gem that I found is: RSpec RETRY.

11:16 – Jason: The test is flapping because of something is wrong with the database or something else. Since you asked about anti-patterns let’s talk about that!

Rails and Angular are mentioned.

13:10 – Do you find that you back off of your unit testing when you are using integration?

13:22 – Jason: It depends on the context we are talking about.

Jason talks about featured testing, model-level testing, and more.

13:58 – What is your view on using MOCKS or FAKES. What should we be doing there?

14:10 – Jason: Going to the Angular world I understand Mocks better than now. There was a parable that I think is applicable here about the young and the old fish.

16:23 – Jason continues talking about testing things in isolation.

16:36 – Question. 

16:39 – I have been looking for an area to specialize in and I wrote an eBook. (Check out here to see the articles and books that Jason has authored.)

Then I was looking around and I wanted to see what people’s issues are with Rails? They have a hard time with testing. I wanted to help them feel competent with it.

18:03 – In your course you have how to choose a framework.

I know Ruby has several options on that front – how do you choose?

18:24 – Jason: There are 2 factors to consider.

Jason tells us what those two factors are.

Jason: Angular, React and Vue.

19:52 – Panelist: I had a conversation with a beginner and we were talking about the different tests. He said the DSL really appealed to him. The surface area of the AI made it approachable for him.

20:27 – Jason: I wished I had figured out DSL out a little better. Understanding the concept of a block. The IT is just a function and you can put parentheses in different areas and...

21:01 – That makes sense. Let’s revisit the Tweet you wrote.

21:35 – Jason: There are certain use cases where it makes sense. Where Gmail was the thing out there. At some point the Internet formed the opinion that...

22:39 – Old saying: Nobody gets fired for using Microsoft and then it was IBM. Nothing wrong with those things if that’s what you are trying to do. Sometimes we make decisions to not be criticized. We try to grab big frameworks and big codes so we are not criticized for.

23:48 – Jason: I think developers have this idea that OLD is OUTDATED. Not so. I think it’s mature, not necessarily outdated. I think it’s a pervasive idea.

24:31 – I think it suffers a bit when all the mind shares get lumped into one thing.

The panelist continues...

24:53 – Jason: I don’t know if I like this analogy.

26:00 – I agree with that sentiment. It’s crazy that the complexity has become so pervasive.

26:18 – I think of SPAs as...

26:37 – Jason: Going back to the Tweet I wrote, I am pulling in JavaScript but I am preferring to sprinkle Java into Rails.

27:02 – Absolutely. I think that’s where we agree on. Late in 2017 we had the guest...

“Use JavaScript sprinkles.”

27:49 – Panelist chimes-in.

28:37 – Jason: That make sense. Use your preexisting...

I am afraid of committing to a single framework. I don’t have anything against JavaScript but I am afraid of using only one thing when something else becomes fashionable.

29:30 – Have you found that Java sparkle approach is easy to test?

29:38 – Jason: I think it’s easier. Client server architecture...

30:10 – Advertisement: Get A Coder Job!

30:41 – Shout-out to the Rails team! What other testing frameworks are there? What if you are not the developer but you are the Quality Assurance (QA) person. They have been given the task of testing on the application.

31:30 – Jason: So someone who is not a developer and they want to test the application. I don’t want to get out of my role of expertise. I did talk to a QA engineer and I asked them: What do you do? All of his tests are manual. He does the same stuff as a Rails developer would do.

32:52 – Panelist talks about pseudo code.

34:07 – Jason: I am curious, Dave, about the non-programmer helping with tests what is the team structure?

34:23 – Dave: You will have one QA per three developers.

34:44 – Jason: If you have a QA person he is integrated within the team – that’s what has been the case for me.

35:02 – Dave: It’s a nice thing to have because we need to crank out some features and we have a good idea what is wrong with the app. We can go in there and see if our application is good, but they are combining different scenarios to do the unit tests and see what they are lacking. They are uncovering different problems that we hadn’t thought of.

36:07 – The organization has to have the right culture for that to work.

36:35 – If it’s a small team then it will help to see what everyone is doing – it’s that engagement level. If the team is too large then it could be a problem.

37:15 – Jason: Engagement between whom?

37:27 – Both.

Panelist goes into detail about different engagement levels throughout the team.

38:10 – Jason: Yeah that’s a tough thing.

38:49 – It’s interesting to see the things that are being created. Testing seems to help that out. We are getting bugs in that area or se didn’t design it well there...

We see that we need some flexibility and getting that input and having a way to solve the problems.

39:32 – Jason: Continuous deployment – let’s segue into this topic.

41:17 – Panelist: Do you have recommendations on how often we should be deploying in that system per day/week?

41:40 – Jason: We would deploy several times a day, which was great. The more the better because the more frequently you are deploying the fewer things will go wrong.

42:21 – More frequently the better and more people involved.

42:45 – Jason continues this conversation.

42:51 – Panelist: Continuous integration – any time you were say to forgo tests or being less rigid?

43:14 – Jason: I don’t test everything. I don’t write tests for things that have little risks.

43:56 – I think it is a good segue into how you write your code. If you write a code that is like spaghetti then it will be a mess. Making things easier to test.

44:48 – Jason: This is fresh in my mind because I am writing an app called Green Field.

46:32 – Uniqueness Validations, is mentioned by Jason.

47:00 – Anything else to add to testing a Rails application?

47:08 – Jason: Let’s talk about 2 things: walking skeleton and small stories.

This book is a great resource for automated testing.

Last point that I want to talk about is small stories: continues deployment and continuous delivery. If you make your stories smaller then you are making your stories crisply defined. Have some bullet points to make it really easy to answer the question. Answer the question: is this story done or not done? Someone should be able to run through the bullet points and answer that question.

50:02 – I am in favor of small stories, too. Makes you feel more productive, too.

50:14 – Work tends to lend itself to these types of stories and running a sprint.

51:22 – You don’t have to carry that burden when you go home. You might have too big of a chunk – it carries too much weight to it.

51:47 – Book the Phoenix Project. Work in progress is a bad thing. That makes sense. You want to have fewer balls in the air.

52:17 – Anything else?

52:22 – Jason: You can find me at: CodewithJason.com also Twitter! 

52:45 – Advertisement – Fresh Books!

1:01:50 – Cache Fly!

Links:

Sponsors:

Picks:

David

Nate

Eric

Dave

Jason

Oct 23 2018

1hr 2mins

Play

Rank #6: RR 428: Arming the Rebels with Rails 6 Featuring David Heinemeier Hansson

Podcast cover
Read more

Sponsors

Panel

  • David Kimura

  • Andrew Mason

  • Nate Hopkins

  • Charles Max Wood

With Special Guest: David Heinemeier Hansson

Episode Summary

Today’s guest is David Heinemeier Hansson, the creator of Ruby on Rails and co founder and CTO at Basecamp. This episode is focused on the release of Rails 6. David talks about the process of getting from Rails 5 to Rails 6 and some of the new features and frameworks in Rails 6. David describes some of the new features as ‘magical, which some people don’t like. He believes that the ‘magical’ element is a good thing because it reduces the learning curve for newcomers, so you can less time studying and more time being productive. This is important because it allows people from other platforms to jump on. Rails 6 will provide users with more frameworks so that they do not have to build all of their own solutions to common problems. David delves into how Ruby goes against the grain by providing tools and how that coincides with their philosophy. He talks about the process for deciding which problems the core team is going to tackle, how they come out of Basecamp, and Basecamp’s methodology in terms of what tools they decide to build. The panel discusses how deviating from the Rails core is almost an antipattern and how having the tools provided for them has improved their experience with Rails. 

David talks about some more upcoming frontend products and more on the process of updating Basecamp. He talks about his belief that most companies should not be inspired by how the big tech companies structure their internal teams. The conversation turns to how Shopify and Github are now running Rails 6 and how they have influenced the feature that have been added to Ruby. David believes that it’s important to focus on how to make a framework that solves problems for people but also focuses on real world results and businesses. Ruby wants to continue to “arm the rebels” by enabling small independent software makers to continue to challenge the industry giants. The show finishes with David giving some advice to new Rails programmers. 

Links

Follow DevChat on Facebook and Twitter

Picks

Andrew Mason:

Nate Hopkins:

Charles Max Wood:

David Kimura:

David Heinemeier Hansson:

Sep 03 2019

1hr 16mins

Play

Rank #7: 202 RR The Struggles New Ruby Users Have with Jake Day Williams

Podcast cover
Read more

Support our Teespring campaign! Get your Ruby Rogues unisex t-shirts, hoodies, ladies’-sized, and long-sleeve tees!

03:19 - Jake Day Williams Introduction

03:48 - What Do New People Struggle With?

04:59 - Teaching While Learning and Video Tutorials vs In-Person Training

16:59 - Responsibility

23:05 - Feedback

26:22 - Leveling Up and Monetizing Content

  • “MPP” (Multiple Payout Potential)
  • Ethics and Morals
  • Long-term Sustainability

33:26 - Impostor Syndrome and The Dunning–Kruger Effect

37:42 - Is the Ruby Community Beginner-Friendly?

42:50 - Content Production: Is it a barrier to entry?

Picks

Survivorship Bias (Saron)
Laurent Bossavit: 10X Programmer and other Myths in Software Engineering (Jessica)
Rachel Nabors: The Hating Game (Coraline)
How to Poo on a Date: The Lovers' Guide to Toilet Etiquette by Mats (David)
How to Poo at Work by Mats (David)
How to Poo on Holiday by Mats (David)
Steelheart (The Reckoners) by Brandon Sanderson (Chuck)
Gitter (Chuck)
The Entreprogrammers Podcast (Jake)
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg (Jake)
Laura Sydell: The Forgotten Female Programmers Who Created Modern Tech (Jake)

Apr 08 2015

58mins

Play

Rank #8: RR 317: Computer Science at University and the Future of Programming with Dave Thomas

Podcast cover
Read more

RR 317: Computer Science at University and the Future of Programming with Dave Thomas

Charles Max Wood interviews Dave Thomas about the Computer Science course he's teaching at Southern Methodist University, Elixir, and the future of programming. Dave is the author and co-author of several well known programming books including Programming Ruby (also known as the PickAxe Book), Programming Elixir, and the Pragmatic Programmer. This episode starts out discussing Dave's course and Computer Science education, then veers into Elixir and the future of programming. Tune in to hear where Dave thinks the programming industry is heading next.

[00:02:30] Dave's Computer Science Course at SMU 
Dave's advanced computer science course covers topics like source control and testing. He's been wanting to get into formal Computer Science for a while, so when he pulled back on his work at the Pragmatic Bookshelf, he approached SMU about teaching a course. He selected Advanced Application Development since he could teach pretty much whatever he wanted. The class is made up of Seniors and Master's students whose coursework primarily focused on theory, but lacked in the basics of coding as it happens "in the wild." The plan was to go in and subvert them with Elixir. 

All of the assignments are coding assignments and must be submitted with a pull request. Chuck recalls taking a class similar to the one that Dave describes. 

[00:06:22] Computer Science's focus on theory
People who go into academia generally get their degrees and don't spend any time in the non-academic world. So, they don't know what's important when it comes down to nuts and bolts programming. This serves the students that stay in academia, but fails to teach the skills needed by their students. They also focus on the mathematical aspects of Computer Science and fail to show students that if they get excited about software, it can be fun.

[00:09:55] This is a job where we make a difference
Sometimes we do great harm. and sometimes great good.

[00:10:23] How do you communicate all of these aspects of coding to the students?
You can't just tell them. Mostly, Dave just tries to be enthusiastic. The teaching as it's done now is like a eulogy given by someone who doesn't know the person. Instead, Dave shows his passion for coding, tells stories, and shows how fun it is to write code. Imagine walking down the street and seeing the code you wrote being used. Dave's code was used on the satellite sent to see Haley's Comet.

[00:13:04] Software as a tool for change
A painter's medium is paint. Sculptors' stone. People in software don't "write" per se, but they still express themselves. This is a medium for programmers to get their thoughts out and interact with other people all over the world. We do a really crappy job explaining this to students.

Dave is involved in after-school programs for software development as well. The ones that succeed don't approach software head on. They do fun and fancy stuff with Raspberry Pi or put a webserver up and then point out the concepts used in the programming. This approach is the future of development training.

[00:16:01] Do you feel like CS programs aren't preparing students well? or have the wrong focus?
Students come out well versed in the theoretics of programming and can write programs. These are good things to know. The assumption is that they'll pick up the rest in their first couple of jobs. They're not preparing people to walk straight into a job, but prepares them to learn the rest on the job.

A 4 year program should be done after 2 years working in the real world. Most of the things not taught don't make sense until the student has the problem that it solves. For example, source control. This would give them context for the things that are important and bring the knowledge back to the 

[00:20:26] What is in the curriculum?
In a few years, these students will probably be writing a functional language like Elixir. They start out writing a hangman game using Elixir. Then they add Phoenix. Then they add a webserver. The focus is around the fact that what you care about is state and transformations. Then someone will realize that you're really just implementing objects. Dave is trying to teach how to think in decoupled services.

[00:22:28] The future is functional?
Elixir is a practical functional language and solves some problems that programmers have been trying to solve for a long time. Clojure has a strange relationship with the JVM. Elixir is not as cleanly functional as other languages, but it's functional enough. At the same time, you can write kick-ass web services as well. You also get the power of the Erlang virtual machine.

Looking at Moore's Law, why aren't our processors getting faster? Over the last 10 years, they're not that much faster and the next generations are slower. But they have more cores. If you double the clock speed, you 8x the power dissipation. So, there's a limit to how fast you can go before you melt the processor. So, you run more cores at a lower speed. This vastly increases your processing power and lower your consumption.

If you're writing processes that run on a core from start to finish, then it only uses 1/16th of the processor's power (if it has 16 cores.) So, we need a programming paradigm that supports parallelism. Concurrent programming is hard. 

Making data immutable makes it so you can eliminate common problems with threading and concurrency. Read-only (immutable) Object Oriented programming is effectively functional programming. We should see this change occur over the next 3-7 years. 

[00:31:05] Most of the people at Ruby conferences are using Elixir
When Dave goes to conferences about Ruby, he finds out that about 50% of speakers and many of the attendees are doing Elixir and/or experimenting heavily with it. Ruby and Rails changed the way we work, but in many ways the functional programming is changing things again. Scaling matters. We can't just throw hardware at it. You can drop your server bill by 10x or 100x.

Elixir can get you there fast like Ruby, but it can also cut costs of running your server.

[00:35:43] Is a computer science degree that way to get in? or should people get in through bootcamps or self learning?
It depends on your learning style. You do not want to get into Computer Science because your parents wanted you to have a good job. The students that get into it because of family pressure don't love what they're doing and are kind of stuck. Programming is hard enough that if you don't enjoy it you won't excel.

In any case, do what works for you. You don't need to do a 4 year course of study to be a successful programmer. Quite a few good programmers Dave knows never took a CS course. If you do a course, find out that if the teachers are doing or have done the kinds of things you want to do. The better IT shops also tend to recognize that it's the person, not what they know, that really matters. So go to them and ask to apprentice with their good programmers at a lower salary. Then if you're contributing, ask for a competitive salary.

[00:41:03] What do we as programmers assume about CS degrees that we need to change?
Don't let the HR department do the hiring. Making them happy is what gets you bogus job requirements. Instead, put together some requirements that hint that enthusiasm trumps everything else. Or, have criteria like "must be able to fog a mirror" and pick for enthusiasm. Or, go to local maker groups or users groups or community colleges where the kinds of people you want are, and talk to people. Then network into the people you want. Ignore the qualifications and pay attention to the qualities.

One of the best people Dave hired was an alcoholic chemistry teacher, but he could get into a project.

[00:45:00] You don't want a career.
Spend the next 5-10 years job hopping. You want experience, not a career. You have no idea what you want to do right now, so try lots of things. Then if it's not working move on.

Picks

Charles:
Ubuntu Bash on Windows
VMWare Workstation: https://www.vmware.com/products/workstation.html

Dave:
Have something in your life that is relatively simple and relatively mechanical that you can fix if something goes wrong. (Dave tells us about his tractor.)

Jul 04 2017

54mins

Play

Rank #9: 208 RR Erlang with Francesco Cesarini

Podcast cover
Read more

Check out and sign up for Ruby Remote Conf!

02:45 - Francesco Cesarini Introduction

03:08 - Erlang Programming Language

08:23 - Francesco and Erlang

10:49 - Building a Company Around a Language (Erlang Solutions)

16:00 - The Erlang Programming Language

24:25 - Error Handling Semantics

  • Actors and Supervisors
  • The Client-Server Behavior
  • The Event Handler
  • Finite State Machines

30:23 - Getting Started with Erlang

34:23 - Elixir

35:28 - Erlang and Polyglot Architecture

37:01 - WombatOAM

38:57 - Erlang Pros and Cons

  • Cons:
    • Number Crunching
    • Parallelism
    • Graphics, Web Development, and Frontends
  • Pros:

40:44 - TDD (Test-Driven Development)

46:10 - Languages/Technologies on the Horizon (for Francesco)

48:21 - The Erlang Community

50:24 - Writing Apps with Erlang / IoT?

Picks

Avdi Grimm: A Personal Programming Language Roadmap (Avdi)
Pharo (Avdi)
Avdi Grimm: In Which I Make You Hate Ruby in 7 Minutes (Avdi)
Babel-17 / Empire Star by Samuel R. Delany (Coraline)
Orson Welles (Coraline)
John Hughes: QuickCheck Evolution @ CodeMesh 2014 (Jessica)
Vehicles: Experiments in Synthetic Psychology by Valentino Braitenberg (Jessica)
Zero to One: Notes On Startups, or How to Build the Future by Peter Thiel (Francesco)
CodeNewbie Podcast (Chuck)
Ask Me Another (Chuck)
Startups For the Rest of Us (Chuck)

May 20 2015

1hr 2mins

Play

Rank #10: RR 296 The Future of Work in Web Development with Erik Dietrich

Podcast cover
Read more

On today’s episode, Jason Swett and David Kimura discuss The Future of Work in Web Development with Erik Dietrich. Erik is the founder of DaedTech LLC, programmer, architect, IT management consultant, blogger, and technologist. Tune in and listen as he talks about where he sees things are headed in web development.

Feb 07 2017

57mins

Play

Rank #11: RR 305 Rails 5.1.0

Podcast cover
Read more

On today's episode, Charles and David discuss about Rails 5.1.0. The new release is moving the community towards front-end JavaScript. Starting a Vanilla application has even become more convenient with Yarn and Webpack support. Tune in to this exciting talk to learn more!

Apr 11 2017

52mins

Play

Rank #12: RR 297 Scaling Web Applications

Podcast cover
Read more

On today’s episode, Charles Max Wood, Jason Swett, Brian Hogan, and David Kimura discuss Scaling Web Applications. Tune in and learn more as each of them share their own experiences in scaling Ruby applications!

Feb 14 2017

49mins

Play

Rank #13: RR 304 The Rails 5 Way with Obie Fernandez

Podcast cover
Read more

Obie Fernandez is the author of The Rails Way series. He has been in the programming industry for almost 25 years. He helped cultivate software development with Jason Swett at Africa. Tune in to today's fascinating talk about The Rails 5 Way with Obie Fernandez! 

Apr 04 2017

1hr 11mins

Play

Rank #14: RR 342 Rails, Development, and More with David Heinemeier Hansson

Podcast cover
Read more

Panel:

Charles Max Wood

Dave Kimura

David Richards

Eric Berry

In this episode, the Ruby Rogues panel discuss Rails, Development, and More with David Heinemeier Hansson. David is the creator of Ruby on Rails, the founder and CTO of Basecamp, and the hosts of The ReWork Podcast.   David Answers a number of questions form the panel about the front-end on Rails, Turbo Link, Stimulus, How does this differ,  cheaper labor, better hardware, and much more. This is a great episode to understand the background of Ruby on Rails, Basecamps, and things to come with Ruby.

In particular, we dive pretty deep on: 

  • The new book The Com Company
  • Where are we going with the front-end on Rails?
  • Turbo Links
  • Stimulus
  • Redux Application
  • Productivity
  • Do you Stimulus providing enough?
  • How does this differ from new things coming out?
  • Ruby on Rails will not last…
  • Toolkits
  • Cheaper hardware
  • Basecamp
  • Higher cost of programmers
  • The Frontier
  • C in Java
  • Why don’t you hire senior experience?
  • Experience and career path
  • Remote Work
  • Paying developers enough
  • Competitive pay
  • Switching jobs and values
  • What is your vision of where Active Storage is going?
  • Cloud Storage
  • Action Cable
  • What are your thoughts on bitcoin?
  • Train wrecks and it will end badly
  • How about BlockChain and the web?
  • What is your daily driver? Cars? Watches?
  • Porche 911
  • Celebrating technological heritage
  • What is in tech that you are liking?
  • VR
  • And much much more

Links:

Picks:

Dave

David

Eric

Charles

Dec 27 2017

1hr 32mins

Play

Rank #15: RR 343: Ruby 2.5 with Jesus Castello

Podcast cover
Read more

Panel:

Charles Max Wood

Dave Kimura

David Richards

Eric Berry

In this episode, the Ruby Rogues panel discuss Ruby 2.5 with Jesus Castello. Jesus has been a developer for several years, and has learned Ruby 6 years ago and is now teaching Ruby. Jesus is on Ruby Rogues to talk about Ruby 2.5 and performance improvements and performance documentation. Also, Jesus talks about the everything Ruby 2.5 and the next editions for the language.

In particular, we dive pretty deep on: 

  • Improvements and documentation
  • Changes to the library
  • RVM - Is Great
  • System Ruby
  • What feels most natural working with
  • Preventing SkyNet!
  • Language changes
  • Top-level constant lookup is removed.
  • Rescue/else/ensure are allowed inside do/end blocks.
  • Refinements take place in string interpolations.
  • New methods like Kernel#yield_self (Discuss possible uses)
    Removed “ubygems.rb” file from stdlib. (We can talk about why this file existed & why it has been removed.)
  • Elixir and writing code fast
  • Ruby performance (Why do so many people complain about it, is it really a limiting factor for them? Would people be happy if it got 3 times faster? Ruby 3x3 project)
  • And much much more

Links:

Picks:

Dave

David

  • These is nothing new under the sun

Eric

  • White Board Tests

Charles

Jesus

Jan 04 2018

56mins

Play

Rank #16: 204 RR Limerence with Dave Thomas

Podcast cover
Read more

02:37 - Dave Thomas Introduction

04:17 - How Dave Got Started in Programming

06:34 - Tools and Constraints

  • “An Enthusiast’s Problem”?
  • Is the focus on tools a form of cargo culting?
  • Leadism Over Chosen Technologies and Its’ Effect on Innovation
  • Switching Tools and Making Excuses

19:29 - Limerence

28:54 - Ruby = Happiness: Does it Hurt?

31:00 - Tools and Falling in Love with Tools

  • Fear of Falling Behind; Fear of Irrelevancy
  • Different Tools for Different Contexts

35:08 - When Do You Learn? When Do You Train? (Not Falling Behind)

38:01 - Choosing Similar Tools and Technologies vs Choosing Different Tools and Technologies

43:36 - Relationships and Identities

46:08 - Looking Forward vs Looking Back (Knowing Your History)

01:01:48 - Is the rampant use of social media hindering the learning of big ideas?

  • Self-Curation = Key

01:08:15 - How You Learn a Language / Decide You Like a Language

Picks

Slack (Dave)
Why Does E=mc2? (And Why Should We Care?) by Brian Cox and Jeff Forshaw (Dave)
Philly Emerging Tech Conference  (Dave)

Apr 22 2015

1hr 14mins

Play

Rank #17: 211 RR DCI with Jim Gay

Podcast cover
Read more

02:48 - Jim Gay Introduction

03:43 - Object Design

04:39 - DCI (Data, Context, Interaction)

07:20 - What Painpoint DCI Aims to Solve

09:31 - Designing From DCI From the Start (Process)

11:42 - Object Composition

13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance

18:37 - DCI and Service Objects

  • Context

24:36 - Roles and Object Factoring

  • Authentication

28:49 - One Context in a Single File

30:17 - Coupling and Cohesion

31:37 - Typeclasses

33:09 - DCI Criticism

36:51 - The Current State of DCI (Skepticism & Criticism?)

38:56 - Preventing Reuse

41:18 - When should you not use DCI?

43:45 - Transition: Using/Undoing DCI (Experimentation)

45:04 - Resources

More DCI Blog Posts by Jim

Picks

Richard Hamming: You and Your Research (Jessica)
Martin Fowler: Yagni (Coraline)
Ruby Monday (Saron)
JunkFill (Saron)
Wappalyzer (Saron)
WhatFont (Saron)
Julian Feliciano: What Is Source Control? (Saron)
Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi)
The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim)
request_store_rails (Jim)
littleBits (Jim)

Jun 10 2015

55mins

Play

Rank #18: RR 409: Turning Fat Models Into Skinny POROs with Jason Swett

Podcast cover
Read more

Sponsors

Panel

  • Charles Max Wood
  • Dave Kimura

Special Guest: Jason Swett

Episode Summary

Jason Swett is a former host on Ruby Rogues. Now he has his own show, Ruby Testing Podcast and runs the site codewithjason.com where he teaches Rails testing. Today, Jason discusses turning fat models into skinny POROs (Plain Old Ruby Objects). He once read an article that said you don’t have to put all your code into active record models, that you can create plain ruby objects. These can go into active models if you want, but you’re not limited to active record models, you can make your own classes. This realazition greatly impacted the way he structures his code.

The panelists talk about the individual ways the structure their code. Jason discusses other structuring methods he has tried and gives some examples of using skinny POROs in the apps he works on. They discuss the pros and cons of using skinny POROs instead of active models, pros being it cleans up the model and makes testing easier, and the cons being it adds to a bit of overhead to the application, as somebody unfamiliar with the application might recreate parts if you don’t have an index.

The panel discusses how to decide when you want to create a new PORO. They talk about each of their methods and discuss the the usefulness of token generators. They conclude that in order for skinny POROs to be effective in code, they must be well factored and organized, and that unfortunately some complexity in code is unavoidable.

Links

Picks

Dave Kimura:

Charles Max Wood:

  • Cloud66
  • Podwrench
  • Podcasting booth
  • New podcasts coming to DevChat-- if you want to revive a podcast that has stopped airing, contact Charles Max Wood
  • Programming Podcasters Slack chat

Jason Swett:

Apr 17 2019

50mins

Play

Rank #19: RR 318 Metaprogramming with Jordan Hudgens

Podcast cover
Read more

RR 318 Metaprogramming with Jordan Hudgens

Today's Ruby Rogues podcast features Metaprogramming with Jordan Hudgens. We have panelists Jerome Hardaway, Brian Hogan, Dave Kimura and Charles Max Wood. Tune in and learn more about metaprogramming!

[00:02:00] – Introduction to Jordan Hudgens

Jordan is the Lead Instructor at Bottega. Bottega has locations in Salt Lake City, Utah and in Phoenix, Arizona. They’re a full-stack development code school.

[00:02:55] – Metaprogramming

Metaprogramming was one of those scary concepts. At the code school, when the students learn about metaprogramming and how it works, you can tell that it’s definitely a pretty exciting thing. Its formal definition is it’s a code that writes code. It can dynamically, at run-time, render other methods available to the program.

[00:04:10] – Use cases for metaprogramming

The best use case that Jordan has ever seen is implemented in Rails and that’s code that can run database queries such as User.find_by_email. By passing the email, it will go and find the user with that particular email. Now, there is no method in active record or in the user model that is called find_by_email. That’s something that is created at run-time.

Another one is something that Jordan has implemented and that’s a phone parser gem. It essentially parses and validates a phone number. It also has a country code lookup. With all the countries in the world, that would be very time-consuming. But within 8 lines of code, it could do what a hundred lines could do without metaprogramming.

[00:06:50] – Performance implications

Jordan never had performance issues because the generation of methods is not something that’s incredibly memory intensive. You might run into that but it would be a poor choice to do in terms of readability.

In Brian’s experience, it comes down to the type of metaprogramming you do. If you have a bunch of logic somewhere and method_missing, that’s going to be a performance bottleneck. And if you’re generating a bunch of methods when the application starts up, it might increase the start-up time of the application. But after that, the performance of the application seems to not have any fluctuation at all.

There are 2 main types Jordan works with. First is method_missing. Method_missing could have a little bit of performance hit because of how Ruby works. The system is going to look at every single method. The second type is define_method. In define_method, you’re really just creating a large dynamic set of methods at runtime. When you start up the Rails server, it’s going to build all those methods but it’s not going to be when you’re calling it. Whereas in method_missing, it has a different type of lookup process. 

[00:11:55] – Method collisions on monkey patching

That’s one of the reasons why monkey patching can have a bad reputation. You don’t know who else may be overriding those set of methods or opening up that class. Jordan’s personal approach is trying to separate things out as much as humanly possible. If there’s something that can be done in the lib directory, you can place that functionality inside of a separate module. And if you’re creating a gem, you have to be sensitive to other gems in that space or even the Rails core.

[00:17:25] – How to be good citizens to other developers

Metaprogramming has a lot of potentials to do great things but it also has a potential to cause a number of problems in the application. For Jordan’s students, what he usually does is walk them through some examples of metaprogramming where it can be done poorly. But then, he will follow it up with showing exactly when this is done right.

He shows examples of poorly written classes that have dozen nearly identical methods. And then, he also shows how they could take all those methods, put the names in an array, and show how to leverage things like define_method to generate them. He also shows them how doing monkey patching can cause issues, how they can actually open up the string class and change one of the basic functionalities. Show that when they override that, that affects the entire rest of the application.

[00:24:45] – Worst examples of metaprogramming

Jordan ran into this hive of metaprogramming. When he opened up one of its classes, he had no idea what that class did. It was method_missing all over the place. Usually, there are 4 or 5 lines of code inside of that. It’s relatively straightforward and makes logical sense when you read it. This was nothing like that.

They had multiple conditionals inside of the method_missing. One other hard thing about it is it does not have any test whatsoever. You need some test to make sure you’re capturing that functionality and to check if changes broke anything. You can’t also decipher what the inputs and outputs are.

[00:28:35] – Testing

Follow as much as real world examples. For example, in the phone parser gem, you can see some tests in there for that. You can also pass in the input that you plan to give. See if that matches the output. Jordan tells his students that respond_to_missing is as important to putting method_missing in there

[00:35:25] – Resources to get started

Paolo Perrotta’s book Metaprogramming Ruby is one of the standards for metaprogramming in Ruby. He also gave some fantastic examples. He created a story about a new developer who goes into a company and learns how to implement metaprogramming from senior devs. It’s very entertaining and it also covers all the different aspects to think of metaprogramming, when to use it and when it could be a very bad idea to use it.

Picks

Jerome Hardaway

Dave Kimura

Brian Hogan

Charles Max Wood

Jordan Hudgens

Jul 11 2017

45mins

Play

Rank #20: 201 RR Game Development with Andrea Magnorsky

Podcast cover
Read more

Thank you RailsClips Kickstarter Backers!

02:27 - Andrea Magnorsky Introduction

02:56 - “What Game Developers Know That Business Devs Can Benefit From”

  • Going From Enterprise => Professional Game Dev

08:28 - Curiosity and Motivation

09:10 - Is game development more approachable than in the past?

10:12 - Learning New Skills and Coding Practices to Write Games

  • Unlearning to Be Clean
  • Game Loop
  • Levels of Code:
    • Low-Level Code
    • Intermediate Layer
    • Scripts and Game Play

15:45 - Performance and Iterations

20:45 - Making Games Inviting

  • FUN

23:11 - Techniques to Cope with State

24:16 - Releasing and Deadlines (Business Issues Between Developers and Management)

28:30 - Testing

30:45 - Writing Aspects of Games (Stories, Artwork, etc.)

32:22 - Why F#?

38:44 - Pair Programming or Agile Techniques in Game Dev?

  • “Stupid Courage/Bravery”

42:22 - Teaching Game Development (Game Jams)

44:39 - Onikira: Demon Killer

Picks

[Vimeo] Carina C. Zona: Schemas for the Real World (Avdi)
Maryville, Tennessee (Avdi)
Monodraw (Jessica)
Elizabeth Naramore: Uncomfortable (Jessica)
ambient_spec (Coraline)
Cosmic Encounter (Coraline)
Ready Player One by Ernest Cline (Chuck)
Mastery by Robert Greene (Chuck)
Dixit (Andrea)
Michael Bernstein: Know Your Types (Andrea)
[Vimeo] Philip Potter: Generative testing with clojure.test.check (Andrea)

Apr 01 2015

57mins

Play

MRS 102: Elia Schito

Podcast cover
Read more

My Ruby Story this week welcomes Elia Schito, a senior developer for Nebulab. Elia has been working with Ruby for the past 12 years. Charles starts off by asking how Elia became a developer.

Host: Charles Max Wood

Joined By Special Guest: Elia Schito

Sponsors

______________________________________

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

______________________________________

Links

Picks

Charles Max Wood:

Elia Schito:

Jan 21 2020

38mins

Play

RR 447: All About Kafka and Oracle with Bob Quillin and Karthik Gaekwad

Podcast cover
Read more

Bob Quillin and Karthik Gaekwad are on the Oracle developer relations team. Karthik has been on Ruby Rogues previously, and he explains how he went from the Kubernetes team to developer relations. They begin the show by explaining what Kafka is, the leading open-source event streaming platform that Oracle is compatible with. It allows cloud developers to build, publish, and subscribe models for streams of records in addition to many other functions. Systems that used to take a long time to make have become very small and simple with Kafka. Kafka stands out from other message queueing systems because of its robust nature and scalability. 

Bob goes into more depth about the evolution of Kafka and the panel discusses some different use cases, concluding that Kafka works best for projects with a large amount of data coming in and for making real-time decisions. Bob and Karthik talk about other things Kafka can do beyond the message queue, such as building streams from specific patterns. They talk about when you should consider moving over to Kafka. Karthik talks about how to get started with Kafka. One of the best ways to do this is to set up a service with Oracle and to just play around with it, which won’t cost you much if you aren’t pushing a lot of data through it. Bob and Karthik talk about some of the features offered by Oracle and Kafka. While the offerings are somewhat vanilla, you get the advantage of it being an open-source driven service on top of a cloud that’s highly secure, available, and built to last. The panel discusses security within Kafka. They talk briefly about the framework Karafka and tools and resources available through Oracle for Kafka. The show concludes with the panel talking about compatibility between Kafka and Docker.

Panelists

  • John Epperson

  • Charles Max Wood

Guests

  • Bob Quillin

  • Karthik Gaekwad

Sponsors

____________________________

> "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

____________________________________________________________

Links

Picks

Charles Max Wood:

John Epperson:

Bob Quillin:

Karthik Gaekwad:

Jan 21 2020

46mins

Play

RR 446: Development Environments

Podcast cover
Read more

Today the panel is talking about their development environments and preferences. Most of them run on Macs, but they talk about other operating systems. They discuss some of the pros and cons of using Apple products. While Apple has conveniences to help you restore data, many of them have had issues with cabling and the fact that Macs are not easily extendable. They agree that the speed at which a development environment gets up and running is less about the hardware and more about how the environment is set up.

The conversation turns to which development platforms they are running. They discuss the value of Docker as a development environment. The panel compares the features of database management systems such as MySQL, MariaDB, and Postgress. David feels that getting up and running in an environment is the most important thing, but the panel challenges him to consider the maintenance required in some environments. The Ruby experts discuss the merits of using RVM and what they like about it, testing libraries they are using, and how they feel about certain gems. The tradeoffs between security and ease of use are discussed. They conclude the show by talking about the benefits of mechanical keyboards and duo vs. single monitor setups.

Panelists

  • David Kimura

  • John Epperson

  • Charles Max Wood

Sponsors

____________________________

> "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

____________________________________________________________

Links

Picks

David Kimura:

Charles Max Wood:

John Epperson:

Jan 14 2020

58mins

Play

RR 445: Location Services with Mithun Dhar

Podcast cover
Read more

Mithun leads development relations at HERE Technologies which specializes in building location services and location platforms. A lot of location is so seamlessly integrated we don’t even have to think about it, but it’s quite complex. He talks about how location services work, such as a ride-sharing app. He talks about some of the tools and data available from HERE Technologies for people who want to use location services. The panel discusses when to use services from companies like HERE and when you should try to do it on your own. Mithun talks about other ways HERE’s services can be utilized. The panel discusses how companies can get mapping so wrong, and Mithun talks about some of the complexities involved in mapping. David Kimura talks about some of his experiences with creating a location app, and the panel talks about the unlimited applications of location services.

Mithun talks about how location services are tested and how they are impacting the public sector and the future of mobility. Mobility is the overarching term for all of location services, such as public transportation, traffic, etc. This is changing a lot in many places, but especially in places like Dubai where self-driving cars are becoming more and more common. The panel discusses how to think about location services as a developer. Mithun talks about how to move from web to mobile development. The panelists discuss the issue of privacy and location services. Mithun talks about how HERE Technologies protects individual data and privacy.

Panelists

  • David Kimura

  • John Epperson

  • Charles Max Wood

Guest

  • Mithun T Dhar

Sponsors

  • Sentry | Use the code “devchat” for $100 credit

____________________________

> "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

____________________________________________________________

Links

Picks

David Kimura:

Charles Max Wood:

John Epperson:

Mithun Dhar:

Jan 07 2020

1hr 1min

Play

RR 444: Rails Against the Machine

Podcast cover
Read more

Brittany Martin, Lead Web Developer at the Pittsburgh Cultural Trust joins the panel today to talk about her talk "Rails Against The Machine". She has given this talk at Southeast Ruby, Rubyconf MY and Ruby on Ice.

Brittany Martin works for the Pittsburgh Cultural Trust as the nonprofit’s Lead Web Developer, where she is part of the team that develops, supports and maintains the Trust’s ticketing and festival web applications. She is a certified AWS Developer and the host of the 5by5 Ruby on Rails podcast. Under her alter-ego, Norma Skates, Brittany officiates roller derby for the Little Steel Derby Girls.

Her talk's elevator pitch is as follows: "What should a development team do when a few bad users threaten their application? Online businesses are plagued with trolls and bots. Learn how your team can leverage features from RoR and AWS to monitor and (secretly) segment bad actors using automation and behavioral triggers."

Brittany and the panel address questions such as "When is it better to block a user instead of incorporating them into your app?" and "How do you know the difference between a security threat or something trying to game the system?"

Panelists

  • Dave Kimura

    Andrew Mason

  • Charles Max Wood

Guest

  • Brittany Martin

Sponsors

____________________________________________________________

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

____________________________________________________________

Links

Picks

Andrew Mason

Dave Kimura

Charles Max Wood

Brittany Martin

Dec 31 2019

47mins

Play

RR 443: Sharing Tips from the Trench with Sven Akerman Jr.

Podcast cover
Read more

Sven Akerman Jr. is the chief architect at Outlook Insight. Today he and the panel are talking about the process behind development, specifically how Sven helped improve the software development process at his previous employer. When he started, they had a formal Scrum/Agile process for the first 5 years, but recognized gaps using key performance indicators like turnaround time. So the company implemented the single piece flow method, which ensures that all developers are focused on one thing from start to finish before moving on. As a company, they have a maximum of 2 products in play at a time, with two in focus. Some of the benefits of single piece flow are that it reduces context switching and increases group knowledge and involvement. 

Sven talks about how the method was implemented in the company, and admits that it takes a really efficient delivery pipeline to move things this quickly. For those that don’t have much to do with a project, the ‘bored void’ was filled with a list of other important things to work on, finding ways to make their own improvements in an area, and automation. Sven found that the method scales well and works both in an office or remote. One of the biggest drawbacks of this method was the psychological barrier among the workers, as it was hard to get people to change the way things “have always been done”. He notes that conversations in meetings shifted from ‘me’ to ‘us’ since people were more aware of others’ work. This shift occurred naturally with the enforcement of the constraints, though it took a couple of months. Sven talks about more ways he saw things change. Charles and David discuss things about this method that interest them, such as shipping things quicker. They talk about possible difficulties with technical debt, which Sven found actually decreased over time. In order to get started with the single piece flow method, it is important to first understand where you’re at and the size and capabilities of your team before moving forward. 

Panelists

  • David Kumura

  • Charles Max Wood

Guest

  • Sven Akerman Jr.

Sponsors

Links

Picks

David Kimura:

Charles Max Wood:

Sven Akerman Jr.:

Dec 24 2019

53mins

Play

RR 442:Ruby Rogues Live at GitLab Commit 2019

Podcast cover
Read more

In this episode of Ruby Rogues, Charles Max Wood interviews speakers at GitLab Commit 2019. Eddie Zaneski from Digital Ocean talks about "Creating a CI/CD Pipeline with GitLab and Kubernetes in 20 minutes", Shamiq Islam from Coinbase talks about "Closing the SDLC Loop- Automating Security" and Jasmine James, from Delta Airlines, discusses " How Delta Became Cloud Native-Avoiding the Vendor Lock".

Eddie, Shamiq, and Jasmine give the 5 min "elevator pitch" for the talks they gave at the conference.

In his talk, Eddie deploys a fake startup going through the whole pipeline: building the application, containerizing an application and shipping it off to Kubernetes.

Shamiq, talks about how the conventional approach to security is to consider it at the very end after all developer has wrapped up their work and why that should change.

Jasmine explains more in-depth what it means for a big corporation like Delta to be in a Vendor Lock.

Sponsors

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

____________________________________________________________

Links

Dec 17 2019

53mins

Play

RR 441: Solidus with Alessandro Desantis

Podcast cover
Read more

Alessandro Desantis is the director of Nebulab and is currently working on Solidus. After talking a little bit about how Nebulab got started, he describes what Solidus is. Solidus is a free, open source eCommerce platform built in Ruby on Rails that gives you complete control over your store. Three things that set it apart from other eCommerce platforms are that it is governed by a single company and that the focus is on quality and backwards compatibility. One of their biggest goals is to make Solidus streamlined, and Alessandro talks about how they handle it with the complex business logic involved in eCommerce. He talks more about the governance of Solidus and the different teams involved. 

Alessandro admits that Solidus has fewer features than some of its competitors, but this makes it very powerful and customizable. It can be tacked onto any Rails engine and you can pick and choose the things you want. Solidus was made with fewer features because of the unique nature of each eCommerce store. The creators noticed that when people create their stores, they had to adapt their business to suit the eCommerce software they used because the software was not as customizable. Solidus wanted to avoid that, so they provide the foundation and people can customize it. To customize Solidus, the documentation is available on the Solidus website, but the company encourages experimentation. 

Alessandro regrets that people think eCommerce companies are not technology companies, and so they tend to delegate it to someone else. He and Charles talk about some of the technical aspects of Solidus and what the future holds. In the future, the company plans to emphasize communication and the presentation of Solidus as a tool to help people make the right choice for their business, as well as streamlining the onboarding experience. To contribute to Solidus, you can contribute to the core itself or any of the extensions. There is also an active Slack community where you can ask for the best place to help. The show concludes with Alessandro talking about some of the other projects he’s working on. 

Panelists

  • Charles Max Wood

Guest

  • Alessandro Desantis

Sponsors

Links

Picks

Charles Max Wood:

Alessandro Desantis:

Dec 10 2019

31mins

Play

RR 440: Swagger and OpenAPI with Josh Ponelat

Podcast cover
Read more

Today the panel discusses the difference between Swagger and Open API with Josh Ponelat. Josh details the difference between the two. Swagger is a set of protocols around describing restful APIs. Swagger was taken over by a company called SmartBear, who donated the donated the specification to the Open Linux Foundation, and that became the Open API. Swagger is the tooling surrounding these specifications. Open API is a standardized way to describe a restful API in a YAML file. Once you’ve got a YAML file to describe your API, you can use tooling like Swagger to leverage that and take it to the next level. Using the Open API process is useful for situations where you already have an API in place, but want to codify and document it so that it’s controlled. Then going forward, you won’t introduce contradictions and it remains consistent because it’s documented in a YAML file. The process leaves room for enhancement in the future as well.

Josh talks about some of the benefits of standardizing your API and some of the use cases besides tooling. A standardized API can help show developers how to use your API, SDKs, and service stubs by knowing your API is consistent in style. This makes it easier to find breaking changes and more. Josh talks more about Swagger, a finite set of tooling around Open API, most of which are open source. He talks about other tools that test APIs and do linting on YAML files. Some of the companies that use Open API include Google, Amazon, and Microsoft. Josh talks about how Amazon implements Open API.

Josh talks about the book he’s writing, Designing APIs with Swagger and Open API. The book goes over describing APIs today, how to design APIs without writing code first, and how to get the most out of the system. The show concludes with Josh talking about the power of consistency and writing things down on paper. He discusses where implications that the standardization of APIs has on the text industry.

Panelists

  • Dan Shappir

  • Charles Max Wood

Guest

  • Joshua S. Ponelat

Sponsors

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

____________________________________________________________

Links

Picks

Dan Shappir

Charles Max Wood

Josh Ponelat

Dec 03 2019

46mins

Play

RR 439: Human Powered Rails: Automated Crowdsourcing In Your RoR App with Andrew Glass

Podcast cover
Read more

Andrew Glass is a Brooklyn based Rubyist operating a small independent devshop called Bang Equals. He has held many ‘enrichment jobs’, including being a ball person at US Open for 5 years, traveling for judging Guinness World Record attempts, and will be a balloon holder in the Macy’s Thanksgiving Day Parade this year. Today the panel is discussing his about his 2018 RailsConf talk, Human Powered Rails: Automated Crowdsourcing In Your Ruby on Rails App. In his talk, he shows the audience how to use Amazon Mechanical Turk. Amazon Mechanical Turk lets you post tasks, set a price point, and then people can go and complete the task. This is often done with tasks that can’t be done with machine learning and to train machine learning algorithms. In his talk he goes into What it is, how it’s used, and how we can use Ruby to automate the process. In his apps, he uses it for lead generation, qualification, enrichment, and some video and photo tagging. More specific uses include recording items from a picture of a shopping list, identifying specific things in a video, categorizing businesses and items, sentiment analysis of text or image. Overall, Mechanical Turk is used for things that machine learning can’t handle yet. The panel discusses some different uses for crowdsourcing and how to submit something to Mechanical Turk. There are multiple ways to ensure accuracy in your surveys, including setting up multiple stages to your task, having more than one person complete your task, and creating a qualified worker pool based on tests to determine their aptitude and skill. 

The panel discusses some of the controversy surrounding Mechanical Turk, citing an article in the New York Times (see links). The big issue is wages and worker rights. Wages can be very low, and it is ripe for abuse by companies as they could easily refuse all work and withhold pay. It is also important for the companies to give an accurate time estimate for the task and a reasonable reimbursement. Mechanical Turk attracts a variety of people, from people that do it for fun to people to actually do it for a living, so it is vital that companies use the tool responsibly. 

Andrew talks more about how his app works. His apps are built on RTurk, Turkee, and Mechanical Turk, and he talks about how they work. The tricky part is figuring out the logic for what answers they will accept. Andrew talks about how to get started with Mechanical Turk and how to validate the work you get back. To ensure you get accurate information, he suggest that you make it happy for your users, make the UX simple and usable, and use a lot of formatting in your forms so that you get good information in. They preface their results with an accuracy score to help determine what is true. Andrew talks about where he wants to go from he. His Turking days are behind him, but his days of coordinating the efforts of many using software show promise. 

Panelists

  • Dave Kimura

  • Charles Max Wood

Guest

  • Andrew Glass

Sponsors

Links

Picks

Dave Kimura:

Charles Max Wood:

Andrew Glass:

Nov 26 2019

44mins

Play

The MaxCoders Guide To Finding Your Dream Developer Job

Podcast cover
Read more

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is available on Amazon. Get your copy here today only for $2.99!

Nov 20 2019

14mins

Play

RR 438: Deviating from the Rails Core

Podcast cover
Read more

Today Charles and Dave are discussing deviating from the Rails core. Dave doesn’t care for JavaScript frameworks or microservices as he believes that they add too much complexity. These things may become necessary when your project gets massive, but otherwise we shouldn’t jump to these as a first option. If you don’t need the frontend powerhouse features, you may want to see how far you can get with Rails and a minimal frontend. React may not always be the solution that you need. They discuss jQuery versus Stimulus. They both prefer jQuery over Stimulus as they find it less invasive and clunky, and it’s easier to drop things in. 

Dave talks about his experience with ElasticSearch and how he simplified it. They discuss using MongoDB and Mongoid. They agree that although these are not Ruby specific, they can help. Dave, however, has not found a need for them, while Charles has found that it gave him more advantages in his schema. He talks about some other advantages of MongoDB. Dave and Charles discuss the default testing library for Rails, MiniTest. Dave prefers RSpec, but he still uses Mini test because it’s included in the rails core. He has found that RSpec benefits him, while Mini Test benefits his application, so he sticks to what’s included. He believes that  sticking close to the core and counting on the widely used things keeping up to speed makes maintaining on the application easier, and things are less likely to break. They turn to discussing when it is appropriate to deviate. Again, Dave believes that small applications without a massive amount of traffic don’t need to deviate, but adds that unique situations require unique solutions. It’s important to Consider if the solution will box you into an infrastructure provider or long term maintenance on something you don’t usnderstand. They agree that the goal is to introduce the least amount of technical debt as possible. 

Panelists

  • Dave Kimura

  • Charles Max Wood

Sponsors

_______________________________________________________

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon. Get your copy on that date only for $1.

_______________________________________________________

Links

Picks

Dave Kimura:

Charles Max Wood:

Nov 19 2019

43mins

Play

RR 437: Deploying Rails Onto Kubernetes with Khash Sajadi

Podcast cover
Read more

Khash and Kasia work for Cloud 66, a company started in 2012 with a goal to make Rails deployment simple and infrastructure easy to understand for application developers. As the company has moved towards containerization, they have integrated with Kubernetes. Khash talks about what distinguishes Cloud 66 from other platform as a service companies and why the company was started. He begins by talking about the structure of Heroku, how they own the entire stack down to the server, and how they are bound to a data center. Cloud 66 differs because they decided to break that unit economy from a data center to a server, so they don’t own the entire stack. Instead, they deploy what looks like an experience from Heroku onto your own server so you can go anywhere you want to go. They talk to the public API of those cloud providers within the data center that you choose that your account is in, and then provision, deploy, and maintain your application the way that you used to with Heroku, on that data center. 

Khash talks about how Kubernetes fits into the Cloud 66 model. Cloud 66 was started with Rails, but they wanted to make it generic and available on any framework, and decided this was best accomplished through containerization. They originally had their own containerization service, but then moved over to Kubernetes. Their Kubernetes for Rails product makes deployment of a Rails application onto Kubernetes extremely simple. The panel discusses the different ways that people get to containerization, and situations where containerization is not the correct solution. They also discuss situations where a containerization service like Kubernetes is useful.  Containerization can help a lot with distinguishing and establishing boundaries within a team. Kubernetes can help create uniform servers because you can tell it what you want and it will help you get there, including notifying you when things don’t align. Kubernetes is also excellent at dealing with microservices, if you have a need for a repeatable environment, and provisioning the infrastructure for commits. Khash notes that since moving to a unified infrastructure powered by Kubernetes, upgrades in Cloud 66 take significantly less time and talks about how things have been streamlined.

In the past, David has seen some issues with autoscaling in Kubernetes clusters, and Khash talks about how those things have been addressed and how to approach scaling in general. The first two things you need to define with scaling problems is how much is needed and what is ‘normal’ for your product. It is also important to consider if you need to scale up or scale down, as sometimes scaling down can hold more benefits. Khash has noticed that one thing that’s missing in the market is that as Rails developers they’re all about finding the best tools and getting the job done, while this approach is lacking in Kubernetes. He closes the show by talking about how Cloud 66 is trying to address what a Kubernetes deployment means for a Rails stack.

Panelists

  • Andrew Mason

  • David Kimura

With special guests: Khash Sajadi and Kasia Hoffman

Sponsors

 "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon.  Get your copy on that date only for $1.

Links

Follow DevChatTV on Facebook and Twitter

Picks

Andrew Mason:

David Kimura:

Khash Sajadi:

  • Follow Khash on Twitter @khash

Kasia Hoffman:

Nov 12 2019

55mins

Play

RR 436: Determining Pricing with Michael Herold

Podcast cover
Read more

Michael Herold is married to an economist and is a staff engineer at Flywheel where he writes Ruby programs to support PHP programs. He gave a talk at RailsConf 2018 about how to price a product. The frame for the problem is whenever you have a business idea, you eventually have to decide how to price it, and the pricing area is ripe for inefficiency on both customer and business ends. In his talk, he gave a simple framework based on the field of market research that helps give you an idea of what to price your product or service at called the Van Westendorp Price Sensitivity Meter, which is based off of talking with your customers about how they would value your product. He explains the difference between consumer surplus and producer surplus. 

The panel discusses other ways of determining pricing, such as basing your price off the price of a similar product. They discuss the pros and cons of different complex pricing they’ve seen. While complex pricing can be a turn off for many customers, it can also weed out less serious customers, and so it can be a good thing. Michael talks about what the Van Westendorp Price Sensitivity Meter actually looks like and how it works. It is based off a 4 question survey where customers are what price is too cheap, what price is a good deal, what price is getting expensive, and what price is too expensive. The answers are charted and you look for intersections in the curves (inflection curves) and it gives you an understanding of how people feel about the price of the product.

Determining pricing gets more complicated on a global scale, and the panelists discuss methods to handle it, such as giving discounts and adjusting prices by country. They discuss the importance of choosing the right price for your service, and a price that is too low can be as bad as over pricing. Michael talks about how his company determined their pricing using the Van Westendorp Price Sensitivity Meter and some of the difficulties they encountered. In the future, he wants to make a tool for how to figure out prices so that people don’t have to build their own pricing model. They conclude by discussing the merits of having a sale on your product. 

Panelists

  • Charles Max Wood

  • Andrew Mason

  • David Kimura

With special guest: Michael Herold

Sponsors

Links

Follow DevChatTV on Facebook and Twitter

Picks

Charles Max Wood:

  • Finding human connection

  • Disconnect from technology when you need to

David Kimura:

Michael Herold:

Follow Michael @mherold on Twitter and Github @michaelherold and michaeljherold.com

Nov 05 2019

45mins

Play

MRS 101: Taylor Jones

Podcast cover
Read more

My Ruby Story this week welcomes Taylor Jones, Support Engineer at Heroku. Charles asks Taylor how he ended up at Heroku. Taylor shares his journey after majoring in Computer Science at Auburn University.

Taylor had a lot of downtime in his first job so he started learning Rails online. Then after he graduated he was able to get more chances working full time with Ruby. He then started speaking at conferences such as RailsConf.

Charles and Taylor talk about how working at a place you really want to is not a pie in the sky but actually is doable if you position yourself correctly. For example Taylor really wanted to work at Heroku and was friends with the people at Heroku. When there was an opening his friends contacted him and Taylor was able to find a job at Heroku.

Charles wonders what drew Taylor to programming and Taylor talks about how he was introduced to developing through video games. Taylor also talks about the concept " if you start out with Ruby you stick with Ruby" and how this was true for him.

Finally Charles wants to know what Taylor's life is like outside of work. Taylor talks about what he does is in his free time which is playing guitars and hanging out with his family and his toddler.

Host: Charles Max Wood

Joined By Special Guest: Taylor Jones

Sponsors

Links

Picks

Charles Max Wood:

Taylor Jones:

Oct 29 2019

42mins

Play

MRS 100: The Origin and Impact of My Ruby Story

Podcast cover
Read more

My Ruby Story celebrates its 100th episode. To commemorate the 100th episode host Charles Max Wood talks about how My Ruby Story podcast started and how it progressed.

My Ruby Story started off as a spin-off of Ruby Rogues. Acting upon advice from a business coach he was working with at the time, Charles misunderstood her suggestion to double on Ruby Rogues and instead proceeded to create a podcast similar to Ruby Rogues. Over the years, the show proceeded to inspire many developers who are just starting out and the show developed a fan base of its own.

Over the years, My Ruby Story has helped people get better jobs, shaped their careers. For those who have been positively affected, Charles requests them to send him an email sharing how My Ruby Story or any other Devchat.tv podcast. If you have any questions or are struggling with how to get a better job, how to talk to your boss, or what steps to take to better your developer career, Charles schedule a call at Schedule a 15 Minute Call with Charles Max Wood.

Host: Charles Max Wood

Sponsors

Links

Picks

Charles Max Wood

Oct 22 2019

28mins

Play

RR 435: Alternatives to Adding React with Graham Conzett

Podcast cover
Read more

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it. 

To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited.

Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins.

If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive.

Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React.

The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it.

Panelists

  • Charles Max Wood

  • Andrew Mason

  • David Kimura

  • Nate Hopkins

With special guest: Graham Conzett

Sponsors

Links

Follow DevChatTV on Facebook and Twitter

Picks

Charles Max Wood:

David Kimura:

Andrew Mason:

Nate Hopkins:

Graham Conzett:

Follow Graham @gconzett on Twitter and Github

Oct 22 2019

59mins

Play

RR 434: Surviving Webpack with Ross Kaffenberger

Podcast cover
Read more

Ross Kaffenberger is a software engineer at Stitch Fix and has been developing web applications for the past 12 years, mostly in Ruby and JavaScript. Today he and the panel are discussing how to survive Webpack. When many folks first encounter Webpack, they feel confused, overwhelmed, and don’t know how to get it to do what you want it to. In the latest version they tried to introduce some more sane default settings, but it is still a major change in technology. 

Ross talks about how his company transitioned Rails 5 to Rails 6 with the new Webpacker. His company chose to take an iterative approach and slowly migrated to Webpacker. His app was very JS heavy with a large number of libraries, many of which were not very Webpack friendly. They chose to separate out the vendor libraries into a separate bundle, that way they could contain each deploy. They still had to add some configuration, especially to make things available on global scope.As they started moving jQuery plugins over, sometimes the functionality would disappear, and Ross talks about how they figured out their mistakes. It was difficult for them to get out of their Sprockets mindset and into the new mindset of Webpack, which requires different techniques. There are also things that Webpack can do to keep you out of that situation

Ross gives some strategy advice for someone who is in a position to update from Sprockets to Webpack. It’s important to consider your app size, your comfort level with Webpack, your team dynamic, and your timeframe. Ross recommends the iterative approach that they took, which took longer, but allowed them to learn as they went. 

Ross talks about the changes that happened in the switch from Webpack 3 to Webpack 4, and some of the contributions they made. He talks about some of his preferred Webpack configs and plugins. They discuss some of the drawbacks of Webpack, particularly the plethora of plugins that can make it seem daunting. 

One of the big gotchas with Webpack is the location of your source code. When you install Webpack for the first time, create a JS folder under App, it will place a ‘application.js’ file in another file called ‘Packs”. The idea of that pack file (application.js file under Packs) is that it’s the entry point for all of the JS that you’re going to add to your Webpack build. But if you add additional files to that Pack folder, Webpacker will instruct Webpack to treat each of those files as a separate entry point in a dependency graph. Make sure that only files that are intended to be the entry points for your Webpack builds are in that packs folder.

 It is also important to understand how you’re using global scope inside your JavaScript modules in your build. There’s a way to allow Webpack to inspect each of the files for a certain variable, such as a dollar sign. If he could go back and do it again, Ross would not split his code manually, but instead Embrace the notion that Webpack understands how to do code splitting for you, as long as instruct it to do it the right way.

Ultimately, it took Ross’ company 3 rather tedious months to transition to Webpack. It could’ve gone faster if they’d known more about Webpack to begin with. The panel discusses whether it was worth it to switch to Webpack. Transitioning to Webpack has changed their team dynamic and their day to day coding and debugging. One nice feature of Webpack is the source maps that aid in debugging. There are still areas for improvement, but now that it’s set up most folks on the team don’t think about it. Overall, the development experience has improved, and he thinks it was worth it, but it’s not for everybody.

Panelists

  • Dave Kimura

  • Andrew Mason

  • Nate Hopkins

  • Charles Max Wood

With special guest: Ross Kaffenberger

Sponsors

Links

Follow DevChatTV on Facebook and Twitter

Picks

Dave Kimura:

Nate Hopkins:

Charles Max Wood:

Ross Kaffenberger: 

Follow Ross on Twitter and Github, and on his blog

Oct 15 2019

1hr 23mins

Play

MRS 099: Joe Leo

Podcast cover
Read more

Joe Leo joins Charles Max Wood on this week's My Ruby Story. Joe is the Founder and CEO of the agile software consultancy, Def Method. He shares his journey as a developer. Joe was tutored by his uncle and learned how to code in Basic on a command line. He wanted to be in the music industry and liked math.

Joe is currently working on holistic product development and is delving into areas such as what makes a good product manager and what makes a good product design. Charles and Joe talk about difficulties in quantifying good product management skills or writing tests and other non-coding aspects that surround making a product.

Host: Charles Max Wood

Joined by Special Guest: Joe Leo

Sponsors

Links

Picks

Joe Leo

Charles Max Wood

Oct 08 2019

55mins

Play

RR 433: ShipLane with John Epperson

Podcast cover
Read more

John Epperson has been doing ruby for 12 years and is a friend of Andrew Mason. He got into Docker a couple years ago and felt like something was missing, so he wrote Shiplane. He liked Docker because it was a promise that he could delegate a lot of the manual devops work to something else, and that something else was able to automate all of it. What he noticed was if you have a Docker thing in development and want to transfer it into production, there was no clear path to get a Docker item from development to production. The process wasn’t truly automated, so he created ShipLane in an attempt to automate it.

ShipLane solves this problem by assuming that you have a box out there, whether it’s a VM or an actual physical box, and you have SSH access to it. It logs in, it makes sure you have Docker installed, and gives you the ability to actually take your development docker compose, and convert it to a productionized version. It also hooks in to Capistrano and replaces that with ShipLane commands. Right now ShipLane is using Docker Raw and creates a network for your stuff to work within, deploys your containers, and then your service is up and running. There are different tools you can use to run Docker in production, but John didn’t want to run containers by using Docker Run with a bunch of stuff after it, didn’t want to maintain a custom script, so he automated it. John is currently working on a version that will translate your Docker Compose files into Kubernetes YAML files.

There’s a lot of choices to be made in Rails, none of which are wrong, but one choice begets many more, and there’s so many to make and so many consequences it’s difficult to know your path, and ShipLane provides clearer a path. John talks about how to get started with ShipLane. First, you need to gem install ShipLane and Capestrano, put it in your bundle file, and require it in Capestrano (there’s a generator). It has Capestrano listed as a dependency requirement. Andrew has used ShipLane and found it very quick and effective, only took them about 30 minutes. John asks for feedback from users on ShipLane, since many people are using it but no one has given any. 

John talks about the versatility of ShipLane as a general solution. He addresses some concerns that people have about putting stuff into containers, and assures them that ShipLane is intended to work right out of the box. It is important that when containerizing services available on the platform of our choice to step back and question if you creating this infrastructure correctly. They discuss some methods for deciding what goes into containers.

The panel discusses some of the advantages of Docker, particularly deployment time. Everything is already bundled, the assets are precompiled, so it cuts your deployments down a lot. They talk about different frameworks for Ruby that they like for their scaling abilities, such as Docker, Kubernetes, and Elastic Beanstalk. While Elastic Beanstalk is not one of the primary targets of ShipLane, it is designed as a generalized path to go from development to production, so it shouldn’t matter what your production target is in the end. If you’re gonna pick a provider that isn’t one of the big 3, then ShipLane is a great option

If you’re picking a SASS provider, there’s always a possibility that it isn’t compatible with the generalized version, but if we’re targeting Kubernetes it should generally work.

The panel discusses the general advice not to use Docker in development and whether or not it has merit. John finds that flips back and forth between projects, and those projects all have different dependencies, so Docker makes it easier to switch between projects because he doesn’t have to think about the dependencies. They talk about how John manages his Docker /compose version with these various projects. They all agree that Kubernetes should not be run locally. 

Finally they discuss whether tools like ShipLane are the next step with Docker. They believe that containerization is here to stay, but the only thing that might remotely threaten Docker is going back to bare metal development or going serverless. They discuss whether going serverless kills Docker. Ultimately, the most important thing is that the problem gets solved. 

Panelists

  • Charles Max Wood

  • Andrew Mason

  • David Kimura

With special guest: John Epperson

Sponsors

Links

Follow DevChatTV on Facebook and Twitter

Picks

Charles Max Wood:

David Kimura:

Andrew Mason:

John Epperson:

Follow John on Github, on rockagile.io, and Twitter

Oct 08 2019

1hr 4mins

Play

iTunes Ratings

43 Ratings
Average Ratings
37
2
0
2
2

Quality

By Dudedudedude111 - Dec 22 2013
Read more
Smart people sharing great ideas.

Awesome

By No-one-else-has-this-nickname - Sep 22 2013
Read more
Kept me entertained while driving across the country.