Tip:
Highlight text to annotate it
X
Okay, so let's wrap up kind of what we've seen, not just the summary of the topics,
but you know kind of let's take a step backwards or upwards or adventure wards
and think about some of the implications so kind of the big picture what we saw,
we've seen a lot of technology buzzwords right and a lot of different protocols and
technologies... We talked but really you can kind of tie all of them back to this
module you can control architecture. The controller, the thing that deals with user
actions. Well, we saw that Uri?s are the ways that actions are expressed. Http is
the way that communication happens between the client and the server. It depends on
tcp/ip, a venerable set of protocols that lets us pretend we're just exchanging
strings and that having restful actions and restful routs is a nice structure and
mechanism, especially for making your app friendly to interoperating and service
oriented environment. Views we saw that the most common way to express them was
with HTML and using CSS for styling. We didn't talk about XML and X-Path because
there wasn't going to be time in lecture, but I'm going to find a time to get that
topic in, especially X-Path, which is like the regular expression of the XML world.
And then for models, we talked about databases. We'll talk about migrations
next time, which is how you make changes, when you want to add a new kind of thing
to your app. How do you change the database, to do that? And we talked about
CRUD, which are sort of the four basic operations, on persistent models, that any
app has to know how to do. So let's talk about a couple of fallacies and pitfalls
that with, with the benefit of our background. Okay, let me pause in the
recording. I should have said in the administrative, don't forget. That there
is a quiz next Tuesday for first thirty minutes. So that means starting at
eleven:10 going through eleven:40 not starting at one. People get here to thirty
minutes after that. And that means that Monday's section would be an excellent
time. >> To ask questions about anything up to this point. The quiz will cover
everything up to the end of today, but obviously it won't cover the stuff that
we're gonna do after the quiz on Tuesday. That'd be rude. >> [laugh] >> And it'll
generally be sort of short answer and multiple choice kind of questions. So you,
you're not gonna have to write out a lot of stuff. You will not be writing limited
in terms of finishing the quiz. Closed book, closed notes, closed everything, but
believe me if you've been keeping up with the lectures and doing some of the
readings, shouldn't be a problem. Yeah? >> [inaudible] It will if it includes any
coding at all, if it includes any coding at all. If it includes coding, [laugh],
it'll be like filling in a blank. Like maybe writing a line of code. Right, it's
a quiz not programming. The coding we're saving more of that for the hallmarks and
the projects. Okay. Audio pause. In 2008, there was a sort of meme circulating about
how rails doesn't scale and part of it came from the fact that Twitter Was having
a number of problems with availability. Twitter was built on rails. It was kind of
one of the poster children for you know, rails as a productive framework. But I
think as we've now seen and, and you know, you guys now understand, scalability is
not a matter of which language or framework are used. It's an architectural
concern. And in fact, the stateless tiers of the three tier architecture scale
really well, especially with cloud computing. You just have to worry about,
you know, how many machines do we need? Is it a matter of ten or twenty machines for
a given number of users? But that's really a matter of efficiency. What we did see
though. Is that relational data bases really don't scale and as a result,
there's been a number of solutions that combined relational with non relational
storage. If you've seen the term no sequel. No sequel has become this catch
all term for relational data bases are terrible because they don't scale. We're
gonna start everything over again. And, never mind the fact that you know, for 40
years, relational database have solved these important problems. We can do better
because we're web 2.0. As it turns out, the truth lies somewhere in between. And
most large sites use a combination of relational or sequel databases and
non-relational storage. As we mentioned, Data Mapper is a way that you can impose
some order on how your storage works even if you're not using a relational database.
But the idea of scalability is much more complex than just saying oh, your language
or your framework doesn't scale. Framework, apps, and design patterns.
We've already seen a number of examples of different design patterns. But keep in
mind that in 1995 or so, when the web was just getting big, it was like the Wild
West. The biggest software sites the biggest staff sites, at that time ran on
mini-computers. They didn't run on the cloud. The three tier architecture wasn't
really a thing. And the idea that as more people build more sites. They sort of
extracted patterns from their experience. And, they try to capture those patterns in
useful frameworks like rails. In fact, rails itself. Didn't start out life as a
frame work. It started out as an application. And rails was extracted from
the application because, it was believed that it will capture a lot of common
stuff. Despite all that evolution, I think its admirable that we have TCP IP suite
from 1969, a markup language based on'60s technology, browser still around that were
released in the nineties and web servers like [inaudible] that had been around
since about 1992, and in 2011 these thing can all work together so the power of API
is in, in well defined protocol, right. This is longevity, this is long lived or
long lasting software. Just to recap some of the examples of patterns that we've
seen along with some alternatives. Client server is how sass apps tend to be
structured on the web but peer to peer is another way to do it. We talked about the
shared method model with cloud computing, but until the mid 90s much more common was
symmetric multi-processor where it's like one large machine. Model to controller is
a way of organizing the entities that your app manipulates. But, you also saw page
controller, front controller. Are other ways to organize apps. That maybe for
simpler apps may be more appropriate. Active record is one way to map the models
back and forth between the data base. But, it takes advantage of some data base
features that might impede skill abilities. So, some people prefer data
mapper if they are able to structure their app in those terms. And the idea that we
can create services who's operations are restful, who's URIs encapsulate all the
information you need to do the request, is in my opinion a strictly better pattern
than this sort of anti-pattern of if the same URI can do different things,
depending on what you did previously and what the phase of the moon is. So kind of
my big message is, as you work on other apps outside this course and in real life,
you should always find yourself asking, what are the architectural alternatives?
What's the choice we didn't make? And are we sure that, that was the right thing to
do? So having said that, We're gonna spend the rest of the course. Doing the
[inaudible] controller. The way you guys have seen. I thought it would be. I would
be remiss in not giving you guys a little bit of perspective. So, to summarize.
Model D controller is a well-known architectural pattern for organizing sass
applications. Rails codifies this structure as Model D control and gives you
a lot of help in terms of sticking to the structure. For views we're gonna use
Hammel with embedded Ruby code. For models we're gonna use a relational database with
Active Record. And for controllers to tie them together, it's just simple Ruby code
that is, is tied via routes to the outside world. This is the view of the world
you're gonna have, but the goal of today was to show you that other views of the
world are possible.