Supplementary Material ESaS-I

Course book:
Engineering Software as a Service: An Agile Approach Using Cloud Computing

Chapters 2.1-2.3 (Foundations)

Topics covered: Client-server, TCP/IP, HTML/CSS

Video CS169 v13 w3l1s7:
CS169 v13 w3l1s7

Video CS169 v13 w3l1s8:
CS169 v13 w3l1s8

Disabling CSS styles in Safari:

Quiz (Slide 20):
Quiz (Slide 20)

Chapter 2.4 (Architecture of SasS)

Topics covered: 3-tier architecture

Video CS169 v13 w3l1s9:
CS169 v13 w3l1s9

Examples for PHP embedded in HTML (server-side):

Examples for JavaScript embedded in HTML (client-side):

Heroku Dynos:

Quiz (Slide 31):
Quiz (Slide 31)

WEBrick replaced by Puma

Definition shared-nothing architecture:
“A shared-nothing architecture (SN) is a distributed-computing architecture in which each update request is satisfied by a single node (processor/memory/storage unit). The intent is to eliminate contention among nodes. Nodes do not share (independently access) memory or storage. One alternative architecture is shared everything, in which requests are satisfied by arbitrary combinations of nodes. This may introduce contention, as multiple nodes may seek to update the same data at the same time.”

Chapter 2.5 (MVC)

Topics covered: model-view-controller

Video CS169 v13 w3l2s1:
CS169 v13 w3l2s1

Example for Sinatra:

Quiz (MCV):
Quiz (MCV)

Chapter 2.6 (Models)

Topics covered: models, databases, and active record

Video CS169 v13 w3l2s3:
CS169 v13 w3l2s3

Definition of Active Record:
“In software engineering, the active record pattern is an architectural pattern found in software that stores in-memory object data in relational databases. It was named by Martin Fowler in his 2003 book Patterns of Enterprise Application Architecture. The interface of an object conforming to this pattern would include functions such as Insert, Update, and Delete, plus properties that correspond more or less directly to the columns in the underlying database table. The active record pattern is an approach to accessing data in a database. A database table or view is wrapped into a class. Thus, an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database. When an object is updated, the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.”

Quiz (Model):
Quiz (MCV)

Chapter 2.7 (Controllers)

Topics covered: controllers, routes, and REST

Video CS169 v13 w3l2s5:
CS169 v13 w3l2s5

Guide on “Rails Routing from the Outside In”:

Quiz (RESTful routes):
Quiz (RESTful routes)

Chapter 2.8 (Views)

Topics covered: template views, Haml

Video CS169 v13 w3l2s7:
CS169 v13 w3l2s7

Ruby Closures 101:

Transform View:

Haml Tutorial:

Quiz (Rails views):
Quiz (Rails views)

Chapter 2.9-2.10 (Summary)

Topics covered: architecture, patterns, scalability

Video CS169 v13 w3l2s9:
CS169 v13 w3l2s9

Top 15 famous websites built with Ruby on Rails:

Quiz (SaaS scalability):
Quiz (SaaS scalability)

Chapter 3.1 (Introduction to Ruby)

Topics covered: naming conventions, variables, arrays, hashes, methods, comparisons, regular expressions, strings, symbols

Video CS169 v13 w2l1s10:
CS169 v13 w2l1s10

Statically typed vs. dynamically typed programming languages:

Quiz (Ruby regex):
Quiz (SaaS scalability)

Chapter 3.2-3.3 (Objects and Method Calls)

Topics covered: objects, methods, “poetry mode”

Video CS169 v13 w2l2s1:
CS169 v13 w2l2s1

Quiz (Ruby methods):
Quiz (Ruby methods)

Chapter 3.4 (Ruby OOP)

Topics covered: classes, inheritance, instance variables, attr_accessor

Video CS169 v13 w2l2s3:
CS169 v13 w2l2s3

Quiz (Instance methods):
Quiz (Instance variables)

Chapter 3.5 (Metaprogramming)

Topics covered: metaprogramming, reflection

Video CS169 v13 w2l2s5:
CS169 v13 w2l2s5

Quiz (Metaprogramming):
Quiz (Metaprogramming)

Chapter 3.6 (Iterators and Functional Idioms)

Topics covered: iterators, blocks, lambda expressions, other functional idioms

Video CS169 v13 w2l2s7:
CS169 v13 w2l2s7

