Git: Tying a Remote Branch to an Existing Local Branch

As I was cleaning up my code directory and forking projects to have personal dev branches up on Github, I ran into a problem. I needed to tie a remote branch that I had created to an already existing branch.

So, I had branch already in my list of local branches. I did one of these:

git push ncb000gt master:refs/head/branch

This made the remote branch and then a:

git fetch ncb000gt

Pulled it into my view. Now I have two branches, one local, and one remote. I had changes and commits in the local one that I didn’t want to lose.

I could have tried to solve the issue following the .config method, but instead I decided to do it a different way. Basically by moving/renaming the existing local branch:

git branch -M branch branch_temp

Then, create you local branch that is tracking the remote branch and check it out:

git branch --track branch ncb000gt/branch
git checkout branch

Then all you have to do to maintain the existing commits is merge the code in.

git merge branch_temp

That should be about it.

JSConf 2009 - Where were you?

To say that JSConf 2009 was a whirlwind isn’t giving it’s creators enough credit. A few ways I’d describe it are action packed, intimate, and collaborative. From talking with Chris Williams, that was the goal.

The Overview

Obviously, as the people who were at my talk noticed, I’m not an artist. But, this gives you a bit of an idea of how the conference was laid out. To the left you have the main presentation room, Track A. To the bottom right you have the Track B room. And, in the upper right hand corner was the Hack room, aka the Hack Track.

The point of Track A was to present some information that would take a much longer amount of time to really get across. Ideally the presentations were on a single topic and lasted about 30 - 50 minutes depending on how much room you wanted to leave for questions. Track B was to be able to present on some topic that didn’t need a full 30+ minutes. The idea here was to have more of a discussion format, hence the single large table that allowed for everyone to face each other. Then, the hack track was to encourage people to sit down and just code. The two twinkies/equals sign represent the food area. All I have to say is bacon…nuff said. The food was excellent to say the least and no, there were no twinkies…I’m just a horrible artist.

There was one track that I couldn’t really show on my diagram. This track was the Significant Other track hosted by Laura Williams. The Significant Other track was a way for us techies to bring our…you guessed it…significant others, but not let them sit in a hotel room or staring at a screen of geek speak. Instead these people were taken around DC to do the touristy thing, checking out the monuments, the White House, and so on. Then they even had a shopping trip planned in Old Town Alexandria. No other conference I’ve been to had this _feature_ and nobody I’ve talked to has had that either. /cheer

When I say I was impressed with everything that Chris and Laura did for this conference, I’m not giving them enough credit.

Interesting

From what I was hearing in the crowd, the topics that people brought to the table in both Track A and B satisfied everyone’s appetite. The topics ranged from client side games in JS to Objective-J to server side JS. There were topics on ORMs, distributed browser testing, and data sources. I also recall there being a Track B session on creating midi’s with JS.

Because I am interested in everything, I like learning, I’m just going to pick a few talks that haven’t gotten much in the way of publicity yet that I found fairly intriguing.

OpenGL and Real Time Simulation

Andrew Turner spoke about some work that he and his company have been doing with integrating JS and really high powered graphics engines. As any of you who know me know, I’m really into in 3D engines. Some of what Andrew and his team have built is the ability to create objects within the worlds they’ve developed by using nothing more than JS. You can control many of the elements in the engine with just JS. This means that those people who were originally deemed “just web developers” now have the ability to join teams of game developers/designers to really have a hand in the outcome of a game. While you could use most any scripting language, the number of people who know javascript is quite vast and the concept lends itself to that mass of people.

I couldn’t find Andrew’s slides anywhere. If you can, send me a link.

Client Side Gaming

Games on the client side are an interesting subject in and of itself not only because they are games, but because of the challenges presented. John Resig talked about his approach to making client side games with Javascript and some of the issues. One of the issues and solutions that I really found interesting was his approach to tackling cheating. If you take a game like World of Warcraft, much of the game is controlled by the physics, money, and items you carry. Imagine that you had an interface to give that mighty sword of killing a +300 to damage. While that doesn’t exist in World of Warcraft, most web people use a tool called Firebug. So, we do! Suddenly we can’t rely on the client (browser) to give us accurate information about the user. This dilemma means that we need to have the client pass us specific information however, anything other than “attack” or “move” should be controlled on the backend.

