Search
Talks
A Mentor in the Limelight
Edit
#apprenticeship
#software-craftsmanship
#test-driven-development
#ruby
#mentorship
#design-principles
#model-view-controller-mvc
Summarized using AI

A Mentor in the Limelight

Justin Martin and Paul Pagel • September 29, 2011 • New Orleans, Louisiana • Talk

Summary of 'A Mentor in the Limelight'

In this talk titled "A Mentor in the Limelight" by Justin Martin and Paul Pagel at RubyConf 2011, the focus is on cultivating software craftsmanship through an apprenticeship model, particularly using the Limelight framework as an educational tool. The speakers discuss the complexities new developers face when starting their careers, emphasizing the importance of mentorship and hands-on learning.

Key Points Discussed:

  • Introduction to Mentorship in Software Development:

    • Justin Martin reflects on his experience as an apprentice at Object Mentor, where he learned the principles of extreme programming (XP) and test-driven development (TDD).
    • Emphasis on the longevity and necessity of skill development in software craftsmanship.

  • The Apprenticeship Program at Eighth Light:

    • Martin describes how their program allows new developers to learn coding fundamentals over several months before working on client projects.
    • Teaching methods focus on immersing apprentices in TDD and collaborative practices from the outset.

  • Learning Environment and Techniques:

    • Use of Katas as exercises to enhance coding skills without the pressure of producing client-ready code.
    • Practical examples demonstrate how apprentices tackle programming challenges and evolve their coding practices over time.

  • Common Pitfalls in Learning Rails:

    • Discussions on Rails DSLs (Domain Specific Languages) that can make it easy to overlook fundamental programming principles.
    • Caution against blindly accepting DSL conveniences that can lead to poor code maintenance and design flaws.

  • Using Limelight for Teaching Principles:

    • Limelight is introduced as a GUI framework that allows for creative exploration of MVC principles without the overhead of Rails complexities.
    • The framework uses a theater metaphor, providing a clearer understanding of programming concepts like observers and commands, helping new developers grasp core ideas effectively.

  • Conclusion and Call to Action:

    • The talk encourages prospective developers to appreciate the learning process and embrace continuous practice.
    • Mentorship is highlighted as a crucial element for growth and understanding in the software development journey.

Overall, this presentation underscores the importance of a structured mentorship approach in software development training, illustrating it through both personal anecdotes and the practical use of tools like Limelight to nurture future software craftsmen.

A Mentor in the Limelight
Justin Martin and Paul Pagel • New Orleans, Louisiana • Talk

Date: September 29, 2011
Published: December 12, 2011
Announced: unknown

Learning how to be a well versed and competent developer is a life long process, but it must begin somewhere. One of the toughest parts about starting a career as a developer is the massive technology stack involved in pushing anything out to the real world. Similar to learning physics, chemistry, or biology for the first time, there is a whole language you need to learn before you can achieve any sort of mastery. With Limelight, you can teach the fundamental principles of becoming a Software Craftsman while only using Ruby! We will first explore Limelight as an educational tool, and then get our hands on our keyboards and work through an example Limelight Lesson. We will actually be writing some code! If you have JRuby on your machine, Limelight will do the rest of the setup.

RubyConf 2011

