Subscribe to
Main blog
Tumble Log

Solving .Mac sync problems

I use a Mac Pro for work and I have a black MacBook for everything else. Managing two sets of keychains, calendars and bookmarks can become a giant pain (“I thought I bookmarked that site…oooh, it must be on the other computer”). Thankfully, .Mac sync keeps the important stuff synchronized between both machines. Mostly. Recently both my keychains and bookmarks had not been syncing properly and nothing I tried fixed the problem.

I was about to give up when I found these instructions on Ars Technica for fully resetting your .Mac syncing. The instructions are straightforward and easy to follow. I followed the procedure on both of my Macs and everything seemed to be golden again. Except bookmarks. My bookmarks would not sync at all.

Turns out there is a problem with .Mac syncing and Safari 3.1. I found a solution thanks to a post on DaringFireball that pointed to an Apple support document. The solution is to quit Safari, run the following command and then restart Safari and sync again:

defaults delete com.apple.safari RegisteredSafariSyncClient

Everything seems to be syncing smoothly again. For now.

I recently changed hosting providers and I am still in the process of moving everything over. One headache that I don’t need is recreating all of the Subversion repositories that I had hosted on the old service. So, I have decided to move the code for my app_version plugin to GitHub.

The plugin’s code is now located at http://github.com/toland/app_version. You can clone the repository using the following command:

git clone git://github.com/toland/app_version.git

Campfire theme for Colloquy

I occasionally use IRC, and Colloquy is my preferred client. The default theme is OK, but not great. Recently, I stumbled upon a Colloquy theme that is based on 37signals’ Campfire chat application. It makes the Colloquy chat windows much easier to read, in my opinion.

Github goes live

Following up on my earlier post, GitHub is now officially live (hat tip: Ruby Inside). So, what are you waiting for, got host some code!

Be sure to checkout GitHub’s Guides, including the list of cool and unusual Git techniques. Finally, the aforementioned Ruby Inside post also pointed out this Ruby and Git roundup at InfoQ.

It’s all about Git

Git seems to have gained a lot of traction lately. Just last week the Ruby on Rails core team announced that they are moving the official Rails source repository to Git. The core team took a lot of flak for the move, but I think it is a good one.

Rails will be hosted on the upcoming Github site, which looks promising. Of course, Gitorious is a similar service that has been around for a little while and repo.or.cz has been around for longer still. The cool thing about these sites is that they can provide advanced version control hosting due to Git’s simplicity. Github, in particular, has some impressive features.

Many people who are used to centralized version control systems don’t immediately see the value in a distributed system like Git. I think that moving from Subversion to Git is like moving from Java to Ruby. If you write Ruby code like you write Java code then you are likely to be disappointed. In order to get the most from Ruby you have to change the way you think about software development and latch on to concepts like duck typing and metaprogramming. The same is true of Git. If you use Git like you used Subversion, it is going to be a disappointment. Once you are comfortable with the distributed SCM model, and begin to take advantage of features like cheap local branches, then you will be much happier with Git.

Tim Burks says that with distributed version control systems like Git “‘the world is flat’ for programmers”:

All participants have the freedom to make whatever innovations they want and the opportunity to promote their changes to the public. Because all repositories are equally functional, the project leader has the ability to act as Brooks’ chief architect, pulling and filtering changes back into his or her personally-branded version.

This is how Linux kernel development happens and it is surprisingly liberating. Development tools tend to be quirky and we accept the little oddities as the cost of doing business. We become insensitive to the quirkiness and accept it after a fashion. These little nuisances wear grooves in our daily development routine and it can be hard to escape those grooves.

Ryan Tomayko describes a thorny version control problem and how Git solves it handily. The point isn’t that Git has Feature X which other systems lack, it is that Git does not impose unnecessary cruft on your workflow:

The thing about Git is that it’s oddly liberal with how and when you use it. Version control systems have traditionally required a lot of up-front planning followed by constant interaction to get changes to the right place at the right time and in the right order. And woe unto thee if a rule is broken somewhere along the way, or you change your mind about something, or you just want to fix this one thing real quick before having to commit all the other crap in your working copy.

