dannygreg.com

The world of version control (if there is such a thing), is currently in a state of flux. The old guard of centralised source control management systems are under attack from the young and up and coming distributed version control systems.

I was first brought into this world when I was introduced to Subversion fairly early on in my programming career. I certainly took my time to get familiar with the system but as far as I was concerned, it made perfect sense and it worked.

Fast forward a few years and I was thoroughly frustrated by “SVN”, not the workflow, but the fact that it didn’t seem to handle anything even mildly advanced. Branching was a joke and merging was hugely painful.

It was around that time when I was introduced to Git. Git was an entirely different way of thinking about version control. As opposed to having a centralised repository, in which you check in changes. The repository is on your system. You then “push” and “pull” to other repositories located on your colleagues machines. There is no enforced “central” repository, but you build and release from whichever branch you feel is the most appropriate on whatever machine.

Here is problem number one. I fundamentally disagree with that being a good way to release software. If you are a company you are just inviting confusion. It is much clearer to have a centralised repository that you are working towards. Sure there are services like GitHub, but as far as I can see that is not using the software how it was designed to be used, whether you consider that a problem is up to you.

However, it is not that simple. Git actually worked, and worked well. True branching and merging changed the way I managed my code and on top of that it is blazingly fast. I also found huge benefits in having a local repository. It became cheap to browse my entire repository history and “checkout” older versions. On top of all this, Git introduced some great features such as “git stash”, a system allowing you to temporarily store changes without properly checking them into the repository. So what I needed was a system which is centralised but gives me the flexibility and features of a local repository. I of course, therefore, looked at git-svn (which comes as part of the standard Git install).

This brings us neatly to where I am now. Git is a fantastic piece of software, but the fact that I fundamentally disagree with the principles under which it is designed makes me very hesitant to invest hugely in it. I also dislike the fact that my workflow currently relies on a “plugin” to communicate between two systems, one of which is far less sophisticated than the other.

So recently I undertook a lot of research to see if my ideal SCM system existed, one which would allow me to have a local repository as well as committing to a centralised one and also provided me with all the new innovative version control features.

While undertaking this research I made a discovery that worried me. The question of centralised vs. distributed has really polarised people and there was very little occupying the middle ground where I sit firmly. No one seems to want to make a nice hybrid of the two, but instead make a one-sided system and preach about why it is the best way to manage source code.

Everyone that is, except Bazaar. Bazaar, is an often overlooked version control system, and one that seems to be the only one that is acknowledging that a middle ground exists. Although it does concern me a little that it describes itself as a DVCS, maybe its because that’s what all the cool kids are these days. However, to me it seems to nail what I see as a much overlooked facet of source control: flexibility. The directly supported workflows in Bazaar are simply unrivalled by any other system.

Sure there are plugins or extensions written for other systems but to know that you are using the software in a way that it has been truly designed to support is very gratifying. However, I am using git and git-svn for all my work privately and at work, why not Bazaar if I think its so great?

The answer is interesting. The first explanation is relatively simple. We use Subversion at work and that isn’t changing at least for a long time and therefore what I use must work, and work well, with SVN. Bazaar still requires a plugin to communicate with Subversion and bzr-svn is no where near as robust as git-svn which. Beyond that, if you remove the advantages of using Bazaar on both the server and client side I gain nothing using it rather than Git on my local machine.

This brings me neatly onto the second reason. Git has spoiled me in terms of speed and Bazaar just feels too slow when doing merges. Looking at the development of Bazaar it seems that they are at work on a whole new engine on the back end that should really bring speed up but right now it feels sluggish. It’s still a speed demon compared to Subversion, but use any one of the newer systems and that is the case.

The third reason is user-base. Bazaar has seen very little uptake compared to Git and Mercurial. Ubuntu is the only big name using it and there is one website offering hosting: Launchpad. Which only hosts open source projects. Considering the trust you put in a source control system, having a nice large user-base to fall back on when your in trouble is an important safety blanket. How many Bazaar experts do you know? Compare that to how many people you know who are a dab hand with Git, yep….. exactly.

So what I have just done is tell you why Bazaar is my ideal SCM system and why not to use it. Which nicely illustrates my frustration with how things are at the moment. Git is the only system I’ve tried that performs in a way that I am impressed with but Bazaar is the only system that seems to be going down a design path that I like. I can only dream of a world where Linus decided to acknowledge that my precious middle ground existed and extended Git to support centralised elements. Until then I will keep plugging away with git-svn.

As I sit down to write this I am tired, both physically and mentally. This is because I chose to spend my weekend doing something slightly different. I attended Yahoo’s open hack day in London for the first time. This meant that I spent 2 days in the same building, and 27 hours straight doing what I do on a daily basis. This tells me two things:

1. I am completely insane.
2. I am lucky enough to do something I love for a job.

I am not going to discuss the process of designing the app, or even the app we built, there is plenty of that form of goodness over on the Realmac blog, you can also download the app and source over on our product page.

What I am going to talk about is the code that the hackethon produced and the effect that it had on me as a programmer. As well as a bit on the team dynamic.

Hacktastic

