Thanks to Christoph‘s hard work taking photos of all 529 minifigures released in 2012, the 2012 minifigs are now available for purchase in the Unofficial Minifigure Catalog app.
To purchase the update, first update the database to the latest version (Settings > Database) and then go to Settings > Collections and look for the purchase button.
UserTiming is one of the W3C specs that I helped design while working at Microsoft through the W3C WebPerf working group. It helps developers measure the performance of their web applications by giving them access to high precision timestamps. It also provides a standardized API that analytics scripts and developer tools can use to display performance metrics.
UserTiming is natively supported in IE 10 and prefixed in Chrome 25+. I wanted to use the interface for a few of my projects so I created a small polyfill to help patch other browsers that don’t support it natively. Luckily, a JavaScript version of UserTiming can be implemented and be 100% API functional — you just lose some precision and performance vs. native browser support.
So here it is: UserTiming.js
README:
UserTiming.js is a polyfill that adds UserTiming support to browsers that do not natively support it.
UserTiming is accessed via the PerformanceTimeline, and requires window.performance.now() support, so UserTiming.js adds a limited version of these interfaces if the browser does not support them (which is likely the case if the browser does not natively support UserTiming).
As of 2013-04-15, UserTiming is natively supported by the following browsers:
UserTiming.js has been verified to add UserTiming support to the following browsers:
UserTiming.js will detect native implementations of UserTiming, window.performance.now() and the PerformanceTimeline and will not make any changes if those interfaces already exist. When a prefixed version is found, it is copied over to the unprefixed name.
UserTiming.js can be found on GitHub and as the npm usertiming module.
It’s not you, it’s me.
A few months ago I released a small JavaScript micro-framework: breakup.js
Serially enumerating over a collection (such as using async.forEachSeries()in Node.js or jQuery.each() in the browser) can lead to performance and responsiveness issues if processing or looping through the collection takes too long. In some browsers, enumerating over a large number of elements (or doing a lot of work on each element) may cause the browser to become unresponsive, and possibly prompt the user to stop running the script.
breakup.js helps solve this problem by breaking up the enumeration into time-based chunks, and yielding to the environment if a threshold of time has passed before continuing. This will help avoid a Long Running Script dialog in browsers as they are given a chance to update their UI. It is meant to be a simple, drop-in replacement for async.forEachSeries(). It also provides breakup.each() as a replacement for jQuery.each() (though the developer may have to modify code-flow to deal with the asynchronous nature of breakup.js).
breakup.js does this by keeping track of how much time the enumeration has taken after processing each item. If the enumeration time has passed a threshold (the default is 50ms, but this can be customized), the enumeration will yield before resuming. Yielding can be done immediately in environments that support it (such as process.nextTick() in Node.js and setImmediate() in modern browsers), and will fallback to a setTimeout(..., 4) in older browsers. This yield will allow the environment to do any UI and other processing work it wants to do. In browsers, this will help reduce the chance of a Long Running Script dialog.
breakup.js is primarily meant to be used in a browser environment, as Node.js code is already asynchronously driven. You won’t see a Long Running Script dialog in Node.js. However, you’re welcome to use the breakup Node.js module if you want have more control over how much time your enumerations take. For example, if you have thousands of items to enumerate and you want to process them lazily, you could set the threshold to 100ms with a 10000ms wait time and specify the forceYield parameter, so other work is prioritized.
As many geeks do, I have a collection of about 30-odd domain names that I’ve purchased over the past few years for awesome-at-the-time ideas that I just never found the time to work on.
Last month, I resolved stop collecting these domains and instead make some visible progress on them, one at a time.
SaltThePass is my first project. Do you have an account on LinkedIn, Evernote, or Yahoo? All of these sites had password breaches in the last year that compromised their user’s logins and passwords. One big problem people face today is managing all of the passwords they use for all of the sites that they visit. People often re-use the same password on many sites because it would be impossible to remember hundreds of different passwords. Unfortunately, this means that if a single site is hacked and your password is revealed, the attacker may have access to your account on all of the other sites you visit.
To help solve this problem, I created SaltThePass.com. Salt The Pass is a password generator that will help you generate unique, secure passwords for all of the websites you visit based on a single Master Password that you remember. You don’t need to install any additional software, and you can access your passwords from anywhere you have internet access.
Check it out at https://saltthepass.com and let me know what you think!
Last night I gave a short presentation on Using Modern Browser APIs to Improve the Performance of Your Web Applications at GrWebDev.
It’s available on SlideShare:
Two other presentations I gave late last year are available here as well:
Nic is a Distinguished Engineer at Akamai building high-performance websites, apps and open-source tools.
Co-Chair of W3C Web Performance Working Group.
he/him
Founder of Wolverine Digital, LLC.