Berkeley CS169 - Software Engineering (Lecture Notes)

Recently finished up all the lectures for the Berkeley Webcast of CS 169 - Software Engineering.  This course focuses on building Software as a Service (SaaS) applications in Ruby on Rails.  Although I don't anticipate the need to know a lot of RoR for work, the concepts discussed in the course were extremely valuable and I would definitely recommend them to anyone looking to learn about professional software development.  Some key topics of interest:

• Agile project development
• Testing and refactoring
• Design patterns
• CI and deployment

These are my notes on the lectures, which are really more like a detailed table of contents so that I could easily reference the lectures if I wanted to revisit a topic.  I figure the course website has all the slides and reference to the book, so recreating that content seemed a bit silly...

Relevant links:

Youtube playlist: [Edit: Berkeley pulled theirs, so this is my mirror]
https://www.youtube.com/playlist?list=PLVEFwJhglgHJQEQ6RjMMjcclix94gp1k2

Berkeley Webcast (basically the same thing as above, though it has mysteiously stopped working for me at times because of complaints about Flash version...)
http://webcast.berkeley.edu/playlist#c,d,Computer_Science,-XXv-cvA_iCfQHHS7rxlfHFsU4aQW1IF

Course website:
https://sites.google.com/site/ucbsaas/

EdX site for course (you'll have to create a login if you don't have one):
https://edge.edx.org/courses/BerkeleyX/CS169/Spring2015/courseware/cd31ed4130dd4343ab776a055ca75623/8255f69693c1442693d7894f227a27b0/1

There is also a book to accompany the class, which I'm still waiting to come (work bought it for me, woot!). On Amazon: Engineering Software as a Service: An Agile Approach Using Cloud Computing

THE NOTES

What is missing from dev’s skills:

• Legacy code
• Working with non-technical customers
• Testing

Advantage of service oriented architecture.

Lecture 2 talks about Agile and Scrum. 

Mentions that Scrum master and Product Owner should be team members and roles should be rotated.

SMART user stories:

• Specific
• Measurable
• Achievable
• Relevant
• Timeboxed

LoFI UI Sketches, advantages over pretty wireframes

• Less intimidating to non-technical customers
• Customers more likely to suggest change
• Customers more likely to focus on interaction 

Code smells, acronym SOFA, tool is reek:

• Is it Short
• Does it do One thing
• Does it have Few arguments
• Is it a consistent level of Abstraction

ABC complexity, tool flog:

• count Assignments, Branches, Conditions
• Score = Square root (A2  + B2  + C2 )
• NIST: < 20/method

Active Record - ORM for Rails 

• subclass from ActiveRecord::Base
• CRUD operations
• Convention over configuration
• Objects in memory, must call save to persist to DB

Debugging is a fact of life RASP

• Read the error message
• Ask a colleague an informed question
• Search using StackOverflow, search engine, etc.
• Post on StackOverflow, forums, etc.

Pitfalls

• Avoid fat controllers. Functionality should be in model
• Avoid fat views… functionality should be in model

2/12/2015 Lecture

• validation and filters in Ruby
• Relation to aspect oriented programming
• The idea is to put the logic for crosscutting concerns in one place
• Associations (relationships between objects)
• belongs to, has many, :through

2/17/2015 Lecture

• Cucumber and Capybara
• User Story, Feature, Scenario, and Step definitions 
• Given, When, Then, And, and But
• Live coding demo of Cuke step defs

2/19/2015 Lecture

• Guest speakers
• Testing is hugely valuable

2/24/2015 Lecture

• RSpec - Unit testing framework similar to JUnit
• Unit tests should be FIRST
• Fast
• Independent - should be able to run any subset, any order
• Repeatable
• Self-checking 
• Timely - tests should be written in close temporal proximity to code (ideally, before code i.e. TDD)
• Unit test - models (RSpec)
• Functional tests - Controllers (Rspec)
• Integration tests - Views (Cucumber) 
• .should_receive(a).with(b) creates a mock object (spy)
• Joel Spolsky guest speaker

