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 <ul>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