The Dopefly Tech Blog

Join Nathan Strutz as he shoots the breeze on techie geeky web dev stuff.

May
   1234
567891011
12131415161718
19202122232425
262728293031 

I am switching to Git

posted under category: IDEs and tools on July 26, 2011 at 8:12 pm by MrNate

I've been a pretty big fan of revision control software since I started hearing about it. It's crazy that I was a developer for so many years before I heard about it at all. I guess that's what I get for keeping my nose to the ground (note to self: write about being a new developer and getting connected).

I thought I had skipped the entire CVS generation until I joined a very large, almost 100 year old company. Boeing loves CVS, I guess just because it's reliable and was around when they set up their servers. My CVS server is doing fine, but it's slated for a migration to a new data center, possibly facing an end-of-life soon; the guy who maintained it left the company over a year ago. Naturally, I looked into Subversion. There is an enterprise hosting group that hosts SVN over SSH, which means SSH software, managing keystores, telnetting, all kinds of things that I am not a fan of. I had it working, just barely, only through Tortoise and not Eclipse, but it was hard and I would have to help all my teammates get it to work, too. They're smart, but this setup is harder than I want to work. I would have migrated to SVN, but they made it way, way too hard.

The great news is that they do make Git available to me (if I know where to look [Boeing has a strict software installation policy {I can only install the software they give me <recursive parentheses are fun «sometimes»>}]).

I had big initial troubles with understanding the concepts of Git. Everyone who switches has the same trouble. Expect it and don't let it get you down. Git uses a lot of the same words with different meanings, and the need to branch and manage branches is much more prevalent. I found EGit (the Git plugin for Eclipse) completely confusing and stupid. The command line was out, come on, this is 2011. Even TortoiseGit was acting broken. I needed help, and lots of it.

Thankfully, I got to attend two different hour-long Git sessions with Tim Cunningham, who pointed out some other resources. I watched a few other videos, the best was probably Jenny Donnelly's Introduction to Git from Yahoo. Then I read a lot, practiced some, and finally, here I am - switching!

I came to terms with EGit and TortoiseGit - they both make sense now and they work great. I use the Git Bash shell now and I don't even feel weird about it. I keep a cheatsheet on my wall and refer to it regularly.

It's at this point that I can look for the real benefits, to see if this little project pays off.

My Git architecture is very simple and based on what Tim showed off. It's simple file shares across the network. At first it sounded awful, but in reality this works like a charm. The shares are backed up. I control file access. I just have to enforce a couple strict pushing practices and everything is gravy.

I think what I most like about this setup with Git is that it inverses the control (IoC! [kind of]) of my source control software. Where before I needed a server, IT hardware support and had one repository, now I make and control the repository when and where I want it. Where before committing to a subversion repo on a flash drive seemed like a half-broken hack and it would never sync to a remote server, now it's a way to win easily. It feels liberating. It's really cool. This developer's tool doesn't need a server anymore. It just needs a capable developer. It's developer's software for developers, and I love it.

As I've progressed with Git, I have branched and merged and pushed and rebased and stashed pulled and diffed. Some of it has been a big challenge, like putting current work aside to get out a quick fix, I had to learn to stash, then make remote branches, and so on. It's tough, but thanks to google's index of stackoverflow, I'm making great progress!

In summary, Git is good, you should learn about it, give it a try and have patience.

(3 comments)

Start Eclipse faster with -initialize

posted under category: IDEs and tools on April 10, 2009 at 1:46 pm by MrNate

There was some good discussion today on the CFEclipse Users email list about getting Eclipse to start up faster, and I offered this suggestion:

Run this command when you log in to your workstation:

eclipse -initialize

According to the most complete reference I could find on Eclipse's command-line arguments, the initialize command:

Initializes the configuration being run. All runtime related data structures and caches are refreshed. Handy with shared installs: running Eclipse once with this option from an account with write privileges will improve startup performance.

The emphasis was mine, and for good reason. It really works!

In a very cheap experiment, using the windows clock as my stopwatch, I closed my open Eclipse (version 3.5, galileo M6), waited about a minute, then started it again. My PC took a full 60 seconds to load my workspace again.

I closed it, and called eclipse with -initialize through a windows shortcut. The initialize command doesn't really seem to do anything, and it took about 5 seconds to complete. After that, I waited 30 seconds and started Eclipse again, this time it took 16 seconds! Closed it, started it, 16 seconds again!

I guess I would have to reboot to get a cold start time, which is more than I'm prepared to do for today's little blog post. I really don't know what -initialize does under the hood, but wow, what a difference it can make.

(0 comments)
Nathan is a co-manager for the Phoenix CFUG (AZCFUG) and a ColdFusion application developer for an aerospace company in the Phoenix East valley (Mesa). Aside from doing ColdFusion applications, Nathan enjoys playing with servers, hacking with a variety of other programming languages and managing his home theater PC. Nathan got his programming start writing batch files in DOS.
This blog is also available as an RSS 2.0 feed. Click your heels together and click here to email Nathan.