Transcript

XO Ruby San Diego 2025 - Architecture by Craig Buchek

From Confreaks · Episode page · Watch on YouTube

· 45 min · 7,083 words · 61 timestamped sections

This is the full, timestamped transcript of "XO Ruby San Diego 2025 - Architecture by Craig Buchek", an episode of Confreaks published January 10, 2026 (45 min, about 7,083 words). It mentions 12 people, works and ideas, including John Hanks Alexander, Pattern Language, Dr. Belinda Beck, Martin Fowler, The Timeless Way of Building.

What is discussed, and when

  1. – 5:00: Pattern Language, The Timeless Way of Building, Craig Buchek, John Hanks Alexander
  2. – 10:00: Pattern Language
  3. – 15:00: John Hanks Alexander, Ward Cunningham, C2 Wiki, Dr. Belinda Beck
  4. – 20:00: Dr. Belinda Beck
  5. – 25:00: John Hanks Alexander, Martin Fowler, Dr. Belinda Beck
  6. – 30:00: How Buildings Learn, John Hanks Alexander, Stuart Brand
  7. – 40:00: John Hanks Alexander, Martin Fowler

Notable quotes from "XO Ruby San Diego 2025 - Architecture by Craig Buchek"

  • Hi, I'm Craig Buchek. I have been using Ruby for nearly two decades now.
    about Craig Buchek · at
  • Faculty to help out figure out how we make our new campus. So they hired this man named Christopher Alexander. He was already an awardwinning architect. he was at UC Berkeley…
    about John Hanks Alexander · at
  • So this is the big one though. I pattern language volume two 1977.
    about Pattern Language · at
  • Actually two. I know someone that's been trained by Ward. who knows who this is. All right. Couple Kent Beck. he wrote the book on extreme programing. he wrote the book on…
    about Dr. Belinda Beck · at
  • Goat for that website and he called it a wiki, which is Hawaiian for quick. So, this is the C2 wiki. the C2 stands for Cunningham and Cunningham. I don't not sure if that's a…
    about C2 Wiki · at
  • All right. 1994 the book on software design patterns was published. it's called the gang of four book frequently because there's four main authors Eric Gamma, Richard Helm…
    about Gang of Four · at
  • Me what that is so patterns are continuing 2002 Martin Fowler has 42 patterns in patterns of enterprise application architecture this is targeted larger systems, enterprise applications, right? so.
    about Martin Fowler · at
  • Too much until I'm giving a talk on architecture. so this is this is a book written by Stuart Brand, 1994. how buildings learn, what happens after they're built. and this was actually inspired by Christopher Alexander's work. he actually.
    about Stuart Brand · at

Who and what is mentioned in this episode?

People

Books & papers

  • Pattern Language — Book · 5 mentions · first at
  • The Timeless Way of Building — Book · 2 mentions · first at
    All right. So the third book was the timeless way of building volume one 1979.
  • Notes on the Synthesis of Form — Book · 1 mention · first at
    Create its own space? so he was already prominent by the late 1960s. he had a paper called notes on the synthesis of form. he was into urban design, community design. We had…
  • Gang of Four — Book · 1 mention · first at
  • How Buildings Learn — Book · 1 mention · first at
    Architecture. so this is this is a book written by Stuart Brand, 1994. how buildings learn, what happens after they're built. and this was actually inspired by Christopher…

Companies & orgs

Full transcript with timestamps

Hi, I'm Craig Buchek. Um, I have been using Ruby for nearly two decades now. uh been in IT for another 10 years before that. Um today I'm going to talk about architecture, design and patterns. Um if you want to add me, just my name pretty much anywhere except for uh GitHub. Um but I don't check social media too often. Um and there's a short URL if you want to follow along um or link to some resources later. So, my Beth my my wife Beth has a degree in interior architecture. So, I find architecture pretty interesting and we have some things we can talk about about that.

