Tag Archive for github

Code Journal 1.4.0 Update

Code Journal LogoI am Happy to announce that Code Journal 1.4 has just been released on the Mac App Store. We took special care to respond to your feedback both in terms of performance and of course new features.

I am particulary fond of the new less wordy way we are naming and dealing with repositires in the title bar and also we’ve added the match requested manual refresh button. For a more complete list of changes, please see the release notes on the App Store.

MDNetworking: My Little Networking Lib

Disclaimer: This is in no way a 1.0 codebase and I strongly recommend against you using this in production.

Summary: MDNetworking is a small Apache 2.0 licensed Cocoa / Cocoa Touch library. It is intended to be suitable for use on iOS7+ and Mac OS X 10.8+ but it may in fact be possible to get it working on older version of iOS and OS X. My intention in creating this library is not to make yet another heavy Cocoa networking framework that is going to solve the meaning of life and the world’s problems. I merely want to present a relatively simple and easy to use facade of NSURLConnection and the like.

Contributing: I’m open and welcome contributions from the community, however, any contributions that don’t adhere to the present code-style will be rejected.

Code Journal 1.3.4 Update

050413_1245_CodeJournal1.pngCode Journal 1.3.4 is now available on the Mac App Store for free. This update includes a number of small bug fixes. There are a lot of big changes coming to Code Journal over the next few months and I think it is really going to take the app in a great direction.

I’ve taken your feedback on the app and in particular feature requests and, though no new features are included in this update, new features and the restoration of the Gist functionality is on its way.

Stay tuned for more updates!


My Open Source Initiative

I’ve been looking at some of the older code I’ve had sitting on my various hard drives and Dropbox accounts and realised something: a lot of this code is not that novel. There is nothing wrong with it, but a lot of just solves problems that I find myself having to solve over and over again.

So, I am going to try to open-source as much of this code as possible. There are of course a few conditions to this: I will of course only be open-sourcing code that I actually own (file that under ‘duh’), the code must be theoretically useful in a very general, and I will need to be able to use the code again in proprietary projects.

Basically, what that all boils down to is that I’ll be using the Apache license for most if not all of the code and there won’t be full applications open-sourced.

You can find all of my open-source on my Github. I’ve already started by open-sourcing a simple Ruby script that I use for Mac and iOS development.

Git Bootcamp

I’ve gotten a number of emails recently from developers that are new to Git and want to know how to easily get started with it. As I have stated before, I do think that it is very important that you have some sort of understanding of what a tool is before you begin using it, so please if you have never used Git before or are new to version control in general please read Pro Git before you blow up someone’s project.

For the rest of you: Git is a distributed version control system that was invented by Linux’s Linus Torvalds for use with managing the source for the Linux kernel. This does not mean that Git is not a cross platform tool; in fact, you can use it on pretty much every operating system in one form or another.


Use the .gitignore file to make sure that you are not adding unneeded files to your source control. What’s an unneeded file? An unneeded file would be anything that your app creates, such as a binary and any configuration files for your IDE.

Don’t be Afraid to Commit
You should be committing your code locally early and often, so if there is a problem you can reset and get back to a sane place without losing work. A good rule of thumb is that if you have been working on something and have not committed in two hours, that is probably a sign of a problem; for instance, it might suggest that your code is not sufficiently modular and may need to be refactored. When commiting make sure you include a logical com

mit message. If you are working off of a bug tracker, consider including the ID or name of the bug that you are fixing with your request. A common format for commit messages is:

“Basic Info”

“More details on your commit”

Make Like a Tree and Branch
Git encourages frequent branching and merging of branches. There are a lot of branching strategies

out there but the one I prefer is to branch per feature. In my mind, this creates a logical flow of project process for the person (your manager perhaps) who is looking at the source. Be sure to name your branches in a logical way; “my_branch” is not a good name, but “feature_twitter_integration” is.

Don’t Rewrite History
Rewriting history is evil. It unnaturally alters your source control and prevents future developers from getting a clear (100% accurate) understanding of the projects progress and any issues that it may have encountered.