In terms of the code it produced is concerned, it is awful. It is the very definition of a hacky product on the back end, there is no class structure, code is copied and pasted everywhere and bits were bolted on to other bits until it worked.

We didn’t sit down and decide “lets build a hacky app” so how did it get that way? The answer is pretty obvious to me: we were designing while we were coding. It is now more clear to me than ever that this is a terrible way to build an application. As the app changed several times during development, the class structure was inexistent, there is no clear MVC and no consistency. If you want to take one thing away from this blog post it is to thoroughly plan your back end before you write a single line of code. Practically this means, essentially, make sure you thoroughly spec out your app. This is something much easier said than done.

I have always considered myself a bit of a lazy programmer, I didn’t particularly like doing the correct thing if it meant a lot more effort for me. Terrible I know, but I have definitely improved on that front. The reason I can say that with a fair amount of confidence is that I discovered something: I really don’t like writing hacky code.

The most painful moment for me was when we started directly accessing instance variables. Now this is something I was “brought up” not to do and it was weird to start doing something so against the grain of how I usually program. Although not writing accessors, or using private properties (which are my preferred method) saved us a lot of time over 27 hours, it wasn’t half hard. I can’t help but think this is a good thing.

Rushing your code has more effects than just bad design and bad practice. Code structure and readability take a huge hit too. I think this is a slightly more complex issue than being just a direct affect of the former problems. I found myself in a curious state where, I had decided I was going to write lazy code so I was starting to put effort in to doing the wrong thing. Yes this was around 4/5am, but it was bizarre. I would half write something the “right” way then re-write it a hackier way. That is a clear net loss of time. Not great considering the amount of typos I was typing.

Having to maintain such rushed code was also a huge problem, especially when we started hitting the late hours. The biggest problem Keith and I found was that it was next to impossible maintaining each other’s code. Although we had split the workload evenly there are times that you need to interweave code. That became nearly impossible under the conditions.

Comments…. well… when they did happen they were making excuses, or making bad jokes. Says enough really.

The point that I learned from all this is that what you think will take you less time usually ends up costing you more in the long run. Best practices were (probably) created for a good reason, stick to them and they will pay you back in the long run.

Hitting the Wall(s)

The affect of sleep depravation was interesting to monitor during the night. I found my mood was far more relative to how well it was all going rather than the time of the night/morning. I was far more awake and alert at 5am when it was all coming together as opposed to 1am when I was battling with Upcoming’s “interesting” API choices.

Having a reason to keep going is important. If you are stuck on something for more than half an hour, move on to something else and come back to it later. This applies to coding normally but in an intense situation such as a hack day you need to move away from staring at one particular set of code. When your brain is that overworked you really won’t be able to see problems, no matter how obvious they are. I was puzzled several times by missing semi-colons around 5am.

Team Playing

Working for 27 hours straight can be a stressful situation. I am lucky enough to work with my mates on a daily basis and I would suggest that anyone who attends one of these hack days does so in a team of people they know, well.

There was a lot of laughing over at the Realmac table and we made a lot of bad (unrepeatable) jokes which kept spirits high and that is important when your staring down the barrels of a mission critical bug at 4:30am. As a team member you need to make sure you are willing to do anything asked of you, and cut your team mates some slack, they’ve been up for 30 hours too. High fives were a plenty around the team and it feels very vindicating to have another member of the team tell you how awesome the thing you just spent 2 hours working on is. Dish out the compliments.

As a team manager make sure you divide the tasks up effectively and make sure no one is without something to do, there is plenty to go around. Someone with nothing to do is a quarter (in this case) of your work power done and they will quickly become tired and un-interested.

Its Fun

It was hard work, very hard, but I am hugely proud of what Dan, Nik, Keith and I accomplished in 27 hours. To have Yahoo! employees telling us how much it rocked was also a new, awesome, experience. It had some downs but mostly ups and I got to spend 27 hours with some of the worst joke tellers I have ever met and it will stay with me for a long time.

I strongly recommend attending a HackDay but I have one principle piece of advice: find a comfy chair. I sat in the same one for 24 hours and I wish I had picked a beanbag.

A couple of nights ago I made a very difficult decision and a very difficult phone call.

I have decided to call it quits on my “second job” as a guitarist in the band Silent Disguise.

It was becoming painfully obvious that I couldn’t keep going with the band while working at Realmac. We were getting more and more weekday gigs and travelling up to London a couple of times a week was beginning to take its toll.

I felt I had to make a decision about what I wanted to do and code won out. The result is I will now have a lot more time to devote to Realmac and other code related projects.

I also have changes planned for this blog which will result in much more regular posts. Stay tuned.

NSConference is coming up in the UK and I would thoroughly recommend picking up some tickets and coming along! The speaker line up looks really good.

Some members of Realmac (including me) will be there and it would be great to meet anyone so come and say hi!

So for a while now I have been wanting to give something back to the cocoa community, since this blogging thing clearly wasn’t working out too well :p.

I got into podcasting through the Mac Review Cast, as I’m sure you know, but sadly my segments faded to nothing as I found myself consumed with cocoa development.

After appearing on a number of podcasts done by the, superb, Scotty over at the Mac Developer Network, it was becoming clear that a podcast could be the way to give back to a community which had given so much to me.

It was only after meeting Kevin on one of the said podcasts, and a relationship which sprung up primarily over twitter that the seeds were planted.

The idea of the podcast is not for us to sound like experts and preach to an audience, far from it. We will each pick a topic which we have battled with that week and tell what we have learned. The other one of us will listen and ask any questions, hopefully to cover anything that wasn’t made clear. We think this is a pretty nice and unique format that should be easy to listen to and learn something.

So head over to the website and subscribe to the feed, at the mo there is no iTunes link but that is on the way

Well I am writing this from my hotel room in Paris after demoing LittleSnapper to some members of the press for the first time, to some very positive reactions.

I am not going to tell you too much about the app here except to point you to the homepage and the official blog post as they cover a good set of the basis. Just keep in mind that there is a lot more to come!

I will of course be blogging here but if you really want to keep up to date you can follow @littlesnapper on twitter and subscribe to the Realmac blog. Those are the 2 best places to keep up to date with LittleSnapper related news.

If you read the Realmac blog you would notice that there was a rather interesting blog post that went up recently.

We (the team) are heading to Paris for Apple Expo. We aren’t having a booth but we are doing something that is enough to make me hugely excited.

We are going to be announcing a new product. Something completely unrelated to RapidWeaver and aimed at a slightly different audience. Beyond that, it is what I have been developing since I have been at Realmac and have been dying to tell you all about it.

Once we are done with the expo we will reveal the next iteration of the Realmac website that will contain info on this new app. Then everyone will be able to see just what RapidWeaver’s new little brother can do.

Let’s get snapping!!

Well, after a brief session of downtime the site is back online.

I decided to move my hosting from some ultra-cheapo stuff from Godaddy as the site was becoming noticeably slow.

Mike, and the fine folks over at MacDock were great with the switch-over and hopefully you will notice a nice boost in performance now the site is sitting on some Apple hardware!

Just a quick post to say that 280North released their web framework Cappuccino today.

Its Cocoa for the web.

No seriously: its Cocoa for the web!!

I’ve been playing with it for a while, I love it and I’m trying to think of excuses to use it! (Then I realise my current work-load and that quickly changes).

It is seriously cool, you program in “Objective-J” which is syntactically almost identical to Objective-C so if your used to cocoa you will feel right at home.

Just head over to the site and give it a try, meanwhile I will try and get my jaw up from the floor….

Its been a while now since the “MacDevNet” opened its doors to membership. Among the perks, which you received in return for you small, $25, membership fee, were significant discounts on some new video tutorials created by the man himself: Steve “Scotty” Scott, the host of most of the MDN’s podcasts, some of which I have appeared on.

To start with there are courses available on memory management, something simply vital to beginners, and StatusItems. The memory managment course being far more extensive, although that is due to the depth of the subject itself.

I had a good watch of both and, although I am not really the target audience for either, I came to some pretty solid conclusions.

Video Length

This is an interesting topic because both of the courses take complete opposite approaches. The memory management course is broken up into 13 episodes, mainly being between 3 and 5 minutes in length (although the introduction is significantly longer), covering distinct sub-topics. The StatusItem course is one video which is 24 minutes in length.

For me, the episodic approach is the way to go. The StatusItem course did feel like a big chunk to swallow at once and the lack of any chapters or breaks made finding certain segments to re-watch fairly difficult.

That being said, I would have liked to have had a couple of the videos in the memory management course be a little longer. It felt broken up in the right places but there were a couple sections where I felt it could have done with dwelling on a certain topic a little more. However, that is pretty severe nitpicking.

Content

I am a great fan of learning by doing. I learnt programming nearly exclusively through examples outside of the classroom, whether thats a bad thing I’m not sure, but I’d take a well documented example over pure documentation for learning something new every time.

So it was great to see a high level of tutorial code demos, guiding you through, with well crafted examples, the theory lesson before. I wish I had had the memory management video while I was learning cocoa, it would have saved me a fair few “gotcha”s.

The content is thorough, but not overwhelming. This is especially true of the memory management course which contains a lot of, nicely explained, background information, which really helps you understand why you are doing things as opposed to just telling you what you should be doing.

Presentation

On the whole I thought the courses were extremely well presented. They are in the form of screencasts (there are some distinct ScreenFlow calling-cards to be found), with keynote slides, code demos and a voice-over. If you have seen an Apple training video from WWDC, then this is a very similar format. Although much more demo, which I like.

There is an issue, where the keynote animations haven’t been captured correctly and so do look pretty stuttery. Its irritating, but by no means does it interfere with the content.

Scotty’s script is well written. Clear and concise without patronising the viewer. There were moments where I had to skip back a bit and re-watch but they were rare and probably more to do with me becoming distracted than anything else.

Conclusion

Overall I think the videos are a very valuable resource, I would love to see the amount of courses expand to offer a library of video tutorials to aid both beginners and old-hands alike. It will be interesting to take a look at the amount of courses offered in a year or so’s time, it may be that it becomes another great cocoa resource (such as CocoaDev and CocoaBuilder). I certainly hope so.