Mat Schaffer's Blog

I’ve been having so much fun with Inkscape lately that I thought I should share. I basically got started with it when my wife and I ended up with no other option for our Christmas cards but to decorate our photos ourselves. Apparently most photo places don’t do Christmas templates in a 4x6 format. So I downloaded Inkscape, bought a set of Christmas-styled stencils from iStockPhoto.com and we went to town.

Then she wanted sparkles. Sparkles… Our stencil set was sadly lacking sparkles. So I did what I always do when I need to learn something: I googled it. And found this lovely tutorial which showed me how to make a sparkle. It worked out great and the Christmas cards looked awesome. I enjoyed the process so much that I subscribed to heathenx’s RSS feed of Inkscape screencasts.

If you’re a coder interested in learning how to create some basic visual elements, I highly recommend checking out screencasters.heathenx.org. It’s basically RailsCasts for vector drawing. So far I’ve only watched the two screencasts, but I feel like I’ve learned a lot already. It also has a similar relaxation appeal to painting happy little trees.

Who knows maybe one day I can even make the jump from engineering to design…

or not.

As an update to my previous post, one of my coworkers found that this technique was also applicable to migration between Subversion servers and that using git as intermediary was actually a bit more graceful than the traditional svnadmin dump/load approach. Git wins once again!

The one thing he noted is that this ends up with occasional 0-length patch files, I’m guessing from commits that only modified svn properties. These files will cause git am to abort, but can just be deleted for the re-import.

Here’s the script he used:

#!/bin/sh

# Source URL
SRC_URL="$1"

# Destination URL
DST_URL="$2"

# Source and destination repo types (svn,p4)
SRC_TYPE=svn
DST_TYPE=${SRC_TYPE}

PROJECT=`basename "${SRC_URL}"`

# Clone SRC repo
git ${SRC_TYPE} clone ${SRC_URL} "${PROJECT}_src.git${SRC_TYPE}"

# Julienne SRC clone into patch files
mkdir "${PROJECT}.patches"
cd "${PROJECT}_src.git${SRC_TYPE}"
git format-patch --root HEAD -o "../${PROJECT}.patches"
cd ..

# Clone DST repo with empty target PROJECT dir
svn mkdir "${DST_URL}/${PROJECT}" -m "Initial repository layout."
git ${DST_TYPE} clone "${DST_URL}/${PROJECT}" "${PROJECT}_dst.git${DST_TYPE}"

# Merge SRC patches into DST clone
cd "${PROJECT}_dst.git${DST_TYPE}"
git am "../${PROJECT}.patches/"*

# Commit changes DST repo
git ${DST_TYPE} dcommit --add-author-from
cd ..

So my new favorite hack of the week was created while trying to find a good way to import code from our partner’s Perforce repository to our Subversion repository.

I wanted to do this while retaining history but the p4svn script that I found depended on the deprecated Perforce Perl API which made me nervous about trying to get it working.

So instead I decided to use Git as an intermediary. My initial attempts to do this by way of a git merge or rebase didn’t work out. The best I could get was the full source as one commit in subversion. But since git has really solid patch file support, I decided to try using git format-patch and git am to get the changes from one repository to the other.

The end result was about as good as I could have hoped for. Including --add-author-from even put the original Perforce information into the subversion commit logs which was awesome. The only downside I’ve seen so far today is that folders that should be deleted aren’t always deleted in the final import. I’m guessing this has to do with how git ignores empty directories but svn doesn’t. But cleaning them up wasn’t too bad for me since the projects had a consistent structure. If the project had some sort of major reorganization happen, you might want to dig into that and try to figure out a better solution.

So here’s the script, also checked into my randomscripts repository. Feel free to ask any questions or school me on a better way to do this!

#!/bin/sh

# Set these before you start
# export P4PORT=myperforceserver:1666
# export P4USER=myusername
# export P4PASSWD=mypassword

# Source Perforce depot path (without @all)
P4PATH="$1"

# Destination SVN url (without trunk, we create that)
SVNPATH="$2"

PROJECT=`basename "${SVNPATH}"`

# git p4 clone "${P4PATH}@all" "${PROJECT}.gitp4"

mkdir "${PROJECT}.patches"
cd "${PROJECT}.gitp4"
git format-patch --root HEAD -o "../${PROJECT}.patches"
cd ..

svn mkdir --parents "${SVNPATH}/"{trunk,branches,tags} \
          -m "Initial repository layout."
git svn clone "${SVNPATH}/trunk" "${PROJECT}.gitsvn"

cd "${PROJECT}.gitsvn"
git am "../${PROJECT}.patches/"*
git svn dcommit --add-author-from
cd ..

A little belated, but not too long ago I went to Barcamp Philly 2009 with my wife and son. It was a great experience not only to be a part of the blossoming Philly tech scene, but also having my family there encouraged me to branch out a little and head to some really enjoyable talks that I probably wouldn’t have otherwise.

Shortly after the event, Kaori posted a writeup in her Mixi blog. I thought this was really cool and wanted to share it with other folks that might be interested. So I’ve reposted it here with her permission.

相方の付き添いでBar campなるものに行って来ました。

IT系やプログラマー系のコンフェランス（協議会？？）みたいな感じかな。

でも堅苦しくなくて、かな～りカジュアル。

大学を貸し切って、いろんな部屋でいろんな人がプレゼンテーションをしてるので、興味があるタイトルならその部屋に行き、自由に聞けたりディスカッション出来るというもの。

テクノロジーにうとい私にはちんぷんかんぷん。。。。と思いきや、意外におもしろい内容のプレゼンテーションもあったり。

カイも参加！

見てておもしろいなと思ったのは、こういうプレゼンテーションとかの途中でも質問とかあったら、みんなどしどし聞いたり、聞いてないのに自分の意見言ったりつっこみ入れたりして積極的なこと。

日本だと、しーーーんとしちゃうよね。

にしても、内容が内容なだけに人々も濃かった。

どれくらいかというと

こんなマニアックなTシャツを着てる人がいるくらい。（何の映画か分かるかな？）

４ヶ月のカイ坊、、、既にこんなところに連れて来られて一体将来どれほどマニアックになるのか。。。。

講義中のカイ。

ちゃんとネーム入りパスをもらった。

So I just ported my blog from WordPress to Jekyll.

Why? Because once again while posting my latest maven trick I got frustrated trying to post code in my blog and also get the formatting to work the way I wanted it.

I think I just prefer WYSIWYM to WYSIWYG. But that’s just me.

The transition wasn’t bad, but was more manual than I had hoped, mostly because of all the garbage formatting in my WordPress posts. Some were good, but others were a mess due to my own indecision on how to get the article into WordPress (edit in browser, edit as HTML, write markdown then post HTML, etc…).

So we’ll see how this goes. One thing that I really like already is how easy it is to fix broken/deprecated links when your whole blog is just sitting on your file system: Just a simple find and replace. I’m also considering writing a rake task that validates the whole generated site and possibly some sort of job queuing set up to move the widget stuff onto the server and reduce my javascript dependency.

Let me know what you think. There’s still some styling to be done, but I think it’s an improvement over the old site and the lady agrees.