Um, who's familiar with this book? Sign patterns. All right. About uh a little less than half. Uh does anyone know remember there was a companion CD you could buy? I I I found that in my bookshelf. Oops. Um, and who's familiar with the Ruby version? All right, actually a few more. Nice. Um, anyone familiar with this book? All right, this is this is where the story starts. Uh, at the University of Oregon in Eugene, Oregon in the early 1970s. So, the university needed some new buildings. Their existing buildings were mostly from the 50s and they were um plain concrete, brutalist. Um, and the students and faculty hated their buildings. Um, so the university administration asked the students and faculty to help out figure out how we make our new campus. So they hired this man named Christopher Alexander. He was already an awardwinning architect. Uh, he was at UC Berkeley at the time, I believe. Um, and he actually had to

design the process as well as the architecture. So how would the community create its own space? Um so he was already prominent by the late 1960s. Uh he had a paper called notes on the synthesis of form. Uh he was into urban design, community design. We had some novel ideas about uh architecture and design that they're more than just structures. They they should focus on the people that you're using them um and having the people even design their own spaces. Um so he had already kind of been this had been years in the making by the time he got involved in this um what he's was what he's planning to do there. Um so there's actually three books in this series. Um the first one published was volume three 1975. They were published in reverse order oddly. Um so this book actually reports um on the results of the experiment like letting the um community design their own space.

Um so it talks about you know what were the hypotheses were they confirmed or refuted and how did the design process work out. Um so it also talks about the implementation of the building the new buildings um and kind of built the core ideas of of the other two volumes. Uh so this is the big one though. Um I pattern language volume two 1977. This is the book that first used the term patterns in the way we recognize them in the software industry. Uh the book has 253 different patterns. Um and patterns is one of the main ideas on the talk. So we will talk about that a lot.

All right. So the third book was uh the timeless way of building volume one 1979. Uh it introduces a series and it's a companion to the other especially a pattern language. Um so if you're uh I I dove into a pattern language and also a timeless way of building to understand where this all came from. Um noted this it's the timeless way of building not a timeless way. Um so he has actually a lot of historical and uh cross-cultural examples. Uh and he was actually rejecting a lot of the modern modern architecture industry at this time.

So this kind of presents a new theory of architecture. Um he's taking these very old ideas. U but he's focusing on the human needs and desires not on the styles or the fashions. And you know architecture for hundreds of years has been about style and fashion, right? Um so um he wanted he focuses on how do people interact within a space and how people use that building. He talks about something he calls quality without a name and how we feel and interact with objects and spaces. It's like the life in the building or the soul of that place.

Um and we should seek that quality in our buildings. Uh he also believes that buildings should be designed by the people who use them. very not not very popular in the uh architectural field even today. Um so what is a pattern language? Uh Wikipedia actually has a good definition. It says a pattern language is an organized and coherent set of patterns that can be used in many ways within a specific field of expertise. I like to think of a pattern language is more like a vocabulary or a glossery for a specific field.

Um so every person in organization should have its own pattern language. Um they should mostly be consistent common patterns but everyone kind of has their own patterns that they see and they like to apply that other people may not. Um a pattern language is um in the structure of a network or mathematically a graph. So patterns reference each other uh creating a network of relationships amongst them. They can compose with other patterns and some patterns are built on top of other patterns. Um, pattern languages are alive. They're constantly evolving.

But what's a pattern? Um the book pattern language says each pattern describes a problem which occurs over and over again in our environment then describes the core of the solution to that problem in such a way you can use the solution a million times over without doing it exactly the same way. Um a so a pattern is about a common problem um and we consider these various forces like what's the context what are the constraints um and the solution needs to balance these forces right one of the definitions of engineering is actually balancing forces to come up with a solution so a pattern actually is very related to engineering um and the pattern also talks about the the invariance what's what's the essence of this solution um Like if we take all the good solutions for this kind of problem, what what's in common with all those all those solutions?

A pattern is a hypothesis actually. Um so we have varying amounts of evidence for each pattern. Um some might actually get proven wrong. Uh we might replace them with a better pattern. Um a pattern is about communicating. So a lot of times uh like a junior engineer will think oh I need to figure out which patterns I need to use to build this thing I'm building. But if you're more senior you more think of oh I do it this way and we call it that thing. So patterns are give us a way to communicate with each other. Well which way did we choose to to build this thing?

Uh so some examples of the book uh he actually talks a lot about how towns are laid out. Um he thinks that you should have agricultural valleys kind of leading out from from the town. Um the community of 7,000. He seems to think 7,000 is sort of the limit for a community. Uh I don't know where he came up with that one. Um ring roads. We're pretty familiar with ring roads. if you you know um large cities tend to have uh uh the interstates going going around as well as through um 9% parking. Don't fill up your city with parking lots.

Let's keep it at 9%. Um people love water. It turns out people love shopping. Like let's put all the shopping places near each other. Um if you want to be bike friendly, you're going to need some bike paths. Um, public squares, public places are very important. Um, he talks even about a house for one person and I think he's got one for uh an old age cottage 155. I like that one's pretty weird. Um, that one has not caught on. Um, flow. So, flow through rooms. Um, a private terrace on the street. Uh, I actually had a home that had a great that did a great job of that. Um, so it was interesting to see. Oh, I kind of knew that this was kind of a nice terrace that I can kind of see people. They can't see me very well. And then I come across this pattern. I'm like, "Oh, okay. That's interesting. They did did a good job on that pattern without even knowing it was a pattern or or it had a name." Um,

child caves. So, child caves was a So, as part of this talk, I read most of this book. Uh, child caves are basically like, hey, if you got some stairs, you know, underneath the stairs, give the kid a little play area. Um, so one of my favorite examples is he calls it the fourstory limit. Um, and he says there's abundant evidence to show that high buildings make people crazy. He actually said that I don't know about crazy, but um, so therefore, in any urban area, no matter how dense, keep the majority of the buildings four stories high or less. It's possible certain buildings could exceed this, but they should probably not be places you live. So probably, you know, maybe your office could be on a higher floor, but uh you shouldn't really live on higher floors. So he actually cites multiple studies on the effects of high-rise buildings. Um so he found that kids on high floors get outside less and

compared to kids on lower floors and so they get less social interaction and people on higher floors are also less likely to know their neighbors. So he actually has a lot of good reasoning to back in evidence to back up his patterns in in most cases. Uh who knows this who this is? Nobody. Okay. Uh Ward Cunningham. Um so Ward Cunningham uh he coined the term technical debt in 1992. He invented the wiki in 1995. Um he was part of the agile manifesto in 2001. Um there's something called a a ward number. Like how far are you in the agile community? How far away are you from actually being trained by Ward Ward Cunningham? Um so my my number is actually two. I know someone that's been trained by Ward. Um who knows who this is. All right. Couple Kent Beck. Uh he wrote the book on extreme programing. Uh he wrote the book on test-driven development. He was there also there for the agile manifesto. and I learned he

co-wrote JUnit. Um he writes a lot about um stream programming. He's got he's got a book called um what's the what's the one I just got? Um Pidy first. Um so it's a it's a short little book and he he talks about sort of prefactoring. I've seen there's an old book called prefactoring. So it's sort of like hey this is already a mess. Should I clean it up before or after I start working with it? um he has this thing called TCR test and commit or revert. So basically you make a change and if it doesn't pass you revert it immediately and start over. I'm like that's that's crazy. That's amazing. Um but it also means you only have one change in each commit. Um which is nice.

Small commits are actually really good. Um let's see. There there's a lot I could probably talk about Kent Peek the whole talk. Um so Ward and Kin work together. Um they started working on small talk together and in 1987 they published a paper called graphical user interfaces and small talk and this was the first known publication of software patents.

So later that year uh at a conference they gave a workshop um and presented another paper using pattern languages for object-oriented programs. They were actually strongly influenced by Alexander's patterns. Um so how did they find that book? Right. Well turned out Kentbeck was at University of Oregon from 1979 to 87. Um and I believe Ward uh lives in Portland. Um so Oregon as well. Uh, so I know someone that knows Kent fairly well and I ask, "Hey, is there a better picture of you two together?" Nope, that's the only one he knows of.

Um, so over the next few years, more people got involved, especially from the small talk community and the object-oriented community, uh, object-oriented design, analysis, and proarine were kind of just coming up at the time. Um, and in 1995, Ward built a website to collaborate and he wrote the goat for that website and he called it a wiki, which is Hawaiian for quick. So, this is the C2 wiki. Uh, the C2 stands for Cunningham and Cunningham. I don't not sure if that's a a spouse or a sibling. I think it's a spouse. Um, and this is pretty much the design patterns kind of where the uh design patterns community worked on these. This site is still live, but I don't think you can uh add or edit anything anymore.