00:00:13.759 thank you
00:00:17.119 this talk is called a mentor in the
00:00:19.380 Limelight
00:00:21.600 so who am I
00:00:24.539 so I got into software
00:00:27.439 by apprenticing at object Mentor I was
00:00:30.660 really fortunate that I happen to live
00:00:33.780 in the same town as uh Uncle Bob Martin
00:00:37.500 and uh he I was taking some programming
00:00:40.920 classes at my local high school and uh
00:00:44.100 found this opportunity to apprentice and
00:00:47.460 what this meant was that I got to
00:00:49.940 go and sweep and do server
00:00:52.620 Administration while they were doing
00:00:54.780 these XP immersions does anyone know
00:00:57.239 does anyone know what the XP immersions
00:00:59.520 were
00:01:01.140 so back in I think it was like 2001 they
00:01:05.400 had like
00:01:07.380 Michael feathers Ron Jeffries
00:01:11.159 um
00:01:13.200 Pascal Roy Brian Barton like all of
00:01:15.900 these people kind of get up and teach
00:01:17.760 one class about how to do extreme
00:01:19.500 programming it was a really humbling
00:01:21.240 experience to learn that pair
00:01:23.700 programming test driven development
00:01:25.560 customer collaboration this is how you
00:01:27.960 wrote software so this is actually how I
00:01:29.759 learned to write software and I
00:01:31.500 Apprentice there for about five years
00:01:32.759 before accepting a job
00:01:34.560 and then
00:01:36.259 went to eighth light with Micah Martin
00:01:39.720 we left object mentor to write code
00:01:42.360 rather than teach code and it has been a
00:01:45.720 really fun experiment so far
00:01:48.720 and the kind of focus of this talk is
00:01:52.560 the eighth light apprenticeship program
00:01:55.140 kind of the things we learned about
00:01:56.640 teaching are the things I learned about
00:01:59.340 teaching and our apprenticeship program
00:02:01.619 is you know we have someone come in uh
00:02:05.520 three to nine months and learn how to
00:02:09.239 write software
00:02:12.120 before they work on any client code
00:02:13.980 we're a Custom
00:02:16.819 Contracting
00:02:18.920 firms so before they write any client
00:02:21.959 code we do this apprenticeshiper and
00:02:23.940 it's kind of the same thing that I had
00:02:26.580 at object Mentor where instead of
00:02:29.819 hiring people and trying to convince
00:02:33.060 them test driven development is the
00:02:35.220 right thing to do we'll just go through
00:02:37.860 this immersion and get people
00:02:40.400 prove it to them that test driven
00:02:42.900 development is right and before they
00:02:44.819 have any other practices we'll just
00:02:46.680 teach them from scratch and that was
00:02:48.720 kind of the thesis and it's gone through
00:02:50.519 some iterations and we've grown the
00:02:52.560 company through this program
00:02:58.500 so apprenticeship itself is kind of this
00:03:03.300 I mean really old idea about learning
00:03:07.140 your craft through a period of time and
00:03:09.959 uh
00:03:10.920 in software Fortune especially in the
00:03:13.560 Ruby community
00:03:15.360 we get to get it up and running really
00:03:17.519 fast right we get to teach ourselves in
00:03:21.140 that success is
00:03:24.659 is really fortunate that we're able to
00:03:27.120 create at such an early stage in our
00:03:29.400 craft we also have to remember that
00:03:31.379 there's a lot to learn at before we can
00:03:34.200 move too far
00:03:36.720 so
00:03:40.319 the people we know as Masters don't have
00:03:42.239 to devote themselves to a particular
00:03:43.739 skill just to get better at it the truth
00:03:45.780 is they love to practice and because of
00:03:48.360 this they get better so the
00:03:50.099 apprenticeship and craftsmanship in
00:03:52.379 general is about this idea that you
00:03:54.360 really love to do what you're doing
00:03:56.040 you're not doing it for the money you're
00:03:57.599 not doing it as a vehicle for some other
00:03:59.879 outcome but that you love to write code
00:04:02.099 and that during he uh George Leonard
00:04:04.680 talks a little bit about this uh Mastery
00:04:07.319 curve where skill acquisition
00:04:10.620 um
00:04:11.640 comes from you learn a whole bunch at
00:04:14.640 once and then you plateau for a really
00:04:16.859 long time practicing the things that
00:04:19.320 you're doing
00:04:20.400 and if you don't absolutely love to
00:04:23.220 write code those plateaus are going to
00:04:24.900 be unbearable right those are times
00:04:27.300 where you're learning intuition and
00:04:28.740 you're practicing and uh
00:04:31.440 so
00:04:32.820 one of the ways that we practice a lot
00:04:35.220 at eighth light is Kata is where uh do
00:04:38.040 the prime factors or Roman numeral Kata
00:04:40.800 and the idea is that you take a problem
00:04:43.320 and you focus on the form of the problem
00:04:45.840 rather than solving the problem so you
00:04:48.479 take the prime factors kind of everybody
00:04:50.100 after you've solved it once you know the
00:04:52.560 solution but then the next time you
00:04:54.780 approach it you can go through and try a
00:04:58.080 different recursive technique try doing
00:05:01.440 the whole thing without if statements
00:05:03.240 try
00:05:05.000 lots of different techniques so that you
00:05:07.979 can get yourself used to writing a for
00:05:10.800 Loop writing recursion so that when you
00:05:12.600 comes time to write client code when it
00:05:15.720 comes time to write professionally
00:05:16.860 you're not thinking about what's the
00:05:18.900 right technique you you already know in
00:05:21.060 your intuition
00:05:22.800 are a great way to practice that
00:05:25.560 and finding a mentor so the best way to
00:05:28.080 learn something is to learn it from
00:05:29.820 somebody else somebody who will take
00:05:31.680 responsibility in teaching and keeping
00:05:36.240 you on the right path there's no need to
00:05:38.280 reinvent the wheel over and over
00:05:41.160 so what is it that we end up teaching
00:05:44.400 um
00:05:45.000 well tdd I think the biggest uh mistake
00:05:48.240 uh you can make is not writing tests I
00:05:51.180 think
00:05:52.560 it will always cost you money later on
00:05:55.320 uh cost you time
00:05:57.479 solid agile design patterns this seems
00:06:00.780 all right I'm sure uh
00:06:03.600 most people have been exposed to these
00:06:06.300 at some point
00:06:08.039 software craftsmanship collaborating
00:06:09.840 with your customers productive
00:06:11.400 Partnerships writing well crafted code
00:06:13.800 caring about the problems
00:06:16.320 and rails so we end up after this
00:06:22.139 apprenticeship
00:06:23.520 most of our work ends up being in rails
00:06:27.259 so even though we during the
00:06:29.580 apprenticeship you might get to learn
00:06:30.900 lots of cool languages and it ends up
00:06:34.259 being the client code all in rails so we
00:06:37.919 have to unfortunately or fortunately
00:06:40.440 teach rails
00:06:42.539 so how do you teach rails
00:06:44.520 this is the way we started the
00:06:45.960 apprenticeship program give them the
00:06:47.460 depot book or give them the depot
00:06:49.020 problem in the book and come back a
00:06:51.240 month later and see that completed or
00:06:53.580 more likely come back in about 20
00:06:56.280 minutes and say I can't I don't I can't
00:06:58.620 download Ruby and have that process go
00:07:01.080 throughout the time
00:07:02.699 and but once they get going they think
00:07:05.340 rails is really easy compared to all the
00:07:08.580 other programming challenges they've had
00:07:12.479 and they're ready to write code they're
00:07:14.520 ready to write client code
00:07:16.620 and then the first time they pair on a
00:07:19.199 client story they realize this is their
00:07:21.539 technology stack it's not from the depot
00:07:24.740 application that they have to be
00:07:26.699 proficient in all of these things
00:07:30.000 so we take a step back and write
00:07:32.520 something that's a breakable toy
00:07:33.960 something we can fix real or something
00:07:35.940 that we can make lots of mistakes on
00:07:40.380 and one week later this is in a rails
00:07:43.139 app
00:07:44.520 I see this code
00:07:45.900 and so I we just went through teaching
00:07:48.660 every day the solid design principles
00:07:52.580 some different patterns command pattern
00:07:55.440 and then they after
00:07:58.680 Googling around and figuring out how to
00:08:01.319 write all of these active record models
00:08:03.539 and using the rails dsls this is what
00:08:06.720 the first solution comes back looking
00:08:08.819 like
00:08:16.139 what happened to your single
00:08:17.340 responsibility principle
00:08:24.780 so it's really easy with all of these
00:08:26.879 dsls to just throw everything together
00:08:30.360 and especially if you're creating
00:08:32.159 prototype applications or applications
00:08:34.919 Greenfield apps in their first month and
00:08:37.200 it's even easier when you're teaching to
00:08:39.300 just say this is okay right this is good
00:08:42.180 enough because this small applicant
00:08:43.500 application will be
00:08:45.360 throwaway
00:08:47.640 so then one week later I see this
00:08:51.779 and
00:08:54.380 it's well tested you know there's a
00:08:56.880 speck of cucumber
00:08:58.640 saying that they're setting the right
00:09:00.720 tab that they have a CSS background
00:09:03.480 switch
00:09:05.640 I ask them to go look up didn't we
00:09:08.100 already talk about model view controller
00:09:10.800 and
00:09:12.180 in
00:09:13.339 rails well
00:09:15.959 so if you have an instance variable in a
00:09:18.300 class you initialize it in the uh
00:09:21.000 Constructor and then you use it later on
00:09:23.220 in that class that instance variable
00:09:25.920 belongs to that abstraction right so
00:09:29.279 that what this is doing that you're
00:09:30.959 setting an instance variable in the
00:09:32.580 controller and you're using it in the
00:09:34.860 view right so that's the same thing
00:09:38.160 so without carefully defined interfaces
00:09:41.519 those instance variables make the
00:09:44.100 controller and the view the same thing
00:09:45.839 so that things like this will separate
00:09:48.959 will uh break down the model view
00:09:52.440 controller which rails
00:09:54.540 sets some kind of model view controller
00:09:56.459 framework for you
00:10:00.480 and then another week later we have the
00:10:02.100 I see
00:10:03.660 code like this
00:10:07.380 these after creates after saves before
00:10:10.800 saves before creates
00:10:13.279 after before every possible thing in
00:10:17.459 just a stack of them in the top of my
00:10:20.040 active record model and then 30 private
00:10:24.360 methods that support them
00:10:27.899 and I'm and I say why didn't why didn't
00:10:30.600 you use the Observer pattern the and
00:10:33.360 when you use the Observer pattern the
00:10:35.399 subject and the concrete Observer are
00:10:38.040 two separate items and there's a reason
00:10:39.959 that we do that and rails actually if
00:10:41.880 you dig in a little bit deeper lets you
00:10:43.980 do that by implementing The Observer
00:10:47.220 interface it lets you abstract what the
00:10:51.180 behavior you're doing in these hooks
00:10:55.140 so then why all the fuss
00:10:59.880 well the fuss is once you start writing
00:11:01.620 client code if you follow all of these
00:11:05.279 rails Frameworks these dsls without a
00:11:08.519 skeptic's eye you end up with these
00:11:11.100 enormous classes that are very difficult
00:11:13.260 to maintain
00:11:16.140 and you end up throwing all of these
00:11:18.120 design principles that you spent your
00:11:19.740 apprenticeship learning and they're just
00:11:21.720 completely thrown out the window
00:11:33.720 so the design principles are one thing
00:11:35.700 but then what do these dsls also show us
00:11:39.360 is they
00:11:42.480 well I guess a better question is when I
00:11:45.060 see this this line of code I ask well
00:11:47.940 what does this actually do right it
00:11:49.980 seems pretty straightforward it
00:11:51.839 validates that some name field on a
00:11:54.779 project
00:11:56.160 is both present and unique
00:12:02.040 so does that guarantee that it's present
00:12:05.399 and unique
00:12:06.899 what does this actually doing
00:12:13.079 if you have two
00:12:15.660 um
00:12:18.060 if you have it run through this code in
00:12:21.000 memory twice is this guaranteeing it as
00:12:23.399 a constraint to the database
00:12:26.519 usually those are the kinds of things
00:12:27.959 that
00:12:29.700 um you really have to know especially
00:12:32.339 when you're building a lot of our
00:12:34.440 clients applications are enormous and
00:12:37.260 they have to be scaled and you have to
00:12:39.779 understand exactly what this is doing is
00:12:41.820 this checking is this guaranteeing you
00:12:43.860 uniqueness well it's not
00:12:49.680 and things like this where it's really
00:12:51.360 easy to get going in these dsls but do
00:12:53.940 you know what do you know what this is
00:12:55.380 doing why would you use put versus post
00:12:59.040 versus get
00:13:01.260 um
00:13:02.339 and I so
00:13:05.820 the problem with teaching rails and
00:13:07.920 starting a Craftsman off early in their
00:13:10.260 career with rails is that we don't learn
00:13:12.360 the details first
00:13:14.040 and so when we learn how to write those
00:13:17.519 SQL queries it hopefully an orm will
00:13:21.660 abstract that from us but we still have
00:13:23.700 to know exactly what that's doing and
00:13:25.740 rails makes it sometimes a little bit
00:13:27.480 too easy where and you only figure it
00:13:30.720 out when you're going the other way when
00:13:32.579 the abstraction has broken and a web app
00:13:36.420 is down and you have to figure out
00:13:38.220 what's going on or when you have to when
00:13:42.240 some query is not taking or is taking a
00:13:44.760 really long time is it loading up this
00:13:47.040 entire object graph rails didn't tell
00:13:49.620 you that it was going to load up all
00:13:51.060 these dependencies
00:13:54.360 so it's these vertical skills learning
00:13:56.540 SQL through first and then the orm model
00:14:00.839 and then designing the business layer on
00:14:03.420 top of that and teaching these vertical
00:14:05.279 skills is uh
00:14:08.040 sometimes very difficult through rails
00:14:10.680 so
00:14:12.060 this talk is about returning to a
00:14:15.060 simpler place a playground for
00:14:17.100 practicing these design principles and
00:14:20.339 early on we used a lot of Sinatra and
00:14:23.040 something that's real kind of simple
00:14:24.420 lets you design and
00:14:27.420 this is about Limelight so Limelight is
00:14:30.779 kind of that place where you can teach
00:14:33.000 these and design principles and play
00:14:35.880 around with them without having to know
00:14:37.620 some of those details yet so getting an
00:14:40.199 architecture sense and a design sense
00:14:42.360 and a testing sense before you have to
00:14:45.720 know what jQuery is before you have to
00:14:48.720 know
00:14:50.180 what SQL statements are
00:14:53.300 so I mean jumping into a new project you
00:14:56.519 have an MVC framework in rails and maybe
00:14:58.740 you have an MVC framework in JavaScript
00:15:00.720 and learning all of these things at the
00:15:02.760 same time it can be a little bit
00:15:03.839 difficult
00:15:06.000 so what is Limelight
00:15:08.760 it's a rich client GUI framework written
00:15:11.459 entirely in Ruby
00:15:16.260 it's got this interesting theater
00:15:18.199 metaphor where
00:15:24.300 you have a production and each
00:15:27.839 production will have stages and scenes
00:15:30.600 and props and actors and so it's a
00:15:33.600 coherent metaphor to talk about the
00:15:36.300 framework itself rather than overloading
00:15:39.720 terms like view or controller or helper
00:15:42.899 in rails where
00:15:45.240 is model view controller and rails
00:15:47.399 exactly like model view controller model
00:15:50.880 view presenter that you were taught in a
00:15:53.160 textbook it's an interpretation of it
00:15:54.959 right so the what Limelight does is it
00:15:58.199 takes
00:15:59.040 it lets you build the model view
00:16:02.100 controller framework for your
00:16:03.959 application instead of
00:16:07.139 kind of putting that on top
00:16:11.279 so it's a blank slate
00:16:15.240 lets you exercise your design principles
00:16:22.440 for instance
00:16:24.839 an observer so the the first Observer
00:16:28.380 that you write
00:16:29.959 you know in Ruby how do you write an
00:16:33.360 observer this is one possible
00:16:36.060 implementation using registered blocks
00:16:39.420 right so it doesn't have to be that uh
00:16:44.759 that the exact way from uh
00:16:48.079 the uml diagram that I showed earlier
00:16:51.240 like there's lots of different
00:16:52.620 interpretations of an observer and when
00:16:54.959 you go through this is one of those
00:16:57.180 written to do Limelight actions and when
00:17:01.019 you have when you're teaching and you go
00:17:03.360 through write a command pattern write an
00:17:05.579 observer and you have no place to start
00:17:07.980 no DSL on top of it it ends up looking a
00:17:11.040 lot like
00:17:12.240 that uml abstraction diagram
00:17:20.220 so embracing the framework with the
00:17:22.079 skeptic's eye
00:17:25.500 so that's the short version of it and
00:17:29.640 now we have I don't know who came in
00:17:32.340 late but this is we're going to do an
00:17:34.679 exercise in Limelight
00:17:57.799 thank you
JM
Justin Martin
1 talk
PP
Paul Pagel
1 talk
Explore all talks recorded at RubyConf 2011
+55