frontend-dev-baseline - rmurphey - pinboard of links for dev-tools you should be using -
- Grunt /
- AMD /
- Testing your JavaScript
- Using break; and stepping in chrome-dev tools
Lea Verou - using regex in terminal, text editors, for databases etc
- http://leaverou.github.com/regexplained - interactive regex calculator
- https://github.com/LeaVerou/regexplained
- Add ?: in beginning of regex to avoid capturing sub-patterns using parenthesis (?:Java)Script\g
- \1 to match again the first matched regex - \ \g
- http:/lea.verou.me
- http://aresluna.org/ - google doodles / attention to detail / sacrificing standards to achieve an effect
- used chrome for computation to render in safari because safari's renderer is faster.
- embedded his own console logger in the site
- controlling presentation with iphone using node-server on laptop and 2 browsers for computation / rendering
- mximize z subject to the following constraints
- overcontstrained - panels.js
- Cassowary Javascript - constraints and hierarchical constraints in javascript ported from c
- linear constraint solver in javascript
- Q: if you want to use constrained solvers for your app you should use? flexbox
- Q: bootstrapping yourself into using custom web elements - x-tags project - using web components and prefixing elements with x- for custom elements
- Experimenting with declarative properties for flexible box models and hierarchical constraints.
- Making CSS render from more declarative syntax (example - which takes precedence: max- min - width or undeclared width)
- Choosing solutions that are too simple - Sproutcore is too complex (learning cliff vs learning curve) VS solutions that are often too simple and wrong -
- file size is important - but correctness, ease of use and productivity are more important.
- "is nodejs better" - talk from jsconf in az that tom recommends
- backbone vs ember
- conventions over configuration:
- why are conventions good - eliminate trivial choices /
- spend time arguing choices that matter within your specific application not with the problems that have already been solved / the problems that are unique to your app
- reduces code - (# of bugs per line, so less bugs)
- increases predictability -
- View hierarchy - handling teardown and child-management in framework - dont rewrite the wheel
- Routing: bring convention to state management 0 serializing and deserializing URLS becomes trivial
- state charts - hierarchy is a great way to model state - explicit state objects -
- create the richer model to describe your app state - then derive a URL to signify that (so use routing instead of URLs and URLS will fall into place)
- "the web sucks" - zed a. shaw - vimeo.com/ - angry about lack of facilities the web has for making applications /
- maybe the web (web technology) isnt really the best place to make applications - "can i center some shit!!" - HTML5 isnt the best tool to build an app - the web is -
- shareable / indexable / interlinked and intertwined / masshups / accessible (as in anyone can get to it) - the web is amazing and the "web" part of "web applications" is why we try to do build in HTML
- web development is mainly about trade-offs (somewhere between crap and shit) - making all the right-tradeoffs (being standalone vs server side - trades off scalability)
- Twitter moved rendering back to the server --- why? -- performance / stability / maintainability - (the trade off)
- Performance: performance is highly contextual (what is "fast"?) - performance is the perception of the user -
- Measurement: Navigation Timing API gives the javascript a broken down timing of when things are visible between connecting, getting a response, rendering a response
- Make your own tradeoffs - identify problems and apply and execute solutions to the problems - not just the latest tech
- Using OpenJS now -
- NPM uses and pro-tips
- the 5 d's of NPM
- discover packages so you dont have to write it yourself
- npm comes with node
npm searchis incredibly slow - http://search.npmjs.com to search- nipster npm - didnt catch the
- dependable
- develop
- deploy and publish
- documentation is a window into code that creates a spectacle - (south korea window into north korea example - its no longer the theater of reality but the theater of spectacle)
- bootstrap + documentation is being used as demos and documentation defines but it's intended to do a lot more
- filling in the gaps undermines the creative potential of something
- rewritting twitter docs rc.getBootstrap.com
- be willing to explore the source
- Zizek - philosopher - the dead-zone, unknown, or other - unidentifiable being that creates anxiety because we can't define it -
- people are too scared to look at or be bothered with undocumented code - but you need to be willing to look in the code
- stimulate people to explore - dont pave the path so much - stop being afraid
- "Don't stop at the documentation"
- socket.io
- travis-ci.org // for testing
- semver.org - // versioning standard // major.minor.patch
- node-brwoserify - require() for client side the node way
- ender.js - package management for npm
- JSFixed -
Here's the url for nipster from Jed Schmidt's talk.
http://eirikb.github.com/nipster/