How To Move off GitHub

If you want to leave Github for whatever reason, you probably want to take all your code with you, and all your history and branches, etc.

Here’s an example for how I moved my Android Eclipse workspace from Github to my own remote server.

First I make a new git repo on my remote server:

$ git --bare init ~/git/workspace

The –bar option means I’m not going to work on the code in the remote git repo directly.

Next I push my current local ‘master’ to the new repo:

$ git checkout master
$ git push ssh://me@myserver.com/git/workspace master

After that I push my working branch:

$ git checkout work
$ git push ssh://me@myserver.com/git/workspace work

You could repeat this step if you have more branches.

I created my local repo using ‘clone’ so it has an ‘origin’ remote branch defined.  This ‘remote’ branch is where git fetches and pushes changes.

Right now my ‘fetch’ and ‘push’ remote origins point to Github:

$ git remote -v
git@github.com:gdonald/workspace.git (fetch) origin
git@github.com:gdonald/workspace.git (push)

So I remove my ‘origin’ and add the new one:

$ git remote rm origin
$ git remote add origin ssh://me@myserver.com/git/workspace

Then I update my local master’s ‘remote’ to the new ‘origin’:

$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master

After this change I can automatically push my commits to the new repo, ‘origin’ is now selected as my default ‘remote’ for ‘master’ :)

$ git remote -v
ssh://me@myserver.com/git/workspace (fetch) origin
ssh://me@myserver.com/git/workspace (push)

$ git push
$ git pull

Be Sociable, Share!

Android Deallocate Bitmaps

Call this in your onDestroy() on your outer-most layout to free up memory:

public void unbindDrawables( final View v )
{
  if( v.getBackground() != null )
  {
    v.getBackground().setCallback( null );
  }

  if( v instanceof ViewGroup && !( v instanceof AdapterView ) )
  {
    for( int i = 0; i < ( (ViewGroup) v ).getChildCount(); i++ )
    {
      unbindDrawables( ( (ViewGroup) v ).getChildAt( i ) );
    }

    ( (ViewGroup) v ).removeAllViews();
  }
}

Helps with memory leaks in Android, especially if you have an app that switches activity screens a lot.

Be Sociable, Share!

iOS NSDateFormatter NSDate for “now” with timezone

In iOS I needed “now” as a string to use in an HTTP POST. This is as short as I can see to make it:

NSDateFormatter *df = [[NSDateFormatter alloc] init];
[df setDateFormat:@"yyyy-MM-dd HH:mm:ss ZZ"];
NSString *d = [df stringFromDate:
                  [NSDate dateWithTimeIntervalSinceNow:0]];

The first time you do something it might be painful. Here’s to hoping your pain is less than mine :)

Be Sociable, Share!

Stack Trace Driven Development

Motivation

If your software project doesn’t “get users” it will die, bottom line. Launching a software project into production sooner rather than later greatly increases the odds the project will “get users” and ultimately succeed.

Situation

You’ve seen it time and again in recent years. You start a new project. You have project specs and a strong desire to include a test suite with your project to prove correctness and efficiency. But along the way your project specs change, you don’t launch on time, and you have a gazillion tests to update. Your hopes of actually “getting users” dwiddles daily as you cope with all the code and test code changes. What do you do?

Solution

Throw out your test suite and launch the project into production.

Having users actually use your software provides near 100% code coverage. Having your “test suite” run in production on real data means you do not waste time creating fake data in the form of fixtures or factories. Continuous integration is provided as a side effect of server uptime. You can confirm your test suite is being executed by examining server load.

Implementation

STDD is super easy to setup. On Android there is ACRA.. force closes stop, stack trace emails start, simply beautiful. In Django it’s DEBUG=True in settings.py.. user gets an oops sorry page, you get a stack trace email.

Origin

I got the idea for STDD from staring at an unread copy of “Ship It” I had purchased some time ago. I don’t know what’s in the book because like I mentioned, I’ve never bothered to read it. I’m much too busy rolling out new versions of my software projects to read a book! But the title made me think, what IS the fastest way to deliver software while still maintaining some sanity with managing coding errors? I realized the actual code could easily be considered a test suite, and since I have the test results: either it crashed or it didn’t, I followed through with stack trace email implementation to close the loop.

Probability Of Success

I created these probabilities based on my experience. I’ve never worked on a large software project with a hand-coded test suite that actually launched into production. Meanwhile most every other project I’ve worked on, without a test suite, has launched.

P(L|T) = 0.01
P(L|¬T) = 0.99

The “probability” of an actual project “launch” seems greatly dependent on the amount of academic masturbation contributed to the project in the form of a “test suite”.

If you have a project where specs change constantly, you should try STDD. It will greatly increase the probability your project will launch, “get users”, and succeed.

Be Sociable, Share!

How-to build latest Linux kernel from Linus’ git repo on Debian

Here’s a how-to for building a recent 2.6 Linux kernel on your Debian GNU/Linux box:

You will need to do all this as root. It’s serious business building new Linux kernels :)

su -

The dash after the su command makes it behave as if you had logged in as root directly, a full login environment is applied.

Make sure you have the required tools and libraries installed:

apt-get install build-essential module-init-tools initramfs-tools \
procps libncurses5-dev kernel-package fakeroot git-core screen \
zlib1g-dev

Use git to clone Linus’ latest git repo:

cd /usr/src

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

cd linux-2.6

This will take a long time.

Once you have the source you’re ready for configuration. I base my new kernel configuration on a known working configuration, then trim it down from there. Check to see what configurations you have in /boot:

ls /boot/config*

Configure your new kernel source using your chosen config file:

make menuconfig

Select “Load an Alternate Configuration File”, enter your config file path, for example I used /boot/config-2.6.26-2-686. Hit exit and save.

Build the kernel and package it:

make-kpkg clean

CONCURRENCY_LEVEL=9 screen fakeroot make-kpkg \
  --append-to-version=1 \
  --revision=1 \
  --initrd \
  kernel_image

make-kpkg clean cleans up the kernel source.

CONCURRENCY_LEVEL=9 translates into `make -j9` later. make -j9 means to compile things in parallel using all your processors, so adjust accordingly for your actual system. I usually go 2x the actual number of processors +1.

screen is a command used to run another command in a virtual screen. The new virtual screen doesn’t end if you disconnect. `man screen` if you’re not familiar, it’s a very useful tool.

fakeroot provides a fake root environment in which to build a package.

make-kpkg is a kernel building and packaging tool.

The –append-to-version is whatever you want, I increment mine by one every time I build a new kernel, and usually start over when Linus releases a “stable” kernel.

The –revision is whatever you want, I set this simply for a shorter package name.

The –initrd option makes dpkg build a new initrd image when you install the kernel package later. An initrd image contains drivers your system needs before your kernel loads, for example, raid and ext3.

Build a new kernel using a distro’s (Debian in my case) default config takes a while. Everything will usually work on the first try using a distro config since everything is built as modules as much as possible, and all modules get built. You stand a good chance of successfully booting a new kernel built this way. Later you can remove stuff from the config and rebuild. Wash, rinse, and repeat until you get your kernel config down to just the hardware you actually have in your system.

Install the new kernel:

cd ..

dpkg -i linux-image-2.6.31-rc7_1_i386.deb

Reboot.

When your system comes back up..

> uname -a
Linux saturn.localdomain 2.6.31-rc7 #2 SMP Mon Aug 24 21:53:19 CDT 2009 i686 GNU/Linux
Be Sociable, Share!