Leko

function profilify(fn, label) {
    var displayName = label || fn.name,
        called = 0,
        profilified = function() {
            var args = [].slice.call(arguments),
                startedAt = new Date(),
                defaults = { total: 0, times: 0, average: 0 },
                ret;

            profilify._stats[displayName] = profilify._stats[displayName] || defaults

anaisbetts

// Pretend that cookies work
(function (document) {
  var cookies = {};
  document.__defineGetter__('cookie', function () {
    var output = [];
    for (var cookieName in cookies) {
      output.push(cookieName + "=" + cookies[cookieName]);
    }
    return output.join(";");
  });

marocchino

ES6시대의 JavaScript

• 원문 : http://techlife.cookpad.com/entry/2015/02/02/094607

안녕하세요. 사원사업부의 마루야마@h13i32maru입니다. 최근의 Web 프론트엔드의 변화는 매우 격렬해서, 조금 눈을 땐 사이에 점점 새로운 것이 나오고 있더라구요. 그런 격렬한 변화중 하나가 ES6이라는 차세대 JavaScript의 사양입니다. 이 ES6는 현재 재정중으로 집필시점에서는 Draft Rev31이 공개되어있습니다.

JavaScript는 ECMAScript(ECMA262)라는 사양을 기반으로 구현되어있습니다. 현재 모던한 Web 브라우저는 ECMAScript 5.1th Edition을 기반으로 한 JavaScript실행 엔진을 탑재하고 있습니다. 그리고 다음 버전인 ECMAScript 6th Edition이 현재 재정중으로, 약칭으로 ES6이라는 명칭이 사용되고 있습니다.

tomohisa

// add child view
    UIViewController* controller = [self.storyboard instantiateViewControllerWithIdentifier:@"test"];
    [self addChildViewController:controller];
    controller.view.frame = CGRectMake(0, 44, 320, 320);
    [self.view addSubview:controller.view];
    [controller didMoveToParentViewController:self];

// remove child view
    UIViewController *vc = [self.childViewControllers lastObject];
    [vc.view removeFromSuperview];

rmurphey

html * {
  color-profile: sRGB;
  rendering-intent: auto;
}
.cm-s-solarized-light {
  background-color: #fdf6e3;
  color: #657b83;
}
.cm-s-solarized-light .emphasis {
  font-weight: bold;

redism

#!/bin/bash
if [ -f ~/Library/KeyBindings/DefaultkeyBinding.dict ]; then
	echo "~/Library/KeyBindings/DefaultkeyBinding.dict already exists"
	exit -1
fi

mkdir -p ~/Library/KeyBindings
cat << EOF > ~/Library/KeyBindings/DefaultkeyBinding.dict 
{
    "₩" = ("insertText:", "\`");

chantastic

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

dominictarr

Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.

@broros

otherwise why would he hand over a popular package to a stranger?

If it's not fun anymore, you get literally nothing from maintaining a popular package.

One time, I was working as a dishwasher in a restu

gaearon

function mapValues(obj, fn) {
  return Object.keys(obj).reduce((result, key) => {
    result[key] = fn(obj[key], key);
    return result;
  }, {});
}

function pick(obj, fn) {
  return Object.keys(obj).reduce((result, key) => {
    if (fn(obj[key])) {

branneman

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions