octocat

# Compiled source #
###################
*.com
*.class
*.dll
*.exe
*.o
*.so

# Packages #

vratiu

#  Customize BASH PS1 prompt to show current GIT repository and branch.
#  by Mike Stewart - http://MediaDoneRight.com

#  SETUP CONSTANTS
#  Bunch-o-predefined colors.  Makes reading code easier than escape sequences.
#  I don't remember where I found this.  o_O

# Reset
Color_Off="\[\033[0m\]"       # Text Reset

bzerangue

Verify and Repair Disk Permissions via Terminal (Mac OS X)

Verify Permissions

diskutil verifyPermissions /

Repair Permissions

diskutil repairPermissions /

tracker1

Directory structure for JavaScript/Node Projects

While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.

Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.

Directories

• lib/ is intended for code that can run as-is
• src/ is intended for code that needs to be manipulated before it can be used

syui

# os : archlinux
# terminal : lilyterm
# font : ttf-dejavu
# source : https://gist.github.com/3feec5b12fcf07c6b64e

### export {{{
PATH=$PATH:$HOME/.rvm/bin
HISTFILE=~/.zsh_history
HISTSIZE=20000

rarylson

-- AppleScript to create a new file in Finder
--
-- Use it in Automator, with the following configuration:
-- - Service receives: no input
-- - In: Finder.app
--
-- References:
--  - http://apple.stackexchange.com/a/129702
--  - http://stackoverflow.com/a/6125252/2530295
--  - http://www.russellbeattie.com/blog/fun-with-the-os-x-finder-and-applescript

lukas-h

Markdown License badges

Collection of License badges for your Project's README file.
This list includes the most common open source and open data licenses.
Easily copy and paste the code under the badges into your Markdown files.

Notes

• The badges do not fully replace the license informations for your projects, they are only emblems for the README, that the user can see the License at first glance.

Translations: (No guarantee that the translations are up-to-date)

• 🇫🇷 Cette liste en français

nvanselow

{
    "env": {
      "browser": true,
      "node": true
    },
    "extends": "google",
    "installedESLint": true,
    "plugins": [
      "react"
    ],

dahjelle

#!/bin/bash

for file in $(git diff --cached --name-only | grep -E '\.(js|jsx)$')
do
  git show ":$file" | node_modules/.bin/eslint --stdin --stdin-filename "$file" # we only want to lint the staged changes, not any un-staged changes
  if [ $? -ne 0 ]; then
    echo "ESLint failed on staged file '$file'. Please check your code and try again. You can run ESLint manually via npm run eslint."
    exit 1 # exit with failure status
  fi
done

wojteklu

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules