A Motivating Example: Building a Static Adolfo Villafiorita For more info: http://www.spmbook.com
Types of s Static: content is fixed. Layout and some content might be modified on the client side by Javascript. However, nothing changes on the server side and every time you reload the page, you go back to the initial state. Advantages: resource, efficient, simple to install (work on any hosting platform), secure. Dynamic: content on the server can be updated, through transactions (web requests in the form of URLs with parameters; PUT and POST). Some requests change the state on the server side in a permanent way. Advantage: collaborative, simple to use, scale up with complexity. Some examples: Blog, CMS (Content Management Systems), Wikis (focus on content) WebApps: focus on functions/services (e.g., Google Maps)
Anatomy of a Web Page CSS and Javascript embedded in the HTML page or loaded (locally or from the Internet) Content (HTML) Media Content (Images,...) Presentation (CSS) Behavior (Javascript) Try: inspect page with your browser Conceptual structure (on the left) different from actual deployment: bundling (put together all files) and compression (to speed up loading time)
Anatomy of a WebPage Many sites are expected to work with different devices and different browsers: responsiveness: adapt to the device capabilities and size modernize : make sure all browsers (especially older ones respond in the same way to your code/webpages) Frameworks (libraries) exist to simplify the work. You include libraries as special css and javascript on your website and use their features. Examples include: Foundation, Bootstrap, jquery, Modernizr, Prototype, However: frameworks and libraries evolve and are themselves built on top of other frameworks and libraries which evolve over time. One important need, therefore, is managing runtime dependencies, that is make sure your website uses a known and decided version of each library it depends on Bower
Building a Static A static website is a good solution for small to medium websites whose content does not change very often
Building a Static Simple approach. Write page by page: Tools: text editor, MS Word, LibreOffice, BlueGriffon Advantage: it does not get any simpler ( for small websites) Problems: coherency of layout, reuse of components, behaviours (responsiveness), etc, etc. Slightly more complex approach: share layout and write content: Tools: Freeway Pro, RapidWeaver, iweb, Sandvox Advantage: separation of content from layout; WYSIWYG (WYSIWYM) interaction Problems: you get what the tool allows you to do; lock-in (migrating your existing content to a different tool might be difficult)
Building a Static A nerdish but effective approach: use a static site generator Prepare content, layout, behaviour, and rules for aggregation: the tool aggregates and generates a website Tools: jekyll (jekyllrb.com) and other 294 alternatives (http:// staticsitegenerators.net/) Advantages: separation of content from layout; flexibility, scalability (you increase complexity as the need arises), no vendor lock-in; fun (if you are a programmer) Problems: it requires skills to master the tools; you are in control of everything (can be an advantage or a disadvantage)
Jekyll, a static website generator Sources Content (HTML, Markdown, Textile, Creole) Presentation (CSS) Structured Data (YAML) Jekyll Page Fragments (HTML, Markdown, Textile, Creole) Behavior (Javascript) plugins (Ruby Code) Media Content (Images,...) Layout (HTML)
Jekyll Basic behavior of Jekyll: take all input pages, apply the directives (e.g., layout, inclusion of fragments) and spit the corresponding HTML pages Variations: allow plugins to pre-process input or output in different ways: generation of galleries, management of non standard markup, generate a site map
Input Files (Sources) Jekyll manages different types of input files in different formats: HTML is boring to write: light markup languages (e.g, textile, markdown, org-mode, creole) Javascript is difficult to write: CoffeeScript CSS is limited: SASS Another problem we need to face, therefore, is managing compile-time dependencies: to build my website I need to make sure I m using all the right versions of all the required tools
Moving from one to many developers Some needs: Site Sources (pages, fragments, SASS,...) jekyll plugins (Ruby Code) Programmer 1 Programmer 2 deploy Live everyone starts from the right (latest) version of sources before publishing everyone uses the same tools (management of compile-time dependencies) Site Sources (pages, fragments, SASS,...) jekyll plugins (Ruby Code) deploy everyone uses the same conventions and run-time dependencies (or it will be difficult to avoid interferences ) work is coordinated
Moving from one to many developers Programmer 1 Site Sources (pages, fragments, SASS,...) jekyll deploy Live Source Repository git plugins (Ruby Code) dependency management system Programmer 2 Project Organization (allocation of work, instructions,...) Site Sources (pages, fragments, SASS,...) jekyll deploy git plugins (Ruby Code) dependency management system
Take-home lessons The development of software systems seldom starts from scratch (library and dependencies) Building software systems requires an appropriate technical setup (compile-time library and dependencies) When we move from single to many developers: we need to coordinate work (who does what), contributions (how things are done), development environment (with what tools) we need to protect our assets: make sure we know what is and where is the latest version of the sources