bmc

# A stack, using bash arrays.
# ---------------------------------------------------------------------------

# Create a new stack.
#
# Usage: stack_new name
#
# Example: stack_new x
function stack_new
{

jaseemabid

A bunch of good git tutorials

Intro to git

• Simplest intro to git by github and codeschool - Try Git

• PeepCode Git Internals PDF

• [Intro to github]

chrisroos

Every so often I have to restore my gpg keys and I'm never sure how best to do it. So, I've spent some time playing around with the various ways to export/import (backup/restore) keys.

Method 1

Backup the public and secret keyrings and trust database

cp ~/.gnupg/pubring.gpg /path/to/backups/
cp ~/.gnupg/secring.gpg /path/to/backups/
cp ~/.gnupg/trustdb.gpg /path/to/backups/

or, instead of backing up trustdb...

aslakhellesoy

/** round n down to nearest multiple of m */
long roundDown(long n, long m) {
    return n >= 0 ? (n / m) * m : ((n - m + 1) / m) * m;
}

/** round n up to nearest multiple of m */
long roundUp(long n, long m) {
    return n >= 0 ? ((n + m - 1) / m) * m : (n / m) * m;
}

jesperfj

A better way to set up Java web apps

If you're building a Java web app that you yourself or your organization will be deploying then you can save yourself a lot of trouble by avoiding the whole build-to-war + deploy-to-server approach. Instead, you should build your web app as a normal Java application with an embedded web app server. Don't build a WAR, just compile the code and serve the files out of their source location. This has the following advantages:

• You can code and test iteratively because you don't have to copy files and create war packages every time you make a change. This is similar to what the mvn jetty:run command is being used for by many developers today.
• You run the same exact code in production as you do in development. Hopefully I don't have to elaborate on the advantages of that. Most developers today use mvn jetty:run or similar to achieve a quick, iterative dev cycle. But come time for deployment, they build a WAR and throw it over the wall to be deployed in some app server

jehiah

#!/bin/sh

#
# a simple way to parse shell script arguments
# 
# please edit and use to your hearts content
# 


ENVIRONMENT="dev"

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 [email protected]