| /** | |
| * 2012-12-11 | |
| * @dfkaye, david.kaye | |
| * serviceable api for loading script tags asynchronously in the DOM | |
| * | |
| * 2013-02-28 | |
| * | |
| * sketched this pretty fast in a notebook in Oct 2012 | |
| * some ideas from controlJs lingered for months, finally arrived here | |
| * others come from previous implementations over the years |
| These are my own commands, shortcuts, configurations for sublime text 2 on windows | |
| There's also a really good one at http://www.sublimetext.com/forum/viewtopic.php?f=2&t=10615. | |
| sublime text 2 documentation at | |
| http://www.sublimetext.com/docs/2/ | |
| preferences |
Why JavaScript is Doomed
John Sonmez, @jsonmez, argues in his post Why JavaScript is Doomed that JavaScript will be replaced some day. Here is the last line of his post:
I don’t know when this will happen with JavaScript, but I am pretty sure it will happen.
Several commenters and retweeters apparently did not read that far, as they have belted out the "troll post" tag and are taking him to task for something he did not say. Some of them are quite uncomprehending:
| /** | |
| * 18 MAY 2013 ~ responded to a tweet | |
| * quick and dirty event source module | |
| * add, remove methods accept config object with context and callback properties | |
| * fire method accepts data object | |
| * a listener may be added only once | |
| * | |
| * last rev 2 JULY 2013 | |
| */ |
AMD is an anti-pattern. CommonJS contains mistakes that AMD amplifies.
RequireJS is a well-written and maintained implementation of AMD - exposing the flaws of AMD, but making them harder to combat.
RequireJS comes with r.js which does a good job of concat-min.
RequireJS supports the loader-plugin concept so that you can use the single require() call to load css, html, text, or other file types. That part's pretty good.
RequireJS also supports loading standalone JavaScript which doesn't participate in the module system (backbone, underscore, jquery, jasmine, e.g.). That's pretty good, too, if you don't want to change the way you're doing things now.
The point of agile is lost when teams fixate on roles and responsibilities. Fixed roles ("dev", "qa") harm you in the long run - and the long run is always up sooner than you think.
That's a noisy prelude to my answer to the question: Should QA Write Unit Tests?
Now, I've never run into this - usually it's Dev & QA siloing themselves away from each other - then writing all their own tests, which duplicates some effort - IF dev writes tests at all - with QA running their own tests late in the cycle, finding issues late, etc.
I'm way into TDD, but prefer to work rather than compete with QA. Dev should do some ATDD along with QA anyway. So, if QA wants to - or must - write unit tests in code and hand them over to Dev, they've actually done some thinking for me - stuff I can correct and hand back to them with actual working code. I can see that leading to much better collaboration over time, as long as Dev doesn't mean just coding and QA or test doesn't mean just run scripts
Whatever you're
| // source: | |
| module.exports = Graph; | |
| /* | |
| * Graph constructor (new is optional) | |
| * param string id - required | |
| */ | |
| function Graph(id) { |
| module.exports = Graph; | |
| /* | |
| * Graph constructor (new is optional) | |
| * param string id - required | |
| */ | |
| function Graph(id) { | |
| if (!(this instanceof Graph)) { | |
| return new Graph(id); |
| module.exports = Graph; | |
| /* | |
| * Graph constructor (new is optional) | |
| * param string id - required | |
| */ | |
| function Graph(id) { | |
| if (!(this instanceof Graph)) { | |
| return new Graph(id); |
| // last update 12 JUL 2013 | |
| // previous update 27 JUN 2013 | |
| // started 22 JUN 2013 | |
| // more to come but here's the snapshot | |
| // in JavaScript, I'd like to import a dependency via an alias | |
| module.require('my alias') |