Skip to content

Instantly share code, notes, and snippets.

@grahamjenson

grahamjenson/README.md

Last active August 29, 2015 13:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save grahamjenson/9586856 to your computer and use it in GitHub Desktop.
Save grahamjenson/9586856 to your computer and use it in GitHub Desktop.
Download ZIP
Fourth 159.707 Lecture
Raw
README.md

Fourth 159.707 lecture

Raw
index.html
<html>
<head>
<meta charset="utf-8">
<link rel="stylesheet" media="screen" href="https://rawgithub.com/imakewebthings/deck.js/master/extensions/goto/deck.goto.css">
<link rel="stylesheet" media="screen" href="https://rawgithub.com/imakewebthings/deck.js/master/extensions/menu/deck.menu.css">
<link rel="stylesheet" media="screen" href="https://rawgithub.com/imakewebthings/deck.js/master/extensions/navigation/deck.navigation.css">
<link rel="stylesheet" media="screen" href="https://rawgithub.com/imakewebthings/deck.js/master/extensions/status/deck.status.css">
<link rel="stylesheet" media="screen" href="https://rawgithub.com/imakewebthings/deck.js/master/extensions/scale/deck.scale.css">
<link rel="stylesheet" media="screen" href="https://rawgithub.com/imakewebthings/deck.js/master/themes/style/swiss.css">
<link rel="stylesheet" media="screen" href="https://rawgithub.com/isagalaev/highlight.js/master/src/styles/monokai_sublime.css">
<link rel="stylesheet" href="https://rawgithub.com/imakewebthings/deck.js/master/core/deck.core.css">
<link rel="stylesheet" media="screen" href="https://rawgithub.com/imakewebthings/deck.js/master/themes/transition/horizontal-slide.css">
<script src='http://code.jquery.com/jquery-2.0.3.js'></script>
<script src='http://code.jquery.com/ui/1.10.3/jquery-ui.js'></script>
<script src="https://rawgithub.com/imakewebthings/deck.js/master/modernizr.custom.js"></script>
<script src="https://rawgithub.com/imakewebthings/deck.js/master/core/deck.core.js"></script>
<script src="https://rawgithub.com/imakewebthings/deck.js/master/extensions/menu/deck.menu.js"></script>
<script src="https://rawgithub.com/imakewebthings/deck.js/master/extensions/goto/deck.goto.js"></script>
<script src="https://rawgithub.com/imakewebthings/deck.js/master/extensions/status/deck.status.js"></script>
<script src="https://rawgithub.com/imakewebthings/deck.js/master/extensions/navigation/deck.navigation.js"></script>
<script src="https://rawgithub.com/imakewebthings/deck.js/master/extensions/scale/deck.scale.js"></script>
<script src="http://coffeescript.org/extras/coffee-script.js"></script>
<script src="http://yandex.st/highlightjs/8.0/highlight.min.js"></script>
<script src="https://rawgithub.com/coreyti/showdown/master/src/showdown.js"></script>
<script src="https://rawgithub.com/coreyti/showdown/master/src/extensions/github.js"></script>
<link href='http://fonts.googleapis.com/css?family=Lato' rel='stylesheet' type='text/css' />
<style>
pre {
border: 0px;
}
pre code {
font-size: .6em;
}
p {
font-size: 1.2em;
}
blockquote {
font-size: 1.2em;
}
.body {
font-family: "Lato", sans-serif;
color: #5d5d5d; }
.pull-right {
float: right;
margin: 10px; }
.pull-left {
float: left;
margin: 10px; }
</style>
</head>
<body>
<div class="deck-container">
<!-- Begin slides. Just make elements with a class of slide. -->
<section class='slide no-md'>
<h1>
159.707
<br>
<span style="font-size: .2em; color: #c00;">Design Patterns in Modern Web Applications (coffeescript, backbone, node.js) </span>
</h1>
</section>
<section class='slide no-md'>
<h2>159.707 Advanced Software Design and Construction</h2>
<ul>
<li><strike>25 Feb: Component Evolution (Graham’s thesis) and recent industry experience </strike></li>
<li><strike>4 March: Dynamic typing case study (Ruby), Convention over Configuration (RubyOnRails)</strike></li>
<li><strike>11 March: Design Patterns in Modern Web Applications (coffeescript, backbone, node.js)</strike></li>
<li>18 March: Architecture, refurbishing/replacing legacy systems </li>
<li> 1 April: Agile Methodologies (SCRUM , Kanban) </li>
<li> 8 April: Data visualisation with D3 </li>
</ul>
</section>
<section class='slide no-md'>
<h2>Today</h2>
<ul>
<li>Software Architecture</li>
<li>Enterprise Systems</li>
<li>Patterns</li>
<li>Legacy Systems</li>
</ul>
</section>
<section class='slide'>
#But First
</section>
<section class='slide'>
##Assignment
1. Ruby on Rails application
2. Deployed to heroku
3. Services layer (JSON API)
4. Some backbone.js frontend (does not have to be entirely backbone)
Code must be available on Github, (if you ask github will let students have private repositories).
A basic non-trivial site will get you a decent mark (there are loads of "Rails Blog in 10 minutes" tutorials out there)
Bonus points for
1. Interesting
2. Useful
3. Google Analytics Integration showing more than 1000 unique visitors
</section>
<section class='slide'>
#Software Architecture
</section>
<section class='slide'>
##Software Architecture
* Patterns of Enterprise Application Architecture -- Martin Fowler
* Ruby Rogues
</section>
<section class='slide no-md'>
<h2>What is Software Architecture?</h2>
<img src="https://maorigeek.s3.amazonaws.com/uploads/fowlersa.png_1394619071.jpg" alt="" title="" style="
width: 50%;
">
</section>
<section class='slide'>
##What is Software Architecture?
> architecture boils down to the important stuff - whatever that is.
Decisions that:
> developers wish they could get right early on because they're perceived as hard to change.
Decisions that caused you to say "it will require a major change to the system"
</section>
<section class='slide'>
##What is Software Architecture?
Decisions like
1. persistency patterns
2. how objects will interact with remote systems
3. how domain logic is seperated in the system
These will effect:
1. performance
2. maintenance
3. design
</section>
<section class='slide'>
##What is Software Architecture?
It is important to look for architectural decisions, and spend time considering their implications
</section>
<section class='slide'>
##What is Software Architecture?
Some people think Software Architecture is 'Waterfall-ish', but Uncle Bob says:
> there has been a feeling in the Agile community since about '99, that "arcitecture is irrelvent, we dont need to do arcitecture, all we need to do is write lots of tests, and do lots of stories, and do quick iterations and the code will assemble itself magically" and this has always been horse shit!
</section>
<section class='slide'>
##When to make Architecture Decisions?
Fowler states that architectural decisions should be made towards the beginning of the project
Others, like Kent Beck and Uncle Bob Martin, say you should defer making architectural decisions until they are absolutly needed.
</section>
<section class='slide'>
##When to make Architecture Decisions?
Fowler argues that you may have a broad understanding of the domain from experience, and you can make architetural decisions early in a project, with the understanding that it might be necessary to change them later.
</section>
<section class='slide'>
##When to make Architecture Decisions?
Uncle Bob states that decisions like which framework or database to use are merely details of an application and should not dictate the way in which it is designed.
</section>
<section class='slide'>
##When to make Architecture Decisions?
Uncle Bob states that decisions like which framework or database to use are merely details of an application and should not dictate the way in which it is designed.
> A good arcitecture allows major decisions to be deferred
</section>
<section class='slide'>
##When to make Architecture Decisions?
This battle between **deferring** and **upfront** architeture.
The first decision in most projects is what framework to use (Ruby with Rails or Sinatra, Node.js with Hapi or Express), which:
* according to Uncle Bob, the decision should be deferred until it is necessary to be made, with the understanding that a price may need to be payed for adapting the existing project to a framework
* according to Fowler, existing experience should be used to make the decision now, with the understanding that at some point a price may need to be paid for changing the framework
</section>
<section class='slide'>
##When to make Architecture Decisions?
Jim Coplien in a discussion with Uncle Bob gave a middle ground where you should:
> capitalize on what you know [and] take some hard decisions up front, because that will make the rest of the decisions easier later.
</section>
<section class='slide'>
#Enterprise Systems
</section>
<section class='slide'>
##Enterprise Systems
> enterprise applications often have complex data -- and lots of it -- to work on, together with business rules that fail all tests of logical reasoning. -- Martin Fowler
They are difficult not only because they can be technically complex, but because the rules you are given are not made with your consideration.
</section>
<section class='slide'>
##Enterprise Systems
> business rules are just given to you, and without major political effort there's nothing you can do to change them. -- Martin Fowler
Most of the time you will be supporting the business to create/sell/market the actual product. Most of the time the product is not what you create.
</section>
<section class='slide'>
##Enterprise Systems
> organise the business logic as effectily as you can, because the only certain thing is that the logic will change over time -- Martin Fowler
Most of the time you will be supporting the business to create/sell/market the actual product. Most of the time the product is not what you create.
</section>
<section class='slide'>
#Patterns
</section>
<section class='slide'>
##Patterns
> Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million time over, without doing it the same way twice. [Alexander et al.]
</section>
<section class='slide'>
##Patterns
> Patterns aren't original ideas; they're very much observations of what happens in the field.
</section>
<section class='slide'>
##Patterns
> [Patterns] are a starting point, not a final destination.
</section>
<section class='slide'>
##Patterns: Layers
1. Understand a layer as a whole, without knowing about other layers
1. Substitute layers with different implementations
1. Minimise dependence between layers
1. Standardisation communication
1. Re-use of lower layers
</section>
<section class='slide'>
##Patterns: Layers
1. Layers cannot encapsulate all things well. Cascading changes, if a database changes it may impact the UI.
1. Lost performance at each layer.
1. Designing the architecture of the layers.
</section>
<section class='slide'>
##Patterns: Layers
Three principle layers:
1. Presentation
1. Domain
1. Data source
There should be no dependance from domain or data source on presentation.
</section>
<section class='slide'>
##Patterns: Service Layer
![](http://martinfowler.com/eaaCatalog/ServiceLayerSketch.gif)
1. Presentation
1. Service
1. Domain
1. Data source
The Boundary between the presentation layer and the domain model.
</section>
<section class='slide'>
##Patterns: Domain Model
Mapping the problem domain to a model
A very OO way of looking at this problem
* We build a model that is organised around nouns in the domain
* The validations and logic will be placed in the domain model.
> when you're used to Domain Model you're infected for life
</section>
<section class='slide'>
##Patterns: Domain Model
The problem:
You will have to deal with the persistance mapping
The more complex the domain model, the more complex the mapping.
</section>
<section class='slide'>
##Patterns: Domain to Data-source
The choice in how your domain talks to the database is far-reaching and difficult to refactor.
* **Table Data Gateway** is where you have an object for each table
* **Row Data Gateway** is where you have an object for each row in a table
* **Active record** is where you start with Row Data Gateway and add domain logic to the class
* **Data Mapper** is where a persistance model seperated the domain model from the data-source
As the domain logic gets more complicated, Active record breaks down.
> As the domain logic gets feisty, you want to be able to test it without having to talk to your database all the time.
*Ruby on Rails uses Active Record*
</section>
<section class='slide'>
##Patterns: Domain Model Inheritance
* **Single Table Inheritance** (STI): one table for a class heirarchy
* **Concrete Table Inheritance**: one table per concrete class in the heirarchy
* **Class Table Inheritance**: one table per calss in heirarchy (including abstract classes)
</section>
<section class='slide'>
##Single Table Inheritance
![](http://www.martinfowler.com/eaaCatalog/singleInheritanceTableSketch.gif)
</section>
<section class='slide'>
##Concrete Table Inheritance
![](http://martinfowler.com/eaaCatalog/leafInheritanceTableSketch.gif)
</section>
<section class='slide'>
##Class Table Inheritance
![](http://martinfowler.com/eaaCatalog/classInheritanceTableSketch.gif)
</section>
<section class='slide'>
##Patterns: Model View Controller
Model View Controller - arose with User Interface pattern, it ensures that the models are completely seperate from the presentation layer.
</section>
<section class='slide'>
##Patterns: View Patterns
* **Transform View** -- like XSLT where you transform data into view
* **Template View** -- Embed markers into the page where dynamic elements neep to go. This lets you put the full programming language to work in the view.
</section>
<section class='slide'>
##Patterns: Concurrency
Enterprise software can for the most part get away with a naive view of concurrency because it is very transactional based.
> few branches of software development use concurrency more yet worry about it less.
</section>
<section class='slide'>
##Patterns: Concurrency
Some useful terms
1. **request** corrosponds to a single call
2. **transaction** pulls several requests together for a single call
2. **session** is a long running interaction between client and server
3. **process** a heavyweight, execution context that provides a lot of isolation
4. **thread** light weight active agent, many threads can be running in a single process. Threads can share memory which can lead to concurrency problems
5. **isolated thread** a thread that does not share memory
</section>
<section class='slide'>
##Patterns: Concurrency
* **Isolation** - partition the data so that a piece can only be accessed by one active agent at a time.
* **Immutability** - define pieces of the data that will not be modified, or at least not modified most of the time. Or seperate the piece into a read only state where each agent has a copy of the data source.
</section>
<section class='slide'>
##Patterns: Concurrency
**Transactions** are the primary tool for handling concurrency in enterprise applications. A transaction is a bounded sequence of work, it must be an all or nothing either success or fail.
</section>
<section class='slide'>
##Patterns: Concurrency
Software transactions are **ACID**
* Atomicity - if succeeds moves forward, else all rolls back
* Consistent - no corruption
* Isolation - reults not visible to other transactions
* Durability - the change must survive the end of the transaction, or end of program (crash).
</section>
<section class='slide'>
##Patterns: Distributed Objects
> **First Law of Distributed Object Design:** Don't distribute your objects!
When you have to distribute objects there are patterns like:
*Remote Facade* whose sole role is to provide a coarse-grained objects non-transparently so developers know the cost they are paying.
*Data-transfer object* is an object that is serialized then reconstituted on the other side.
Hiding an object being remote hides the cost that a developer pays when using it. The goal of these patterns is to reduce the number of remote calls being made, as this is the highest price to pay.
</section>
<section class='slide'>
##Patterns: Conclusion
>Architecture refactoring is hard, and we're still ignorant of its cost, but it isnt impossible.
1. Start at the domain layer
2. Move to the Data Source Layer
3. Finsih with the Presentation Layer
</section>
<section class='slide'>
#Legacy Systems
</section>
<section class='slide'>
##Legacy Systems
Systems that are not worth upgrading, so they are either used to their deaths, or replaced entirly.
</section>
<section class='slide'>
##Legacy Systems
Replacing these is my current job
</section>
<section class='slide'>
##Legacy Systems
My Current Environment
</section>
<section class='slide'>
##Legacy Systems
Challenges
* Busniness dictates pace
* Heavy dependence in the organisation
* Limited development to adapt
* Third Party dependance (contractual obligations)
</section>
<section class='slide'>
##Legacy Systems
Challenges
* Busniness dictates pace
* Heavy dependence in the organisation
* Limited development to adapt
* Third Party dependance (contractual obligations)
</section>
<section class="slide">
<h2>Graham Jenson</h2>
<ul>
<li>Twitter: <strong>@grahamjenson</strong> </li>
<li><strong>Blog:</strong> http://maori.geek.nz/blog</li>
</ul>
</div>
</section>
<!-- deck.navigation snippet -->
<div aria-role="navigation">
<a href="#" class="deck-prev-link" title="Previous">&#8592;</a>
<a href="#" class="deck-next-link" title="Next">&#8594;</a>
</div>
<!-- deck.status snippet -->
<p class="deck-status" aria-role="status">
<span class="deck-status-current"></span>
/
<span class="deck-status-total"></span>
</p>
<!-- deck.goto snippet -->
<form action="." method="get" class="goto-form">
<label for="goto-slide">Go to slide:</label>
<input type="text" name="slidenum" id="goto-slide" list="goto-datalist">
<datalist id="goto-datalist"></datalist>
<input type="submit" value="Go">
</form>
<!-- End extension snippets. -->
</div>
<script>
$(function() {
hljs.initHighlightingOnLoad();
$.deck('.slide');
});
(function($, deck, undefined) {
var $d = $(document);
var converter = new Showdown.converter({ extensions: ['github'] });
$d.bind('deck.init', function() {
$.each($.deck("getSlides"), function(index, value) {
var cssClass = value.attr('class');
// Prevent slides marked with no-md css class to be interpreted as markdown
if (!cssClass || cssClass.indexOf('no-md') < 0) {
value.html(converter.makeHtml(value.text()));
}
});
});
})(jQuery, 'deck');
</script>
</body>
</html>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment