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.
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).
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']
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
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.
Note that if you just want to edit the last commit message, it's easier to just fire
$ git commit --amend