By Bill Heaton @pixelhandler
http://www.w3.org/TR/user-timing/#performancemark
See post: Measuring Performance with User Timing API, in an Ember Application
By Bill Heaton @pixelhandler
http://www.w3.org/TR/user-timing/#performancemark
See post: Measuring Performance with User Timing API, in an Ember Application
While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/
is intended for code that can run as-issrc/
is intended for code that needs to be manipulated before it can be used/** | |
* User Timing polyfill (http://www.w3.org/TR/user-timing/) | |
* @author RubaXa <trash@rubaxa.org> | |
*/ | |
(function (window){ | |
var | |
startOffset = Date.now ? Date.now() : +(new Date) | |
, performance = window.performance || {} | |
, _entries = [] |
Simple pure JavaScript plugin to rotate text snippets as if they were being typed.
A Pen by Gregory Schier on CodePen.
// Support routines for automatically reporting user timing for common analytics platforms | |
// Currently supports Google Analytics, Boomerang and SOASTA mPulse | |
// In the case of boomerang, you will need to map the event names you want reported | |
// to timer names (for mPulse these need to be custom0, custom1, etc) using a global variable: | |
// rumMapping = {'aft': 'custom0'}; | |
(function() { | |
var wtt = function(n, t, b) { | |
t = Math.round(t); | |
if (t >= 0 && t < 3600000) { | |
// Google Analytics |
I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.
From Require.js - Why AMD:
The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"
I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.
Most examples I found tell you to run rvmsudo or passenger-install-nginx-module. I ran into problems with these because:
rvmsudo leaves root owned directories and files under rvm passenger gem directory. This will give you seemingly odd errors later when you try to remove/upgrade passenger gem, or try to use homebrew to install passenger.
There's no good place to put nginx using passenger-install-nginx-module. Putting it under /usr/local means you have to remember it's there amongst homebrew files. Anywhere else, you still have to remember you put it there. We'd rather manage nginx install via homebrew.
So to install everything with homebrew, this is what it took:
gem install passenger
require 'digest/md5' | |
require 'aws/s3' | |
#set your AWS credentials | |
AWS::S3::Base.establish_connection!( | |
:access_key_id => 'XXX', | |
:secret_access_key => 'XXX' | |
) | |
#get the S3 file (object) |
Node.js core does its best to treat every platform equally. Even if most Node developers use OS X day to day, some use Windows, and most everyone deploys to Linux or Solaris. So it's important to keep your code portable between platforms, whether you're writing a library or an application.
Predictably, most cross-platform issues come from Windows. Things just work differently there! But if you're careful, and follow some simple best practices, your code can run just as well on Windows systems.
On Windows, paths are constructed with backslashes instead of forward slashes. So if you do your directory manipulation
var parser = document.createElement('a'); | |
parser.href = "http://example.com:3000/pathname/?search=test#hash"; | |
parser.protocol; // => "http:" | |
parser.hostname; // => "example.com" | |
parser.port; // => "3000" | |
parser.pathname; // => "/pathname/" | |
parser.search; // => "?search=test" | |
parser.hash; // => "#hash" | |
parser.host; // => "example.com:3000" |