Mint as a new VM?

UPDATE: after going through all of this, the OS locked up on me. I had to hard-stop it and then could notrestart - VirtualBox couldn't find the boot disk. So I'm going back to Ubuntu. I don't know why this happened, but I don't have time to explore it either...


I've gotten in the habit of created Ubuntu virtual machines on my laptop for various projects. I have a new one starting up and decided to create a new VM for that. I was going to install Ubuntu, but I recently heard about the Mint OS. Kind of an Ubuntu clone with a different desktop - Cinnamon instead of Unity. Since Unity isn't my favorite part of Ubuntu, I thought I'd give mint a try. So here's the blow-by-blow.

I have a Dell XPS I7 quad-core with 16Gb RAM and 2x750GB HDDs. The hardware is a beast. It's running Win7. I use Oracle VirtualBox to create the VMs.

I downloaded the 64 bit ISO of the Cinnamon version of mint from http://www.linuxmint.com/

I already have VirtualBox installed, so I started out by creating a new VM in VirtualBox. I specified a 64bit Ubuntu system with 10gb RAM and an 80GB hard drive. In settings I put the following:

1. General->Advanced: Bidirectional Shared Clipboard and Bidirectional Drag'n'Drop
2. System->Processor: 4 CPUs, 100% execution cap, Enable PAE/NX
3. Display->Video: Max Video memory (128 MB), 1 monitor, Enable 3D Acceleration (more on monitors below).
4. Network->Advanced->Port Forwarding: I add in some forwarding depending on what I'm doing so that I can run a browser on the Win7 host OS and access a web server on the Guest VM. But that can't be done until we know the IP address of the Guest. See image below.
5. Shared Folders: I create two -- one for a directory on the Win7 HDD through which I can share files and another to the Dropbox directory on the Win7 HDD. I could install Dropbox on the VM OS, but why have those files duplicated on the host and the guest. I make these shared folders Automount and *not* readonly. See image below

Now, I'm ready to install the OS into the VM, which is easy the first time I click "Start" in the VM. I have to say, if I screw that part up, I haven't looked into how to install on a second start :-) - I just point at my downloaded ISO and go...

Unlike Ubuntu, there are no questions or anything. So I'm guessing I need to customize it after the install. First things first, reset the root password:  sudo passwd root -- That makes all the installs easier.

And I set up the mounts to Dropbox and the shared folder:

sudo mkdir /home/Dropbox
sudo chmod 777 /home/Dropbox
sudo mount -t vboxsf Dropbox /home/Dropbox
sudo mkdir /home/Sharing
sudo chmod 777 /home/Sharing
sudo mount -t vboxsf Sharing /home/Sharing

And created a shell script I can run when starting up to make those mounts (I can never remember the mount command).

More on the various tools and apps I installed later...

A Basic GIT Workflow

I'm using GIT more and more. It's different enough from other source control systems that I ended up cobbling together a basic approach to interacting with GIT during development. This works best with development of small bits of code that are committed frequently. Oh, and I never (except by mistake) edit in the MASTER branch. I always work in a development branch that I try to name after the changes I'm making. There's a basic git philosophy about creating a lot of little (often local) branches to do your work and then merge stuff together once it's really done.

So, here is my "Typical Developer Git Workflow":

1. Create a local feature or bug fix branch

/project.dir(master)> git checkout -b new_feature
/project.dir(new_feature)>

2. Make your changes and commits to the branch

/project.dir(new_feature)> git commit -am "adding awesome features"
/project.dir(new_feature)> ...
/project.dir(new_feature)> git commit -am "finally done"

3. Bring things up to date with the "master" branch

/project.dir(new_feature)> git checkout master
/project.dir(master)> git pull  # bring master up to date
/project.dir(master)> git checkout new_feature
/project.dir(new_feature)> git rebase master

Note: the last command rewinds all the changes you made, then applies all the changes that have been made on master, and then replays your changes on an "up to date" version of the code.  Here is where you'll get information about any potential conflicts to fix / edit accordingly

4. Merge your branch into master and push your changes

/project.dir(new_feature)> git checkout master
/project.dir(master)> git merge new_feature
/project.dir(master)> git push origin master

That's it - the basic development workflow - it helps people isolate their changes in a separate branch and merge things in when they're done.  They can also create separate branches - for bug fixes and multiple features they may be working on at the same time.

