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:

Video CS169 v13 w3l1s8:

Disabling CSS styles in Safari:
https://support.apple.com/en-au/guide/safari-developer/dev39df999c1/mac

Quiz (Slide 20):

Chapter 2.4 (Architecture of SasS)

Topics covered: 3-tier architecture

Video CS169 v13 w3l1s9:

Examples for PHP embedded in HTML (server-side):
https://www.ntchosting.com/encyclopedia/scripting-and-programming/php/php-in/

Examples for JavaScript embedded in HTML (client-side):
https://www.w3schools.com/js/js_whereto.asp

Heroku Dynos:
https://www.heroku.com/dynos

Quiz (Slide 31):

Info:
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.”
https://en.wikipedia.org/wiki/Shared-nothing_architecture

Chapter 2.5 (MVC)

Topics covered: model-view-controller

Video CS169 v13 w3l2s1:

Example for Sinatra:
https://en.wikipedia.org/wiki/Sinatra_(software)

Quiz (MCV):

Chapter 2.6 (Models)

Topics covered: models, databases, and active record

Video 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.”
https://en.wikipedia.org/wiki/Active_record_pattern

Quiz (Model):

Chapter 2.7 (Controllers)

Topics covered: controllers, routes, and REST

Video CS169 v13 w3l2s5:

Guide on “Rails Routing from the Outside In”:
https://guides.rubyonrails.org/routing.html

Quiz (RESTful routes):

Chapter 2.8 (Views)

Topics covered: template views, Haml

Video CS169 v13 w3l2s7:

Ruby Closures 101:
https://medium.com/swlh/ruby-closures-101-e130d62b7fa0

Transform View:
https://www.martinfowler.com/eaaCatalog/transformView.html

Haml Tutorial:
http://haml.info/tutorial.html

Quiz (Rails views):

Chapter 2.9-2.10 (Summary)

Topics covered: architecture, patterns, scalability

Video CS169 v13 w3l2s9:

Top 15 famous websites built with Ruby on Rails:
https://prograils.com/posts/top-10-famous-sites-built-with-ruby-on-rails

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:

Statically typed vs. dynamically typed programming languages:
https://stackoverflow.com/q/1517582

Quiz (Ruby regex):

Chapter 3.2-3.3 (Objects and Method Calls)

Topics covered: objects, methods, “poetry mode”

Video CS169 v13 w2l2s1:

Quiz (Ruby methods):

Chapter 3.4 (Ruby OOP)

Topics covered: classes, inheritance, instance variables, attr_accessor

Video CS169 v13 w2l2s3:

Quiz (Instance methods):

Chapter 3.5 (Metaprogramming)

Topics covered: metaprogramming, reflection

Video CS169 v13 w2l2s5:

Quiz (Metaprogramming):

Chapter 3.6 (Iterators and Functional Idioms)

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

Video CS169 v13 w2l2s7:

Lamdba expressions in Ruby:
https://www.rubymonk.com/learning/books/1-ruby-primer/chapters/34-lambdas-and-blocks-in-ruby/lessons/77-lambdas-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:
https://stackoverflow.com/q/5018633

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:

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’.”
https://stackoverflow.com/a/4205163

Difference between Ruby classes and modules:
https://stackoverflow.com/q/151505

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.”
https://stackoverflow.com/a/827656

Quiz (Ruby modules):

Composition vs. Inheritance: How to Choose?
https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose

Chapter 3.8 (Yield)

Topics covered: blocks, iterators

Video CS169 v13 w3l1s1:

Ruby blocks and yield statement:
https://bowenli86.github.io/2016/07/08/ruby/Ruby-Ruby-blocks-and-yield-statement/

The Ultimate Guide to Blocks, Procs & Lambdas:
https://www.rubyguides.com/2016/02/ruby-procs-and-lambdas/

---

Chapter 7.1 (BDD and User Stories)

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

Video CS169 v13 w4l1s3:

Verification vs. Validation:
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”
http://softwaretestingfundamentals.com/verification-vs-validation/

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?” https://www.atlassian.com/agile/project-management/user-stories

Spike:
“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.” http://agiledictionary.com/209/spike/

Epic:
“Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).” https://www.atlassian.com/agile/project-management/epics-stories-themes

5 Whys:
https://en.wikipedia.org/wiki/Five_whys

Quiz (BDD):

Chapter 7.2 (Points and Velocity)

Topics covered: story points, velocity

Video 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.” https://www.atlassian.com/agile/project-management/estimation

Velocity:
“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.” https://www.agilealliance.org/glossary/velocity/

Agile estimation techniques:

• Estimation as a team effort: https://www.atlassian.com/agile/project-management/estimation

• “Planning Poker” http://www.agileadvice.com/wp-content/uploads/2012/06/The-Planning-Game.pdf

• “The Bucket System” http://www.agileadvice.com/wp-content/uploads/2013/07/H10-Estimation-The-Bucket-System.pdf

Quiz (User Points and Velocity):

Chapter 7.3 (SMART User Stories)

Topics covered: SMART user stories

Video CS169 v13 w4l1s7:

Quiz (SMART User Stories):

Chapter 7.4 (UI Design)

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

Video CS169 v13 w4l1s9:

Quiz (UI Design):

Chapter 7.5 (Cucumber)

Topics covered: Cucumber, Capybara

Video CS169 v13 w5l1s9:

Quiz (Cucumber):

Video CS169 v13 w5l1s11:

Chapter 7.9 (Scenarios)

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

Video CS169 v13 w5l2s2:

Happy paths vs. sad paths:
https://en.wikipedia.org/wiki/Happy_path “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.” https://en.wikipedia.org/wiki/Happy_path

Quiz (Explicit vs. Implicit Scenarios):

Chapter 7.10-7.12 (Fallacies & Pitfalls)

Topics covered: fallacies & pitfalls, BDD pros & cons

Video CS169 v13 w5l2s4:

Quiz (Low-Fi UI Design and BDD):

Video CS169 v13 w5l2s6: