technoweenie

GitHub OAuth Busy Developer's Guide

This is a quick guide to OAuth2 support in GitHub for developers. This is still experimental and could change at any moment. This Gist will serve as a living document until it becomes finalized at Develop.GitHub.com.

OAuth2 is a protocol that lets external apps request authorization to private details in your GitHub account without getting your password. All developers need to register their application before getting started.

Web Application Flow

• Redirect to this link to request GitHub access:

jagregory

So you've cloned somebody's repo from github, but now you want to fork it and contribute back. Never fear!

Technically, when you fork "origin" should be your fork and "upstream" should be the project you forked; however, if you're willing to break this convention then it's easy.

* Off the top of my head *

1. Fork their repo on Github
2. In your local, add a new remote to your fork; then fetch it, and push your changes up to it

    git remote add my-fork git@github...my-fork.git

skhatri

apply plugin: 'checkstyle'

checkstyleMain {
    ignoreFailures = false
    reports {
        include ( '**/*.java')
        xml {
           destination "${rootProject.buildDir}/reports/checkstyle/main.xml" 
        }
    }

philipbjorge

package edu.wwu.cs412.tvfanatic;

import edu.wwu.cs412.tvfanatic.account.AccountPreferenceActivity;
import android.app.Activity;
import android.app.FragmentTransaction;
import android.app.SearchManager;
import android.app.FragmentManager.BackStackEntry;
import android.content.Context;
import android.content.Intent;
import android.content.SharedPreferences;

chadmaughan

#!/bin/sh
# this hook is in SCM so that it can be shared
# to install it, create a symbolic link in the projects .git/hooks folder
#
#       i.e. - from the .git/hooks directory, run
#               $ ln -s ../../git-hooks/pre-commit.sh pre-commit
#
# to skip the tests, run with the --no-verify argument
#       i.e. - $ 'git commit --no-verify'

listochkin

JavaScript Static Analysis Tools

Most people are familiar with these three tools:

1. [JSHint][1]
2. [JSLint][2]
3. [Google Closure Linter][3]

The first one is more popular among developers because it is style-agnostic. The other two enforce rules of [Crockford Style][4] and [Google Code Style][5] respectively.

nzakas

Versioning in a Repository

Lately I've been doing a lot of thinking around versioning in repositories. For all the convenience and ubiquity of package.json, it does sometimes misrepresent the code that is contained within a repository. For example, suppose I start out my project at v0.1.0 and that's what's in my package.json file in my master branch. Then someone submits a pull request that I merge in - the version number hasn't changed even though the repository now no longer represents v0.1.0. The repository is actually now in an intermediate state, in between v0.1.0 and the next official release.

To deal with that, I started changing the package.json version only long enough to push a new release, and then I would change it to a dev version representing the next scheduled release (such as v0.2.0-dev). That solved the problem of misrepresenting the version number of the repository (provided people realize "dev" means "in flux day to day"). However, it introduced a yucky workflow that I really hate

MarkMjw

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.8.+'
    }
}

apply plugin: 'android'

jouni-kantola

define(['can', 'localCache'], function(can, localCache) {
    'use strict';

    describe('storeLocal()', function() {
        var sandbox;
        beforeEach(function() {
            // create sandbox environment for mocking about
            sandbox = sinon.sandbox.create();
        });

kimmobrunfeldt

// Style 1
// Export all manually

// Good: Calling functions inside the module is convenient
// Bad:  module.exports becomes verbose and it's tedious to add new functions

function a() {
    b()
}