Welcome folks. This is the St. Louis Linux users group meeting.
Thursday, July 18, th 2024.
The speaker tonight will be Craig Buch. Talking about software architecture, big and small.
Up front, though. We have some discussion gonna.
Choice in your website. But before we do that, Stan.
Why don't you run through our introductory segment.
Hey! There!
This is special interest group of that's.
Affiliated with the St. Louis Unix users group. They support us with.
All kinds of stuff, that.
The agenda is gonna be central standard time. 6 o'clock on till 6 30. Arrival. You can test chat.
And microphones, your sound and screen sharing things like that.
And at 6 30 we start our introductions. Announcement meeting archives, calendar mailing this, and then we go to call to help.
I'm the.
Stan Reichart. I I do production here. James Conroy is our chairman.
Gary Myer normal and see may or may not be here later.
Lee Lambert of On the Tech, is our host.
Would appreciate it if somebody.
Monitors, the chats as we go along.
5 days from now. 4th Tuesday is the new Linux.
Meeting next slack meeting is usually on the 1st Thursday.
To the General meeting is on the second Wednesday of each month, and some.
Talk about the alternate Slugan.
St. Louis web pages. He's been doing.
We have other sponsored meetings.
The new Linux Users group and the slack meeting group.
They. They deal with beginner, workshop and configuration workshop for most part.
We also have our archives. We record these meetings, and a St. Louis Linux uses group meetings, and they are recorded.
And
They they are on our.
On each of our web pages we have links to the presentation archives, listings.
We have a calendar system.
That, and I'll on the calendar. Our sponsored events are highlighted in red.
And.
You can.
And we also have mailing lists. Unlimited announcement lists.
Usually just. The instructions for the meetings are sent there.
General discussion can be done on our discuss. We have a steering committee list.
And we also have assist Admin list. But it's only for volunteers that actually do any work for for our staff.
Staffing, our meeting.
And we can go into our call for help meeting.
Portion.
I think at at this point we should go right back into the.
Announcement section and Sean, you wanna talk about the.
Your thing.
Yeah, sure, thanks. Let me share my screen here. Appreciate it.
So I've been working on a new.
Website, for slug.
And I've been talking about a lot I. And today I just want to do a quick little update on what has changed since.
Last meeting, so like 8 days ago.
Hold your questions to the end. So I'm gonna try to get through this really fast. So.
The 1st thing that I added was the calendar on the homepage.
So down here, it's the exact same calendar. I literally copy and pasted it off of the existing org website.
If you click this little open and new icon right here.
It will take you to the full page.
Calendar on Google.
So that's that. The other thing is, I added, some new color. So if you saw it last week it was very gray.
And I wasn't too happy. With that I've changed it to a lot more bluish.
And to me it looks a lot better.
In addition to that, I have came up with this.
I think pretty slick mode. So now, if you're one of these dark mode people, you can
View the site in dark mode, and it automatically switches based on your system.
At least you know.
Hopefully that works, and we'll see.
Well, yeah, should automatically switch based on your system.
So like, I just changed my system to dark mode. And the website automatically.
Responded to that.
And you know I'm not good at picking colors or anything like I don't know anything about that. So all I did was.
I pulled up the default dark and light themes from Vs code.
And I picked a few of the colors they use and just put them on the website.
Very easy to change this, or whatever.
Oh! And then the other thing is across the top of the nav bar. Here there used to be a link for Stlen.
Where you could see those individual meetings.
But I didn't think those were too useful, so I took them off the nav bar. You can still get to them from the about page.
But I took those off in favor of this new resources link here.
And on this resources link, I basically linked to all of this a lot of the stuff from
The old site.
So like the attendance is posted on the old site.
The handouts, the Newsletter, the Mailing list, the Presentation Archive.
All this stuff is linking, just linking back to the old site. But I wanted the new site to be, you know, somewhat, you know feature parity with the old one, so I put some links here.
Including the wiki and stuff.
If there's something on the old site that you use.
On the existing site that you use. It's not here.
Let me know, and I'll copy a link over to it.
Or some of the stuff is so out of date, we don't want it on the website anymore. Like the handout of the newsletter, we can remove that, too. It's it's.
You know, all this stuff is very easy to change.
I also added some stuff to the about page. So I added, the Socials section here, where I put all of our.
All the groups. Social media stuff.
You might notice that
This is new from last.
Week, but.
We now have a mastodon account.
As well as a twitter, and I'm crossing our meetings to both of these.
And when I upload like the Youtube videos or the recordings to Youtube, I'm posting.
About that as well.
So if you're on Twitter, please follow absolute, or if you're on mastodon at Sluke, underscore org at Mastodon, social.
Please follow us, please. Subscribe to the Youtube that helps us with the.
Algorithm alright. And then I also added, this contacts.
Departments and mailing address. I don't know if this Po box is still a thing, but it was on the old website. So I kind of.
Ported it over.
I also did some work, so that our links show up all pretty like this.
So this is where I posted that I was excited for the presentation, and I included a link.
To the site.
And, as you can see, it has, like the title, The presenter, and then our our image.
All pretty in the preview. But here, if you look at like Meetup, for example.
Meetup doesn't do it as well, like, yeah, it has the title and the whatever, but it doesn't have the image.
So we got a leg up on Meetup that way.
And these previews, should, you know, should.
Work on like a Linkedin Facebook.
Twitter masted on whatever.
A lot of these social sites kind of all use. This thing called open graph.
And so, theoretically, if you post a link to the new site on any of those it should show up in this pretty preview.
And I think that's it. I think that's everything I've done since last week on the site.
I think it's pretty good now. I think it's pretty feature complete now.
At this point.
I am. I think it's ready to become the main site that people see when they go to Slug Org or Stlennx org.
So I'd like to discuss that at the next meeting.
So if you don't want that to happen, let's have that discussion either on the steer mailing list or.
The Steercom Meeting.
Early next month.
But I'm good, definitely gonna bring it. Be bringing this up that we should make this our main site.
You know, at that meeting.
And also, if you know any other lug organizers that want this.
A website like this.
Have them go ahead and reach out to me, or reach out to steer.org.
And
I can help them.
Cause. You know this is all open source, so they can fork the repo, and I could help them get up and running with having their own site like this. I think it'd be very easy.
To port this over to any other type of.
User group or anything like that.
And that's it. Hopefully, it wasn't too much more than.
Looks looks great. Sean.
Then 5 min. But that's that's what I got since last time. So, thanks for your time and attention. Appreciate it.
Are there any other announcements?
From anybody.
A.
Oh! Guess not!
I see Craig has joined us.
Are you ready.
Are we doing a call for help? Anybody have a problem that we can solve.
Hopefully, something related to computers.
I'm watching the chat, and I don't see anything there, if that's what you're looking for, Stan.
Yeah.
This.
Okay. I I guess at this point we should go into.
There he is!
Craigs.
Yeah.
Well for anybody. It's been.
Hello!
Been here for a while, Craig.
Old member of the group been around for years and years and years.
He actually got me starred in ruby about.
But 1520 years ago, Greg.
And the.
Fit, the.
He jumped ship.
Went.
San Francisco, and he's been doing this thing out there for what.
6 or 7 years.
Reached her 40 years.
4 years. Okay?
Yep.
Well, anyway!
Craig, I will turn the floor over to you, so you can tell us about your presentation.
Alright Hi! I'm Craig. I'm gonna talk about architecture, design, and patterns.
Welcome to my coworker, Mikael, not from St. Louis.
He is from North Carolina.
Actually, it's originally from Ukraine.
So welcome. He's been my.
My main.
Coworker for the past 2 years. Actually, so.
Hello, Craig!
Thanks for showing up.
Hello! Everybody!
Alright! So this is a talk. I am giving it Madison Ruby Conference. In 2 weeks from today, I believe.
And I have been.
A member of the St. Louis User group. Since.
2,001, I believe. So. Yeah, we're.
I've known most a lot of you here for.
A couple of decades. So.
You'll ride it home with this group.
So this is for Madison Ruby. If you want to add me my Twitter handle.
And my mastodon on Ruby, Social, or Craig.
I don't have this short URL already, and I don't have the slides online yet. But.
Hopefully. I'll have them and.
Share that on the mailing list.
Let's see.
Think we're ready to go.
Oh.
So. If you have questions.
Feel free, just unmute.
And just color out. I don't really have access to see.
Who has the hand raised, or chat, or anything like that? Because.
Already got 2 screens full of.
Presentation in my Notes.
So just holler out, you know.
Try to wait till I'm getting to the end of a.
Slide or sentence, or something that'd be great. I'll try to remember at the end of each slide, also to
To ask if anyone has questions. So start off with. I have questions for you, so you can unmute. And you guys can.
Answer in the affirmative for anyone that can so.
Who's familiar with this book design patterns. Anyone.
Alright!
I think I remember it from college, seeing books like it.
Yes.
Alright! Does anyone remember that there was a companion? CD, you could buy.
I.
Even though I own the book, I don't know if I own the.
CD or not. But in my research.
And it turns out, when you give a talk you're the one else.
So I learned this. There's actually a ruby version.
Of the book.
And is anyone familiar with this book.
Nope.
No.
Alright. So this will be new to a lot of you.
So.
I, else.
Actually own a copy of this.
And a lot of the presentation is based around this.
So my agenda is to talk about software design patterns.
Their history, where they came from.
And their history coming from building architectural patterns.
I'll talk a little bit about pattern languages and figure out some things we missed, and talk about architecture in the small.
So software design patterns a design pattern is like a general solution to a common problem, not an algorithm that specific. It's not specific code.
It can't be copied and pasted. It's more like the blueprint of an outline of the solution.
Does that make sense? I'll I'll have some examples here in a bit.
So.
Patterns up is, to use a common language, to describe.
These solutions to these counting problems.
And so our patterns usually break down into a couple of different pieces. So we have the name of the pattern.
There might be some aliases.
The intent is, what are we trying to accomplish?
And.
We're trying to accomplish those within a certain context. So the context is conditions under which.
The pattern works well.
And then we've got a problem.
And the problem is, we're we're trying to reach some goal. But we've got constraints.
Like, like all engineering. Right? We've got.
Competing constraints, and we need to figure out how to get.
A solution that that meets all those are bound.
And our solution is is going to balance those system.
And of course, we're gonna cross reference, because, a lot of these design patterns depend on other design patterns or reinforce or are similar.
So.
We'll see these. I'll I'll show some examples shortly.
So.
These are some names of some design patterns, some software design patterns.
So a single 10 is a class that can only be instantiated once.
So you can only have a single thing of that class.
A factory is a class or method that creates.
Objects.
A strategy as as a class that provides an algorithm that can be swapped up for another algorithm.
So in the context of Linux.
You might have different.
Spread scheduling or processing.
At a certain point in time, you could actually, there were a couple of different strategies, different algorithms you could swap in for your threading or process.
A template method provides a default implementation that can be overridden.
The visitor pattern we'll take a look at. It's used to iterate over collection of objects that's pretty common in a lot of languages.
And a null object is used to provide a default implementation that does nothing. And I just happen to give a talk on object pattern.
And a conference about a month and a half ago.
That's why I added that one.
Alright, so.
Actually, I am going to go show the null object pattern.
Find it. Okay, this is one. Websites version of a patterns, catalog.
So.
We've got the null object design pattern. Here the intent is encapsulate, the absence of an object for providing a suitable alternative.
That offer suitable default. Do nothing. Behavior.
So we need.
So we should use it when we.
Require a collaborator.
But I.
Clever, really shouldn't do anything.
What is.
Effect.
So we got a problem statement.
Yeah.
-Oh.
Would it be fair to like in a null object to the concept of 0.
In math.
Yes, yeah. So 0 is a null object. If you are adding.
So let's say you've got an addition function, and you've got number 10. But you.
Want to add it.
Different things, to it.
So if you've got.
Any red one. You get a.
11, but if you want to add nothing to it, you would pass in 0 would be your no object for addition.
And so depending on what you're.
Your your algorithm or your behavior is.
You.
You're gonna have different. No objects. Actually. So for addition, 0, in fact, used to know object.
So then we have discussion about, okay, how does this all work? And we do have some diagrams of the structure.
So.
So in this case we've got a ball, and it's using the strategy here.
Which I'm not sure. Why, that's just complicating things, I think.
But we could pull in the no ball motion strategy when you tell it to move it. It just doesn't move.
Because.
Probably don't actually have a ball.
It's probably the no wall.
So.
If you don't have a ball.
And you need.
And pretend like you have a ball.
We use the norm for the Nobel movement here.
So.
Here, we've got basically.
An abstract object, so.
I guess that would be a ball, and then we've got a real ball, and then we've got a ball that does nothing.
So the structure there.
And then some some pointers and tips.
And usually there are some.
Links to other.
Patterns.
I've already listed no.
Alright!
Should I get into? Actually, I'm gonna get into this one this is from.
Actually the that blue book I started with.
This is the iterator pattern.
And it is to access the.
Elements of an aggregate object sequentially.
So actually.
And also be, might be known as.
A cursor, and this is pretty long.
But say, you have a list, and you want to iterate through the list. You can create this other object.
That, you know can get the 1st thing the next thing, and tell you when you're done.
Which seems all very complicated, because it kind of is, and I'll get back a little later. So the point is, we can have an iterator for a list, but we could use a similar iterator for.
Oh, I guess it's not in here for trees.
So.
We can abstract this iterator idea.
To.
Lists or arrays, or maybe hashes.
Trees, graphs. Kind of anything.
That that can be, that is an aggregate object actually.
And so I don't think it's here, but I saw.
If you remember your your college things about trees.
There's a pre-order in order and post order. Traversals.
Which means that.
You know your tree has a parent, and it has children.
And.
If you're gonna traverse.
So do I start with the children first.st
Or the the left children. We're gonna start with myself first, st or do I start with the right children.
And so.
That's that's so in order would be.
The pair comes between the left child and right, child, if it's a balanced tree.
Otherwise it's it's pre order means the parent goes first.st
See what else is interesting in here.
Applicability multiple.
Right? That's nice that we can actually have.
We can iterate.
Have 2 iterators for the same object.
Which isn't very common in.
Frigging languages that have built in integration.
And it's a uniform interface. So if you're.
In Java. And you see this.
An iterator. You'll kind of understand what that means.
So here's the participants, collaborators, and.
Like, I said, variations in traversals.
So we might have that in order.
Or poster, or whatever tree.
They simplify the interface.
And it's.
Opinion itself. There.
So here's an implementation.
This book is a lot in Java, and.
But it does talk about small talk and comma lists.
Object, system.
So.
This is. Let's see where how many pages this is. Quite a few pages of just this one.
So we started on page 2, 77.
And.
2 82.
2, 57.
And.
We're still, we're still going so there's a lot to this.
There's a lot to that.
So it looks like we're like 12.
15 pages in.
So here's the end of it.
So related patterns. We have cross-references here.
The factory method.
Never.
Might. We might use a factory method to create an iter.
Let's see.
I've never done this the use case, I think, for writing your own iterator.
Have you ever used this in practice?
Yeah. Well, I don't usually write my own.
And I'll get.
So why, that is in a couple slides, actually.
Let's see, we've got examples from.
From Booch.
I'll talk about him in a bit.
And actually get there.
So basically, here's a bunch of examples.
Here, we've got the list traverser in.
This appears the Java.
So, yeah, examples, any any questions on this, anyone wanna dig in any.
Closer to any part of this.
I. So so in Java the list are very weekly typed, I think, or like they're strongly typed about what objects you can put in the list, but then.
You know all bets are off when it comes to.
Mutating those objects from inside the list, or.
Replace objects inside, and so sometimes I feel tempted, like.
Maybe I should create my own list class here that way. I know that people aren't.
Changing out these objects on me, or adding additional ones like.
Because sometimes you want like a fixed size.
And I don't, you know.
Anyway, I've thought about doing this. But then it's always like so much work. And it would slow me down. So it's okay. I'm just gonna use a normal list.
Yeah. So so here's an example here, they've got a list, but it also has a skip list. And so you can have an iterator for your list.
And an iterator for your skip list.
And they should actually have the same Api. They should work the same.
They don't really care if that list behind it is an array or a vector or a single link list, double linked list, or a skip list.
That makes sense.
Alright
Yep.
Alright, I think that's enough on that guy. Alright.
Continue on so.
We've got these software design patterns, and they tend to fit into 4 or 5 categories. So we've got patterns which create objects.
Like the factory pattern. The factory pattern is specifically to create objects.
The structural pattern is a way to organize your classes and objects, to form larger structures.
Behavioral patterns provide communication between objects.
So the null.
Object pattern is is a behavioral. So you want to have this thing behave as if it's nothing, instead of.
So concurrency patterns.
Pretty clear. Those deal with multi-threading, multitasking.
And then architectural patterns deal with the high, level structure.
And a lot of people don't actually put that as a separate thing. There's usually end up instructional.
Let's talk a little bit about that as well.
So.
The 1st problem with design patterns is that many developers misunderstand what the purpose is and how to use them. So you'll often see a junior developer trying to take.
The patterns they know and apply them to every problem, even though they don't fit that context.
So.
Instead of thinking as.
These are tools that I need to plug in everywhere.
I like to think of them more as a common language, describe the solutions to common problems.
So you know, before iterator had a name.
People are probably using it a lot.
And probably using it in similar ways, and they kind of figured out, hey, this is probably the best way to do this, at least in this context.
And
So they they started writing these things down.
They probably started writing down before they even called them patterns.
So.
One of the other problems with patterns is you can't reuse a pattern. You can't reuse the.
The code for a pattern.
It's more like we apply this pattern.
And it's gonna be different and depending on what code we're doing.
They're also.
They are not.
Oops!
Relax.
So the context dependent. They're not very usable.
And components.
The thing we've been waiting for for I don't know 40 years. It seems like.
Components are better way to reuse code.
I guess, reactions components. But I'm not very happy with them.
So.
Many of these patterns are paradigm specific.
And you'll see almost all these original patterns for object oriented.
And nobody really touched functional programming.
Patterns until much more recently.
So.
They're they're paradigm many times. They're language specific, and I'll get into that in just a bit.
And they're not a substitute for experience.
Like, if you have experience, you're usually going to sort of internalize these patterns.
And to me.
The important part of the is you've already internalized is to make sure you use the proper name, so we can communicate with other developers more easily.
So so we're using the same language.
So.
Many parents. Are just a replacement for missing language features, for example, in machine language, we had a pattern called subroutine.
But now we don't think of that as a pattern. That's just a language feature, you know. Call a function call method.
And ruby. We have.
An inevitable.
Api.
So we don't need the iterator or the visitor patterns very much.
So most of the patterns in the game of 4 book which I'll get to in a second, are object oriented.
And let's get into some.
Messing language features. So the top is in Java.
And we are using an external iterator.
So nodes.
Some.
You know this is a set of notes we don't know here. Maybe it's a
A list. Maybe it's an array made a factor.
And but we we get it's iterator. We create an iterator for it.
And then, while it has a next item in that iter.
We hit next, and then we do something with that note.
But in Ruby we don't really need an external iterator, because we have.
Have this built in each.
In some ways that that's an iterator. But it doesn't need to be a separate thing.
It's just a method call that we pass the block to.
And a block is really just an anonymous function.
So.
Whereas in.
Java. We had to do 4 lines and and ruby. We do. We do one line and it doesn't. It doesn't feel like a thing, because it's not. There's nothing special about it. There's nothing outside the lineage, features.
That makes sense any any questions.
Alright!
So design patterns? Where did they come from?
So this is the software design patterns.
It's called the Gang of 4 Book.
As Eric. Amma was the the lead author.
So sometimes we call it gamma, and.
But usually we call the gang of 4.
Covers, 23 patterns.
Only 23 patterns. It's a fairly substantial book, but you saw along each of the patterns.
They're mostly in Java and C. And.
Their language, agnostic.
Ish.
Like, they they apply to.
Pretty much.
The languages, the objection, language that existed.
And 1994, when it was released.
But not so much with newer languages, not so much with functional programming.
There might be a few that apply, but not too many.
So this is Eric Gamma. He's a Swiss computer scientist.
In 1 88 he started on his Phd.
And he started applying the idea design patterns to software engineering.
He also called coauthored the J. Unit book with Kent Beck.
He worked for Ibm Ibm rational. He worked on the eclipse.
Ide.
Which before that was visual age, id.
And he's actually worked some on visual studio.
There are no individual pictures of Richard Helm that's him on the right there.
He's an Australian soccer, engineer and consultant.
He's in the software architecture object, oriented design and it strategy. And it.
Transformations. So he doesn't seem to be quite in the software realm as much as he was back.
This is Ralph Johnson is American computer scientist at Ui Uc.
Some you may have gone there. He was a major contributor to the development of.
Object, or any programming and small talk actually.
You'll hear, you'll hear, and I'll talk a lot.
And stop.
This is John. Both sides.
An American software engineer, researcher.
He! He!
Work with Stanford University and Ibm. Watson Research Center.
Software design and development software visualization.
Design tools and techniques.
Application frameworks. And is anyone here ever used which was like a.
A competitor. In the early X. 11.
He was involved in that.
Ui ui tools toolkit.
Let's see.
So the forward of the gang of 4 Book was grainy.
He, the year before that he had written the book, object, analysis, and design, with applications.
Which is.
Explain the Booch method.
He probably claimed the term objection.
He was heavily involved in Uml, the unified, modeling language. He also worked at Ibm rational.
Before you had the rational, unified process.
Which is use case driven.
Architectural, centric.
And iterative and incremental, so.
What this is! 1993.
Well, I guess Rob was after 1,009.
But this incremental and iterative is very much in the agile.
I believe he's now at Ibm a research scientist for software engineering. And he's working on a book called the Handbook of Software Architecture.
Also apologies to Brady Bunch, because on Github I ended up with the booch.
Handle, and he did not.
And that's my last thing that's booch. Instead of buying.
Alright!
So prior to the the gang of 4 Book there was a community of people who are already using patterns.
The Ganga for themselves.
Brady Bunch.
And I'll get into some of the others in sec.
So this is the C 2 wiki.
C. 2 stands for Cunningham and Cunningham. We'll get into that.
This wiki was designed for.
The the design patterns community to.
You talk.
In the the.
I actually had the date here mid nineties, maybe even late nineties.
Part of it was called the Portland.
Pattern, repository.
People, projects and patterns.
And Cunningham, which will.
Talk about in a bit lives near Portland, Oregon, so.
That's why it's the Portland and Cunningham.
So this is actually the very 1st wiki.
He called it Wiki Web.
And Cunningham.
I wrote that software to be used for collaboration.
See something.
So 1,995, Jim Copeland.
Released a a conference set of papers called pattern languages and program design.
I actually knew Jim Copeland from his book on Advanced Programming South and idioms.
So I was. I was actually surprised to see him in the.
The patterns.
Community.
I thought he was more of a but it turns out a lot of these folks involved.
Are involved in a lot of different things.
Alright, so word! Cunningham, who knows word? Cunningham. Anyone know who.
Or Miss.
How many, how many people know who it is?
I've heard the name.
Alright you should have heard the name a lot. You will hear the name a lot.
Is he the one that got the bullet board system?
See the gap in Chicago.
I I know.
No.
Okay.
Okay, so the 1st Bds.
You'll probably get. So he invented the wiki.
There's another person that's related to.
The 1st vbs sort of.
I'll get to him in a couple slides.
The word wasn't involved in a lot of stuff. It was involved in small talk.
The Eclipse Foundation. It's a signature to the Adam Manifesto, which was 2,001.
The framework for integration testing.
That is a testing framework. Pretty cool, actually.
Extreme programming.
He probably coined the term technical debt in 1,009 92.
If you are old, school object, oriented analysis and design.
You may remember the Crc class.
Responsibility and collaboration cards.
He invented the wiki, and more recently the federated Wiki.
Which is sort of a forklable wiki, which I kind of blows my mind.
And he's also known for Cunningham's law, which says, the best way to get the right answer on the Internet is not ask a question.
It's supposed to wrong. Answer.
And the funny thing is, Cunningham says that is the wrong answer. It's not actually he was not the original.
So ward.
Along with Kent Beck. Who's the next slide?
Wrote a paper on graphical user interfaces in small talk in 1,009. So.
They preceded the 1993, 94 gain the forebook by quite a bit. So they were.
Involved in this earlier.
And Kit pack.
So today learned that Kimp was actually at Apple around this time.
He would go on later to.
Develop, extreme programming.
Test Driven Design.
You also signed the agile manifesto. He wrote J. Units.
And he was another small doctor.
And
I talked about a book in a bit.
One of the things that I like is make it work.
Make it right.
Make it fast.
In that order.
All right. Another person involved was Martin, 1,999. He wrote a book on refactoring. He wrote the book on refactoring with Kent back.
Currently, and for a long time he's been the chief scientist that thought works.
2,002. He wrote a book called Patterns of Enterprise, Application, Architecture.
It's written books on domain specific languages. Uml.
Continuous integration and micro services.
So this is his book. This is so. The 1st book was 23 patterns, the gang of 4 book. This is 42 patterns.
And these are targeted larger systems.
So there's not. I don't know if there's any overlap. If so, there's there's minimal overlap.
And when Dhc. The author of Ruby on Rails.
Learn patterns.
He read this book, and he applied under Ruby on rails, so.
Ruby, unreal, actually uses the active pattern and the model model view controller pattern.
That actually came from this book.
And.
Not have that one.
Nope.
I don't have that pulled up.
Out!
Okay, so where do the idea for these design patterns in software come from?
Well, turns out, they came from a book about architectural designs.
So this book is by Christopher Alexander.
He gets mentioned a lot in the history of these software design patterns. People.
So.
This book is called a pattern language.
And he gets into towns.
And buildings, and and how to construct buildings.
And and and does. It is a series of patterns just like the.
The software paddings.
And I'll show a little bit of that in a bit.
So.
Oddly enough.
Christopher Alexander had been working since the.
Mid to early 60 s. On Architecture, and trying to.
To get to the philosophy of architecture. And like, how do we make decisions.
So he'd he'd been talking and thinking about these things a lot, working on them.
So.
This this book is actually part.
It's. It's part of a 3 book series.
Oddly.
They released Volume 3, then volume 2, then volume one. I don't understand how that works, but that's that's what they did.
Volume 3 was the organ experiment, in 1,975.
The University of Oregon. They.
Applied Alexander's ideas.
To.
Campus community planning.
And this.
This organ experiment was sort of the test bed.
Of the ideas in the in. The later 2 books.
It's very people syndric.
His philosophy is that feeling should be the primary to use for making changes to somewhere to a place that we're building.
And that people can and should be involved.
And the design process of their spaces.
So.
Dad resulted in a theory of architecture and planning.
And that led to the 2 other books. So.
Second book was the pattern language, this book which we'll get into more. This is the book we're gonna focus on.
And then volume 1,009, whereas this book was 77.
It's a timeless way of building.
And this is more of his philosophical approach, whereas pattern language is more about.
Details more.
White country. But you know, somewhere in between abstract and concrete, whereas.
Timeless way is more about the the abstract.
And the timeless way introduces, like the concept of the quality without a name.
And we should seek to include that nameless quality in our.
So!
I was actually surprised that this book is a little more.
Out there. A little less.
I'd say it's a bit of an iconoclass actually.
So it's interesting that this iconoclass kind of.
His ideas, or at least the way he expresses ideas got taken.
From.
Architecture, to soccer.
So this is Christopher Alexander. I believe he's still around. I think it's like 85 years old.
He designed it personally, built over a hundred buildings.
As an architect and a general contractor.
A lot of the way he describes building.
Building is.
Things that have been 1,000 years, how people built their own buildings before we had builders.
As a separate thing.
He's British American. He was at Uc. Berkeley. For a long time.
Oh, you did die a couple of years ago.
See.
He's got other books on architecture. Another 4 series of books called the Nature of Order.
Which seems really interesting because it gets sort of in beauty and life, and how.
We need to focus on those things when we're doing our design.
Alright, so a pattern language. So the book is called a pattern language. So what is a pattern language? It's it's a collection of patterns.
It describes the problems and the solutions.
And it's organized in in a coherent way.
And it's specific to a field of expertise. So.
In his case. You know, it's architecture of buildings and towns.
So the.
So so ward.
Cunningham and Kent Beck.
Had been introduced to this book.
And.
They're like that would be a good way to.
Talk about our patterns, this design.
Pattern, language.
Who knows about this book.
Guessing.
I remember that.
At least.
3 of you. Yes, yes, Phil.
Remember this one.
Yeah.
Yes, I do.
Alright!
I've heard.
Alright, so
Alright! So Stuart Brand wrote this originally in 1 68 to 1972.
Stuart Brand. This person comes up in computer history.
He started in the early sixties doing Lsd studies.
He was actually there at Douglas, unworth mother of all Demos, in 1,960.
I know Skype man has talked about that.
Several times to this group.
1,984. He founded the 1st online community called the Well.
Which is the whole earth electronic link.
He worked at Stanford, mit Media Lab.
Be probably coined. The term personal computer.
The 1st printed use of it was from him in 1974.
He was a director of the Eff.
From 1,994.
I found it a long now foundation. Has anyone heard of that one.
They've got the 10,000 year clock.
That they built.
They're working on a.
10,000 year, library.
And now they've got something called long bets, which is like.
In the long term this would probably be true.
How do we make it better?
And couple of other people.
And Lee in the Long Foundation.
Are Brian Eno and Esther Dyson.
So.
Another little tidbit here.
66 he posted, and they had buttons printed up to where.
Why haven't we seen a photograph of the whole earth yet? 1,966.
NASA had sinned.
You know, spaceships up to.
Earth, orbit, or or even.
Maybe to the moon by that point, I guess.
But we didn't have any real good pictures of it until.
A year or 2 later.
So he's he's started with possibly pushing NASA.
To accelerate.
Giving us good color photographs of the earth.
And the ecology movement takes shape.
A lot in response to seeing the earth from that vantage point.
Okay, so.
Okay. So Stewart Brand gets involved in the story by 1,994.
Writing a book, how buildings learn what happens after they're built.
So this was expired by Christopher Alexander's work, and he he.
Extensively spoke with Alexander.
There's actually a 6 part TV series for the BBC from 1,997.
With music, by ray and.
So.
His.
Theory there. Well, actually, it's got quite a few things he gets into here.
But he says the best buildings are made from low-cost standard designs that people are familiar with.
And are easy to modify.
Another tip he's got is use materials to smell bad when they are wet.
You know when you have.
I'm like, that's that's that's brilliant. And like, how do we apply that to software design is.
I haven't quite wrap my head around that one.
But we do have sort of.
Well, I guess we log things. We we log moreisily.
When things break.
I guess we have. We have layers, so we do hit that boundary.
I guess you do.
Have observability to tell when there's a leak.
So all those things apply to software as well. I don't know. Stuart thought about this at the time. Oh, hang on a second.
Okay.
You know that did.
Alright!
So all those ideas apply to software as well.
Incremental change.
Let's see suggestion learning as you go.
Choose the option that gives more options in the future. That is a huge part of what we're trying to do.
And software design.
To be maintainable.
Because we don't. We have to admit that we don't know.
How this house is going to be used.
We don't know how this software is going to be used completely.
We're gonna have to worry about maintenance.
He says that maintenance.
See if oh, man, these are hang on a sec. I need to do something mute here.
Alright!
All work.
Okay. Better.
It says, buildings are predictions, and all predictions are wrong.
So we should design so that it doesn't matter when we're wrong.
He says a building is never finished.
In fact, I didn't really talk about this yet, but I should get into this.
So the last picture on this cover his book.
Is the original.
2 buildings.
That are shown in current time. On the right.
And you can see they've evolved differently.
And.
Unfortunately, I just discovered this book or rediscover this book like a couple days ago, so I haven't gotten into everything that I might want to talk about, but.
My presentation in 2 weeks is only half an hour, so I can't get too far in it.
So he. He talks about the different layers.
They're called shearing layers after a person named Shearing.
He's got this layers of of building.
So 1st is the site, the site of the building.
And the site doesn't change a lot right?
And then there's a structure. There's the foundation.
The load bearing walls.
The outside walls. They don't change very often.
And then outside of that, it's the skin.
So.
Maybe the the installation, the windows.
Those get changed every 20 to 50 years, because, hey, maybe we find better windows, better insulation.
Learn how to make our homes more air.
And then you've got the services layer.
Which is interesting because we call it the services layer. Also in programming.
And this changes more more frequently in this.
And you know.
You're upgrading your electrical box.
You're putting some ethernet in.
And those change. Now pretty much. You're gonna make some changes, probably decade or so.
And then you've got your space plan, which is your interior layout. The interior walls, doors.
And these change. Sometimes we change out our flooring, probably every 20 years. But the interior layout.
We tend to do that probably more like 5 to 10 years.
And then inside of that is all your stuff.
So sharing layers are site from the bottom down.
I'm a site structure.
Skin services.
Space.
And stuff.
So he also says, we shape our buildings and our buildings shape us.
Annotation between buildings and users is a slow and continuous process.
And but over 50 years it changes within the building cost more than the building itself originally cost.
I remember.
Anytime they do some reconstruction on, especially like a theater. I remember when they did the
Fox Theatre, in St. Louis.
And they did the.
What's the theater downtown next to the arena called.
I remember they redid that.
And it was amazing because those.
Those renovations cost more than the building. I'm like Whoa!
That's crazy.
So he says.
Over 50 years.
The maintenance costs will generally be about 3 times the cost of the building.
For commercial building, and 6 times for residential building.
So his advice.
Our good builders, and save money in the long run.
Because if you can extend that to make it more maintenance free, it's gonna save you a lot more money than you're gonna cost you.
He says the temporary is.
Mostly permanent. So how many.
Thanks. Can you think of a temporary workaround or a temporary thing in your home that.
Been there for years or decades right.
He says, feel small early and often, and you will succeed in the long run.
A couple more things.
A new building is a band teacher of maintenance, since deferring of maintenance is a habit.
And building that has been maintained for a long time is a good teacher, since its maintenance is a habit.
So.
In many fields architecture means like the unchanging deep structure.
But brand here.
Shows us that that there really is no unchanged instruction.
So I like to think of.
Of architecture just is structured.
Not not so much as I'm changing.
It might be harder to change. I guess it might be. An argument.
Some other question or comment.
Oh, Grant says there's nothing in it as a temporary solution.
Alright! Anyone else.
Yeah, about ready to say, yeah, when you're talking about the
The time the amount of maintenance are.
About 3 times more than the building.
Made me think of the.
The mythical man by Brooks.
He is.
He is right in the center of design.
For sure.
So.
Yeah, you're talking about the mythical man.
And.
See, I don't see me.
Where am I?
The command month.
Fred Brooks.
He also has a book called The Design of Design, so.
Kind of gets into this topic as well.
So there's all these threads of.
Different people, in in.
Yeah, different communities. That kind of all get together and and share ideas. It's amazing that happened.
So we think of architecture as big. We think of buildings. We think of cities. We think of software systems.
We can also think of small architecture.
Like rooms and and software components.
My wife happens to be an interior designer. She has a degree in interior design.
And some programs actually call that interior architecture.
Because it's it's the architecture of the small.
And and.
That's another reason that I kind of.
With architecture, because.
It's it's related to her.
Or field.
So
Ironically. This is one of my favorite books on one of the best books, in my opinion on Ruby.
Even though it almost came out before Ruby came out.
It turns out, the small talk in ruby are very similar, so.
Most of the things that apply to.
So I'll talk. Apply to Ruby.
A lot of these actually.
Our smaller patterns that apply to almost any programming image.
So I want to get into that.
Some specifics here.
Man.
That way.
I can't do that. Okay.
Let's see Sudan.
Okay.
So this is small tech small talk, best practice patterns. This is a pattern called intention, revealing select.
And a selector is the name of a method.
So.
I mean any other language you would call this an intention, revealing name.
And I have.
Mikael has probably heard me say, and.
I went. I want something revealing.
So.
We are trying to name a method.
And here's here's the question, what do you name a method.
1st is to name it.
After Howard accomplishes his task.
And.
The second option is to name.
What it's supposed to do, and we don't care.
A method.
Does something we care what it does. That's kind of the whole purpose of a.
Of a procedure or function, or method.
It's to not care about how it's done.
Like, let.
Let that method, that function, that procedure.
Let it figure out how to do it.
I just want to tell it. Hey, do that!
So when I tell it to do that, I don't want to tell it. How I just want to tell it. Do that.
So name methods after what they accomplish.
So his patterns are a little bit.
A little bit different.
So here's the cross references here at the top. That's kind of probably a little early.
Oh, actually, he might have some at the top and the bottom.
Yeah, he does have them at the top or the bottom.
So the ones at the top are.
Once they came earlier, actually, most likely.
They are.
Patterns that this pattern builds on.
And the ones at the bottom are patents that build on this one.
So he just talks about how to name a method.
So if I'm searching for something, just say search or search for.
Don't say, you know. Search for tree, search for.
It it. It shouldn't matter in those cases.
Write a name it after what?
Oh! Did he change.
Oh! So he changed search for.
Includes, actually.
So yeah, I just wanted to cover one of those that's.
That's a very small thing like your program. Your method names, your function, names, your procedure, names.
Cyber team aims in a program.
They're a very, very tiny part of your program, right? Like they're usually just a few characters.
Out, of.
You know how many thousands of lines of code.
And yet he's.
Thought about.
A pattern on how to name things.
Name our methods and and functions.
I thought that was.
Pretty amazing that if he really gets him down into nitty, gritty.
With his patterns.
I found this book to be pretty amazing.
Yes, account, says the most difficult task.
And program is naming things.
I believe the quote is the 3 hardest things in.
Programming, our.
Cash and validation!
Naming things and offline error.
Although that last one was added on, there.
Actually got a book. What did they do with that book?
There's a little book I just.
Radic.
Probably 6 months ago.
This. It's it's an entire book on how to name things in programs.
And it's like 120 pages. Nice short book, but.
It very much. Got into that same sort of.
Advice.
But it actually dug down on.
What are the reasons why we choose a good name? What makes a good name, and what makes a good name? And how do we decide when there's.
Counteracting constraints.
Engineering.
We've got constraints to pull in different ways. How do we come up with a solution.
So I want to talk about doorknobs.
So I was actually surprised that Alexander's book didn't cover this. And I will actually get into some some of this things he did cover.
I don't know if this but my AI! That was helping me write this says door knobs were invented in 1,878.
Very hard for me to lead, to leave.
But door levers are much older.
And.
So.
We usually use doorknobs, but levers of becoming more common, and apparently, you know, long time ago levers were more common.
So.
How do we decide?
Which of these to use? I mean there, there are patterns. There are reasons that we can choose one over the other.
And I actually found 2 web pages that hell they choose. Which of these? So they basically give you the patterns.
So now I'm set more styles.
Available.
And they go much more better with an older building.
The style of an old building.
And knobs can turn left or right.
But levers are easier to use.
And they can be used with when your hands are full. You know you can.
You can use your elbow or something.
You can use your nose if you want. Sometimes.
Levers are easier for for kids disabled people, older people.
Someone that might have arthritis might not be able to grip that handle very well.
I think.
We could push that lever down pretty easily.
But levers can easily snag on clothing, so the advice is.
Don't use letters.
In place of handles.
If you're in a confined space, because if you're in a confined space, you're gonna be rubbing up against it more. So if you got wide.
A wide hallway.
The the levers, the handles are actually pretty good.
19.
Alright
So.
Architecture, of.
Doorknobs and and handles and levers.
We have a similar thing with buttons in
In architecture. I I claim that a button is an architecture.
Lost him.
I don't hear Craig anymore.
I was wondering if it was me.
And I don't.
My connection. But yeah, he.
He's he's screen is frozen.
And but we should.
Also shouldn't have every button be different.
I once.
Alright!
Craig Craig, you you would froze there for a second. Can you kind of back up and start over with the button?
Yeah, yeah, yeah.
Yeah, sure.
I don't know why my my wife has good so we rarely think of a button as an architectural element.
In our software. But an architectural element is anything that's part of the structure of that application.
Or or that building. If we're talking about building architecture.
So we should choose the right button.
For the contacts that we have. Right.
There shouldn't be a single one. Size fits all button.
But we also shouldn't have every button be different.
This is, I believe, from material design. Buttons.
And.
Honestly. That feels like way too many buttons.
Like I could see different colors. There's some.
But in examples where you've got a primary button on the secondary and a call to action, and maybe a tertiary.
Maybe a warning.
But really you should only have like.
More colors, and maybe 4 shapes. These feel.
Like we've got too many things going on here.
They don't agree that like.
Like these switches sometimes. I don't know when they're even on or off.
I I almost talked my way into an architecture, position.
By talking about architecture and small and like.
How many different buttons has your team.
Mike.
Now, it's not so bad because we can get these components from.
From a component library, but until, like 10 years ago, we would.
Every team would write a different button, and they work different, and they just made.
They made, you know, got a lot more code to maintain.
Maintenance is the major cost right.
But it also makes the users like confused. How do I use this button? How do I use this button? Why does this button different than that?
So.
You know, we need to think about.
Our context, we need to think about.
Well, when we're building architecture, we also we wanna context. But if contexts are similar, we want to have similar.
Design similar outcomes.
And let's not get started on like which button like is the cancel button on the left or the right is the okay button.
I mean. Oh, my goodness, the the conversations that I've been in that go on and on about.
Which button goes on. Which side? Oh, man, get me out of there!
Didn't Ibm.
So so it's it's.
Standard that they tried to have all of their programs adhere to.
It was either the eighties or nineties.
Yeah, cool.
Yes, I believe you talked about this.
Yeah. So before that, we're perfect, like, everyone had a different set of commands to open a file.
And then Ibm said, Hey, let's
Let's standardize these.
And I actually.
Even though I rarely use windows, anything. I become related.
I still have many of these.
Hard coded.
Like, who remembers using.
Cut copy pastes, you know, with the delete, and insert keys.
With shifting control. Right?
Did.
Yesterday.
Hey, yeah. Exactly.
Tab.
Today we'll get you between fields.
And dialogue boxes and shift tab will take you backwards.
The other one I use is the cursor movements like a shift. Cursor movement will select.
And then like a.
Think an all cursor movement will.
Unify, word.
Maybe that's.
That's.
And then you can actually add them together, and you can shift.
Select by word or by sentence.
Alright!
Now.
Aye.
Nope, there we go!
So before I hit the conclusion slide, I want to show.
Some of Alexander's.
Design patterns, and.
This Pdf doesn't have the entire book. It's only got about half of it, so I couldn't show.
Specifically the ones I wanted. So I didn't go through and.
We'll see.
So spoke is published in 1,900, so the pictures are not great.
So I think I can make that a little bigger.
So that's a little kid hiding in a little cove.
Looks like they're playing cards, 2 kids. Now that I.
Zoomed it in.
And there's a little piece of wood over their heads.
Not sure what that is.
But let's go find out. Okay. So.
This is.
Pattern number 2 and.
The pattern Languages. Book.
And it references, some earlier ones.
And he's talked about.
Having playgrounds for children, how we should make children's difference.
How the rooms should be laid out.
And we probably wanna have thick walls because they're gonna be noisy.
So
So this is sort of his premise. Children love to be in tiny cave like places. And then he's gonna tell us, well, how do we create these, some ideas on, on, where to create these and how to create these.
So here's an example. And
There he's under. Think! Here he's under the stairs here he's under the.
The table.
Because kids are gonna make those places for themselves right?
So we might as well help.
So his role is wherever children play around the house in the neighborhood schools make small kids for them.
Tuck these caves away, and natural left over spaces on your stairs, kitchen counters.
Keep the ceilings low.
Like 2 and a half to 4 seat, and make the entrance.
Fill the case right in the fabric of the walls.
So basically those are.
Follow lines on on. Okay. So we've decided, make this thing.
How do we flow from there?
So.
One thing interesting is so.
The way he wrote his.
Patterns.
Some of them.
Like get too asterisk, and those are like.
Yeah, everyone should be doing these.
The ones with one aspect are like.
Yeah, you should probably consider these and the ones with no asterisk or ones. He's like.
I just kind of spit on here.
So I thought this would actually have one asterisk definitely, not 2.
But yeah,
So.
Some of the interesting ones that.
Didn't get the the capture here. One of the more interesting ones was,
His research on how tall to make a building.
And you know he's got he's actually got footnotes and and sources for for his reasoning.
So he says, not to make.
Buildings taller than 4 stories.
And a lot of that has to do with just, you know, not having buildings that are, you know, different sizes next to each other.
But especially residential buildings.
He says it's not good to be up by the 4th floor, and the research shows.
They had kids growing up.
On the 4, th the 8th floor.
Get outside half as much as kids on the 1st floor.
That's just amazing statistics. So that means that those kids are not socialized. You know, they're not getting outside. They're not getting an exercise. They're not getting fresh air, but they're not. So. They're also socializing less with other kids.
And so his. His thought is.
There's not a lot of good reason in most cases to make sure buildings more than 4 stories.
So let's try not to make buildings more than 4 stories.
Interesting thing. There is my dad. I remember my dad. He was a construction worker.
And I remember when he was a kid.
When I was a kid he told me.
You know. Look at all the.
The buildings in in office parks.
They're almost always like.
3. 4. Stories.
It turns out there's another reason for that, and that is water pressure.
It turns out that if you've got a you know an 8 story building, you've got a.
Push a lot of water up to the top.
To put it in your.
These are the things that the water receptacle, that that.
If the electric goes out and your pumps aren't working.
The waters will still flow, due to pressure.
Reservoir.
From.
Yeah, yeah, our, water.
I'm.
Tower, a water tower, basically on the top of your building.
Yeah, when do you know?
When he made those statements compared to like.
Mass adoption of elevators.
It's.
So this is 1,007! So I would imagine that.
Elevators were were pretty common at that point.
Okay.
So.
There are some really interesting ones, and.
You know this is a half hour talk that I'm now. What 40 min into.
So!
Okay.
I know that this group can.
That's a little more time than my 30 min, so I'll I'll talk about a.
A few.
Interesting ones.
He talks about Al codes instead of having rooms. It's almost more
I'm better to have alcoves.
He's got.
There's 1 about the marriage bed.
And how to like.
Oh, the marriage bed is different from.
Like a teenager's bed, and he's got a different.
He's got advice for teenager rooms, and, in fact, he says teenagers.
And
Older folks should sort of have a.
And outbuilding on your property.
Like they should have their own wing of the house, I guess. What is it, mother-in-law?
Entrance or.
Mother-in-law's room, where it's like it's it's got its own entrance.
But it's also shared space with the with the family.
Yeah. So he gets in. And all kinds of architectural things.
Alright! Let me get back to my conclusion. Then.
Alright!
Today.
Alright. I think we're synced. Okay.
7 conclusions so.
We have patterns as a way to describe common solutions, common problems.
And when we make a pattern language, we that gives us a common language that we can use amongst our peers.
Or at least the the people that are.
Are familiar with that particular pattern language.
And and Alexander talks about. He's like, Okay, this is a pattern language.
Like. There could be other pattern languages, even for architecture like you might have.
Like a brutalist.
Pattern, language for architecture.
You might have a pattern language for mobile apps versus web apps.
So there might be different patterns in those different contexts.
Architecture is about structure.
And structure doesn't necessarily have size.
And and the funny thing is,
When I start doing these presentations.
I often think the conclusion is gonna be one thing.
But I find things, and it it turns out to be different. So.
Finding that second book.
About buildings.
Excuse me changing over time.
That's that's more like the the conclusion I want to.
To get across. We we can't predict what our future needs will be.
So we need to design a change in that evolutionary adaptation.
Into our software, into our buildings.
We need to learn. We need to make habits.
And we need to recall that the.
Most of the costs are going to be in maintenance.
And architecture is about people, how do they interact with the space and the software application? We need to keep that in mind.
And I I feel like
These these people have.
Kept a lot of this in mind.
Like they're trying to help us be better software developers and use our tools better.
So I did show the so some resources you can do. Source making, I believe, is one of the
Once I showed.
So.
Oddly.
There are.
There's this refactoring Guru designs.
And then there's.
Source, making.
Which appears to be the same thing by the same people.
But a different design and different set of patterns. So it's it's very weird.
Alright!
So the hillside group.
Still has a
Conference. The pattern language is the programming Conference.
Martin Fowler. He had that.
Principles of application.
Enterprise, application, engineering.
He also has.
And Architecture. Guide.
And he has some of the diagrams from his.
Book online.
The Wikipedia.
Entries on pattern, language and software design are are pretty darn good. Actually.
And this one I probably should have put earlier. This is a paper from 19. The 1st known paper on patterns in software.
There's, of course, Ward Cunmingham and Quebec.
So I imagine some of you know Alex Miller has attended back in the day.
He had talk called design patterns, reconsidered.
I haven't looked on archives.org, but the.
Yeah, our the website is lost for now.
Doug Lee wrote
An introduction to Christopher Alexander for programmers.
Object, or in pro specific specific.
Before we had the wiki there was actually this
Fact.
On a mailing list.
We have to update 2,000.
So this is before the the wiki before any wiki existed.
Pattern language.com is.
A site that actually.
Still exist for the book.
And I will probably sign up for a $5 monthhip, so I can actually get.
Digital access to this book. So I can.
Copy some pictures out.
For the.
For the conference. Talk. Let's see what else we got.
There is this awesome design patterns.
Let's click on it.
Awesome. There's awesome list all over the Internet. Of software things. And this is software and design.
So.
Like, I said. We have. We have, general, but we have. We have.
Pattern languages, for you know, micro services.
And serverless, and cloud.
So.
Serverless patterns.
Let's take a look at some of those.
So.
Hooking up your clients in Api gateway. A lambda dynamo. dB.
And we've got other other patterns to do.
Service.
Alright, and.
So I actually found a few patterns myself that I documented.
This is a long time ago I wrote this one.
I called it a grenade.
Basically, you're debugging.
And you want something to blow up.
Instead of doing the right thing, you want to blow up. So when you call it, it just blows up and throws an exception. And now you know.
Where that object got called.
So I found that useful, and I.
I documentedable shell scripts is basically saying.
It's really simple.
Instead of.
Structuring our code like this in a shell script.
Just have a main function. First.st
So that we can see the main function.
Ahead of everything else.
Very very simple pattern.
And then a very complex pattern in ruby.
So, yeah, patterns can be very simple like this.
And and.
We'll we'll run into parents and and can tell you this.
In in our code base, we have patterns that really don't fit any other piece of software than.
The the application that we happen to be working on together.
So you'll see patterns everywhere.
And.
Try to find the good ones, try to document the good ones and try to replace the bad ones with the good ones.
And I am interviewing now. I'm interviewing 3 companies, so don't really need.
But if anyone has a little work.
I don't know.
Opportunities.
So thanks. I appreciate you guys,
And I would be happy to.
Hear any feedback on how to make this better for a conference.
Hey! This is Stan.
Hey! Stan!
I would recommend that you put text.
Yeah.
On the photos of the people you're talking about put their name.
In in that photo.
Okay.
And.
Cool.
I think that would make it better.
Yeah. And if I, if I want to say, Does anyone know who this is.
I can have it without the name, and then I can put the name on top.
Cool thanks.
Yeah, I think I think there's some ordering things that need to be a little bit different. But
You touch on a bunch of different things.
And I'm thinking to myself, I wanna once you publish the slide deck go through and reference some things.
I almost feel like.
You might be at a point you'd benefit from something akin to a bibliography.
Whereas in.
You mentioned something.
But you can then later in your slide deck.
Like this thing, and a.
One to 3 sentence. What this thing is commonly known for.
Might help people that are wanting to.
They see an idea, something in your slide deck and want to research it later, you know, even if it's a person's name.
The Internet, you're gonna find 8 people by that same name, but maybe just more content.
Yeah.
To help narrow down the.
Sure!
Cerie, maybe.
That.
Cause. Ralph Ralph Johnson was not easy to find.
Alright! What's someone else? Say something? There.
Well, I can say.
Great speech.
I enjoyed it.
But I I would say that
It has a lot of.
About architecture.
And a little bit.
Less about actual. You know software application of this architecture which I enjoy it because I love learning new things.
But maybe you need to give a heads up for.
People that like.
It's not a.
It's not a speech about software architecture. It's a speech about architecture and software.
Yes, yes.
Yes, for sure.
But I mean I real.
Yeah, the the abstract actually does touch on that. But it didn't.
And when it sees a good page I don't think.
Otherwise it was great. I actually, I really enjoyed the part with the children.
Caves.
Yeah.
Yeah, I do need to get a little more from the books onto the slides.
And for the 30 min version I'm gonna talk a lot less about.
People involved in the history of.
While we sleep every day.
It's.
It's definitely an interesting and.
And I think this group is more.
Familiar, probably, with some of those.
Figures, in, in.
Competing history.
Alright! Any anybody else.
Yeah. Craig.
Could you maybe put in the chat, or whatever that URL.
Wikipedia on that Ibm those keyboard things, whatever it was.
Oh, oh, yeah. Yeah.
Yeah, I
Feel like we've lost some things as people have abandoned.
Common user access.
And one of the things that.
About Kua.
Was. They tried.
Impose that on.
Dos and windows, applications as well as mainframe applications.
And make.
How things.
Behaved.
Consistent.
They wanted things to be repetition, and you didn't have to stop and think. How do I do this?
In this thing. It's.
I want a copy that's control. CI want to paste that's control V, or.
Shift, delete, or shift, insert.
And I know that apple.
Was.
Known for trying to enforce that.
In their ecosystem.
Before windows started doing it, and it seems like a lot of the windows.
Environments.
There was.
Our our programs they're in. We're not necessarily aware of.
There was actually a book on the Macintosh design.
Interface. And yeah.
And it's actually Craig. It's.
I think it's in the same article in Wikipedia about you already opened.
And for all of its annoyances and Java applications.
Yep.
They did have a consistent interface.
Provided by Java, across platforms.
Yeah. So apples is called the human interfaces, guidelines.
I think it's still called that.
And it says down here that.
Gnome, and Katie.
Are pretty well compatible.
Of course, on a Mac. It's.
Command instead of controls. So we can use our control keys in the terminal.
Which kind of makes sense to me. I kind of like that.
So almost every. So if I select so.
I mean, if I double click a word it right.
If and I could hit, shift the arrows and select characters, or.
Shift control, and I can select my words. So a lot of it.
A lot of these muscle memory still work.
And that's.
Yeah. The command. C, command, X.
A lot of those are command Z for undo or control z.
A lot of those. A lot of us have muscle memory, that's for sure.
Anything else.
Alright! Someone on a wrap up.
Alright! Anybody else have any questions for Craig.
I will say that my presentations will be.
Here soon. I don't know.
It might be a couple weeks before I get it up here, but I will probably have it here in a few days.
Do we want to throw up your current slide deck.
Our, our.
Are not the Presentation Archive.
Oh,
Yes, I'll see what I can do.
The other thing I was gonna ask is, once you do upload it to either Github or your.
Site.
Would you please.
Send a message to discuss, saying, it's there.
So people could.
Go out and pull down the.
Finish copy.
Okay. Cool.
Hence.
This is Stan. I'd like to make the comment that is under the firm opinion.
That.
Developers for.
Android phones. They have to have a frontal lobotomy before they start working.
Which which patterns are they violating.
Yeah, all of them.
So I didn't cover it, I should have actually mentioned it. There's something patterns.
There's there are patterns that people think are good and turn on not to be good. They're usually.
It.
Any alternatives.
It amazes me that so many of these.
Systems, they they expect you to figure out.
Pinch and swipe, and which direction and.
All this magical stuff and.
There's no documentation, hardly on any of this stuff. You just.
Unless you.
You hear somebody else on the discussion group talk about oh, you do it! 3 fingers.
Swipe to the left. Does this or some scary thing.
Us. It's so.
Frustrating.
It's intuitive. It's intuitive. Stan. Come on.
Also do.
That is not a damn thing in the world. It's intuitive.
Do Android phones.
Absolutely nothing.
The nipple, the nipple.
The nipple isn't is the only thing intuitive.
Well, that's the exception. Yes.
Do Android phones still have a back button.
And it always works.
Not as you expect.
Oh, no, don't worry. That's gonna get a lot better, cause they're doing some kind of AI back button coming very soon, so don't worry.
Yeah, I, I doubt it.
Oh, man, AI is good.
AI is going to give us a lot of anti patterns, isn't it?
Already has.
Once they put AI on it. It's gonna get all better.
Oh, man!
I think AI is gonna be big. But it's also gonna be.
It'll make changes. It'll make drastic changes to society.
It's not gonna be as big as some people think.
Yeah, the the biggest, the biggest problem I see. I've been playing with chat. Jpt a lot.
It takes more work to de hallucinate.
Then the time you save, and asking the question and getting the answer.
Sometimes. Yeah.
Here's I put the link to what I.
The hallucination I was talking about earlier in the chat.
Yeah, I'm not sure about math in charge. It's I. I think it's language model. In the 1st there is like a specific math models that.
Should do better.
So probably in the future they will have Gpt called the.
Hmm.
Specific model, like they, they have function call. And now, so, yeah.
Well, you know, chat Gpt just looks for an average answer.
From all the writings, and we know everyone's bad. So.
That sounds about right.
Just grabs the average bad answer.
I'm curious. Where my book on naming things did I give it to somebody.
I did find my old James Copeland.
Advanced c plus plus.
It's funny.
Lee, you want to do a bookend here.
Turn off the recording.
I can certainly do that if we're.
Anybody else.
I I think.
Alright. This has been the St. Louis users group.
July 18, th 2020.
The Speaker as our longtime member, and Evie San Francisco Craig Buch.
Who is still doing his tech thing. He still hangs around, and he's got some interesting stuff to talk about.
His presentation was on.
Software patterns, large and small, and how they relate to building architecture.