This gist is a simple no-brainer description of the 3 ways (actually 2.5) the Web handle events.
The declarative inline HTML event listener is mostly an indirection of DOM Level 0 events, meaning this simply uses the equivalent of tag.onclick = listener behind the scene.
click me
| $ grep -P "^[ABCDEFabcdefOoIi]{6,6}$" /usr/share/dict/words | tr 'OoIi' '0011' | tr '[:lower:]' '[:upper:]' | awk '{print "#" $0}' | |
| #ACAD1A | |
| #B0BB1E | |
| #DEBB1E | |
| #AB1DED | |
| #ACAC1A | |
| #ACCEDE | |
| #AC1D1C | |
| #BAB1ED | |
| #BA0BAB |
Here are the areas I've been researching, some things I've read and some open source packages...
Nearly all text processing starts by transforming text into vectors: http://en.wikipedia.org/wiki/Vector_space_model
Often it uses transforms such as TFIDF to normalise the data and control for outliers (words that are too frequent or too rare confuse the algorithms): http://en.wikipedia.org/wiki/Tf%E2%80%93idf
Collocations is a technique to detect when two or more words occur more commonly together than separately (e.g. "wishy-washy" in English) - I use this to group words into n-gram tokens because many NLP techniques consider each word as if it's independent of all the others in a document, ignoring order: http://matpalm.com/blog/2011/10/22/collocations_1/
The proposal you’re about to read is not just a proposal. We have a working implementation of almost everything we discussed here. We encourage you to checkout and build our branch: our fork, with the relevant branch selected. Building and using the implementation will give you a better understanding of what using it as a developer is like.
Our implementation ended up differing from the proposal on some minor points. As our last action item before making a PR, we’re writing documentation on what we did. While I loathe pointing to tests in lieu of documentation, they will be helpful until we complete writing docs: the unit tests.
This repo also contains a bundled version of npm that has a new command, asset. You can read the documentation for and goals of that comma
Service Worker - offline support for the web
Progressive apps - high-res icon, splash screen, no URL bar, etc.
Data Down / Actions Up
Plain JSBin's
Ember Version Base JSBin's
| /* | |
| * anchor-include pattern for already-functional links that work as a client-side include | |
| * Copyright 2011, Scott Jehl, scottjehl.com | |
| * Dual licensed under the MIT | |
| * Idea from Scott Gonzalez | |
| * to use, place attributes on an already-functional anchor pointing to content | |
| * that should either replace, or insert before or after that anchor | |
| * after the page has loaded | |
| * Replace: <a href="..." data-replace="articles/latest/fragment">Latest Articles</a> | |
| * Before: <a href="..." data-before="articles/latest/fragment">Latest Articles</a> |
Ember.js currently doesn't have baked in support for Service Worker. They want this and there's an ember-cli RFCS thread discussing strategies however a number of tooling efforts exist to help fill in this gap today.
Note: you can of course just write vanilla Service Worker code for your Ember.js apps and that will work just fine. This doc tracks tooling and libraries that lower the friction for getting this setup
These static resource precaching and runtime caching libraries are lower-level than Broccoli, but can be used directly