It is different, but sometimes different is good. It is also frustrating and the interface can be a bit odd at times. But the interface is getting better and the frustration subsides as you begin to “get it.” All in all, now seems to be a good time to get comfortable with Git.

Learning from games

Bob Cringely wrapped up a three-part series on education this weekend. The series (Part 1, Part 2 and Part 3) provides some salient insights into our current educational system. For example, in the final article of the series Bob points out that the actual goals of the educational system don’t often match up to the lofty ideals that are often attached to it:

Part of any answer is figuring out what education is for. We use it for paying dues, for passing time until a certain level of maturity is reached. We use it for networking and finding mates. We use it for acting goofy at the expense of our parents. And we use it, to some extent, to learn what we need to know to get by.

He then wonders what education will look like in the future. One possibility he throws out is that games will replace much of what we think of as “classroom education”:

If you play a Beowulf game for 20 hours and it includes all the characters and narrative of the book, will you have mastered the material well enough to pass a test? Probably.

This is an interesting thought. My first reaction is that I don’t remember most of the story, or facts, in games. The assumption is that the details are made up and simply provide an excuse for you to shoot some aliens…so why remember them? This isn’t always true; Mass Effect has a wonderfully rich backstory and the information is well presented within the game.

Still, there is the problem of knowing when the game content is purely fiction and when it is not. Since games are an entertainment medium that is driven almost exclusively by fiction it might be difficult for players to make that distinction. I like the idea, and it will be interesting to see if things play out the way Bob envisions.

OOP is a tool

I spotted this comment to a lengthy article about the proper use of inheritance in Object Oriented programming:

On one of the ‘communities,’ someone had a sarcastic response to the Final == Good article: To boil the article down: OOP is hard. Let’s make it as non-object-oriented as possible so that things don’t get too complicated!

I think that’s actually correct in a way. OOP actually is hard to get right. Encapsulation is not hard, it is a simplifying principle. But inheritance is seductively easy in the trivial case but hard to get just right in the wild. Thus, the admonition to favour composition.

That does’t mean we never use it of course. But I am not embarrassed to say that I think inheritance is hard to get right.

This strikes me as odd; the whole point of OOP is to make it easier for programmers to conceptualize and build complicated software systems. If inheritance is complicating the issue rather than simplifying it, maybe OOP needs a rethink.

The only “right” way to do OOP is the way that helps the programmer deliver high quality software in a reasonable amount of time. This isn’t something that strikes me as capable of being objectively right or wrong. I think that there is a danger in overthinking issues like this or in assigning too much value to being “object oriented.”

  • Cringely on education: While it is fine for society to create opportunities for advancement, what’s more important is removing BARRIERS to advancement. And for the most part that’s not what we are about.

Darcheology Screenshot

You ask and I deliver. Mark asked for a screenshot in a comment to my original post on Darcheology. So, here it is:

darchy.png

(Click the image to see a larger version)

Update to ANSI Smalltalk

While doing some Smalltalk related research, I ran across this announcement on Smalltalk.org from last October:

Fellow Smalltalkers,

I have had a conference call with representatives of INCITS and it seems that getting the process restarted to revise the ANSI standard for Smalltalk is very doable.

The first step is to submit a proposal for the project of working on the Smalltalk standard. If the proposal is successful the outcome will be some form of committee which we must then populate and put to work.

This is exciting news. I am glad that some movement is taking place to update the Smalltalk standard. A stronger Smalltalk is good for the whole dynamic language community.

I think that Seaside has had a revitalizing influence on Smalltalk similkar to the influence Rails has had on Ruby. There is one critical difference between Ruby and Smalltalk: Ruby is much more approachable for the average developer. Ruby makes use of the standard development toolchain of a text editor and command prompt. While the Smalltalk environment provides great tools, it manages to do so in a way that is completely alien to many developers. I am speaking mainly of Squeak here, but I have also used VisualWorks and it isn’t any better.

Older Posts »