01:31 - Martin Fowler Introduction

• “Author, speaker and general loud-mouth on the topic of software development”
• martinfowler.com

02:05 - Patterns of Enterprise Application Architecture by Martin Fowler (PoEAA)

• Programming Ruby 1.9: The Pragmatic Programmers’ Guide by Andy Hunt (The Pickaxe Book)
• Transform View 10:47 - Architecture 12:30 - Patterns
• The Timeless Way of Building by Christopher Alexander 
• Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides (Gang of Four Book)
• Domain-Specific Languages by Martin Fowler
• Portland Pattern Repository 21:51 - Jargon

25:17 - Code of Ethics & Authority 29:08 - Rails

• The five programming books that meant most to me by David Heinemeier Hansson of 37 Signals 34:09 - Growing/Evolving Patterns
• Active record pattern
• Data mapper pattern
• Identity Map 42:55 - NoSQL
• NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence by Martin Fowler
• Aggregate pattern
• Ruby DataMapper Status | solnic.eu 49:59 - Row Data Gateway56:52 - Potential Book Updates 01:00:23 - Service-oriented Architecture
• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe and Bobby Woolf 01:05:45 - Service Layer01:14:00 - Remote Facade Pattern01:19:55 - UniformAccessPrincipal
• Ruby Tapas Episode 4: Barewords 01:22:28 - PoEAA for Beginners
• Dreyfus model of skill acquisition
• Mocks Aren’t Stubs: Martin Fowler 01:26:28 - Martin’s Next Book Club Book Suggestion
• Domain-Driven Design: Tackling in the Heart of Software by Eric Evans

Book Club

The Rails View by John Athayde and Bruce Williams: Read along with us! We will be discussing the book with John and Bruce and the episode will air on Wednesday, May 8th, 2013.

Next Week

DRb with Davy Stevenson

Transcript

