Lecture 2: (9/6) Source Control, Browser Ecosystem, Javascript

by Mike Gleicher on September 5, 2012

Topics for today:

  1. Version (source) control (DCS) – need for collaboration, need for tutorials
  2. Browser Ecosystem – what are the various tools, graphics libraries and things that go along with doing Javascript
  3. Javascript – a taste to get started

Project 1: Pairs, Javascript, Canvas, Flocking, Game

next time: what is flocking, time after that, what is a game

Version Control

Why is this valuable for working by yourself.

Why is this critical for collaboration?

  • safety
  • being able to “undo” (and check against old stuff)
  • being able to handle collaboration issues
  • being able to support parallel exploration

Policy vs. mechanism:

  • disallow simultaneous edits (hold the token / lock)
  • allow simultaneous edits and hope for the best
  • provide good mechanisms for cleaning up later

A little history

  • several different styles of systems
  • new systems based on old models
  • new models are different
  • perspective is useful in understanding what you can do
  • policy vs. mechanism (some systems let you decide)

RCS

  • linear repository
  • single stream

CVS / Dropbox

  • centralized repository of all versions (keep history)
    • picture of model: working dir, repo, check out, edit, commit
  • concurrent checkouts allowed
  • still linear revisions
  • per-file histories
  • ability to layer policies on top
  • conflict resolution
  • fork
  • Problems:
    • commit is a scary proposition
    • can mess other people up
    • version skew (different people edit different files) – conflicts you don’t notice
    • Forks are not handled well (and generally never come back together)

SVN

  • modern version of CVS – fixes some of the problem, but still has the centralized linear repository concept

DCS

  • Mercurial and GIT – differ in the details. I use Mercurial, I can’t tell you why its different than GIT except that the UI seems better (but that could just be that I am more used to it).
  • Big ideas (some of these could be in other systems) – could be independent
    • History is a DAG
    • Versions are for the whole project
    • Multiple copies of repos
    • Lightweight commits/forks/switching
    • every copy has whole repo
  • Concepts
    • working dir, repo
    • commit, update => Tree
    • heads, current head, switching
    • merge, conflicts => DAG
    • clone/copy => multiple repos
    • parallel work without interference
    • push/pull => synchronization
    • dealing with distributed merges (reconsiliation)
  • Payoffs
    • commit a lot / fork a lot
      • doesn’t affect anyone else
      • easy to undo
      • easy to try multiple pathways
    • centralized repo is policy, not mechanism
      • may not be a single “master”
      • disaster proof since everyone has entire repo
    • parallel exploration – merge later
    • stay out of each others way – except when you want to synchronize
      • only push/pull
    • Efficiency/Scalability (central server isn’t hit that often)
    • Easy to start (any directory can be a repo – no need to set up server)
  • Downsides
    • redundant storage (might be a good thing)
    • different model (no explicit locking)
    • complex histories may make merging very complex
    • easy to forget a step (commit without push)
    • biggest benefits come from fully using it (not push always)
    • so easy to use different versions, you might edit the wrong thing
      • protection against this (Mercurial) makes multiple-heads hard
  • personally, I am totally sold

Using DCS mechanisms for other purposes: Tutorial

  • tutorial is a mercurial repo
  • final version is “head”
  • go back to an earlier version to see the steps
  • mercurial repos are easy to web serve

Browser Eco-System

Part of what makes learning Javascript hard is that you not only are learning JS, but all the stuff that goes with it.

What does it take to make something happen in a browser? Lots of different pieces

  • HTML
  • CSS
  • DOM (the internal representation of HTML)
  • Plugins (old way to get other things)
  • HTML/5 (new way to do things – add other types of data services not easily represented in HTML)
  • Javascript (in-browser language integrated with HTML)
  • In-browser vs. on-server
    • can keep serving new pages
    • can have the page get new information from server (programmed) – AJAX
  • Can do lots of stuff by manipulating “standard stuff” (text, layout, style, …)
  • Graphics – built in
    • Images
    • HTML5 Canvas
      • rectangle under program control
      • immediate mode drawing (commands act)
      • draw, clear, re-draw
      • interaction and input
    • SVG
      • pictures
      • represent graphics objects (lines, circles, …)
      • retained mode (keeps the objects once they are drawn)
      • explicit object model (it’s a tree, like a DOM)
      • can manipulate objects
      • interaction by tying events to objects
      • create, modify (for animation)
    • WebGL (actually still canvas)
      • provide low-level access to graphics hardware
      • resource management (chunks of memory) + immediate mode execution
      • we’ll talk about this a lot more later
      • not just for 3D – it’s about direct access to graphics hardware
  • Libraries
    • lots
    • easy to adapt and mix/match
    • jquery
      • gives a different model for thinking about programming
      • useful for lots of stuff – not necessarily the kinds of things in class
      • may be thought of as part of language by some

How do you actually build stuff

  • need to make web pages
  • asset rich is good (browsers are good at loading files (images))
  • CSS/web page info is convenient way to have browser store stuff for you
  • need to write javascript programs
  • may need server side stuff (if you want to do more than just fetch)

Recommended tools

  • Something for making web pages/CSS
    • if its simple, a text editor is OK
  • Something for making pictures, …
  • Something for editing source code
    • simple editors (Notepad++)
    • richer IDEs (Aptana)
  • Debuggers
    • Chrome’s built in stuff
    • Firebug (connects with Apatana)

Javascript

Javascript gets a bad rap – some of it justified, have the right expectations

  1. Javascript is not at all like Java – more like Python
  2. The good ideas in Javascript may be weird to you, and can be misused
  3. The mistakes in Javascript are details in how those good ideas are exposed – be wary of them
    1. Good practices (and tools – if they exist) are key to avoiding problems
    2. flexibility is good (let’s you do things) but also lets you shoot yourself in the foot

Foundational concepts (much more like Python than Java)

    1. C / Java Syntax – but don’t let that fool you
    2. Literals
    3. “Things” (objects) are dictionaries
      1. concept of environments (with literals)
      2. environments (functions)

  1. Lexical scope
    1. Closures
    2. Closures give objects
    3. JS isn’t completely lexically scopes
      1. scopes only for functions
      2. can’t use for object access
Print Friendly, PDF & Email

Previous post:

Next post: