Github has a great feature (and bad, that I'll discuss here) to fork a project. So the fun began, I forked the project, cleaned up a ton of code, made the project more of a tool kit and finally got the code working the way I thought it should. All was good. However, the toolkit was far from done. I had big dreams of really making this in into the toolkit thousands of developers would use. I even created it as a static library that could be linked easily into other developers projects.

Right about at this time, as human as we all are, I was going thru a life changing event (a divorce). Needless to say I was not able to work on the project as much as I would have liked (none at all actually). During this time, a few people had forked the project and began making their own changes. That's the beauty of github. If you don't like what you see, you can fork it and begin making your own changes. Hopefully the changes made are good enough the project that it's forked from will pull this code into their branch. It's a win win for everyone.

Since I no longer had the time to make all the changes on my own, I was able to merge the code that others had made, which in turn made the toolkit even better! This is the the beauty and the beast of Open Source.

Let's go over what I've learned.

The Good

While I was not able to work on the code, others had stepped up. A couple found some memory leaks and fixed them. That was awesome.

Another developer decided that maybe using a static library was not the best idea, since many people found it confusing. So he moved it out of the library and back into the main project. Great! The toolkit still had life.

Github can merge other people's code back into a branch as long as the changes are not too drastic. At this point pretty much all the changes other's had made could be merged with no effort on my end. So why not include the changes? We had my fork of the project going still strong and in many ways I was still in control. (Even when I was not really working on it.) However, I still had the final say that would be merged into my code base. All was good! Or least I thought it was...

The Bad

At this point, the project was stale. I was not checking on the updates, nor even responding to the emails from people who needed help or had suggestions to make it beter. (Sorry guys). There were still forks of the project going on. However it was not from my project, but from others whom had forked my toolkit. By the time I gotten back into having some free time to review the changes again, the project was a complete mess. We had way too many forked versions and some really bad versions began to popup.

To make matters worse, I had developed the toolkit for the iPhone 3 and now iOS4 was out with major changes to the framework. The project was in a deep pile of crap as I'd like to say.

The Ugly

This is where it really gets bad. One of the forks was created from someone who had the best intentions but I seriously judge the changes they were making. I don't think they really knew what they were doing.

Since I was not maintaining my project, this fork now became the fork that people were using because it seemed to be the most active. (I would have done the same) With this version, many bugs were introduced and people were making changes to the code base that made life very difficult to merge back to mine.

I began getting emails from people asking if I could fix my version of the project (code did break with iOS 4) because the other forked projects were so unstable. I became to feel their pain. It's time to get back into the game again...

A New Hope

Yesterday I finally got some free time and went thru all my issues and began to fix the problems that others had found. I fixed the code so that it would run in xCode 4.2 and run on the iPhone 4. I also reviewed some changes that were made by other forks that I thought were good and added them to the toolkit. Someone even created the app Icon, so I grab that and added it too. Thank you by the way!

Now I have the project updated and I hope people can grab this version and begin using the AR toolkit again. I'm so excited about the project again that I plan on making some new code updates to make the toolkit even better!

As you can see, this seems to be the typical problem that happens with an open source project. If there's no one core owner to keep the dream alive, or the wrong people take over, a project can go sideways pretty quickly. I'm glad to be back, I'm grateful for the people who were able to contribute the changes to what I believe to be a good learning tool in the world of Augmented Reality!

Thanks to all the people who kept it going!

#1 Local Repository features

The one advantage Git has over other repositories is how much you can actually do on the local version. Besides doing a fetch, push or a pull, most commands are done locally. The ability to do a diff locally without hitting the server can save a ton of time.

One feature I like is creating local branches that I can do all my work on and not have the fear of messing up the remote repository with my changes because I committed the changes. Now I can work locally, make as many commits as I need to and if I have to rollback I can do so with no worries. Once I have the version that is what I feel is good for everyone on the team to use, I can simply commit to the remote repository.

#2 The staging area

The staging area is a great idea. Sometimes you have code that you're not quiet sure you want to commit but you want to store it in a place while you continue to work on the file. If the changes made in working directory have gone 180 on you still have the code in the staging area. However, If satisfied with the new code, simply add the code to the staging area again. Then use the commit command and the code is moved from staging to the local repository.

The main advantage of using the staging area is that when committing to the repository only the files ready to be committed are actually added. This avoids accidentally sending files in the working directory that may not be ready. Git does not force the developer to have to use the staging feature. Directly going from the working directory to the local repository can be done by adding the -a option when issuing the commit command. However, remember that using the -a argument of the commit command, sends all the modified files that were added previously to the local repository. This has been a hard habit to break for myself since I'm so used to the way SVN handles commits, that I was using the commit command with the -a option. Now what I know of the advantages of staging, I can avoid these problems I've had in the past.

#3 Local Branching is super easy

Local branching allows for the developer to create as many branches without having to have them stored on the the remote repository! Keep one(1) branch for production, one (1) for development where to do all work in, and then other branches for experimental work.

The beauty is that switching between branches is as quick as typing the branch name. Simply type git checkout <Your Branch Name> and the working directory has switched over to the selected branch. It's very easy to then merge changes from each branch. Again this is all done locally. These branches can stay local or any branch can be added to the remote repository.

#4 Cloning a remote Repository gives you the entire repository!

When cloning from remote repository, a complete copy is added to the local repository, not the current version like how Subversion handles it. This alone has many advantages. If working offline because the internet connection is down, or on a train or plane, the entire repository is still available for all the features normally found only when making calls back to the remote repository. The ability to continue to make commits when offline is a huge deal! Commit the changes later when back online!

#5 Github.com rocks

There is no better place to host open source or host your private repositories than Github! Github has a great set of features that are simply amazing. Open source projects are free but to host a private repository will cost a few bucks a month. The prices are cheap and offer so many features that's its a no brainer to use them to host your projects!

Summary

I love SVN but when something better comes along that you can't simply ignore it because your comfortable with something else. I'll still have to use Subversion for some of my older projects, but from now on, all new projects will be using Git and Github.com. Sorry Subversion but it's time we parted our ways! :)

Well I was pleasantly surprised to find out that when I starting using Xcode 3.2 and clicked Cmd + F to bring up the find dialog, that it did not pop up the old dialog but instead a docked version of it appeared in the IDE!  If you've used Safari, you know what I'm talking about.  It now expands  above the editor.

Here is a screen shot of my Editor before I did a find.

This is is what it looks like after I did a find:

Now what's cool is that when you enter the word your'e looking for, they are all highlighted and the first one found is highlighted in yellow.

As you can see above, all the matches are highlighted.  Now if you want to cycle between all of the found results, you can either click the arrow buttons or CMD + G to find the next result. 

Not a huge deal but this new update makes it feel like the rest of the Mac applications in Snow Leopard. I also believe this increases my productivity because I'm not messing with the dialog box, I can instantly see how many results were found!

 If you're not using Interface Builder, then make sure to set the delegate of the textfield to self. I also include the returnType. For example, if the textField was called gameField:

gameField.delegate = self;

gameField.returnType = UIReturnKeyDone;

Implement the UITextFieldDelegate Implement the UITextFieldDelegate for the ViewController is required.

@interface YourViewController : UIViewController <UITextFieldDelegate>

Finally, implement the textFieldShouldReturn method and call [textField resignFirstResponder]

- (BOOL)textFieldShouldReturn:(UITextField *)textField {{
     [textField resignFirstResponder];
     return YES;
}

All the textFields will use this same method, so this only needs to be setup once. Make sure the delegate is set for the textField and the UITextFieldDelegate is implemented for the interface. Finally, add the textFieldShouldReturn method and call the resignFirstResponder . That's it! Now there should not be the problem of dismissing the keyboard if these few steps are followed.

The short answer is Yes but you have to use a couple of undocumented API calls. It's actually quiet easy. Set the cell's editingStyle to UITableViewCellEditingStyleDelete. This is an undocumented feature. Currently the documentation will show that it's a read only property. However there is nothing stopping one from setting the set property. A compiler warning like below will appear when implementing the set property.

To set the style, do it either in the cellForRowAtIndexPath method or implement a TableViewCell object. I'm not going to get into details of how to create a cell, I assume you already know how to do that.

- (UITableViewCell *)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath

{

   // Add your code here to create the cell

    .....

    [cell setEditingStyle:UITableViewCellEditingStyleDelete];

}

The final set step is to actually do something when the user swipes the cell and clicks the Delete button. This is handled by adding the commitEditingStyle message to the view.

- (void)tableView:(UITableView*)aTableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath*)

{

    if (editingStyle == UITableViewCellEditingStyleDelete)    {

        //Add Code to delete from the Data Source

    }

}

That's all to it. A very simple implementation for an elegant solution. I'm still miffed why this is undocumented, so be warned, you could have Apple decline your app because of the usage of an undocumented feature. UPDATE: iPhone 3.0 SDK you no longer have to set the EditingStyle of the Cell.

Move the cursor to the beginning column you want to start highlighting from. Hold down the ALT/Otption key and then press and hold down the left mouse button. Next, highlight the code with the mouse or arrow keys. After the code is highlighted, simply copy it to the clipboard. (command + C Key)

Notice in the image above, I previously pasted the @property four (4) times so that I could then insert the selected code once. To do this, move the cursor to the position of the first @property and paste. (Command + V).

There you go! The columns of code that were highlighted and saved to the clipboard are now pasted all at once. No need to have to paste each variable one at a time!

ALT + Left Mouse button = Column Mode Text Selection