Some other useful commands
1. Bug fixes and release branches

When you're doing bug fixes across branches (master and a release branch that is in production) you'll use the "cherrypick" command to pull changes from one branch to another.  Let's say we have a bug fix that was committed with id 12b10f5f

/project.dir(master)> git log
commit 12b10f5fc49faedb0a9d8008ad0100a67a6cbca7
Author ...

/project.dir(master)> git checkout release-1.2  #a branch out there for release 1.2
/project.dir(release-1.2)> git cherrypick 12b10f5f
/project.dir(release-1.2)> git push  #now the change has been applied to that release too

2. Generally getting around

git log  # show me a list of recent commits
git show 12b10f5f  # show me a diff for this commit
git blame database.yml  # who wrote this code
git diff  # show me a diff of my local changes (not committed)
git status  # show me the files that are new, changed, deleted, etc.
git mv  # move a file from one name / directory to another

Tools that can help

1. Putting the current branch name in the command prompt

http://asemanfar.com/Current-Git-Branch-in-Bash-Prompt

2. Update your ~/.gitconfig with shortcuts and colorized diffs, etc.

[user]
name = Your Name
email = your email
[color]
diff = auto
status = auto
branch = auto
interactive = auto
[alias]
st = status
co = checkout
ci = commit
ca = commit -a
br = branch

Git and DropBox - An Approach for Small Projects and Small, Distributed Teams

I work on any number of software development projects and over the years have worked my way through any number of source control systems: RCS, CVS, SVN, until now (finally) I've landed on GIT.

Although GIT can be used with only a local repository, I always set it up on a remote repository, basically for two reasons: to have a backup in the event something happens to my computer, and to share the code with other developers, or even with another computer of my own. For some projects, we've created a GIT repository on one of our servers. For others, we've used GitHub, which is fantastic, IMO.

Creating a project repository in GitHub is perfect for projects that are being developed for public access and use, but to create a private GitHub project requires a paid-for account. And while the cost is not huge (~$8/mo at this writing), it would be nice to have an alternative, cost-free option. Enter DropBox.

I use DropBox all the time for transferring files between people and even between multiple computers of my own. It's just too easy. And on most projects in which I'm involved, the whole team uses DropBox to share files. So wouldn't it be cool if I could simply create a GIT remote repository in DropBox and share that with the development team? Yeah. So what we'll do here is set up a "bare" GIT remote repository under DropBox and then use that to capture a project's code. Importantly, this is a bare repo - it's not meant for any developer to commit to directly. Instead, developers should clone from this repo, commit locally, and push back to it.

So here's what I did:

1. Download and install GIT (http://git-scm.com/downloads).
   While this includes some GUIs, I use the command from a terminal. So after installing, open a terminal or a command window and...
2. Create a directory in DropBox for the repository. I used git_repos. Then cd into that.
3. Initialize a git repository:
   git init --bare myproject.git
   You should see a message something  like this:
   Initialized empty Git repository in .../Dropbox/git_repos/myproject.git
   And you should see a DropBox notification of this as well.

And that's it. The bare GIT repository is created. if you look in the myproject.git directory, you'll see all the GIT folders and files.

Now, we can create or add a project to this repo using normal GIT commands:

cd 
git init
git add .
git commit -m "initial GIT commit"
git remote add origin 
git push -u origin master

The URL is important. It needs to point at that new DropBox repository, something like this:

d:/DropBox/.../git_repos/myproject.git 

This value will get written into the .git/config file in the project directory and will be used as the location for the "origin" or remote GIT repository.

Other developers on my team can now clone from this:

git clone d:/DropBox/.../git_repos/myproject.git myproject

and so on.

Documentation has Little Value - Read the Code

Again, I got this from Jeff Atwood HERE. But I feel so strongly about this that I'm plagiarizing  and not just linking to his page...

"... writing for people is way harder than writing for machines, the documentation will continue to suck for the forseeable future. There's very little you can do about it.
Except for one thing... You can learn to read the source.

No matter what the documentation says, the source code is the ultimate truth, the best and most definitive and up-to-date documentation you're likely to find. This will be true forever, so the sooner you come to terms with this, the better off you'll be as a software developer.

Nobody reads other people's code for fun. But we must read other people's code because we have to understand it to get things done. So don't be afraid to read the source.