6-170-spring-2013-Software Studio

ruby on rails and html/css/js/jqurey

client-side programing

• JS, html, css, jquery, ajax
• react

manipulating the DOM

• traverse the elements
• add and delete elements
• modify properties(e.g position)
• registering events(against timers, buttons)
• making calls to webserver
• basic page load is synchronous
• when page arrives, often loads others(images, css, js)
• complications: caching, asynchronous calls, events

Modularity & dependences

• client --users-> service

Model-driven development

• request -> apache -> rails -> mysql -> rails -> apache -> response
• framework: routing, request data, data mapping, templates, validation, session state
  routing: client's name for op, developer's name for method

  Separation of concerns

  • Edsger Dijkstra
    let me try to explain to you, what to my staste is characteristic for all intelligent thinking. it is, that one is willing to study in depth an aspet of one's subject matter in isolation for the sake of own consistency, all the time knowing that one is occupying oneself only with one of the aspects... it is what I sometimes have called "the separation of concerns", thich, even if not porfectly possible, is yet the only avaliable technique for effective ordering of one's thoughts, that I know of.
  • semantis
    what things are there
    how are things classified
    how are things named
    what mutable
    what updates happen
    what queries are asked
    what invariants hold
  • representiation
    what information is stored
    which tables or classes
    what are the datatypes
    what columns? associations?
    what are the keys
    encoding generalizations
    optimize common queries
    integrity constraints

  operators & properties

  • cardinality of a set
  • union, intersection, differnce
  • domain and range
  • image
  • transoise
  • join
  • a relation R is symmetric
  • a relation R is reflexive
  • a relation R is transitive
  • a relation R is an equivalen
  • a relation R is a function
  • a relation R is injective

  Atoms

  concepts#

  • weak concepts
    hard to use
    a mess to maintain
    unreliable & buggy
  • strong concepts
    intuitive, predictable
    decoupling & localization
    more dependable
  • standard parctice
    to design something really well, you have to get it. You have to really grok what it's all about. It takes a passionate somthing, chew it up. not just quickly swallow it. Most people don't take the time to do that.

  thinking & sketching

  • simulating features
  • normal design practice
  • coping good ideas
  • evaluating products
  • user feedback
  • discarding failed designs
  • "refactoring"
  • focusing: what are the concepts
  • what properties do they have?

  instend: core concepts

  • what are the concepts
    that make it work
    that you need to grasp as a user
    that characterize this class of systems
    that characterize this class of systems
    that distinguish it from other system
  • identify the design problem

  mistake

  • not a stateful relation
  • should be split into multiple relations
  • relates > 2 atoms

  object model

  semantics

  • meaning = set of instances
  • an instance is an object diagram
  • non-instances
  • violate some rule in the object model

  statics & dynamics

  mutability

  object model + operations = labeled state transition system

  common mistake

  • bad sets
  • using subset for relationship role
  • reading subset as is-a

  relationship

  • naming
  • property
  • containment
  • association

  multiplicity

  • • one or more
  • • zero or more
  • ! exactly one
  • ? at most one
  • ommit =*

  idioms

  • Tony Hoare
    I gave desperate warnings against the obscurity, the complexity, and over-ambition of new design, but my warnings went unheeded. I conclude that there are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obviius deficiencies
  • well-established concepts
  • used in many apps and context

  format problem

  • a design problem to be solved

  solution

  • one or more concepts

  example

  • in well known apps

  refinements

  • more elaborate forms often used

  object model

  • concepts & relationships

  Every problem in computer science can be solved by introducing another level of indirection

  requst data

  • query strings from GETs
  • form data from POSTs

  web app = data conversion

  • update request -> request.form -> database table -> response -> show request

  data mapping

  • basic idea
    object in heap = row in table
  • object relational mapper
    generates database schema from class defs
    back up object methods with SQL updates/queries

  HTTP methos

  • GET : get a document from a server
  • POST: send a document to a server
  • PUT: updata a document at a server
  • DELETE: delete a document from a server

  request components

  • query string: for searching
  • body: for new version of page

  four function of persistent storage

  • CRUD: create, read, update, delete
  • SQL: insert, select, update, delete
  • HTTP: POST, GET, PUT, DELETE

  RESTful

  • general strategy
    instead of calling an action, create a resource
    instead of 'login', create a session
    instead of 'closing account', create a 'cloing'

  Log in and out

  • whatever your login/Authentication plugin does
  • more important to have session in model than to reflect in URIs

  RESTful routes

  • client app uses web service API
  • HTTP verb path action used for
  • XSS
  • CSRF

  MVC

  • CRUD routes
  • model: data persistence
  • view: url routs/ page routs, process user input
  • controller: How to deals with the data and so on, processing business logic