Uh it still has actually good stuff on on patterns and um extreme programming. Um let's see. Uh Ward says this wiki was a direct consequence of Christopher Alexander's work and agile extreme programming is too. All right. 1994 the book on software design patterns was published. Uh it's called the gang of four book frequently uh because there's four main authors uh Eric Gamma, Richard Helm, Ralph Johnson and John Besides. It covers 23 patterns mostly in Java and C++. So some of these patterns apply to Ruby and some don't which is interesting when you think about well why does a pattern apply to some languages and and other languages it doesn't. Um that's a fairly deep topic as well but different language has diff have different constructs and sometimes those constructs will replace the need for a pattern completely. Um it turns out in um like back in the assembly days or machine code when people were hand

coding machine code a subruine was a pattern and today we're like that's that's not a pattern that's just part of the language. So patterns can kind of grow from hey this is something we do frequently to well this is just how it works. Um, so Eric Gamma started his PhD in 1988 applying the general idea of design patterns in software engineering and he also co-authored JUnit with Kent Peek. Something I learned um I think he's involved also in VS Code uh tip, right? Uh okay. So uh these are some oop patterns that come from the book. They all involve classes and objects. So probably not going to apply to functional programming or procedural or logic programming. They generally have their own patterns. So that's sort of the the paradigm you're working with is going to have a different set of patterns from a different paradigm.

Um let's see. Um yeah, so you're probably familiar or have at least heard these terms. Uh singleton, there's just one of them. Factory is something that builds other objects. uh strategy is to sort of uh plug in an algorithm. Uh a template method is uh oh I don't remember what that one is. Uh the visitor is to take a like a tree or uh an array and visit each element in it. So 1996 Kent Beck wrote small talk best practice patterns and it's got 50 patterns. Um, and these cover a lot of smaller patterns. And in my opinion, this is maybe the best book on Ruby, even though it isn't about Ruby and was published almost before Ruby was released. Um, but um I I got to see uh Avi Bryant talk at RailsCon 2007 and he made a great case that Ruby is is pretty much just a dialect of small talk. Um, so most of these apply really well to Ruby and in fact there have been several efforts to produce a Ruby version of

this book. Uh, none have worked out. Uh, I've considered it myself, but uh, apparently there's a few too many uh, legal roadblocks. Um, so here's some of the ones he talks about. Um, compose method is basically a method that you kind of split out into multiple methods. uh query method we'll talk about on the next slide. Um decomposing message um basically it's when you have one method and you break it down into you decompose it into separate parts temporary variable that seems very very low level right um simple superclass name um Chantel talked about who's good at naming uh turns out he's got things on how to name things in here um and also I bought a book that's called naming things there is a small like 90 page book called naming things that actually tells you okay we we kind of think we know how to name things but like what are the priorities like like how do we name nouns how do we name

methods how do we name objects um a good book there actually um a guard clause who knows what a guard who doesn't know what a guard clause is anyone not know what a guard clause is okay um yeah it's it's uh it lays out how to use that well an intention revealing method. Um, intention revealing is basically picking a name that kind of says what it does. So, um, one example is query methods. So, how do you resump uh represent testing a property of an object? And this is where we come up with the is or will or has um methods that return booleans. And in Ruby we use the question mark which is nice. Um so a query method. We call them predicate methods at this point. Um but she at that point was calling it a query method.

Um so this is probably my f favorite pattern of all. It is the intention revealing selector. Um and selector is a word for in small talk for method name. So it's basically how do we reveal intention with our method names. Um, hang on a sec. I kind of missed the line right at the top. Um, so name methods for what they accomplish. Um, so don't name them how they work. Um, name them for what they do or even better like what they give you back. Um, one of the one of my pet peeves is um like get XYZ. Like well I just want XYZ. I don't it's it's not a it's not a verb it's a noun or an adjective like I want that property of that object and I don't want to think about how am I how I'm getting it I'm not I'm not processing I'm not getting I'm just I just want that tell me what that is so patterns are continuing 2002 Martin Fowler uh has 42 patterns in patterns of enterprise application architecture

um this is targeted larger systems, enterprise applications, right? Um, so DHH actually learned patterns that he applied to Ruby on Rails here. Active record comes from this book. Um, and we are still living with active record. Model view controller is in here. Um, so Martin Fowler also wrote the the book on refactoring with Kent Beck and was also there for the agile manifesto.

So, how are software design patterns different from architectural patterns? And turns out there's not that much difference. They're all about common problems and context and solutions. So, software designs are not design patterns are not code. You can't just copy and paste them. They're not as specific as an algorithm. Um they could be at any level of abstraction. I talked about the enterprise architecture patterns and then the the Kent Bachi kind of patterns in the small um patterns are often a a best practice sort of blueprint of the outline of a solution.

Um so the software design patterns uh use roughly the same format as Christopher Alexander used. Um so we give the pattern a name so we have a common language to talk about it. uh the intent like what are we trying to accomplish the context is well what situations does this apply and what situations does it not apply then you've got the problem and solution and then cross references because like I said uh a design pattern may depend on other design patterns or you know might have a back reference um so or things that are similar or things that have um a different context but sort of the same problem those will be very related to each Um so going to get into architecture now. Um so the dictionary definition of architecture is the complex or carefully designed structure of something. In many fields this kind of means the unchanging deep structure of of whatever you're building. Um so we think of architecture

as big buildings. That's that's something you you say the word architecture. You see that building you're like that's architecture. um cities, cities like we architect cities. Um Christopher Alexander talked a lot about communities and cities um and large software systems, right? The architecture of your large software systems. Um but structure is fractal fractal. Uh we can zoom in and we can say see patterns at all the different levels. Um we can also think of small architecture rooms, aloves, software components.

For example, doorork knobs are an architectural element. So um while I was doing research, I found famous architects that have designed doorork knobs. Gaudy Emmes, Franklidd Wright. Um and I found uh a couple different web pages that tell you how to pick between these two different kinds of of doorork knobs. So the levers are easier to use. They can be used when your hands are full, easier for young people, old people, disabled people. They can snag on clothing when you're walking by. Uh knobs have more styles and knobs can turn either way.

And if you do uh download the presentation, I do have show uh some presenter notes that will uh get you to those pages that tell you how to how to subside. Um so we rarely think of a button as an architectural element, right? Um but it's part of the structure of an application and it has the same kind of constraints as any other architectural feature. Uh you've got context. Okay. Well, where am I using this button? Which button I choose is going to depend on that, right? Um and we we we make decisions based on how the users are interacting with them. We want we want consistency when the context are similar.

So, uh, I I first gave this talk last year, um, and later in my research, I found this book and, um, I might even go as far as saying it was it was life-changing. Uh, I'd seen the book before, um, didn't think about too much until I'm giving a talk on architecture. Um, so this is this this is a book written by Stuart Brand, uh, 1994. how buildings learn, what happens after they're built. Uh, and this was actually inspired by Christopher Alexander's work. Um, he actually collaborated with Alexander and mentions Chris Alexander about every other page.

Um, there's also I found on YouTube there is a six-part TV series from the BBC that came out in 1997. Um, I just mentioned the the the cover of this. So two buildings on the left um are from 18 late 18 mid 1800s and then on the right is 1993. Those are the same two buildings and they diverge quite a bit um a lot and they diverged in different ways too. So that's that's very interesting and and it kind of goes to the heart of what book is. Um so this is Stuart Bran. Uh he was at Stanford. He also worked at MIT Media Lab. He possibly is the one that coined the term personal computer in 1974 way before the IBM PC. Um he also has a phrase the information wants to be free. Um he was a director of the electronic frontier foundation uh which is about digital rights and freedom. Uh now he works with something called the LA long now foundation. So, they have a 10,000-year clock that they're working on, a

10,000-year library, and something they call long bets, where you see these people that have betted on things that, you know, decades from now, like, hey, what's what's going to be the answer? Um, he was involved in LSD studies in the early 60s. Um, he helped design and participate in the mother of all demos. Has anyone seen the mother of all demos? All right, I encourage you all to see the mother of all demos. It is an amazing thing from um 1968 and it introduces all these things that were not in computing yet. The mouse, the pointer, uh network collaboration like they didn't even have networking really on computers then and these people were collaborating from like a 100 miles away. Um this guy is very interesting. um in the I think it was 1966 he's like why do we not have a good picture of the earth from space we had satellites by then and we were headed towards the moon um and supposedly he

this inspired oops trying to scroll the wrong thing uh uh the rumor has that this inspired NASA to actually get that picture um and so that the picture especially the one when we landed on the moon the earth rise picture is just amazing right Um but we had a some good pictures uh slightly before then. Um there's a lot to cover. In my opinion, this is the best book on software engineering that's not about software engineering. Um so um here's some things that he covers, things that he says. Um and and how familiar are these to software, right? Nearly all these lessons apply to software as well.

Um, and in fact, it even this sounds a lot like agile to me. Um, not like the watered down stuff like I usually end up with pretty watered down scrum. Um, but like the the real like the the agile manifesto agile like how it was meant to be. Um so I mean they're all about agile is all about incremental change adapting and focusing on users and that's exactly what he is uh talking about buildings. Um he says buildings are predictions but all predictions are wrong so we should design so that it doesn't matter when we're wrong.

And this is something I've kind of learned. I think um Dave Thomas has started talking about this a lot lately. Um, and it's kind of how I see what is what is good software. Good software is because we know we're going to be wrong. Good software is something we can change. Um, so the ability to change is actually one of the highest indicators of internal code quality. Um, we shape our buildings and our buildings shape us. So adaptation between buildings and users is a slow and continuous process. Um he says over 50 years the changes within a building will cost more than the original building. Um three times for commercial buildings and six times for a residential building. That seems a little large for me, but uh I haven't owned a house for all that long, so I'm not sure on that one. Um so if you hire good builders, uh you could actually save money in the long run by not having to spend as much on maintenance. Um

temporary is permanent most of the time he's found. Um and he says fail small early and often and you will succeed in the long run. Um one of the most interesting uh buildings he talks about is building 50 in the in MIT. Um and this was built uh I think the late 40s may maybe early 50s and it was meant to last like 10 years and because it was temporary people that are doing experiments they'll just drill into the wall or dig up the floor and connect two different offices. So it's so adaptable because it's temporary, but turned out it wasn't temporary. It's been there as long as, you know, let's see. So it's uh 70 years now, I think.

Um so some some conclusions that we could draw from looking at these these patterns and and architecture. Um pattern languages help us communicate. Um and they have solutions to common problems, but they're common solutions that a lot of us would have figured out on our own. um and and have um but once you figure out oh we call that that thing now I can communicate it to other people easily. Um so in many fields architecture means unchanging deep structure but architecture does change. Um architecture is really about people how they interact with their environment. Uh that could be in time and space um and with other people and with with objects.

Um, we can't predict what our future needs will be. So, we should design for change, evolution, and adaptation. And because we can't predict, we're have to learn as we go. Um, when I look at AI, I think, well, okay, but when we're building things, we're learning about what we're building. I don't know. AI doesn't seem to be capable of that yet. So, uh, we at least have that going for us for now. Um, small talk, small talk's legacy is huge. Um, object-oriented programming pretty much came from small talk. Uh, there were a few languages before that.

Um, but the designer of the language also is the one that came up with the term object-oriented. uh agile the same people involved in in uh small talk a lot of them were involved in agile and a lot of the same people were uh uh involved in design patterns uh for software and got that from the architecture side. Um so this was a small group of people involved in all these things. Uh they probably were there at the beginning of open source as well. Um if we think about Dave Thomas who brought us the first Ruby book in English, he was also at the the uh the agile uh manifesto conference in 2001.

Um and Ruby is very much like small talk. Many of the same people are now using Ruby. Um and and this is why agile is actually so common in in Ruby. Um if you go to other programming language communities, they probably aren't quite as as um forward on on the agile techniques. Um let's see. Um and we can learn from other fields like so this is definitely a case of someone knowing something about a field outside of software seeing the ideas and and understand that hey maybe we can learn some things from those people and apply them and and find something useful.

