.:  GAY  :.

Most people heard about the 80/20 rule.

For those who didn't it basically says that you do 80% of work in 20% time and then 80% of time is spent on the remaining 20% to finish the project/product/service.

BUT

It is these 20% of polish that will ultimately get you the 80% of the market. Because the teams that spent 80% (or even more) on the last 20% of polish to their product and/or service are the teams that usually produce the product/service that wins the major of the market. And this is all that usually matters – to own the majority of the market, to be the leader or in the leader pack  in the market.

This is not a recipe for success of course. There are polished and good products that fail. Speaking in math terms, this is rather the necessary, than  sufficient condition for a successful product and/or service.

Garbage collection in Eclipse

There are several GC options available for eclipse's optimization. Try which one works best for you

The (original) copying collector (Enabled by default). When this collector kicks in, all application threads are stopped, and the copying collection proceeds using one thread (which means only one CPU even if on a multi-CPU machine). This is known as a stop-the-world collection, because basically the JVM pauses everything else until the collection is completed.

The parallel copying collector (Enabled using -XX:+UseParNewGC). Like the original copying collector, this is a stop-the-world collector. However this collector parallelizes the copying collection over multiple threads, which is more efficient than the original single-thread copying collector for multi-CPU machines (though not for single-CPU machines). This algorithm potentially speeds up young generation collection by a factor equal to the number of CPUs available, when compared to the original singly-threaded copying collector.

The parallel scavenge collector (Enabled using -XX:UseParallelGC). This is like the previous parallel copying collector, but the algorithm is tuned for gigabyte heaps (over 10GB) on multi-CPU machines. This collection algorithm is designed to maximize throughput while minimizing pauses. It has an optional adaptive tuning policy which will automatically resize heap spaces. If you use this collector, you can only use the the original mark-sweep collector in the old generation (i.e. the newer old generation concurrent collector cannot work with this young generation collector).

Speeding up Eclipse

If you want more information on how to speed up eclipse on OS X – read this post: [link id='240' text='How To speed up Eclipse on OS X']

Let's have some fun within the Android (Samsung) vs. Apple battle

If you are using Git as your version control system, it can be very helpful in generating the changeset between releases.

First step is to find the last commit where you started the new (or the next) release that you want the changeset for. It can be easily achieved by something like this:

 
git log --pretty=format:"%h - %an, %ar : %s" | grep "RELEASE: X.X.X"

Then you just do:

 
git log --pretty=format:"%h - %an, %ar : %s" b9c28fc..

The formatting options can be altered of course. You can find many more options in the "Pretty formats" section in the git log man pages

The funny octocat by Github

For more funny and creative octocats check out : http://octodex.github.com/

Initial checkout (to ~/branchtest folder) since it was not specified

apollo:~max$ git clone git@bitbucket.org:inteist/branchtest.git

Let's create a file named "master.txt"

apollo:~max$ echo This is master branch > master.txt

Now let's add the file to track changes

apollo:branchtest max$ git add .
apollo:branchtest max$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#	new file:   master.txt

Now let's push the file to the master branch (until now there were no refs). The "-u" switch adds upstream tracking
apollo:branchtest max$ git push -u origin master

Now let's create a new branch and name it "new". The "-b" switch makes us immediately switch to the "new" branch

apollo:branchtest max$ git checkout -b new
Switched to a new branch 'new'

Make sure we are on the "new" branch. Indeed we are.

apollo:branchtest max$ git status
# On branch new
nothing to commit (working directory clean)

Let's add a file "new.txt"

apollo:branchtest max$ echo New addition > new.txt

It's on the file system.

apollo:branchtest max$ ls
master.txt	new.txt

But is untracked by Git just yet

apollo:branchtest max$ git status
# On branch new
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#	new.txt
nothing added to commit but untracked files present (use "git add" to track)

Let's add the file to be tracked

apollo:branchtest max$ git add .
apollo:branchtest max$ git commit -m "Adding the new file while on the new branch"
[new 67f764e] Adding the new file while on the new branch
 1 file changed, 1 insertion(+)
 create mode 100644 new.txt

