Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

Meeting 2014 03 03

Jump to bottom
Eric Bollens edited this page Mar 4, 2014 · 16 revisions

Information

  • Location: Math Sciences 5907
  • Date/Time: Monday March 3 from 1:00 to 2:00 PM Pacific Time
  • Conference Line: 888-921-8686 #3102061670

Attendees

  • Eric Bollens
  • Logan Franken
  • Chris Patterson
  • Quyen Vaillant
  • Lloyd Nicks
  • Alfonso Roman
  • Praveen Dugar
  • Donny Morada
  • Sanjay Sutar
  • Babak Goshtasbi
  • Eddy Mishiger
  • Emily Kim
  • Christina Fries
  • Nathan Lai
  • Haoni Li
  • Yami Reddy Yannam

WebBlocks 1

  • How's the 1.1 release working out for people?
  • Other thoughts and items?

MWF Next Generation Meeting

  • Attended by UCLA, UCSB, UCSD and UCSF
  • Discussion of where the next generation of MWF is headed
  • Some key perspectives:
    • UCLA: Mixed strategy of responsive and mobile-specific
    • UCSD: "Responsive isn't the magic bullet"
    • UCSD: Want mobile optimization strategy
    • UCSF: Not too many situations seem to justify a separate mobile site
  • Eric presented how WebBlocks 2 will distance itself from being a framework
    • Configurable package, dependency and configuration manager
    • Focus on integrating other frameworks and tools
      • Efx and ariaMapper were both developed for WebBlocks, but as separate standalong packages
      • WebBlocks 1 modules will become their own mini-frameworks (such as row, cluster, form, etc.)
      • WebBlocks itself will essentially just be a linker based on relationships defined in package metadata
      • This new strategy, coupled with making MWF assets static, makes WebBlocks an obvious assembler choice
    • Question about where it fit in the stack against yeoman, grunt, bower, etc.
      • Uses bower and npm for package-level dependency management
      • Could be used to feed scaffolding in yeoman
      • Similar level to grunt except offloading logic responsibilities to packages rather than Gruntfile
    • Next generation of MWF will be a distribution of WebBlocks with particular packages and configuration
  • Other discussion items included:
    • Native app development where first couple tiers are native and then hop to mobile web
    • Agreement that performance is the key goal - where web and native should be almost comparable
    • A new name is needed for MWF
  • Next steps:
    • Vision document (Eric, Alex, Brett, Rose) to be created on GitHub wiki page
    • "MWF 2" shall not be the name -- wiki page to be created for this as well

WebBlocks 2

DEVELOPMENT DISCLAIMER

While the WebBlocks 2 repository contains working code, and while some specifics are discussed herein, the implementation may change significantly before release. As such, no guarantees are made about the consistency of the API at this time. Anything discussed herein may change in the future, up until the point of a beta release.

Recap

  • Because WebBlocks will no longer be a single repo, new GitHub organization
  • Core repository (under development):
  • This is a completely fresh start to the architecture -- new version will:
    • Be a command-line tool blocks
    • Provide package, dependency and configuration management
    • Distributable as a gem, rpm, deb, pkg, etc.
    • No longer include modules in the main repo
    • Modules from WebBlocks 1 become their own microframeworks
    • Only bower.json and Blocksfile.rb files to define a WebBlocks build
  • During January:
    • Proposed and implemented DSL
    • Created CLI for inspecting blocks and dependencies
    • Some examples of commands include:
      • blocks help
      • blocks inspect help
      • blocks inspect blocks
      • blocks inspect blocks --attributes
      • blocks inspect bower_registry
      • blocks inspect dependency_list
      • blocks inspect dependency_order
      • blocks inspect dependency_order --type=scss
      • blocks inspect dependency_order --type=js
    • No ability to actually run a build
  • Been quiet for about a month due to other priorities (CASA)

Updates

  • Over the past week, added the following commands:
    • Operations:
      • blocks build
      • blocks watch
    • Partial commands (which produce into .blocks/workspace):
      • blocks link scss
      • blocks link js
      • blocks compile scss
  • First runnable dev pre-release snapshot available on RubyGems:
  • Code climate:
    • Code Climate
  • Hooked up to Travis but tests are still intermittent
    • Goal of next sprint to get test coverage above 80%
  • Internal architecture:
    • bin/blocks is simply a call-forward to a Thor class WebBlocks::Thor::Runner to improve testability
    • WebBlocks::Thor defines all the Thor commands registered through WebBlocks::Thor::Runner
    • WebBlocks::Manager::Bower interacts with Bower
      • This allows bower.json to be the canonical mapping of repositories within WebBlocks
      • Actual bower system calls are expensive, so caching is built in
      • bower_components will not be reloaded unless --reload-bower is called
      • WebBlocks will not resolve added/remoted Blockfile.rb files unless --reload-registry is called
    • WebBlocks::Manager::Builder encapsulate a full run of a type of file for a task
      • Make it easy to extend and leverage as a library programmatically
    • WebBlocks::Manager::ParallelBuilder wraps WebBlocks::Manager::Builder for parallel processing
      • Abstracts out split/join logic from the rest of the application
      • Easy as saying wait_for_complete! to block main process until all worker processes finish
      • Currently fork-based model but eventually configurable (pool size and threads versus forks)
    • WebBlocks::Strategy defines strategies with execute! method to invoke
      • So far Link::Scss, Link::Js and Compile::Scss
    • WebBlocks::Structure defines a set of classes that represent the tree defined by Block/Blocksfiles
    • WebBlocks::Framework is module with framework method to bootstrap into the DSL for structures
    • WebBlocks::Product defines a set of classes that represent build products (at various stages)
    • WebBlocks::Support::ScopedLogger extends Ruby logger with progname scoping

Examples

Start by reviewing the Getting Started guide here:

https://github.com/WebBlocks/WebBlocks/blob/master/README.md

First functional module implementing WebBlocks 2:

https://github.com/ebollens/efx

A wrapper implementing WebBlocks for a framework that doesn't support it internally:

https://github.com/WebBlocks/wrapper-jquery

Moving Forward

  • Near-term:
    • Add tests and inline documentation
    • Add optimize stage that can minifies CSS and JS (currently sitting in pull request)
  • Further out:
    • Add multiple asset builds rather than just building one CSS and one JS file apiece
    • Consider the question of how to add images and fonts to this stack
    • Start creating blocks (and providing Blockfiles for existing frameworks)
    • Investigate programmatic features:
      • How can a block add its own routines to run?
      • How can a developer hook into the execution stack?
  • Anyone interested in helping work on WebBlock 2 dev?

Discussion Items

  1. Concerns raised by Alfonso about Java requirement
  • Eric explained that this comes from YUI compressor - even the Node.js one wraps a jar
  • Eric to investigate options that are not Java-based - although performance is a concern
  • One possibility is use Java version if available or else fall back to pure Ruby
  1. Alfonso asked about if there are any plans to support Less?
  • Eric suggests two ways that we might look at tackling this problem:
    • Convert less files to sass files and then compile in one sheet
    • Treat less files separately and compile a separate sheet
    • Not a critical concern
  1. Alfonso asked about timeline
    • Suggested it would be useful to have this by start of summer
Clone this wiki locally