So um the night before I gave this talk for the first time this picture was blowing up on Facebook with a caption that said overwhelmed. Um the house on my left is the house the house on the left is the one I was uh living in at the time. Um it's a two-story Victorian. Um and on the right is a 16tory highrise. Um so apparently the story was they wanted to build this high-rise and this owner didn't didn't want to sell out so they just built around them. Um so there are several patterns being broken here, right? Um, one is that four-story limit I talked about. 16 stories is much higher than four stories. Um, but it is it does have an ocean view. So things tend to be a little more lenient there because you more more people want to be there. Um, but there's another pattern called number of stories that says do not let the height of your building vary too much from the predominant height of surrounding buildings. So uh, yeah, it

really failed on that part. Um, but actually down at the bottom there's some hedges. This one really named nails pattern 140 a private terrace. So I could sit on that front terrace behind the shrubs and I could see out but they couldn't see in. Um, so it's actually a good example as well as some some bad examples. Um, so a lot of resources you can find. There's actually patternlanguage.com um where I grab some of this info. Uh it does cost $5 a month oddly. Um that that BBC TV documentary I talked about. Um good things on patterns.

Um Dougley has a paper on object-oriented designers and Christopher Lee Christopher Alexander. So, uh, it it was several people that have noticed the pattern between software and architectural patterns. Um, let's see. Uh, there a couple really good sites on design patterns. Um, Sourcem is probably the best one I found. It's also great for, um, info on refactorings and antiatterns. Um, there's a site called Refactoring Guru that seems to be kind of the same site but kind of different. Um, Martin Fowler's got a software architecture guide uh worth looking at. Um, I believe he also has a pattern guide and um, uh, refactorings guide. So, uh, he's got quite a few things on his wiki um, and a couple other resources there. Um, so I actually found a few patterns independently and documented them on on a blog entry. Um, so readable shell scripts, people tend to write shell scripts, they just blah blah, you get to

the end and it like does the main thing. I'm like, maybe we should put that at the top and not bury the lead. Um, so little pattern I found independently that uh I don't see many people using. Uh, I talked about the parameterized module inclusion um in a talk at uh, Ruby Comp, I think 2014 or so. Um, and debugging pattern. Uh, this one's sold. I don't remember the details of it. Um, basically when you are having trouble with an object and you're not figuring out where it's failing like have it just explode like when anything's called on it just explode and like give a back trace. So like oh so I need to back trace over there and my object comes from here and I don't know where it happened. Well, let's just have it explode when anything is used to that object.

Um, so one reason I give talks at conferences is to start conversations. So come talk to me, send me a message, send me a job offer, uh, contract that is ending, uh, probably January or February. Uh, thanks to Jim for putting on all these, uh, conferences and thanks for you for coming. Thanks, Any questions? Yep. One sec. So, I have two questions. One for Jim and one for you. Uh, Craig. Jim. Uh, are we going to be able to put our slides anywhere for people to access later? The answer is yes. I don't know where, but we'll we'll find out. I'll figure it out.

Well, mine are easy to find. Just spell my name right, you can find me. Um, no, the reason I'd asked because the your presentation was very helpful and I definitely want to go back and look at the different things that you had here. Um, I was put on a on the spot earlier and so if this question is not uh easy for you to answer immediately, I'd love to start a conversation offline. Um, but I'm curious because you you talked about uh naming things and I'm curious if you can give some examples of like what's maybe not the best name for something versus a a good name for something in your opinion?

I spend a lot of time thinking of names sometimes and if I can't think of a good name, I start off with like blob. Um, which forces me because I'm not going to commit blah in my repository. I'm not gonna have a pull request with BL in it. Um, so that's sort of a forcing function that I use as a trick sometimes. Um, like I said, the getters that have get in them are just drive me nuts because I'm like, we have a convention for that. We don't use get in Ruby especially. Um, he had an example that was um, let me see if I can pull that up real quick.

his example. Let me zoom in. Can't zoom in. It's only on my laptop. Um, so what does it say? Um, array uh linear search for. So he's like, okay, I've got this method called linear search for. And he's like, does linear really matter to me? Let's let's get rid of linear. like we're just searching for something. But like I said, searching for is is a verb and we kind of want to have more of an adjective or a noun. And the first thing he comes up with is um just search for. But then things he says, well, what if we just made it include? So, uh this is Ruby includes, right? You don't say search for this object in this collection. You just say collection does it include. Um, so it it takes a lot of time. Um, you also want to make sure you're using words that your customers are using. Um, otherwise you have an impedance mismatch with what they're talking about and what you're trying to build. And that

