billybonks

semantic-dom-selectors -----> ember-semantic-test-helpers
          |                           |
          |                           |
          |                           |   
      qunit-semantic-assertions ------
          |
          |
          |
 qunit-dom

gricard

If you enjoyed reading this, I'm intending to do more blogging like this over here: https://cdgd.tech

This is not a complaint about Webpack or v4 in any way. This is just a record of my process trying it out so I could provide feedback to the webpack team

Hmm... I don't see any docs for 4.0 on https://webpack.js.org. I guess I'll just wing it. All I need to do is npm i -D webpack@next, right?

+ [email protected]

selvagsz

#!/bin/sh

# Usage
# ```
# sh ./parser.sh -p=/path/to/logs/directory -s=start_date -e=end_date
# TODO: need to wire the cli options
# ```
# This output csv will be generated in the same directory where the script is run

## Parse the command line options

sadikay

@font-face {
  font-family: 'ABeeZee';
  font-style: normal;
  font-weight: 400;
  src: local('ABeeZee'), local('ABeeZee-Regular'), url(http://fonts.gstatic.com/s/abeezee/v9/JYPhMn-3Xw-JGuyB-fEdNA.ttf) format('truetype');
}
@font-face {
  font-family: 'Abel';
  font-style: normal;
  font-weight: 400;

nemtsov

module.exports = (file, api, options) => {
  const j = api.jscodeshift;

  const printOptions = options.printOptions || {quote: 'single'};
  const root = j(file.source);
  const requires = {};

  const filterAndTransformRequires = path => {
    const varName = path.value.local.name;
    const scopeNode = path.parentPath.scope.node;

billybonks

These are my thoughts, on how the translation files should be modeled, take into consideration the following postulates:

• Web applications are modeled around their data.
• Web applications data models have the following states.
  • Saved
  • Deleted
  • Updated
  • Empty
  • Created
  • Loading

marty-wang

const compose = (...fns) => (...args) => fns.reduceRight((input, fn) => fn.apply(null, [].concat(input)), args)

const combine = (...args) => args.join(" ") 
const shout = (x) => x.toUpperCase()
const emphasize = (x) => `${x}!`
const yell = compose(emphasize, shout, combine)

console.log(yell("hello", "world")); // "HELLO WORLD!"

runspired

Ember Named Yields

Current Idea

The current thinking floating around for named yields looks something like this. You can't mix use of named blocks and non-blocked content. Once you use a block helper within a component, everything, including your main yield needs to be within one. If you don't use one, then your yielded content is the main block. This gist is a suggestion I have for how named yields should be implemented and work, and follows the evolution of my thinking on it.

davideast

isUser(uid) = auth != null && auth.uid == uid;

type Post {
  uid: String;
  title: String;
  description: String;
  timestamp: Number;
}

type User {

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])) {