John also talked about the issues around a game he’s working on called Deep Leap. The approach he has taken here to curbing cheating is by replaying the game on the server side. So, in essence he records all the “moves” and pieces that exist and then uses the same JS on the server side that can be done on the client side. This is a really great idea. You are using the same code base which means you only have one bit of code to maintain and it’s a really simple way to remove cheating.

Take a look at John’s slides

Server Side JS

There were a few presentations about SSJS. Kris Zyp, James Duncan, and I all gave Track A talks on our respective frameworks. And, Kevin Dangoor held a Track B discussion on what the #ServerJS group is doing to standardize SSJS. I don’t bring this up to make a plug for the framework I work on. I bring this up as just an example of the number of frameworks popping up with some power behind them and to make mention of the stuff the server JS group is doing.

The #ServerJs group has been working to standardize libraries and modules that plug into SSJS frameworks. One of the issues plaguing the SSJS world is the utter lack of standard libraries. Python, PHP, RoR, etc. all have massive communities behind them because they have huge library sets. But, most of the JS world has been client side till now. So where are the libraries for reading files? What about just the ability to pull libraries in a standard way? None of this has existed till now. So, while we, the framework developers, go about making these tools for people, we can’t really expect anyone to switch over without some basic level of library support. If you are interested at all in SSJS I highly recommend taking a look at the Google Group and contributing to the discussions.

View Kris’ presentation on the Persevere framework

Take a gander at my slides from JS Conf on Axiom Stack

I couldn’t find James’ slides anywhere. If you can, send me a link.

Others

Some others that I wanted to mention include Titanium App by Jeff Haynie, Real Time Web with XMPP by Jack Moffitt, and CouchDB to the Edge by Chris Anderson and Jan Lehnardt.

Fin

JS Conf 2009 was a flurry of information and great ideas. To say it was awesome is insulting.

Hopefully, I will see you all at JS Conf 2010. Till then, keep up the good fight.

WoW: Versioning Your Addons

If any of you are like me, you play World of Warcraft and love your mods. I try new mods all the time in the attempt to better my UI. I tend to look at it as a constant work-in-progress. So, I’m trying to find mods that best fulfill the needs I have in the game while minimizing the overhead created on my CPU and RAM. To go along with my addiction to addons, some of the people I play with have the same mentality I do towards mods and constantly tell me to try new mods.

The problem is that you never know if the mod is going to conflict with your setup. Also, if you are upgrading to beta versions of addons you need a way to just rollback. Normally this is done by copying your SavedVariables directory out of your WoW directory. This is tedious. Enter Git.

Git

Git is a version control system generally used when trying to save time and effort on source code. However, it’s also useful on files that have settings. Essentially what version control software does is allow you to make changes to your files, and then recover older, working sets when you completely annihilate your files. Believe me, it happens. Let’s focus on just Git for now to give you an idea of how it works and we’ll apply it later to WoW specifically.

There are a lot of terms that go along with Git. Much of which are irrelevant to the masses. I’ll explain some of the basics.

A repository is the directory that all your Git information is stored. So, if I was in my WoW directory and typed “git init”, that directory is now a git repository. If I was in my Addons directory and typed “git init” I would have made my Addons directory a repository.

Branching is the notion of creating copies of the repository. These branches store the differences between your sets of repositories. When you create your repository, you are actually creating a branch, among other things. The initial branch is called “master”. You create branches by typing “git branch [new name]“. This will branch the current branch you are on. So if you are currently doing things within the “master” branch, you will create a copy of that branch. To see which branches you have and which one is active, type “git branch”. The branch that is starred is your active branch.

When you switch between branches it is understood as a checkout. So, lets assume that I created a branch called “experimental” (git branch experimental). I am not immediately in that branch, I still have to move to it so that I don’t destroy my stable state. I would type “git checkout experimental”.

To save your changes you commit. This means that you store your changes into the branch you are working in. You do this with “git commit”. Now, know that git doesn’t necessarily know about anything new you are adding to the branch without your explicit say-so. Thus, you’ll need to type “git add .”, where the ‘.’ is the current directory, and then ‘git commit -a -m”Saving mah changes!”‘. This will put all your changes into your branch.

At some point you’ll realize that your experimental branch is your preferred setup and you’ll want to make it your master branch. At that point you’ll want to merge your changes. This is easily done with “git merge experimental master”, where ‘experimental’ is the branch with changes and ‘master’ is your stable branch.

One small detail that I neglected to mention till now is that Git runs in a command line. “Oh noes!” Easy! Deep breaths. It’s ok. There are a few ways to tackle this beast (aim for the legs!). You can use the Windows installer for Git or Cygwin. Either will work. If you are using Linux or a Mac, get your terminal on. For the purposes of this I’ll go through it with the Windows installer for Git. For the rest of you the commands above should work assuming you installed Git correctly.

Open “Git Bash”, should be on your Desktop. Once there you should see a command line window (black screen, white text and a blinking cursor). This is good. Once you are here, any of the commands I described above should work.

I could go on for days describing the details that are Git, but this should be the necessary information for your success. If you are interested in learning more, check out the Git documentation.

Git with WoW

Now that we are past some of the basics, lets get into how you can use it in WoW.

When I’m working with new mods/addons/etc. I first go into my Git command line (see above). I change into my World of Warcraft directory.

cd c:
cd Program\ Files/World\ Of\ Warcraft/


Once I’ve moved into my WoW directory, I need to decide what is important in terms of layout. We have our Addons directory inside of the Interface directory, and we have our settings inside the WTF directory.

I’m going to change into my settings directory.

cd WTF/Account/AccountName/

This puts me into my actual account. From here, I want to create a repository because everything here is important to know about when it changes. Note, Auctioneer type data isn’t necessary to know, but will be included here if you use the mod. So I create my repository and then create a branch of the data so I can muck around with settings and not disrupt the stable set.

git init
git add .
git commit -m "Initial commit to stable branch"
git branch experimental

Now that I have my stable and experimental branches, I can move between them by checking each of them out.

git checkout experimental
or
git checkout master

The above allows me to move between branches without any issues.

So, if you’ve gotten this far, that means you’re now ready to version your “settings” files. But, you now need to make sure that you keep the versions going so that you can roll back anything you might mess up later. Let’s say you’ve been gaming for a while and found that your unit frames sucked being right in the screen or that grid was good enough for party frames. So you make some changes to some mods. You need to make sure you commit those changes back into the branch you are working in.

git commit -m "Removed party frames, grid is enough."

Now you’re cooking with fire? Welcome to being a mage…

You’re done with your settings. Congrats, lets move to Addons. I’m going to assume that you are in your WoW directory (see above if you’ve forgotten).

cd Interface/Addons

You need to repeat the steps above.

git init
git add .
git commit -m "Initial commit to stable branch"
git branch experimental

You can now switch between branches and add/remove/modify mods.

When you start getting into this, note that you don’t need to commit every time you leave WoW. It’s just not necessary to track every settings change unless you feel you need that level of control of your UI and the settings within.

My Approach

I usually run on my master branch for a while and then when I get the urge to change the UI spend a few hours doing it. So, what I tend to do is this:

• Run on ‘master’
• Create a branch: ‘experimental’
• Work on my experimental branch till it’s finished. This includes removing addons (git rm XPerl*).
• When I remove items from my UI I usually commit the changes I’m making and state why. This allows me to be able to switch between branches should we be raiding or if I need to run an instance with someone.
• Once I’m done making my changes and am happy with the outcome, I merge the experimental back into the master.
• Rinse and repeat.

There are uses for Git here without just massive UI modifications too, but I tend to really use it for that.

How do you use Git with your WoWing? Are there any things I missed that you prefer to do? Let me know. Also, let me know if something doesn’t work for you.

Scratching An Itch

A couple friends an I were talking a few weeks ago about building applications. There are a handful of reasons for creating websites or web apps. The topic of discussion that day was about applications that do something you need and not just about the ideas, but about finishing those projects.

To say that creating applications to scratch your own itch is fun is an understatement. Usually you are heavily invested in the idea and so you have a lot of drive to start it out. I love the idea stage of ideas. I have a lot of them and have a whiteboard in my apartment covered with ideas and mini-architectures around those ideas. Yet, most of them don’t seem to happen.

I know that I am pretty well motivated to create stuff that I’ve bought into, so what are the reasons that these projects seem to stay stagnant in the idea phase.

Exhaustion. The first killer is exhaustion. The reason this ruins the drive to do more is that when I get home from work where I’m trying to solve other problems all day, I’m not necessarily focused on pushing through mine. Doing more work on top of the work I’ve already done doesn’t sound like loads of fun to me.

Ideas are fun. Plain and simple, work is hard. Running around thinking “I can make it fly and produce magic ponies too!” is great. But, when I’m the one that has to produce the result of the idea phase, it becomes a major stumbling point to getting something done.