2/26/2015 Lecture

• Mocks and stubs
• assigns(), response()
• Kyle says something clever at 33:00 but I can’t hear…
• Same material covered in Lecture 10 of Fall 2013
• look out for mock trainwrecks

3/3/2015 Lecture

• Code review and Design review
• How to run an effective meeting
• Start and Stop on time
• Agenda created in advance; no agenda, no meeting
• Minutes recorded
• One speaker at a time
• Send material in advance
• Action items as end of meeting, assign tasks
• Set date and time of next meeting.
• Start next meeting by reviewing minutes and action items
• Git - branch per feature
• Debugging - 
• Report
• Reproduce
• Regression Test
• Repair
• Release the fix

3/5/2015 Lecture

• Continuous Integration and Deployment
• Legacy code and refactoring
• Establishing ground truth about what works today
• black box, integration level tests
• characterization tests

3/10/2015

• Method level refactoring
• Fixing the Zune bricking bug
• Refactoring fallacies and pitfalls
• Power Cucumber (Capybara)
• tabular data
• has_css and has_xpath
• passing state between steps in a scenarios
• timecop (redefining time.now)

3/17/2015

• Patterns, Antipatterns, SOLID
• Separate the things that change from the things that stay the same
• Architectural Patterns: MVC; Pipe and Filter (compiler, Unix pipeline); Event-based (interactive game); Layering (SaaS technology stack) 
• GoF Patterns: structural, creational, behavioral
• Antipattern:
• code that should follow a pattern and doesn’t
• accumulated technical debt
• Symptoms:
• Viscosity: easier to hack than do right
• Immobility (can’t DRY out functionality)
• Needless repetition
• Needless complexity from generality (YAGNI)
• Discuss SOLID and Patterns...
• Strategy and Template pattern for OCP
• “Prefer composition over inheritance”
• Decorator Pattern
• Liskov - Square/Rect problem
• Demeter Principle
• only talk to your friends, not strangers
• Can call methods on:
• yourself
• your own instance methods, but not their results
• symptom: inappropriate intimacy… a.b.c.d == x
• mock trainwreck in testing
• replace method with delegation

3/31/2015

• Visitor and Observer patterns
• Dependency Injection (Inversion)
• Adapter and Facade patterns
• Null objects
• Proxy pattern
• Composite Pattern
• Plan and Document perspective on Design Patterns

4/2/2015

• Fun stuff
• Github DDOS attack
• 10 Women who changed CS
• Favorite April Fools tech hack
• Armando’s thoughts on node.js
• Heilmeier questions:
• Problem you are tackling
• current state of the art
• If you succeed, who will care
• what have you already accomplished
• what does “success” look like

4/7/2015

• APIs and Single Page Applications
• API-ify the Hangperson game
• React frontend js framework

4/9/2015

• Code fixup clinic
• Common problems:
• Long controller methods
• Passing data between Ruby and JS
• Don’t use javascript_tag - not cachable
• Do use data-xxx attributes or content_tag
• Metaprogramming to DRY stuff out
• Not using temp variables

4/14/2015

• Code clinic part 2

4/16/2015

• Deployment 
• Discussion of PaaS
• Discussion of response time in web applications
• Scalability - more users doesn’t increase cost per user
• Feature flags and upgrades

4/21/2015

• Monitoring
• In development (Profiling)
• Internal and external monitoring
• use of cucumber and new relic to test performance
• stress/load testing
• Caching 
• Queries and Indices
• table scans are bad… indices can make lookup almost O(1)
• indices can make updates more expensive
• use index on FK, columns in where, columns on which you sort
• Security
• Fallacies, Pitfalls, and concluding remarks
• Don’t optimize prematurely or without measurement
• Database is hard to scale; use caching and optimize queries
• All sites are targets, scrub user input, make backups

4/28/2015

• Poster previews (class projects)

4/30/2015

• Retrospective