$ xcrun simctl list --json
$ xcrun simctl delete unavailable
| export default function animateCSS({ element, classes = [], callback }) { | |
| element.classList.add(...classes) | |
| function handleAnimationEnd() { | |
| element.classList.remove(...classes) | |
| element.removeEventListener('animationend', handleAnimationEnd) | |
| if (typeof callback === 'function') callback() | |
| } |
mkdir -p /usr/local/etc/nginx/sites-{enabled,available}
cd /usr/local/etc/nginx/sites-enabled
ln -s ../sites-available/default.conf
ln -s ../sites-available/default-ssl.conf
File locations:
nginx.conf to /usr/local/etc/nginx/default.conf and default-ssl.conf to /usr/local/etc/nginx/sites-availablehomebrew.mxcl.nginx.plist to /Library/LaunchDaemons/| --colour | |
| -I app |
In researching topics for RailsCasts I often read code in Rails and other gems. This is a great exercise to do. Not only will you pick up some coding tips, but it can help you better understand what makes code readable.
A common practice to organize code in gems is to divide it into modules. When this is done extensively I find it becomes very difficult to read. Before I explain further, a quick detour on instance_eval.
You can find instance_eval used in many DSLs: from routes to state machines. Here's an example from Thinking Sphinx.
class Article < ActiveRecord::Base| require File.expand_path('../boot', __FILE__) | |
| require 'rails/all' | |
| module MyApp | |
| class Application < Rails::Application | |
| # you app configuration code | |
| end | |
| end |