miscommunication can will will cause bugs and just frequently cause them you not even to build the right thing. Um, let's see. I do highly recommend that book I talked about. Um, let's see if I can find it.

I think it'll Yeah, it's it it's it's a little yellow book. Maybe they'll come up. Oh, I got to There we go. Would recommend quick read. Probably pretty cheap. Does that answer your question?

I think I think it does. My uh I I did have specifically I was wondering when you said the naming convention of using verbs versus using an adjective. I was really curious about that because I find myself using verbs.

Yeah. Uh intentionally so, but this is this is helpful to to see a different perspective.

Yeah. And I I keep evolving on that verb thing too. um like we're definitely doing stuff. Are we have methods to do things like do is a verb. So there's there's places where it makes sense. I think process might be if you're processing things, process might be a good name. Um but usually I try to give names the results of what I'm getting back, not how it did or or even what it did. Question. I can repeat it. Uh I don't get this kind of a no too long to repeat both uh on naming again. Someone gave me the advice. Uh I'm curious where you stand.

If you see the method every minute, name it X and use it a thousand times because everybody's going to gain the context. They're all going to know what X is. If you if it's if you're only gonna encounter it once over the next six months,

make it make it 15 characters long and descriptive. Ah, and yes. And and then if if you never want someone to use your method,

obviously make it as long as possible and autocomplete takes that away, but make it as long as possible. Like is that is that something you think about when naming as well is like who's going to use this, how often, and

Yeah. Yeah. Um and uh that the last example where you give a really long name, I consider that synactic vinegar. So the the opposite of syntactic sugar. Um and I have used that occasionally a couple times. Um so what was the first part of the question? um super short cuz people are getting annoyed.

Yeah, like it's like I don't recommend just single letters unless maybe you're just indexing through a variable, but um we don't even do that in in Ruby very often. Um so let's say transactive and we say TRX. Yeah, I'd still depending on what the um domain is. Like if the domain experts would call it TXN in that case, then then call it TXN. But I am a fan of spelling things out in almost every case um because it it just leads to less confusion. But TXN is not going to lead to confusion either. Your confusion there is going to be like, okay, when did am I supposed to use transaction and when am I supposed to use TXN? Um, so consistency is is so this book actually talks about, okay, we need to be intention revealing, we need to be consistent. Um, and it actually figures out which order to do those things in.

And while a lot of us probably had some of that in our head, we never really saw it put down on paper and and explained, oh, okay, so actually do have rules. It's one of those um things you know that you don't know. Like we have rules for naming things. We don't know what they are. And this book kind of fills in the gaps and and tells us what they are.

How about a big hand for Craig?

Questions about this episode

What is discussed in "XO Ruby San Diego 2025 - Architecture by Craig Buchek"?

In order: 0:00 Pattern Language, The Timeless Way of Building, Craig Buchek, John Hanks Alexander; 5:00 Pattern Language; 10:00 John Hanks Alexander, Ward Cunningham, C2 Wiki, Dr. Belinda Beck; 15:00 Dr. Belinda Beck; 20:00 John Hanks Alexander, Martin Fowler, Dr. Belinda Beck; 25:00 How Buildings Learn, John Hanks Alexander, Stuart Brand; 35:00 John Hanks Alexander, Martin Fowler.

What is mentioned in this Confreaks episode?

12 people, works and ideas are mentioned, including John Hanks Alexander, Pattern Language, Dr. Belinda Beck, Martin Fowler, The Timeless Way of Building, Ward Cunningham. Each one on this page links to its own page with every episode that mentions it.

How long is "XO Ruby San Diego 2025 - Architecture by Craig Buchek"?

The episode runs 45 min; the transcript is about 7,083 words in 61 timestamped sections.

More from Confreaks

About this transcript: the episode's spoken words as captioned on YouTube, split into timestamped sections. Reclip.Me locates every person, work and idea in the text, keeps the time it is first named, and quotes the words around it verbatim. Last updated January 24, 2026.