JAMES:  I will try to start us off here, I think. JOSH:  James, do you have your smelling salts handy? [Laughter] JAMES:  Selling salts: I’ve been dosing myself regularly. [Laughter] AVDI:  Now, you have a resistance to smelling salts. JOSH:  Wait! Does that work like Iocane powder? [Laughter][Hosting and bandwidth was provided by The Blue Box Group, check them out at **BlueBox.net**.] **[This podcast is sponsored by New Relic. To track and optimize your application performance, go to  **RubyRogues.com/NewRelic** .]  **JAMES:  Hello everyone and welcome to the 97^th episode of the Ruby Rogues podcast. Uh, oh! I think I said 97^th. Josh prefers it when I say Episode 97 of the Ruby Rogues podcast. Chuck’s out today sick, we’re very sorry. We hope that he feels better soon. David Brady is out today and we have no idea what he’s doing but the rest of us are here. I’ll be your host James Gray and with me today is Avdi Grimm. AVDI:  Hello from Pennsylvania. JAMES:  Josh Susser. JOSH:  Yes, I took a correspondence course in Pedantics. [Laughter] JAMES:  And Katrina Owen. KATRINA:  Hello from Colorado. JAMES:  And also with us today is special guest, Martin Fowler. MARTIN:  Hello from melting Boston. JAMES:  Martin, this is the first time you’ve been on this show. So, for the one person out there who doesn’t know who you are, why don’t you introduce your self? MARTIN:  Okay, I’m Martin Fowler. I refer to my self as an author, speaker, and general loud mouth on the topic of software development. I’ve written more books than I would care to admit and have a blog website-y thing at martinfowler.com. JAMES:  Awesome. AVDI:  Good morning and welcome to the show. JAMES:  Yeah. MARTIN:  Yeah. Thank you for having me. JAMES:  Absolutely. So today, we’re going to talk about one of your books that you mentioned and that is ‘Patterns of Enterprise Application Architecture’ which is kind of a mouthful. MARTIN:  It is. I often wondered about that when I was working on the book whether it was just too much of a mouthful. But I couldn’t think of any more piffy title to go with, so I ended up just going with it. It doesn’t seem to have harmed the book. JOSH:  Well, it is a whole lot of vowels in the acronym. You couldn’t go with something with a cute acronym like POODR, right? [Laughter] MARTIN:   No. I didn’t worry too much about the acronym, I guess. JAMES:  So to kick this conversation off, I’d like to give one of my favorite quotes from the book. And it says -- and this was written over a decade ago now, right? It says, “The only reason I’m concentrating on Java and .NET environments is that they look like the most common platform for an enterprise application development in the future although, I’d like to see the dynamically type scripting languages, in particular Python and Ruby, give them a run for their money.” MARTIN:  Wow! Did I say that? JAMES:   Yeah. MARTIN:   Cool. JOSH:  Yes. That was a memorable quote for me too. MARTIN :  Yeah. And I’ve completely forgotten it. I guess it’s somewhere in the book, but yeah. I guess, at that time, I was actually just starting really with Ruby at the time I wrote the book. But I only really started programming Ruby when the Pickaxe book came out. I mean, Dave and Andy had been going at me to say, “You really ought to try Ruby, you’d love it. I know you’d love it.” And I kept going, “Oh, no. Not another freaking language. Python’s kind of okay for my scripting needs. I don’t really need anything else.” And then I read the Pickaxe book. So, I thought, “Oh, this Ruby looks really sweet.” And I steadily, all my personal programming work now, keeping the website going and the like Ruby is the dominant language that I use to program that. I don’t however program in Rails at all. I’ve read some books about Rails. I’ve looked at Rails code. I keep intending to spend a really long time looking at one of our bigger code bases at ThoughtWorks but I’ve never actually programmed Rails seriously just because I haven’t -- I keep asking my wife, “Would you like a database-packed web application?” And she just sits there, “Yes.” So, I haven’t got around to writing it. [Laughter] JOSH:  Isn’t that like the 37^th Anniversary? [Laughter] JAMES:  Surely, it’s one of them. JOSH:  It’s like a three-tier web application? [Laughter] JOSH:  Martin, do you remember what your first Ruby program was? Or maybe the first one of any significance? MARTIN:  The first one of significance was when I had to fly to India for, in the early days setting up in ThoughtWorks India. And I thought I really would like to get on this blog thing that people were talking about. But I didn’t really want to do the regular kind of blog stuff. So, I had this vision of something that would be kind of part blog, part wiki which turned, of course, into the Bliki part of my website. And at that time, all the stuff for my website was based on XSLT transformations. I would write articles in my own vocabulary of XML and then transform them into HTML. And that process worked really well. But I was getting really, really sick of XSLT. I’d gotten good at it and I knew that this wasn’t the future. So, I thought, “I wonder what it would be like to try out this whole blog thing in Ruby and give that a spin?” So, on the two flights from Boston to Frankfurt and Frankfurt to Bangalore I did the first version of the Bliki program. And since then, everything I’ve done with my website has been in Ruby. I completely stopped using XSLT. There may be some bits of it still lying around but it’s only because I haven’t bothered to re-implement them. JOSH:  Well, if you didn’t use Rails to write your Bliki, what did you use for -- I guess, you didn’t use a framework, you just built it? MARTIN:  I used XML processing libraries because as I say, it’s an XML transform. So, my website is purely static. It just uses file system, my deployment script is Async. It’s all very, very simple. I don’t see the need for a database because it’s only a ‘read only’ site. And if you do a purely static site, it does really cache very, very nicely. So, it’s very web friendly. And people are beginning to copy and caught on to that now. And so, in the Ruby world, we see G: and the like to handle that. And so, really, the question is just how do you do the transform? It’s really just slurp up the XML and then I have a very small class that tree walks through the XML and spits out HTML. That’s been the essence of all of my processing. It’s somewhat influenced by the XSLT programming model because I have little methods for each element class that you come across. And so, you can certainly see echoes of that. So, it’s really nice. And it’s just so much better than XSLT. JOSH:  [Laughs] Okay. So, since we’re talking about your book, which of the main patterns in your book do you think your Bliki is using? Is that something like a transaction script? JAMES:  I was going to say transform view. JOSH:   Transform view. [Crosstalk] MARTIN:  Transform view, it doesn’t really use any of the patterns in the book, of course, because the book is all about enterprise applications which tend to be sort of much more data intensive, update, read. While mine is very much very simple, my website because it’s purely static, it’s just a one-way transform. So, it doesn’t really touch. But the kind of two step view, transform view is the closest to that, but I don’t tend to think of it in those kind of terms because it’s a different kind of program. This is a very important point about the book, actually. The reason I wrote this book is because I felt that if you were going to write about -- I mean, there are certain low level programming patterns that are used quite widely. The design patterns book captured a fair few of those. But I felt that as you moved into more exploration of how to talk about software patterns, you ended up being where you had to go for patterns that were specific to certain kinds of applications. I sat in a bunch of patterns workshops around telecoms, for instance, because there were a bunch of people who did telephone switches. And the patterns they use totally meant nothing to me because I’ve always concentrated in this enterprise applications world. And so, I felt that any patterns that I was interested in would come from that particular area and they would be very focused on only enterprise apps. And as I say that, I have to mention that enterprise applications, it didn’t have the bad connotations of enterprise that we have now. So really, by enterprise applications, I mean typically database backed systems where you’re bringing a lot of data, throwing it up on the screen, allowing people to modify it, running business logic, usually a lot of talking to third party and existing legacy systems. So you’ve got to kind of combine all of that as well. But it’s very data intensive and it’s very much about editing fairly rich data structures and communicating with other systems. JAMES:  That’s awesome. In the book, you do actually spend quite a bit of time defining the title, actually. Like, what is a pattern? What is an enterprise application? Why are we talking about architecture? Actually, I found that section kind of enlightening to read, what you were thinking about at each level. JOSH:  It’s like you wrote that book for me. You started off defining everything. [Laughter] MARTIN:  Well, yeah. I mean, with a title like that, you really do have to define what you mean by the title. The title really does describe what the book is about but only if you know what the words mean. And of course, every word in software development gets overloaded 25 different ways so we have to be somewhat careful to say what it means. If you’re wondering, “Is this book for me?” The first thing you have to -- I mean, I always took the line of saying when you’re writing the first part of the book, the people are asking themselves, “Is this relevant to what I need to know about?” So in this situation, you kind of have to define what you’re talking about early on. KATRINA:  I particularly like the definition of architecture as being a pretentious word that sounds important so you know that what we’re talking about is important. MARTIN:  Yep. That has still been my feeling. I still notice I shy away from using the word ‘architecture’ because it does carry a lot of that pretention. And you see that very noticeably in certain communities. Certainly, people around ThoughtWorks tend to be very wary of the word ‘architecture’. Hardly anybody puts architect on their business card. I think and it’s partly sad that that’s happened, it’s partly because of the fact you run into so many people who do use the word ‘architect’ who have really distanced themselves a lot from day to day software development and have lost touch really with what the serious issues are. And this is, of course, a thread that goes through the Agile community. A lot of the people in the Agile community, particularly those around the extreme programming part of it, very much are of the view that if you’re going to stay technical, even though you’ve got an operator kind of a relatively high level and talk about fairly broad issues, you’ve also got to be prepared to dive in and work at the code level. If you can’t operate at both levels, then you don’t really have an understanding of what’s going on. KATRINA:  I’ve rarely heard the word ‘architect’ used in the past few years without having it be prefixed by Ivory Tower. MARTIN:  Yeah. JAMES:  Or architecture astronaut, right? KATRINA:  Right. JOSH:  You need architecture to build an Ivory Tower. It’s a building. [Chuckles] Okay. So, let’s not rag on ragging on architects too much, let’s talk about what the cool stuff from the book is, right? JAMES:   The definition of patterns, I also found really cool. The book says, “Each pattern describes a problem that occurs over and over again in our environment.” And then describes the core of the solution to that problem in such a way that you can use the solution a million times over without ever doing it the same way twice. MARTIN:  That’s somebody else’s quote, not mine, it’s got to be. Yes, it’s Alexander’s one. I'm just looking at it. Yeah, but that is the essence of what it’s about. We’re trying to say -- the way I describe it now, I’d have to re-read how I describe it in the book, is patterns are common solutions. Things that you run into time and time again, but they’re not -- you can’t just cookie cutter them. You can’t just throw them into a library and say it’s done. Well, let me go read and breathe past that. But each time you solve it, there are often little variations. So as a result, it isn’t quite the same in the different cases that you use it. I mean, if you do run into it the same time, then yes, you can embed it into a library and of course, that’s what active record does. But the point is I have used the act on seeing the active record pattern in Java, in .NET, in Ruby, you see it all over the place. And in fact, when I was writing the book, of course I wasn’t thinking of Ruby’s active record which didn’t exist at that time. I was thinking the most common one that was most virulently in front of us which was the entity beans of EJB. And if you want to complain about active record, you need to spend some time programming with those. JOSH:  [Chuckles] Right. Hey Martin, I remember when the whole pattern stuff started to take over in the software design community. When I was working with Kent in like ’88, he showed me Christopher Alexander’s ‘Timeless Way of Building’. And Alexander’s approach on patterns was that they were all interconnected kind of stuff. Then when I looked at the Gang of Four Design Patterns book, they don’t have much interaction between the patterns that they described in the book, they’re all sort of stand alone things and the level of granularity that they’re addressing is pretty fine grain in a lot of times. But one of the coolest things about your book as I was reading it was the interconnectedness of the patterns. And I think it’s because you have these things layered and that you look at them as different aspects of system building that it’s so nice that when I sit down and read through a section on a pattern, you say, “Well, if you’re building this kind of application, this pattern works well coupled with this other kind of pattern.” So, I think it’s much truer to the original spirit of that kind of mix and match, retarget this pattern however you want to use it in your particular situation. I find that pretty nice. MARTIN:  Yeah. I think that’s part of the nature of where I’m at. I mean, with the Gang of Four patterns, they are relatively independent and really, you want them to be. I mean, the reason I use patterns as a tool for writing and I use it for this book, I use it for the Domain-Specific Languages book, it’s really because I’m trying to deal with the problem of how can we deal with the overload of all the information that you need to consume? I mean, there’s so much stuff you’ve got to read out there. So, you need a way to kind of chunk it up so that I can get to the stuff that I need to read right now to solve this particular problem that I’m dealing with. And my interest in patterns is that there’s a way of breaking up what I’m talking about into such chunks. So, there’s a very explicit structure in this book and in other books I’ve written and other books that people who have a bit of an influence by me have done, where you’ve got a short section at the beginning of the book, just 100 - 150 pages which you are supposed to read through from piece to piece. But the bulk of the book is like a reference book where you dip into actual patterns as needed. So, that’s purely there so that you don’t have to read the whole book in order to be able to get value from it. And so, you kind of want the patterns ideally to be independent of each other. Now, of course, there are links and you do have to mix them together. And I think that’s more true for the kinds of patterns I’m talking about than was true with the Gang of Four’s ones. JOSH:  Oh, yeah. I wasn’t trying to be critical of the Gang of Four book. I think that it stands on its own. But it’s just saying that it was really nice to see all of the interconnectedness and there was a lot of prescriptive advice in there which was really great. JAMES:  I was just going to say that what Martin was talking about there, the section at the beginning of the book, kind of introduces you to all the scenarios that these patterns are written around. And it’s just ridiculously practical. In like, it will say something like, “When you find yourself in this situation, here are your three choices,” you know. And then… JOSH:  Yeah, and what are the trade-offs? What are the costs and the benefits? JAMES:  Right. MARTIN:  Well, I think program design is all about trade-offs. There are very few cases when you can say, “Whatever you should do, you should do this.” All the time, you have to say, “Well, here are my options. Here are the trade-offs between them.” And I choose whichever one sucks less. [Laughter] JOSH:  Nice. Yeah, that’s pretty much how we all think, right? Everything’s going to suck. It’s what sucks less. AVDI:  I have a little question about patterns in general. It seems like right now, the Ruby and particularly the Rails community is kind of rediscovering patterns. There have been a lot of talks and blog posts kind of pulling out patterns and re-exposing a newer audience to them and a lot of kind of awareness that a some of the practices that have been used in larger Rails applications don’t hold up and going back to the patterns literature for that. It’s interesting to me because Rails is built on, basically, it’s built on your book. Many, like half the classes in it, are actually named after patterns from this book. And yet, we have this phenomenon of people that are basically new to patterns. When I was learning software, a lot of what I learned was from reading the patterns, portal and patterns repository and stuff like that. It seems like there’s less work in patterns now. There are fewer conferences. I was kind of racking my brain. I can’t think of the last time I saw somebody go through the process of documenting an observed pattern in Rails development or something like that. I guess the question is what has happened with the patterns community lately and kind of wither patterns from here? MARTIN:  Well, I think the patterns community went through the usual cycle of enthusiasm and then tapering off. I mean, for a while, patterns were incredibly fashionable and then they lost their fashion ability and people moved off into other things. For me, it was kind of odd. I mean, the patterns community brought together a lot of really quite different people from different backgrounds whose really only common thing was that they were exploring this way of writing about stuff in terms of patterns, which was good because it allowed us, I think, to -- like I said, I got insights into telephone switch design that I never otherwise would have got. But there wasn’t really much holding it together in that sense. For me, patterns are very much a writing tool. They’re a way to organize larger bodies of stuff and I tend to deemphasize the fact that I’m using patterns even when I’m using them. At that time, you had to have ‘patterns’ in the book title. So, this book had ‘patterns’ in the book title. But my domain specific languages book is structured in exactly the same way, is pretty much all patterns, but I don’t use patterns in the title because it’s less fashionable now, I guess. But it’s still the technique for trying to organize a large body of advice. I still think patterns are a good way to do it. And this idea of naming common solutions, I mean, that appears in other places, certainly in my work. So, one of the things that appealed to me about the wiki naming style thing for my blog, hence the ‘Bliki’ was because you have these nouns. And every time I want to write something in my blog, I have to think, “What am I going to name this,” in such a way that it’s going to fit in with conversation. And then I hope that allows me to be, to focus more on writing for the long term than writing for the short term because this is where I think patterns are really interesting is that they’re trying to capture long term knowledge. The stuff that I wrote about in ‘Patterns of Enterprise Application Architecture’ book I think has held up very well over the course of ten years. And the Gang of Four book, similarly. Those patterns are still relevant to know about. And that’s really important because our languages change, our technologies change all the time. But if you can understand core principles of good software design, they’re going to last you for a really long time. JAMES:  Yeah. And you talked about how it’s valuable in writing but I was actually thinking more like in communication in general, right? I mean, I can say ‘method object’ and all of us here just start nodding, right? So, that kind of shared grammar. MARTIN:  Yeah. You're trying to build up -- I mean, it’s often people criticize people for being heavily into jargon. But the reality is, in order to communicate effectively, you need a jargon in any complicated field. I worked for a bunch of time in the National Health Service and doctors, they use jargon. And it’s not even in English because they’re using Latin and Greek words all the time. But they have to because how else do you communicate? Can you imagine describing somebody’s medical condition using only simple English words of no medical jargon in it? It would take you forever! And so, we do the same. When you say, “Oh, this is an active record object,” immediately, I have a bunch of connotations going through my mind about what to expect about that object. There was actually, this came out of one of the threads in Parley. If somebody says, “Oh, this is a value object,” or, “This is a service,” I immediately have a bunch of expectations about how the object behaves, what I expect it to look like, what I expect to do with it. And the more we can share these then it makes it easier for us to see different code bases and understand what’s going on. KATRINA:  One of the things that really surprised me as I was reading the book was that there was a lot of the jargon that I had a completely wrong understanding of and possibly this is because of exposure. And as you mentioned earlier, terms are often overloaded. But there are like the application controller, for example. I’ve never thought of an application controller in the same way that the book describes it as being sort of the controller for a type of wizard where the order of the pages matter, et cetera and there could be variations in where you would end up in this sort of applicable tree of options. And another one that surprised me was the query object. I’ve always used the query object as this dumb sort of thing where you stick a big ugly sequel query in it just so that you can hide it from the rest of the application, it doesn’t really belong anywhere else. Whereas the query object that you talk about in the book is a very complex thing. MARTIN:  Right. And the thing, of course, is that there is no official committee that registers all these names and makes sure that people only use them properly. So as a result, people use lots of names in different places. And whenever you encounter a name, you have to say, “Okay, what particular version of this name does this co-notate?” And over time, I suspect if what’s the case is with other professions, over time, that situation will gradually converge but it will take generations. If you look at the history of the early days of chemistry, for instance, there’s this huge divide between what the British-oriented people used for chemical terms and what the French-oriented ones came from. There probably were other schools as well. But that was the most noticeable one that I read about. And in the end, the French one won but it took several generations of the Brits to give in and switch terms. And I suspect that’s going to happen in our industry, as well. AVDI:  This leads into a question that I’ve really been wanting to ask. So, you describe yourself as a ‘loud mouth’ and I love that description. I guess as hosts of a podcast, we’re sort of loud mouths ourselves. And I think it’s safe to say that at this point when you write a book, a lot of people consider it authoritative. And what I'm curious about, I know that like journalists, traditional journalists, they have a Journalist Code of Ethics that they try to, or at least most of them try to stick to with rules like, in order to say, “Sources say,” you have to have at least two independent sources and things like that. I’m curious, in your approach to documenting this stuff, do you have like an equivalent to a Journalist Code of Ethics, a set of guidelines or rules that you follow in order to determine whether something is authoritative, whether you feel like it’s worth documenting for the ages or whether it’s just something that you used yourself and you’re not so sure about? Where do you draw that line? MARTIN:  I don’t have any kind of explicit hard rules. I do use a lot -- a lot of it is my personal judgment of what I think is important.  But it’s couched heavily in conversations with other people. So, the great beauty for me of working at ThoughtWorks is I get to interact with a lot of people who are doing real work unlike me, who just writes. And I can get to bounce ideas off them and look at what they’re doing. And anytime I write anything that goes on my website, almost always it’s gone through the ThoughtWorks mailing list first. And they’re not shy at telling me where they think I’ve got something wrong or whatever. And there are posts that have gone in there and I’ve never posted publicly because I’ve just got it wrong. And so, that’s what I use as kind of my sounding board. But in the end, it does come down to judgment. Now there’s an interesting twist on this as the number of people in the patterns community at that time, kind of late ‘90’s, were saying, “In order for it to be a pattern, it has to have two known uses or three known uses.” whatever the number was. I was never strict about that. I can’t remember who but it was somebody else I remember commented that, “It’s perfectly okay for something to be listed as a pattern, if once you saw it, you realized you should have used it in three different places.” [Laughter] MARTIN:   And so, I was relatively casual about that. But I do take very seriously the fact that I know I have a loud megaphone. And so, I do put a fair amount of care into what I write about, and choose what I write about, and how I write about it. And I also do a similar amount of care in trying to use that megaphone for other people. So, when somebody else puts an article on my website, there is a sense that I’m saying, “Yes, I think that this is worth the time and trouble for you to read.” And I do take that responsibility quite seriously. AVDI:  Use your powers for good and not evil. MARTIN:  Exactly. JOSH:  Well done, sir. [Laughter] MARTIN:  Well, I try. But I mean, who knows? I could be completely wrong. That’s part of the situation we’re in, right? We don’t really know very much about what works and what doesn’t work. And as I like to say, “Twenty four percent of everything I say is wrong.” [Laughter] JOSH:  Well, that’s life, right? You do the best you can and hope it works out. MARTIN:   Yup. JOSH:   So James, you probably have, I have a stack of index cards of notes that I took from the book. You must have like sheets of TextMate documents or something. JAMES :  [Chuckles] Evernote, I use Evernote for notes. JOSH:   Okay. [Chuckles] JAMES:   Yeah. I’ve got some more thoughts. I found it super interesting to hear you say that you’ve never used Rails because if I were to title your book today, it would be ‘The Secret Manual of Rails’. [Laughter] JAMES:  Because when I was reading it, I was like, “Oh, wow! I know what all this stuff is,” because it’s all in Rails. I mean, it’s amazing how many patterns Rails uses out of here. I mean, obviously, Active Record, MVC, template view. It uses almost all of the state sessions, state patterns, client server, database serialized LOB as active records, serialized macro, and all that. JOSH:  Lazy loading. JAMES:  Yeah, lazy loading is in there for how it does queries these days. It’s just unbelievable. And Katrina actually mentioned this. But the application controller, Rails has that but when I read the pattern, I didn’t think it was the same thing. AVDI:  It’s the router. JAMES :  Well, you see I thought the router was the front controller. Am I wrong in that? I don’t know. JOSH:  So, that’s something that I wanted to do was to try and categorize the classes in Rails according to what’s going on in the book. And that might be like a project that we could do collaboratively on the Parley list. JAMES:  Yeah, that’s a neat idea. My opinion was that the router is the front controller pattern, but I may be wrong about that. But, yes. Anyway, Rails obviously… AVDI:  Martin, would you like to express an opinion? MARTIN:  Well, because the problem here is I don’t know enough about Rails. But from what I know of routers generally, and I’ve used Sinatra more than I’ve used Rails which may be influencing. I think it does fit more like a front controller because it’s saying, “Okay, given this bit of information, what should handle it?” It’s picking off the handle. The application controller is much more about, “Here is the state of the application or this part of the application. Now, this has happened, what do I do next?” JAMES:  See? That’s not what Rails’ application controller is at all. Rails’ application controller is actually what you call a layer super type, I believe, that it pulls out of all the controllers so they can have basically shared ideas between them. MARTIN:  Yeah. But that would be a naming thing that I wouldn’t be surprised about because controllers used so heavily in the Rails setup that having some kind of layer super type with that kind of name is inevitably going to follow. I want to point out though, you say Rails is full of these patterns, I would argue most application framework building tools are going to be full of these patterns. And they’re going to be full of these patterns not because I’m some clever clogs. They’re full of those patterns because where did I get them from? Well, I got them by looking at lots of enterprise applications that were being built and saying, “Oh! That’s a common pattern! I see this all over the place.” AVDI:  Well, Rails did go and name the classes after your patterns. So, there's that. MARTIN:  Yes. So, I know David had read the book because I don’t know how many people know this. But if you go to my website, you’ll notice in the little website summaries of the patterns, you’ll notice some of them have really nice OmniGraffle drawings and some of them have crappy Visio drawings. And the really, really nice OmniGraffle drawings were done by David. JAMES:  Yeah. David actually did a blog post not too long back where he list what he considers the five programming books that we all need to know. And ‘Patterns of Enterprise Application Architecture’ is one of the five. It’s definitely clear that he based a lot of Rails on it. MARTIN:  Yeah. It would be interesting. I’ve never done this, sat down with David to talk about how that thinking went in there because I’m sure the book was helpful, I certainly hope the book was helpful. But also, there are lots and lots of systems out there that do these kinds of things so that you can look at them in different places. One of the comments that was made about the book when it came out was hearing an experienced developer of these systems say, “Oh, there’s nothing new in this book. This is all stuff people like me already know.” To which my reaction was, “Yes, that is the point.” [Chuckles] JAMES:  It’s actually still immensely relevant like just recently, Rails has had kind of a rash of security issues. And you know how that goes, they find one then they find all the similar ones. So, we’re in that phase right now. And one of the things they’ve been examining is how they keep track of session state. And Rails currently favors doing it client side with a cookie. And there’s some security issues with that. And then, I’m reading your book and lo and behold, it says, “One of the major problems with client session state is there’s some security issues with that.” [Laughter] MARTIN:   Exactly. JOSH:  The thing that stood out to me when I was reading the book and in exactly along these lines, James, is that Rails started with, I think, a smaller set of patterns. And it has grown over the last five or so years and evolved and incorporated more of these things. So, if you’re talking about session state, Rails started off with database backed sessions and that was how you did it. Then some people came out with ways of using Memcached to store their session data so you didn’t have to hit the database all the time, and then it went into the cookies. So, it started with one approach and then pretty quickly, expanded to include the three different main flavors, the three different main patterns around there. And likewise, things like lazy loading has become more and more common throughout active record. And now, we have the lazy treching on scopes. I’m curious if there’s -- I guess the other side of that is that you look at active record itself and how just like you talked about in the book, you said, “This is great for simple stuff.” But when you really want to do a rich domain model that has more than a couple dozen classes in it, it’s going to run out of steam and get too complicated. And now, everybody is hitting that. It’s like half the conference talks I’ve seen in the last year have been about dealing with that in one way or another. Is there an evolution over time perspective that needs to be addressed more fully? I know you talked about that in the book somewhat. But it seems like that whole arc of, what are the patterns you start with and what do you move to over time is really worth considering. MARTIN:  Yeah. Although, I’d like to throw a caution in there is that there’s a natural tendency to, once you’ve hit the point where a simpler pattern isn’t working for you anymore and you have to start using the more complicated one, to then always reach for the complicated one in other situations where the simple one would be just fine. And so yes, there’s a sense of maturity and it’s only really once you’ve popped across the boundaries of the active record pattern that you begin to realize why the extra complexity of a data mapper pattern is needed. But you should never forget that when you’re coming into a new situation, if active record is a good fit, it’s still going to be a good fit. And I think because the beauty of the active record pattern, it manages to keep that similarity through from the database into the object, into the UI. If you can pull that off and your problems simple enough to be able to work with that, then that’s a great thing. And I think that from what I’ve seen of the Rails implementation of active record, it is a very nice implementation of it, certainly way nicer than Entity Beans in EJB was. JOSH:  It’s a bit of a Frankenstein in that it’s mainly active record but it’s not quite. It’s maybe a mutant of active record. But I think that the simplicity that you’re talking about there and how the active record pattern is a really good fit for a lot of problems, I think that that limited focus of Rails in the 1.0 days was part of what made it successful. It was so easy for people to adopt that style of programming. MARTIN:  It’s one of the things I liked about Rails from the beginning is it was very clear about what kind of framework it was, what kind of problems it was aiming at. And when people said, “Hey, how do we use this with complex integration databases with God-awful steamers?” David’s reaction was to say, “I don’t care.” And I felt that was a good thing because when a framework is trying to do too many different things then it’s much harder to use. And I rather liked that simplicity that it tried to flow and say, “If this doesn’t fit your problem, use something else.” It’s too easy for people to try. And we saw this a hell of a lot in the ‘90’s where people would try and create something that would handle every possible problem in order to gain market share or whatever. And the trouble is those things just end up being too complicated to use. JAMES:  That’s a really good point, actually. Even some things in the book, you pretty much site as staples. Rails actually has ignored some of that. The example that pops into my mind is the identity map which you pretty much say, “Once the database layer reaches a certain point, you’re going to want the identity map so that all objects are the same.” And Rails had a kind of half-busted identity map that was off by default for a long, long time. Now, it may have a whole-y busted identity map or none at all. I don’t remember. But anyway, they do not drink the identity map Kool-Aid. And it is actually an issue, right? I mean, you don’t run into it often, I don’t think. But you can and I have run into scenarios where I ended up fetching the same object twice and it’s not the same object. So then, I change one thinking I’ve done something and the other one has stale data or whatever, you know. And you run into those scenarios. JOSH:  The identity map, I think, it got pulled out of Rails. It was something in the 3.0 timeframe. They were trying to -- it was there for a while and they pulled it out because there were problems. My just a real quick read on why the identity map failed is because the active record abstraction in Rails is way too leaky. And there’s all these times where you have to deal with the raw SQL in parts of the query. And that, in itself, isn’t terrible except that the way that identity map works, there’s not really any provision for having a subset of an object or queries that have complicated conditions that can affect basically the result set in crazy ways. So, I know the active record query caching stuff is pretty sensitive to having conditions on queries that return particular objects and it can’t tell that they’re the same object even though they have the same ID or primary key. JAMES:  Right. It’s also possible with active record to bring back the same object but with different fields, right? JOSH:  Yeah, right. So, I think that’s mostly what killed the identity maps implementation in active record. But Martin, I don’t remember the details in the book. I seem to remember that identity map wasn’t necessarily a good fit with active record. MARTIN:  Yeah, although it’s also a case of does it make a good fit when you have a much more visible sequel? Identity map tends to go with much more the ‘shut the database up in the attic so we don’t have to look at it’ style ORMs, where really, you never want people -- people don’t want to be writing sequel. Active record has much more in the habit of, “Hey, you’re a programmer. You’re programming a very relational database. You should download our sequel. We’ll do the simple stuff for you in active record. But as soon as you want something complicated, go to sequel.” And when you do that, that immediately then begins to bugger up identity maps because how do you make sure that ID is coming back synchronizes what you were thinking in the identity map. And it also kind of matters less because the whole point of the active record is you actually are looking at objects that look like database rows. And so, you’re relying on that isomorphism. As a result, it tends to matter a lot less. One of the other big threats for the book was there are no uber architectures that you should use all of the time. And part of the reason I wrote this book was a reaction to a number of bodies going out there saying, “Oh, here is the standard architecture for all applications.” And I wanted to say, “Well, no. There isn’t one standard because there all different kinds of applications.” And sometimes, you want to go one way and sometimes, you want to go another way. The active record and the Rails kind of route definitely takes you down one particular direction, does it very well and you have to be conscious of when that isn’t appropriate. AVDI :  This has led me to a new question I hadn’t originally planned on asking this. But you recently authored a book called NoSQL Distilled, right? Where you go through kind of a bunch of different approaches to non-relational database or NonSQL databases and talk about strengths and weaknesses. And obviously, we are talking about POEAA. But I’m curious like a lot of people are working with these NoSQL databases. And I’m just curious if you have any insights to quickly share about the patterns to use with these databases or just like thoughts on how the things that you documented in that book apply to these data stores. MARTIN:  I haven’t gone through in great detail with this. And I really need to spend some time looking at some of our code bases where we’ve used NoSQL systems. The first thing I want to say is that you have to remember there’s more than one kind of NoSQL system floating around here. And they have very different characteristics. The way you interact with a graph database is very different to the way you talk to a document database. One thing that is a very strong thing for me, at least, is that many of these NoSQL databases have a very strong sense of a pattern that isn’t in my book called the Aggregate which is a pattern that’s in the main driven design. And the notion of saying, “We’re going to actually take a clump of data that’s got a much richer structure than simple rows and we’re going to be able to interact with it as one single thing.” That’s a very central part. That’s essentially the document for document databases or the value for key value databases. And that has a very big role to play. That’s what shifts a lot of the assumptions that you would typically make when dealing with relational databases. And so, that has a very interesting consequence and interplay with these kinds of patterns. Because for instance, all the relational patterns are really about how do I deal with the fact that I’ve got this mismatch between fairly rich object structures in memory and rows and tables on the database, a lot of those simplify and go away when you can say, “Oh, I can take a rich structure as long as it’s a well defined hierarchy and I can just throw it in the database in one go.” JAMES:  That’s kind of neat too because when I was reading the data mapper pattern, I’m not as familiar with that one because I came up through Rails. And so, I read your pattern and that actually got me to looking at -- Ruby does have a data mapper library and it’s kind of in a big transition right now. Historically, it was a little closer to an active record but it is in the current rewrite. They are molding it more as a traditional data mapper, as you described it. They’ve added in a lot of other cool stuff really. Like unit of work, the pattern from your book is definitely in there and stuff. And it got me to reading about all that and thinking about how it goes. And it’s pretty interesting for the reason you were just talking about because something like, if you have some top level table within its dependent rows in a different table, a great example from the book is an order and the line items. Those are almost always tied together. And you don’t typically have a lot of heavy relations to something like a raw line item, right? It’s usually just the order and stuff. You can actually write the mapper where it just deals with the whole thing as one concept in order plus the line items. MARTIN:  Right. And that’s a classic example of an aggregate. And also, I think, it’s a classic example (a) because it’s very familiar and obvious, but also you can see the flaw because the flaw is what happens if I want to see breakdowns of sales of different products? Well then, I want to look at the line items a completely different way. And that’s where a relational approach is really nice because I just slice the data differently by having different queries. But an aggregator approach that treats all the orders as their own aggregate, then you got to do something different. That’s why you have to reconstitute aggregates by using map produce jobs and all that kind of stuff comes into the picture. But again, it depends on the system you’re working with. I’ve been looking at the code recently for one of our projects. It’s all about managing purchase orders and the purchase order’s an obvious aggregate. And surprise, surprise! It works swimmingly well with a suitable NoSQL database because most of the time, you’re pulling purchase orders back and forth. AVDI:  What’s the best way to tackle that kind of decision? I feel like you could sort of make an artificial distinction between two schools of thought where in OO design where the one school is kind of an OO purist school where you come up with some objects to represent your business ideas, your domain concepts and you try really, really hard to make storage and presentation and all that stuff, an implementation detail that you can maybe swap out. But then, a lot of the stuff we’ve been talking about in this conversation, we’ve been talking about making pragmatic decisions like Rails actually makes a lot of sense. All the patterns, all the opinions in Rails actually make a lot of sense for a lot of web applications. Where do you fall in that continuum, if that even is a continuum, between like modeling your domain objects in a kind of a pure world and then attaching them to implementations versus looking at a problem upfront and thinking kind of architecturally and saying, “Well, actually I think I know. We should actually think about the storage here. And I think I know what kind of storage makes sense for this?” MARTIN:  I think one of the large drivers on this is the complexity of your domain logic. That’s certainly something that I felt at the time when I wrote the book because I said that was the thing that drove you from transaction script to domain model and I think it has a lot to do with this now. The whole point of a domain model is you want to construct this model that’s going to be as independent as possible of all things like storage. And the payoff for doing that is when you’ve got a lot of complex behavior in it and you need to really be able to think about the behavior independently of all the other stuff because the behavior is sufficiently complicated, that’s a brain full right there. If on the other hand, you’re just slinging some stuff out of the database, throwing it on the glass, allowing people to edit it, maybe doing a couple of bits of validation and then slinging it back in the database, then a complicated domain model isn’t really worth the trouble. JOSH:  I have a couple particular little questions. Probably the most nitpicky thing, well, I don’t know about nit picking. Anyway so, row data gateway. This is an interesting little pattern and I don’t know that I’ve done anything exactly like that. It gets kind of close to active record sometimes. One of the things that you mentioned when you were talking about the pattern is that if you have sufficient metadata, you can basically generate the row data gateway classes. I found that kind of interesting. It’s like, “Well, if you can generate this thing automatically from metadata, how much value is it actually providing?” And then I realized, “It’s actually sort of bringing concepts in one layer into a different layer and making them accessible.” This whole sort of like, “Okay, I’m generating an interface that I can use on my code based on metadata in the database.” Is that what you’re talking about there? Or is it something more than that? MARTIN:  Yeah. There was, in that particular thing, that was definitely what I had in mind. The idea that you can actually query the database table, metadata itself and generate suitable row data gateway objects because the row data gateway, I should define what the pattern is for those who aren’t familiar. From a Rails background, I would say it’s an active record but you have no logic in there whatsoever other than the logic to map back and forth to the database tables. So, you have just plain data. It’s completely bereft of certainly no domain logic but nothing else. It’s just really handling that data back and forth. And that is something that -- people did write various tools to allow you to do that. And you often see underlying even in other applications that do things differently because what you want to do is to have this very close combination. There’s some of that generation going on, of course, in active record itself. I seem to remember certainly in the very early days before migrations, for instance, I seem to remember it, you did pull off directly based on the database structure because the demos were you were doing something in the MySQL GUI or something and then you would just pick it up from the tables. And that’s part of active record is generated. Being Ruby, it generates it at runtime. But obviously, in every environment, you might want to generate that as a static step. But the point is if you’ve got the information in the database, why copy that information again? What you want to do is you want to have that data presented in a way that’s convenient for you to work with as Ruby objects rather than fiddling around with SQL cores. JOSH:  Right. And active record still does that. It introspects the database and figures out what the attributes are. MARTIN:  Right. And the point of a row data gateway is when you’re expecting to put your business logic in other places. So maybe, you have an application where you are going to use transaction scripts. My sense is that there’s less need to do that because a lot of the problem here was the fact that a lot of people would build databasey-like frameworks where there was no real easy place to put behavior in objects. The classic two-tier frameworks of the late ‘90’s, Visual Basics, Power Builders, the [inaudible] of the world, they would have these database to where visual controls and there was nowhere to stick the logic. You either had to stick it in transaction scripts installed procedures in the database or effectively transaction scripts stuck in the GUI layer in Visual Basic. There was no intermediate place. One of the nice things about Rails is that the active record objects give you a place to put that kind of logic and it kind of naturally flows in there which I would expect then to mean, well, there’s less need to do it in other ways. JOSH:  It seems like some of the stuff that has been talked about in making Rails tests fast in the last year or so is like what Corey Haines has been doing. He’s trying to make Rails active record be more like a row data gateway and moving the domain logic out of the active record class into just a plain old Ruby object. And maybe that’s one of the reasons that I always found that a little awkward in terms of how to structure the code. You say in the book, row data gateway isn’t very compatible with a rich domain model. The impedance mismatch gets a little hard at that level. MARTIN:  Yeah and that’s why I don’t -- the idea is that if you’re using the row data gateway then that implies that your code is directly accessing the gateway and if you’ve got a rich data model, then that’s going to get tangled up with your domain model. And if you’re doing it on a one to one basis, one domain model class exactly mirroring the row data gateway class, then why don’t you just combine them and do the active record thing? Now, I haven’t looked at what Corey Haines has been doing with this stuff. But that conversation actually is very familiar to me because we had this huge dispute about this in the early days of Ruby at ThoughtWorks. So, this is several years ago now. Where there was one faction that said, “Hey, Rails likes to talk directly to the database. So, we’re going to write our tests that way and we’re going to do our best to make the database access fast by using in-memory databases or whatever we do to handle that.” And another faction said, “No. We’ve found our experience that whenever you talk to the database, it slows down the tests. So, we’re going to find clever ways to step out of the database.” And they came up with ways of stubbing out individual methods within an active record class so that those are never actually talking to the database and came up with clever ways to do that kind of thing. That question sort of raised itself right from the beginning. JOSH:  Nice to see how everything comes full circle eventually. JAMES:  Yeah, we’re still having exactly that same conversation today. It’s almost unchanged. [Laughter] MARTIN:  Yeah. And I think part of it is that the issue has become more pronounced because people are getting more used to the idea of tests running faster. Have this conversation ten years ago and you say, “Oh, we might as well talk to the database. The tests only take half an hour to run.” And people will go, “Wow! Those are really fast!” [Laughter] MARTIN:   And now, people don’t see half an hour as really fast these days. [Laughter] JOSH:  Well, at least we’re doing something with all those gigahertz. MARTIN:   Exactly. JOSH:   Okay. As James said when we started off the show, the book is over ten years old. It’s over a decade old. Parts of it hold up amazingly well. I think most of it holds up amazingly well. I think there's a few places where -- actually, there are a lot of places. I’m just reading the book and I’m like, “Oh, wow! I can tell this is a ten year old book.” And obviously, the thing you do when you’re reading is say, “Oh, there should be a Version 2.” I’m not going to curse you with the request for a Version 2. But I’m curious if there are places that stand out to you that would like be the natural candidates for updating? Like, you don’t talk about JSON, or REST or things like Memcached. And then there’s a whole thing about like Mongrel and Unicorn, all of the server architecture or, I guess, the web server component is all talking about sort of like Modperl type hosting within the web server process. And now, we have like Mongrel and Unicorn and Node kind of things going on that are so new. If you were going to do a Version 2, what are the things that you would want to update and hit? MARTIN:  I haven’t actually thought about that. I’m constantly writing stuff. And at the moment, I’m trying not to think about anything big like a book. And so, I’m just letting my self find interesting things and work with that and trying to come up with different ways of writing about things since my interest with Infodecks at the moment. And I haven’t really sat down to think, “What would I need to do if I was going to update this book?” And also, the question is I’ve long felt that there are additional materials to add to the book. It’s almost like a running joke now. I’m going to write this book about patterns around how to organize validation logic. [Laughter] MARTIN:   Well, I mean, we sketched it out back in the early ‘90’s. There was a little workshop in Arizona and I sat down with some people including a couple of my colleagues. And we had a bunch of cards and we had a whole bunch of patterns listed about two dozen or so. And we thought, “Yeah, that’s the skeleton on what would be a book for stuff about validation.” And I felt really excited about doing that. Then I realized that I couldn’t write those patterns without the context of writing about how the flow with user interfaces worked. Because the way validation fits in, depends upon how you structure your user interface flow. So, I started writing those patterns. And those are on my website, the ones to do with presentation layer patterns. So, things like presentation model and the various model we presented knock-offs and the like. And then that stopped when I started writing the Domain-Specific Languages book and I haven’t gone back to it yet. AVDI:  By the way, thank you for that stuff on your website because I referenced that heavily when I was writing objects on Rails. Very, very useful. MARTIN:  I’m certainly really glad that I put it up on the website while I was in the -- even though it was in a very shoddy state. It seemed to be odd to do it at that time because I was kind of thinking, “Well you know, this isn’t really properly worked out and I haven’t even proofread a lot of this stuff and it’s really kind of crummy.” But I’m so glad I did it anyway because a lot of people clearly have found it to be helpful. And if it’s been helpful to you then that is a great justification. JAMES:  Let me take Josh’s question in a slightly different direction. In reading your book, I almost got the impression that you would not be a fan of things like service-oriented architecture which now is very common, I think, in many cases especially where you have to handle load and stuff. In fact, in most of the book, you are pretty against a lot of remote things. I realize you do have patterns like remote façade and stuff. But I could read you some of your awesome quotes about what you think about distributed objects, they had me cracking up as I was reading the book. And I assume that’s from the time the book was written. I mean, you know, it is heavily steeped in that. Whereas now, I think we’ve changed a little bit and we tried to split things out into separate pieces more and stuff. So, I guess, I would ask, what is your opinion on something like a service-oriented architecture? MARTIN:  Well, of course now, we’ve run into the problem of service-oriented architecture means so many different things to different people. But I think we’re close enough that I can run with it. The big problem with distributed objects was the fact that they tried to hide that they were distributed. The whole magic of CORBA and it kind of fell into the enterprise particularly entity being the side of EJB was we can make objects and you don’t have to worry about whether they are on the other side of the world or they are in memory. Everything will just work the same. And I never thought very much of that argument. JAMES:  Right. And that was common then. But now, we don’t think like that. We think translate everything to something ridiculously generic like JSON or you know, and make it very clear there’s a separation layer and go more coarse grain, like you said, instead of fine grain. MARTIN:  And those are all good things. We’re thinking in terms of coarse and granularity. We’re consciously making remote calls as opposed to trying to hide them. And so therefore, we have a better degree of understanding of the cost that’s involved in doing them. That’s really the critical thing. I mean, remember, this is where people were thinking of the fact that if you wanted to query the customer data and get a thousand customers, you create a thousand remote objects, proxies in your model where every single method called on one of those object proxies would transparently result to a remote procedure call over to the server where the object really was living. I mean, we’re kind of laughing. But people were talking about that stuff with a very straight face at the time. JOSH:  I do remember distributed Smalltalk. [Laughter] JAMES:  Just to give one example of a great quote I think when you’re describing a system very much like that in your book, you actually say, “This design sucks like an inverted hurricane.” [Laughter] MARTIN:  Yeah. And I still remember when I was working on the book, one of the most useful sources of feedback was the University of Illinois patterns group which was run by Ralph Johnson, Brian Foote and Joe Yoder and that crowd. And I can still hear the voice of this student who I’ve since got to know a bit better, calling out when they were going, “Is it allowed to be able to use such language in a technical book?” And the old guys were saying, “Yeah. This is Martin. This is the way he likes to speak.” [Laughter] KATRINA:  One of the things that we talk about a lot more, I think, when we talk about distributed systems now or services architecture is conscious choices about asynchrony, conscious choices about what can we process offline or out of band of the current request. MARTIN:  Yeah. JAMES:   Yeah. And the whole background job problem seems kind of unaddressed by this book, right? MARTIN:  Yeah. That was one of the areas I knew I wasn’t hitting. And in fact, there’s another book that spent a lot of time going into asynchronous messaging stuff that’s the ‘Enterprise Integration Patterns’ book by Gregor Hohpe and Bobby Woolf. At the time I was writing this book, they were just beginning to start that one. So, it actually worked out kind of nicely because one of another good source of information for me when I was writing the ‘Patterns of Enterprise Application Architecture’ book was Kyle Brown who was a senior IBM guy and an old Smalltalker and he’s worked with Bobby Woolf. And in fact the Kyle Brown - Bobby Woolf stuff on the systems was one of the main sources of information for object relational mapping patterns at the time. I'm blanking on the name of it. But if you were around in the late ‘90’s, you would be looking at the Brown and Woolf stuff. And we got Bobby and Gregor together to work on the asynchronous messaging stuff and that’s a large part of why I thought, “Oh good, I don’t have to talk about it in this book.” Because it’s quite big enough and there’s a whole book of similar size on this by Gregor and Bobby which is also, I think, a very worthwhile book. JOSH:  Sorry. We’re hearing a little static over you. So, it’s a little distracting there but good point. The service stuff, the service layer pattern that you talk about, I think that we’ve been seeing a little conversation on the Parley list about service orientation and the service layer and service objects. My read of the service layer pattern is, and I’m trying to find out how to fit this into how we are thinking about Rails web applications because that’s mostly what we deal with, is that it’s a way for the application to present a layer of services to the external world that’s more high level. So, it’s more driven by use cases is what you call it in the book. But it’s more like the semantic operations or like the policy level abstraction built on top of the lower level mechanisms of the domain model. MARTIN:  Yeah. I mean, the service level is really, I think of it as trying to build an API for your application and that’s something that is -- I mean, increasingly people are looking to do that because they’re trying to expose data not just -- to expose data in terms of API’s for people to consume other than your usual UI frontend. So that has, I think, increased people’s interest in that. I should also point out something I should say is that the service layer is actually an example of the book but there are other authors than me that wrote the stuff. I mean, Randy Stafford did the stuff on service layer. The concurrency stuff was handled by my colleague Dave Rice. I really gained a lot from having other people participate in the writing of the book. Not just people actually wrote chapters but also, a lot of the people who provided some of the deep review and things of that kind. JAMES:  Yeah. I think it’s really confusing because in the Rails world, when people bring up service layer, it’s not always clear what they’re referring to. It’s definitely one of the more overloaded terms. I think more often, they’re referring to the more DDD definition of it, I think, is what we hear a lot of where they’re kind of just separating the controller from the interactions underneath it. But in the layer you and Josh were just discussing, we do see a lot in like service oriented architectures where we put that layer between the service and the main application that’s using it. MARTIN:  Right. And it’s often the case of where I don’t necessarily want to be talking directly to what I see as the domain object. What I’d rather be doing is thinking of it in terms of a more broader set of operations. And in that kind of situation, the service layer kind of provides those operations and then coordinates what’s going on underneath. But that is different to the kind of service object in the domain driven design sense where a service object is something that is kind of modeling a verb as it were within the domain model. JOSH:  The place I was trying to lead with this is that with the service level and you have a higher level of abstraction and semantics on your code, it seems like this is a good candidate for some higher level integration tests. And I’m curious, if you think about the service layer as something that’s distinct from the core domain model logic, does that influence where you put the tests for that? MARTIN:  Yeah, I think so. It’s interesting I mentioned this app I was looking at recently, one of our apps and one of a good way to understand what it did was it had a very clear service layer, partly because it’s a single page web app so it’s slinging JSON back and forth. And it has a very good set of tests, [inaudible] tests that just purely operates that service layer. It’s a classic way of constructing that. And it makes it very, very readable because you can very easily see, “Oh, here’s the various interactions and things that I’m expecting the server side component to do.” And it provides a very good layer for understanding the capabilities of the system as well as obviously a good test base or testing that the server side stuff is working properly. JOSH:  Now, if you’re doing TDD or BDD outside in design, do you start with your service layer API? MARTIN:  That’s certainly one way to do it. I tend to be, I’ve always tended to think very iteratively. And of course, the service layer should really be based upon the demands of your clients like any API. You have to really say, “What is it that people need from me?” And base it around that which is often people don’t put enough attention into thinking in that terms. One of the most important things about API design is realizing that the way the API is structured, it should be based upon the needs of the client and it can be completely independent from the underlying implementation. In fact, it’s that distance between implementation and API that really tells you whether that layer is working well. JOSH:  Do you think of a service layer as fully encapsulating the domain model or is it value added? MARTIN:   Again, it depends on the circumstances. In some situations, I think it can be very nice to completely encapsulate what’s going on underneath. It really depends on, am I going to gain benefit by trying to expose more of what the domain’s doing? Again, it’s going to depend on what people’s needs are. I tend to prefer more encapsulation rather than less in these situations because once you expose something, it’s very hard to take it back. And that’s the tragedy of the published interface essentially. Once you’ve published an interface, you’re kind of stuck with it. JAMES:  That’s a great point. MARTIN:  Yeah. And any sort of restful endpoint is a published interface. So, you always have to be aware of the fact, “Okay, now I’ve published this. I’ve got to be much more careful about changing it than I can, just interfaces of objects within my application itself.” JOSH:  Okay, cool. That definitely answers that. I have one more kind of high level question about, I guess kind of related to that. And that’s about, throughout the book you talk about rich clients a lot. And that was ten years ago. And rich web applications have come along way since then. We now have things like Backbone and Ember, and all sorts of other, MVC going on in the browser. It seems like that’s a whole new world of patterns where you have MVC on the server side and then MVC in the browser. Are there patterns within this book that are already applicable there? That makes some sense between what goes on in the browser and what goes on in the server? MARTIN:  That’s a good question. What have I got in this book now? JOSH:   [Laughs] MARTIN:   I actually see the rich web applications these days as really, they’re just the same as, in architectural terms, to the rich clients that we did with Swing or .NET in the past. I mean, we’re just doing them with JavaScript instead. And many of the same patterns still apply in particular, the patterns that I wrote on the website about presentation layer stuff is very relevant here, what do we really mean by model view controller and things of that kind. And I didn’t have that much of that in this book, if I remember, because I focused on web presentation patterns and there’s only a few of them. I’d have to think about answering that question. I mean, there’s still some of them you see because you still see people making templates and using template views. And there’s still that tension between, do I use the template approach or do I use a transformer approach when creating view constructs? That’s still very current, as well. JAMES:  You did have one section that was kind of an “Aha!” moment for me in the Remote Facade Pattern where you basically said, I guess in that time, everybody was starting to go crazy over web services and what they were going to do for applications. And you were like, “Yeah. Web services, we know that. That’s just a Remote Facade.” And that was kind of a neat “Aha!” moment for me. And I was like, “Oh yeah, everything you’re saying about Remote Facades and the coarse grained interface, all that, it just applies to web services,” which is kind of true. MARTIN:  Yeah. Any restful endpoint is effectively a Remote Façade and any JSON document you’re slinging around, you can think of as a data transfer object. So, those patterns are still very much in the forefront. AVDI:  You answered the one tiny question I was going to ask you which is that, in the age of JSON, whether it’s worthwhile to still have separate data transfer objects? MARTIN:  Now, that’s a bit more of an interesting question. And the reason I say it’s interesting is because if you are completely creating the structure of the JSON object within the server, then yes, having some kind of data transfer object can be a sensible way of doing that. Although your data transfer object may be a little more than a bunch of hash maps and arrays because that serializes really nicely and cleanly into JSON. The interesting thing then lies into what if you’ve got your backend in JSON as well? And you’re basically just taking a bunch of JSON out of a NoSQL style database, may be doing a little bit of manipulation with it and then sanely gets up to the server. And in that situation, effectively, what you want to avoid doing is lots and lots of copying around. I’m getting the sense that some people say, “Well, I’m pulling all of this data off and then I copy into a bunch of objects and then I re-serialize it again.” In those situations, you may want to say, “No, let’s just serialize it into my data transfer object.” Maybe wrap some object over the top of it if you need access into there and you don’t want to expose its guts to any clients within your server side application. But then, take that same JSON object and throw it out over the wire once you’ve gotten it out to the other end. You don’t want to be spending a lot of time writing code that’s just shuffling data from one field into another field without any value being added in the process. JAMES:  I think I see why you say that but don’t you have some concern that like, to me, it always seems like a bad thing when you just expose the underlying data structure to the outside world. Because like you said, the published interface then you’re kind of bound to that. Plus also, don’t you feel that -- well, we’ve talked about it. But the data should be formatted to the needs of the client not just how it’s stored on the server. Does that kind of make sense? MARTIN:  Yeah. But the key thing is, can I intervene and change the shape of the data without my clients realizing that I’ve done it? As long as I’ve got a place to go in and say, “Well, I used to have a good isomorphism between what was stored and what I was exposing. Now I’ve got to change it. I can go in and make that change. And I can do it in a way that my clients don’t even realize I’ve done it.” Then I'm okay. In many ways, it’s the simplest analogy I can think of in Ruby is like the attr_reader, attr_accessor things that you can put in your Ruby objects. If I’m just exposing a field as a reader, I’ll write attr_reader because I know that if I need to do something else, I can just define a method and none of the clients of that class will know what I’ve done. And that’s, of course, the essence of what this kind of encapsulation is about. Yes, I can expose the data directly. And if I want to do anything else, you don’t have to care that I’ve done something else. JAMES:  That’s a great example. JOSH:  That’s what you call eating your cake and having it to look at too. MARTIN:   Yeah. JAMES:   [Laughs] MARTIN:  And the tragedy of say, a language like Java was that it made it so hard to write those getters and setters that they became such a pain. And I really like the fact that Ruby allows me -- I mean, with Ruby, I know this destruct thing in Ruby but I’ve never felt the need to use it because I can just write class Foo attr_accessor, blah…blah…blah…blah…blah be done, and I’ve got a full blown class and it’s what, three lines of code? And then, if I want to do more stuff to that and I actually want to give it some real behavior, I do all of that and nothing else needs to know. And that’s the essence of it. How can I make changes without those changes impacting us widely outside my scope? JOSH:  Right. And I think the other side of that is a language like JavaScript where you don’t need getters. Anybody can just grope through your object and get to all of the properties of it. So, you can’t do the thing that you can do in Ruby where you have an attr_accessor that you can replace with your own method that has a bunch more stuff going on it. You can add semantics. You can't do that in JavaScript. MARTIN:  Oh, yeah. It’s an absolute freaking pain in JavaScript because I have to know the difference between whether I’m calling a function as a member of an object, or whether it’s a piece of data. JAMES:   Exactly. MARTIN:   If I change it, I’ve got to go around and put all those parentheses on everything. And what’s more, if I forget one, I won’t even know because function comes back. [Laughter] JOSH:  Yeah. So Yehuda Katz got me using the term Uniform Access for that property. Is that a standard term that you’re aware of? MARTIN:  Yes. I think I even wrote it up in my blog once. JOSH:   Okay, cool. I use that term in my Thinking in Objects talks that I do. MARTIN:  Uniform Access Principle, it’s a Bertrand Meyer originally coined the term. And I have it in my blog. So, I’ll put the link into our chat window. JOSH:   There we go! MARTIN:   And it is a very important part of the thing and it’s something that I think Ruby did a very nice job of maintaining that. JAMES:  Yeah. My favorite example of kind of the Uniform Access Principle in action is Avdi’s Ruby Tapas video on Barewords. He really hammers it home with like in Ruby, a local variable, a method. They have this Uniform Access to them and Ruby selects between them. And so, if you kind of purposely target that, then you can provide this Uniform Access. It’s really interesting. JOSH:  That’s one of my favorite Tapas episodes. But it’s really from sort of the internals of a class perspective. I think the exterior view of a class and just what Martin said about there’s this nice evolution from attr_accessor upward is one of the things that I like most about Ruby. AVDI:  Absolutely. MARTIN:  And you want to treat that as a fractal thing. So, you want that to be true at all layers going out. It’s all about -- the key to encapsulation is making secrets of things. How can I hide decisions or ways of doing things in one place from the rest of the world? That’s how Parnas originally described encapsulation and I think that’s always the thing to think about. And one in particularly important thing to hide is your data structures. If you’re passing JSON structures around, for instance, don’t copy all of the data into the field. Just stick the JSON object in as one field in your Ruby object and then provide a bunch of methods that look like simple field accesses but are actually digging around in the JSON structure. That’s perfectly good use of data encapsulation. JAMES:   Great point. JOSH:  Yeah. James, is it time for us to move to picks soon? JAMES:  Yeah. We’re way over on time. Does anybody else have any other questions? MARTIN:  I feel concerned that Katrina hasn’t spoken up much. KATRINA:  I’ve been sitting here thinking. One of the things that I really enjoyed about the book was that it’s so heavily, it hedges everything. Everything is a trade off and it really explores that in depth and I think that as -- I’m quite a beginner in programming. And as a beginner, often, things are very much a recipe. You do this, you do that. You really need to do it like this. And in many ways, I wish that I had read this book several years ago. And on the other hand, I wouldn’t have understood a word of it several years ago. So, I don’t know how we can help beginners sort of approach these difficult problems of trade-offs, these very real trade-offs in real world applications and real world problems earlier on. MARTIN:  Yeah. Well, it is all part of the whole learning cycle. I mean, things like the Dreyfus model that says, “As you begin to learn something, you really just want to know the answer.” And it’s really okay if it’s just an answer that’s not necessarily even the best one. You just want to get something done. And as you begin to learn more and more, you begin to appreciate more of the trade-offs. You can begin to see what’s going on there. It’s definitely -- I try to write for people who are more interested in trying to understand trade-offs because to me, I don’t want to make decisions for people but I want people to be able to make their decisions knowing what the consequences are going to be. And so, that they haven’t left something important out when they say, “Oh, I should have thought about this!” And that’s what I’m trying to capture. But again, it’s a demand for different learning at different points as you’re picking things up. JAMES:  When he was saying that, I thought of Sandi and her rules like how she kept going out and her clients kept asking her, “Give us some rules to follow.” And she didn’t want to do that because there’s no rule you can follow universally. And then finally, she just gave in and made up a bunch of rules, “Okay, no method that takes more than four arguments. No method over this length.” Just a bunch of rules and they were totally arbitrary and they didn’t even matter. It was that they had the rule that they could follow. And then when they began to feel the pain of that rule, then they would know why they wouldn’t follow it, right? MARTIN:  Right. And I guess I’d like to be at that point as where you’re beginning to question the rules and say, “Okay. Where are the real trade-offs lying?” And to me, that’s the most interesting thing. I’m most interested in patterns where you say, “Well, there’s three different ways of doing this.” When would you choose one or the other? And I’m particularly interested when I run into good developers that I know are good developers that would make different choices to me. The best example I have to that is stuff I’ve written about Mocks Aren’t Stubs article that talks about different styles of unit testing. Because I learned and did my unit testing with Kent Beck and we didn’t really use mocks very heavily. And then, there was a different group of people who use them all the time. And it’s easy to say, “Well, they’re idiots,” because I’m me and anybody who doesn’t agree with me must be an idiot. But an inconvenient problem with that point of view is I knew they were damn good developers. So in that situation, you start getting interested and say, “Okay, why are they choosing a different path? What are the different forces and trade-offs that are present that make me want to go one way or the other?” And then, maybe you get an understanding of realizing, “Well, there are certain things I value more and they just value things differently.” And therefore, we end up going down a different path. JAMES:  Any other questions or should we end it there? AVDI:  Real quick one, do you have a recommendation for another book to do for our Book Club? MARTIN:  Well yeah, Domain Driven Design, have you done that one yet? JAMES:  We haven’t actually read the book. We did do an episode on Domain Driven Design and we had someone come on and talk to us about it. MARTIN:  Right. You had David come on and do it. I would do it in -- I wouldn’t try to do the whole book though. I would perhaps do the first part of the book only. But definitely, at some point, do the second part of the book, the Strategic Design part because that is really, really good. But I think in order to do that, you really have to have got a good understanding of part of it. Sometimes, a whole book is too much. Otherwise, I’ll just tell you to do all my books. JAMES:  [Laughs] You know, one of the things I love about doing your books is I have both Refactoring and Patterns of Enterprise Architecture, are those really nice hardbacks with the bookmark built in and everything. Man, I love those books! MARTIN:  Yeah. The starter is the Carter Shanklin who put the ribbon in the Refactoring book and I’ve insisted on having one ever since. JOSH:  Those books with the red ribbon bookmarks always make me think that they’re like some religious book because it’s like, “Oh, this is a Bible.” [Laughter] JAMES:  Right. And Refactoring which was my first Martin Fowler book is kind of a religious book for me. So yeah, that works. MARTIN:  But it’s actually really practical having that ribbon in there, isn’t it? I find it really useful. AVDI: 'Design Patterns' has two ribbons. JAMES:   Whoa! JOSH:   Wow! [Laughter] JOSH:  So, just to let you know, my red ribbon is on the data mapper pattern. JAMES:  [Chuckles] Yeah, I do love the ribbon because I have a two year old. And she loves to run around the house and take my bookmarks out of books. So if it’s stuck in the book, she can’t do it. JOSH:  That’s great. JAMES:  Alright. We started on a quote, we got to end on a quote. This is page one, paragraph one, sentence one of ‘Patterns of Enterprise Application Architecture’, “In case you haven’t realized it, building computer systems is hard.” I think we should definitely end with that. [Laughter] JAMES:   So, let’s do some picks. Katrina, what do you got? KATRINA:  Today, I only have one pick. It’s a little micro controller, a wireless micro controller that you can basically give your real world objects a rest API. It’s really, really cool. It’s called Pinocchio. I’m waiting for my dev kit. I have the beta dev kit right now. They have a bunch of, they built a bunch of little demos. So, I think they hooked it up to like a sprinkler system. They’re working on hooking it up to e-Paper. They have a little bit of e-Paper that’s like about as big as a credit card and the micro controller is just a little bit smaller than that. It’s just a perfect size. It’s a ton of fun, definitely look into it. JAMES:  I already want one of those. Avdi? AVDI:  So, I am on the perpetual search for the perfect wireless headset and I haven’t found it yet. But I’ve been using one for a while, it’s the Corsair Vengeance 2000 which is a very threatening name but it’s because it’s a gaming headset. And it’s not bad at all. It’s reasonably comfortable although it’s a little too tight on my head. But I think it’s more comfortable than anything else I’ve tried. And it has good features like you can charge it while you’re using it and it gets a full day of use out of one charge. And the sound quality is pretty good. So, that’s been working out for me pretty well for a few months. Less technical pick, White Tea. I actually have been largely off of coffee and caffeine for quite a while now. I decided to just take a break and reset. And I kind of transitioned from the Black Tea to the Green Tea to the White Tea and I’ve been really, really enjoying starting my days with White Tea lately. So, good stuff. JAMES:  Josh? JOSH:  Okay. My first pick is -- so Katrina, you had a pick last week, I think it was your pick where you were talking about… KATRINA:  Electronic tattoos. JOSH:  Oh, no! This wasn’t that. It was something about. It was more sort of like meta-language where you were talking about… Was it the…? JAMES:  The 1000 easiest words? JOSH:  Yeah, yeah. It was Up-Goer Five. Right, yes. So, that got me thinking of this talk that I was lucky enough to get to see years ago and there’s a kind of poor quality video there on YouTube now which is ‘Growing a Language’ by Guy Steele which, in my opinion, is probably the best technical talk ever given. MARTIN:   Yes! JOSH:   So, this is my pick for this week. That talk was just -- the whole point of that talk was just to give you a sense, a visceral sense of what it’s like to start with a limited language and expand it to something that is fully featured and rich and can deal with all the concepts that you need. MARTIN:  Oh! That was such a magnificent talk. I was actually thinking of making that a pick myself. I remember sitting and watching that at OOPSLA. And at the beginning of the talk, you’re thinking, “This is very odd. This is not like a Guy Steele talk. There’s something very strange about what he’s doing.” I mean, gradually, when he explained what he was up to, you went, “Oh my, God! This is so awesome.” JOSH:  Yes! Don’t ruin the punch line for everyone. MARTIN:  No, I won’t. But it is the best technical talk I’ve ever seen and I’ve seen several very good ones. It’s an absolute cracker. JOSH:  Yeah. So, you were in the room there too? We were both in that room together. [Laughter] JOSH:  So, that’s my technical pick. And then my other pick is, I don’t have a specific technology or product to recommend here. But I’m just going to say my pick is, have back ups. A friend of mine just went through a very painful experience of losing his hard drive in finals week. And he’s going frantic trying to get his papers recovered and all the stuff. It’s just -- I think we’ve all been through data loss scenarios from time to time. But the catastrophic loss of your entire digital life is catastrophic. So, back up your stuff. I was kind of thinking that it would, like a fun web app to build would be an app where you can enter in the name and Email address of someone you care about and nag them every week to say, “Have you backed up your stuff yet? [Chuckles] JAMES:  That’s hilarious. JOSH:  And then like, you put your mom and your dad and your sisters and all your family members that you have to do tech support on. And just make sure they’re backed up. So, I guess my pick is like, choose someone who you care about and make sure and pester them until they back their stuff up. JAMES:  So, I have just one pick this time too and it’s not technical. It’s kind of an interesting thing that while I was reading the definitive book to ‘Enterprise Application Architecture’, I was also reading the definitive book about the decline of violence which is Steven Pinker's ‘The Better Angels of Our Nature’. And the book is just epic, is the only word I can think of to remotely describe it. It’s an 800-page tome. It’s a lot of work to get through but it’s intensely rewarding. It’s basically about how we are becoming a less violent society over time. And just in almost every aspect of everything we do to obvious things like murders down to how we handle financial default on loans, and I mean, so really comprehensive. He gives all the reasoning which is just tons and varied. And it’s really great. I found it very inspiring. I mean, it’s got ideas in it about why feminism is such a great thing for us and just all these things. Really, really great book. If you’re remotely interested about society on any level, morals, and stuff like that, it’s definitely got something for you. So, ‘The Better Angels of Our Nature’, that’s my pick. Martin, what have you got for us? MARTIN:  Yeah. All this time, I’ve been thinking about what I’m going to do for my picks. So, I’ve got three picks; one technical, one semi-technical, and one not technical at all. So, the technical pick is a tool I use on my Mac a lot called Source Tree which is a tool to help you manipulate and visualize your version control repositories. It works with Git, it also works with Mercurial, for the five people who are using Mercurial. But I find it really nice as a way of visualizing what’s going on. It doesn’t do all the operations. You need to do some stuff in the command line. But it’s still really good. And of course, distributed version control systems are an excellent source of back up. I’m going to throw in a proto-pick as well, meaning this is something I haven’t actually tried yet. But since I don’t know if I’m ever going to be invited back on the show, I’d better get it in there in case it’s useful to people. I just ran across it recently, it’s called JQ. It’s a library to basically allow you to do the kinds of things you do with textual pipeline manipulations in UNIX but do them to JSON data. And if it does what it says on the tin, it should be very, very useful. But I haven’t tried it out yet. So, I don’t know if it actually does what it says on the tin. JAMES:  That sounds amazing.  ** MARTIN:  It could be really handy. So, I thought I’d mention it since as I said, I don’t know if I’ll be coming back. JOSH:  Martin, just so it’s clear, you have a standing invitation, just let us know when you want to come back. MARTIN: You might regret that. [Laughter]JOSH:  I hope I do. JAMES: He is kind of a loud mouth. [Laughter]MARTIN:  So, my semi-technical pick is my favorite book I read last year. And it’s called ‘Thinking Fast and Slow’. It’s a book by a guy called Daniel Kahneman who has won a Nobel Prize, very much in the center of a lot of cognitive psychology and behavioral economics. Basically, what it’s about is how our minds get fooled particularly with things to do with statistics and numeracy. How we easily see patterns that don’t actually exist there and why that happens and how we can perhaps do something about it. It’s a great book of lots of things to say, “Oops! I’ve got to watch not to do this.” And I think it’s particularly important at the moment because of this interesting big data wherein using statistics for everything. People are bound to be over fitting and doing bad things left, right, and center. And I think it’s part of our responsibility as software developers to be aware of how these things can be misused so that we can at least begin to guide people away from it. So, it’s almost a case of if you are doing anything that even approaches big data risk stuff, as well as playing around with R and D3 and stuff like that, make sure you read this book at least once, preferably two or three times. And you get aware of the ways in which your mind can be fooled. And I just had a lovely time reading it. It was a really, really great book. And finally, my not at all technical at all pick, I gather from this podcast that one or two of you have the good taste to be Doctor Who fans. Is this true? JAMES:  It’s true.   **AVDI:  It is true. JOSH:  You’re not allowed on the show unless you have a favorite doctor. MARTIN:  My doctor, of course, is John Pertley. JAMES:   No, it’s…. [Crosstalk][laughter] MARTIN:   Everybody else is but a pale imitation. But that’s who I grew up with. So, it’s always your first doctor is the one that counts. But if you are a Doctor Who fan, then you will know that many of the recent episodes of Doctor Who were written by a writer called Steven Moffat; in fact, most of the best ones. Steven Moffat is also one of the writers behind Sherlock which I know has been a pick on here. JAMES:   He’s excellent. MARTIN:   Which is also excellent, and so therefore, I want to unreservedly recommend Jekyll which is pure Steven Moffat , six one-hour episodes with all of the wonderful Steven Moffat non-linear storytelling, brilliant dialogue, fantastically drawn characters, really magnificent six-hour show. And it’s also, by the way, why I pronounced the Jekyll as G-cull earlier on. Apparently, I learned from watching this show, that apparently when Robert Louis Stevenson wrote the book, he actually pronounced it G-cull and tried desperately to get everybody to pronounce it G-cull and, of course, completely failed. So as a result, if you really want to show yourself off, always pronounce it ‘G-cull’. JAMES:  That’s awesome.  ** JOSH:  Nice. I got to say that he wrote the Blink episode of Doctor Who which is one of the most freakishly frightening hours of TV I’ve watched. AVDI:   Yes. MARTIN:  Yeah. I mean, do you think that the Empty Child which was the standout of the first series was years ago? I really do feel he’s the best writer in TV and I say that as a Joss Whedon fan. Steven Moffat really is on a roll. And his latest, the Snowman Christmas episode was just, knocked me backwards time and time again. And Jekyll is that in full floor. You have six hours and each episodes tops and twists around and it’s magnificent. And of course, the lead actor plays the Jekyll and Hyde characters with no discernable change in make up. It’s just purely done through his acting and his body posture and it really is just a corker. I really do think if you like Steven Moffat, you will love Jekyll. And it’s on Netflix, so you’ve got no excuse. JAMES:  Awesome. I’m definitely watching that. Hey, a quick announcement. Our next Book Club Book has been chosen. We’re going to read ‘The Rails View’ by John Athayde, I think is his name, and Bruce Williams. It’s a great book, I’ve already read it. It’s a book all about the Rails view layer which is something we don’t often read about. Typically, it’s about the database layer or the interactions with the controller or things like that. But this book is all view. And it’s really good, it’s not too long. Both authors have agreed to come on the show and we will have them on May 1^st. So, you have until May 1^st to get that read. That’s our next book. And I think that’s everything that we need to say. As always, you can find us on iTunes, leave us a review. Thanks again to Martin for coming on the show. We absolutely loved having you. AVDI:   Thanks a lot. MARTIN:   Thank you for inviting me. I had a good time.   **JOSH:   Well, come back again soon. JAMES:  Yes, do come back. And with that, we will see you guys next week. JOSH:  Bye. KATRINA:  Bye-bye.  ** AVDI:  Bye. MARTIN: ** Bye-bye.