Let's switch back to "master" branch. The "new.txt" is not there. It is tracked under the new branch.

apollo:branchtest max$ git checkout master
Switched to branch 'master'
apollo:branchtest max$ ls
master.txt

Let's switch back to the "new" branch

apollo:branchtest max$ git checkout new
Switched to branch 'new'
apollo:branchtest max$ ls
master.txt	new.txt

Now with the "master" branch pushed and the the "new" branch created locally but not pushed to the central repository, let's clone the repository to a different folder.

apollo:max$ git clone git@bitbucket.org:inteist/branchtest.git branchtestNEW
Cloning into 'branchtestNEW'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.

We checked out the "master" branch, which has the "master.txt" as expected

$ cd branchtestNEW/
$ ls
master.txt

Let's see if the "new" branch is present:

apollo:branchtestNEW max$ git checkout new
error: pathspec 'new' did not match any file(s) known to git.

Nop, it is not, of course, since we did not push it yet.

Now let's push the the "new" local branch to the remote repository. Just to make a case, I will name it "newremote" on the remote.
This is not required. If the second parameter is omitted, then the local and remote names are the same.
We are going to have the "-u" switch so it is tracked in the upstream

apollo:branchtest max$ git push -u origin new:newremote
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 305 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: bb/acl: inteist is allowed. accepted payload.
To ssh://git@bitbucket.org/inteist/branchtest.git
 * [new branch]      new -> newremote
Branch new set up to track remote branch newremote from origin.

Let's clone the repository to yet another folder.

apollo:~ max$ git clone git@bitbucket.org:inteist/branchtest.git branchtestNEWREMOTE
Cloning into 'branchtestNEWREMOTE'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.

Let's see if there is the "new" branch now.

apollo:~ max$ cd branchtestNEWREMOTE/
apollo:branchtestNEWREMOTE max$ git checkout new
error: pathspec 'new' did not match any file(s) known to git.

Surprise? No. There is no "new" branch of course because we named it "newremote" on the remote and this is how it was checked out.

Was it?

apollo:branchtestNEWREMOTE max$ git checkout newremote
Branch newremote set up to track remote branch newremote from origin.
Switched to a new branch 'newremote'

Yes, it was :)

Let's see what's there:

apollo:branchtestNEWREMOTE max$ ls
master.txt	new.txt

And what about the "master" branch?

apollo:branchtestNEWREMOTE max$ git checkout master
Switched to branch 'master'
apollo:branchtestNEWREMOTE max$ ls
master.txt

Surely enough there is only what was tracked under the "master" branch

It's fairly easy to determine whether there is an app that is registered to handle

market://

requests.

In most cases this will be enough and you can just use the "canHandleMarketURI()" but if you want absolutely make sure that the com.android.vending package is present on the device and is registered to handle the

market://

URIs, then you can simply use "hasGooglePlayMarket()" method.

This method seems to work very well for me.
Enjoy and let me know in the comments if you think this can be further improved.

If you just did a commit and you then realized that something is wrong and you need to amend that commit to include your change, then you do:

 
$ git add .
$ git commit --amend

that’s all. Git will pick up all your changes that you want to the commit and add them to the last commit.

If you need to change/amend a text comment for one of previous commits, it's possible and fairly simple actually. Git allows to do that.

First, you need to issue a rebase command in interactive mode for any number of previous commits. For example:

 
$ git rebase -i HEAD~5

the above command will let you work with 5 previous commits. You can do various changes for the commits as Git does not have the SVN approach of set in stone commits. But if you just want to change the commit message for one of the commits, it's very simple.

After you issues the rebase in interactive mode command, a default configured editor should open with the list of commits that you specified in the command. If it's ~5 then last 5 commits will be there.

Just change the "pick" to "reword" at the commit you want to update and and then save the file and a new editor window should pop with the old commit message letting you change it to the right one. Change it and save and you should be all set.

***Note that the commits appear in a reverse chronological order in the list so if you have commits with the same message be careful. But of course you can always check yourself with the commit hash.

UPDATE

Note that if you just want to edit the last commit message, it's easier to just fire

 
$ git commit --amend