Broad ideas are broad. Without defining a limited scope to what you ought to be doing, your focus and ADD will take you in 90 different directions. Rather than getting something done, you’ll be focused on starting a number of different things and leaving others to hang out in a partially working state.

Lacking skillset. When you are lacking a certain something to get the project finished, you will find it very frustrating to not be able to just hammer on the rest of your idea.

So what do you do?

Focus. Harness that N.A.D.D. and get something created. The original idea doesn’t need to be your “pony, dragon, rocketship” release. It’s your proof of concept (POC). You need to see that your idea _can_ work. You being the brainchild behind it, make it work and then add onto it.

Give yourself a deadline. When I want to really get one of those projects on my whiteboard done, I give it a deadline for a POC. This means that if the idea isn’t done by that date that my interest either isn’t there, or that the problem is far more complex than I originally thought. If the idea is too complex, I’ll know early on and will have to rethink my approach. Otherwise, I should be able to push through. And, generally by applying a date to it I know that my interest level is there. It’s just a matter of doing it.

Have people to push you through the “hard times”, as my friend called them. The hard times are when it’s not easy going, when you need to sit and actually think about the solution and the best way to implement it. Often times when the hard problems hit there is no obvious solution. This makes it quite a bit more complicated and if you can have someone around to get you through those points, you’ll be more likely to succeed. The point here is that you have someone or a group of someones to hold you accountable for moving the project forward to completion. Believe me- this doesn’t always work, but when it does it is a good way to keep yourself on track. Also, it will allow you to get feedback about what you are doing. To steal an idea from the agile methodology, “Release early and often”. Meaning, put your project out there sooner rather than later and make smaller incremental changes. There are _many_ benefits to this practice, but those are better left for another post at some point.

Lastly, if you don’t have a skillset, you are fine. Just keep in mind that you might not be able to get some part of the project working for a bit. Either read up on it and learn it or outsource it. Phone a friend, check in the freelancing sites, etc. I know that personally I am _horrible_ with design. If you want squares with black and white, I’m your guy. The point here is knowing your limitations, and finding a way to push through them. This tends to be my biggest competitor to actually producing a full project for public consumption.

Now, if I were in your shoes I’d be thinking, “What do you know? You’ve got a list of untouched projects.”

Although that is true, this is what I’m using to start doing to tackle that list of projects. I’m curious to know how some of you hunker down and get your stuff done. I know that some people use Backpack and/or Basecamp. I know others use events like Hackday to get their ideas done.

I’ve tried those and they didn’t work well enough for me. The Hackday approach is what has worked best for me but there are tools that are other tools helping me out here.

The first tool helping me is Git. This version management tool allows for some very nice things. If you haven’t taken a look at Git yet, do so. You’ll be glad you did. Another tool, based on Git, is Github. While Git itself is great, having a central repository is very nice for having your source be always available. I’ve been putting all of my projects up there and while the decentralized model of DVCS is still alive and well I know that I will always have access to the source so long as the internet exists. Lastly, telling people about the projects is the key to me getting the work out there. I have people to push me through those hard times and friends that can help me to complete the design work that I seem to be exceptional with.

Back to that conversation I was having with my friend; one thing I realized in that conversation is that usually when you have smaller projects or ideas they do not require a team of people architecting a larger solution and in fact that collaboration can hinder your progress. They require a few hours of attention to just focus and hammer down on. When I started doing that, a few of my projects started to take shape. You just have to dive in and see where you come out. You don’t need the communication overhead produced from more people on the project.

Ultimately, I don’t know that this approach is going to work in my attempt to get some projects done, but so far so good. I’ve thrown a bunch on Github and am going to be displaying them here as well. I’ll be looking forward to some feedback. The licensing for now on most of my stuff is AGPL, but that could change shortly. The reasons for this are all the topic of another blog post about licensing.

New Host, New Posts, and the Inbetween.

Any of you who recently came to the site may have seen a “Godaddy” landing page. I’ve recently moved my hosting to Slicehost and am managing the domain with Godaddy. It’s cheap and has an easy to use control panel. I was tired of managing my domains with a number of different services. Thus the move. Sorry to anyone that I inconvenienced with that.

That being said, I’m going to be writing a bit more and about more topics. Normally I try to keep it business oriented but I’d like to get more into the CS side of things and talk a bit more about random things that are coming up. I think that doing that will make me more apt to write.

Also, I’m likely going to give this blog a face-lift as it’s had the same design since I started.

So, look for more soon!