Get Homebrew installed on your mac if you don't already have it
Install highlight. "brew install highlight". (This brings down Lua and Boost as well)
# Rails developers have long had bad experiences with fixtures for | |
# several reasons, including misuse. | |
# | |
# Misuse of fixtures is characterized by having a huge number of them, | |
# requiring the developer to maintain a lot of data and creating dependencies | |
# between tests. In my experience working (and rescuing) many applications, 80% | |
# of fixtures are only used by 20% of tests. | |
# | |
# An example of such tests is one assuring that a given SQL query with | |
# GROUP BY and ORDER BY conditions returns the correct result set. As expected, |
if Rails.env.production? | |
require 'fileutils' | |
FileUtils.mkdir_p(Rails.root.join("tmp", "stylesheets", "admin")) | |
template_path_one = "#{Gem.loaded_specs['activeadmin'].full_gem_path}/app/assets/stylesheets" | |
template_path_two = "#{Gem.loaded_specs['activeadmin'].full_gem_path}/lib/active_admin/sass" | |
old_compile_path = "#{Rails.root}/public/stylesheets/admin" | |
new_compile_path = "#{Rails.root}/tmp/stylesheets/admin" | |
Sass::Plugin::remove_template_location template_path_one |
Get Homebrew installed on your mac if you don't already have it
Install highlight. "brew install highlight". (This brings down Lua and Boost as well)
I'm a fan of MiniTest::Spec. It strikes a nice balance between the simplicity of TestUnit and the readable syntax of RSpec. When I first switched from RSpec to MiniTest::Spec, one thing I was worried I would miss was the ability to add matchers. (A note in terminology: "matchers" in MiniTest::Spec refer to something completely different than "matchers" in RSpec. I won't get into it, but from now on, let's use the proper term: "expectations").
Let's take a look in the code (I'm specifically referring to the gem, not the standard library that's built into Ruby 1.9):
# minitest/spec.rb
module MiniTest::Expectations
//If you need to spy or stub the global require function in node.js, don't try to spy on the require function itself..you aren't going //to be successful. | |
//Instead, spy on the require.extensions object like so: | |
var spies = {}; | |
spies.require = sinon.spy(require.extensions, '.js'); | |
//Then when you need to assert you can do stuff like: | |
spies.require.firstCall.args[1].should.include("path/to/some/module"); |
package str | |
func Reverse(input string) string { | |
return "" | |
} |
#!/bin/bash | |
file=$1 | |
test -z $file && echo "file required." 1>&2 && exit 1 | |
git filter-branch -f --index-filter "git rm -r --cached $file --ignore-unmatch" --prune-empty --tag-name-filter cat -- --all | |
git ignore $file | |
git add .gitignore | |
git commit -m "Add $file to .gitignore" |
/** | |
* Example webpack.config.js for an AMD project (or AMD + CJS mixed project). | |
* This file should be at the root of your project. | |
* | |
* This can then be used in combination with Karma as well | |
* Just load this file and pass it to karma.webpack key | |
* (see https://github.com/webpack/karma-webpack#alternative-usage) | |
* | |
* This example is a bit extreme. Typically in webpack, you don't need much | |
* configuration if you have nicely behaving code and work with correctly |
# Start by stopping the built-in Apache, if it's running, and prevent it from starting on boot.
# This is one of very few times you'll need to use sudo:
sudo launchctl unload /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null
# We need to tap homebrew-dupes because "homebrew-apache/httpd22" relies on "homebrew-dupes/zlib"