Lamdba expressions in Ruby:
“the convention followed in Ruby is to use {} for single line lambdas and do ... end for lambdas that are longer than a single line.”

Difference between print and puts:

Quiz (Iterators and Functional Idioms):
Quiz (Iterators and Functional Idioms)

Chapter 3.7 (Mixins and Duck Typing)

Topics covered: duck typing, Ruby modules, mixins, spaceship operator, composition vs. inheritance

Video CS169 v13 w2l2s9:
CS169 v13 w2l2s9

Duck Typing:
“It is a term used in dynamic languages that do not have strong typing. The idea is that you don’t need a type in order to invoke an existing method on an object - if a method is defined on it, you can invoke it. The name comes from the phrase ‘If it looks like a duck and quacks like a duck, it’s a duck’.”

Difference between Ruby classes and modules:

The Spaceship Operator <=>:
“Basically instead of returning 1 (true) or 0 (false) depending on whether the arguments are equal or unequal, the spaceship operator will return 1, 0, or −1 depending on the value of the left argument relative to the right argument.”

Quiz (Ruby modules):
Quiz (Ruby modules)

Composition vs. Inheritance: How to Choose?

Chapter 3.8 (Yield)

Topics covered: blocks, iterators

Video CS169 v13 w3l1s1:
CS169 v13 w3l1s1

Ruby blocks and yield statement:

The Ultimate Guide to Blocks, Procs & Lambdas:

Chapter 7.1 (BDD and User Stories)

Topics covered: behavior-driven design, user stories, spikes

Video CS169 v13 w4l1s3:
CS169 v13 w4l1s3

Verification vs. Validation:
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”

User story:
“A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective. The purpose of a user story is articulate how a piece of work will deliver a particular value back to the customer. […] User stories are a few sentences in simple language that outline the desired outcome. They don’t go into detail. Requirements are added later, once agreed upon by the team. […] As a [persona], I [want to], [so that]. Breaking this down: As a [persona]: Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max. Wants to: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you’re missing the point. So that: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?”

“A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a ‘spike’, which is some work whose purpose is to provide the answer or solution.”

“Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).”

5 Whys:

Quiz (BDD):
Quiz (Iterators and Functional Idioms)

Chapter 7.2 (Points and Velocity)

Topics covered: story points, velocity

Video CS169 v13 w4l1s5:
CS169 v13 w4l1s5

Story points:
“Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to story points. Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. It may sound counter-intuitive, but that abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work.”

“At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.”

Agile estimation techniques:

Quiz (User Points and Velocity):
Quiz (Iterators and Functional Idioms)

Chapter 7.3 (SMART User Stories)

Topics covered: SMART user stories

Video CS169 v13 w4l1s7:
CS169 v13 w4l1s7

Quiz (SMART User Stories):
Quiz (SMART User Stories)

Chapter 7.4 (UI Design)

Topics covered: sketches, storyboards, lo-fi to HTML

Video CS169 v13 w4l1s9:
CS169 v13 w4l1s9

Quiz (UI Design):
Quiz (SMART User Stories)

Chapter 7.5 (Cucumber)

Topics covered: Cucumber, Capybara

Video CS169 v13 w5l1s9:
CS169 v13 w5l1s9

Quiz (Cucumber):
Quiz (Cucumber)

Video CS169 v13 w5l1s11:
CS169 v13 w5l1s11

Chapter 7.9 (Scenarios)

Topics covered: explicit vs. implicit scenarios, imperative vs. declarative scenarios

Video CS169 v13 w5l2s2:
CS169 v13 w5l2s2

Happy paths vs. sad paths: “A happy path is a default scenario featuring no exceptional or error conditions. For example, the happy path for a function validating credit card numbers would be where none of the validation rules raise an error, thus letting execution continue successfully to the end, generating a positive response.”

Quiz (Explicit vs. Implicit Scenarios):
Quiz (Explicit vs. Implicit Scenarios)

Chapter 7.10-7.12 (Fallacies & Pitfalls)

Topics covered: fallacies & pitfalls, BDD pros & cons

Video CS169 v13 w5l2s4:
CS169 v13 w5l2s4

Quiz (Low-Fi UI Design and BDD):
Quiz (Low-Fi UI Design and BDD)

Video CS169 v13 w5l2s6:
CS169 v13 w5l2s6