jehoshua02

<?php

namespace Cli;

/**
 * Color
 *
 * Applies colors to strings for cli output
 */
class Color

jehoshua02

Requirements for Front-End Resource Loaders

• Explicit dependencies: I want to know a) what dependencies a any piece of code requires, and b) that that code will not execute until all dependencies are successfully loaded, so that I can have confidence that dependencies are isolated to each piece of code and not being clobbered somewhere, that code is not executing without required dependencies, and that broken dependencies will be obvious so that I can fix them easily.
• Dependency Manager: I want to lock onto specific versions of dependencies so that I don't have to worry about my application breaking when a new version comes out. I also want to be able to install different versions of a dependency easily so that I can test and make changes to migrate. Oh, and I don't want to have to worry about dependencies of a dependency. That should be handled by dependency manager. I only care about the direct dependency to my application or library. Also, two dependencies can be dependent on different versio

jehoshua02

My Requirements List for Static Blog Generator

• Markdown: Obviously I want to write my content in markdown, save it in markdown, in the state I wrote it.
• Watch and preview locally: With Jekyll, it's one command: jekyll server --watch. I like that.
• Publish with Git: One simple command to publish: git push origin master.
• Complete Control: I want full control of all javascript and css. Therefore, I want them in plain old files that I can edit, preview, and publish easily.
• Complilation: I want css, javascripts, and markdown to be compiled into deployable code. This should happen when I watch and preview. If the server does the compilation, that's cool. But I wouldn't be bothered committing the compiled resources and publishing them myself. I don't really see why the server has to do it when it's already happening locally.
• Code: It's safe to guess that I'm a developer and will probably blog some code from time to time. I want the whole shebang: backtick markdown code block

jehoshua02

• HTML
• CSS
• Javascript
• PHP
• MySQL
• Apache
• EmberJS
• Ember CLI
• Zend Framework
• Memcache

jehoshua02

HTML

• No inline styles.
• Use the most semantic tag available for each blcok and element on the page.
• Think in pages, blocks, elements.
• Start with an understanding of the structure of the page. With this understanding, you should already have a good idea what class selectors you will attach to each element.
• As few elements as possible to structure the document.
• Only add elements for presentation if there is absolutely no pure-css solution.
• Keep html classes simple. Call it what it is.
• Classes used to indicate state should be qualified: .active = wrong; .collapsible-active = right.

jehoshua02

@media print {
  a[href]:before {
    content: "[";
  }

  a[href]:after {
    content: "](" attr(href) ")";
  }
}

jehoshua02

• Why {{#link-to}} and not {{#bind-attr}} but {{bind-attr}}?
• Why .property()? What is actually going on there?
• Difference between view, partial, render, or component?

jehoshua02

Songs We Know

Checking off songs we know as we learn them so we can see what to choose from for evening song and prayer and have links to quickly access sheet music.

• Recent
• Children's Songbook
• Hymns
• Music From the Friend

Much more music is available through the LDS Music Library.

jehoshua02

#!/bin/bash

URL=

FIREFOX=false
CHROME=false
SAFARI=false
IE10=false
IE11=false
IE8=false

jehoshua02

Reusables.Breakpoints.Breakpoint.prototype.jsondoc = {
  name: 'Breakpoint',
  namespace: 'Reusables.Breakpoints',
  type: 'Class',
  description: 'Represents a breakpoint on a set of elements.',
  params: [
    {
      name: '$elements',
      description: 'Represents set of elements for this breakpoint.',
      types: [