- Download the perforce visual tool suite from here: http://www.perforce.com/perforce/downloads/index.html
- Copy only the p4merge.app file into your /Applications/ directory
/** | |
* | |
* uk.co.soulwire.display.PaperSprite | |
* | |
* @version 1.00 | Jan 11, 2011 | |
* @author Justin Windle | |
* | |
**/ | |
package uk.co.soulwire.display | |
{ |
git archive --format zip --output /full/path/to/zipfile.zip master |
⇐ back to the gist-blog at jrw.fi
Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.
This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso
[merge] | |
keepBackup = false | |
tool = p4merge | |
[mergetool "p4merge"] | |
cmd = /Applications/p4merge.app/Contents/Resources/launchp4merge "\"$PWD/$BASE\"" "\"$PWD/$REMOTE\"" "\"$PWD/$LOCAL\"" "\"$PWD/$MERGED\"" | |
keepTemporaries = false | |
trustExitCode = false | |
keepBackup = false | |
[diff] | |
tool = p4merge |
-- Adapted from these sources: | |
-- http://peterdowns.com/posts/open-iterm-finder-service.html | |
-- https://gist.github.com/cowboy/905546 | |
-- | |
-- Modified to work with files as well, cd-ing to their container folder | |
on run {input, parameters} | |
tell application "Finder" | |
set my_file to first item of input | |
set filetype to (kind of (info for my_file)) | |
-- Treats OS X applications as files. To treat them as folders, integrate this SO answer: |
alias ng="npm list -g --depth=0 2>/dev/null" | |
alias nl="npm list --depth=0 2>/dev/null" |
[mergetool] | |
prompt = false | |
keepBackup = false | |
keepTemporaries = false | |
[merge] | |
tool = winmerge | |
[mergetool "winmerge"] | |
name = WinMerge |
#!/bin/bash | |
DIR=. | |
if [ -n "$1" ] | |
then | |
DIR=$1 | |
fi | |
# Find image files in. | |
FILES=`find $DIR -type f | grep ".*\.\(jpg\|gif\|png\|jpeg\)"` |
by Gavin Lazar Suntop @gvn
I love clean code. There, I said it. I pride myself on passing strict linting standards and keeping my code easy to read. It's not just a personal proclivity, but a choice I hope benefits other developers.
My general experience with teams has been that code style is something people care about and have strong personal preferences. Typically, at some point people get tired of dealing with inconsistency and a standardization meeting is called. This is, of course, an important discussion to have. The problem that tends to occur is either lack of documentation or lack of enforcement of the agreed upon style. Additionally, new team members or contributors may not have access to a clear set of rules.