Blog-2009-01-30

Yeah, another knitting post, and so soon, too! Okay, so this is a post all about Intarsia-style colour knitting in the round, as the title might suggest. See, when I was working on my pacman cap, I had this problem: when you knit Intarsia-style, you basically have colour strands for each "section" of the piece. So, if you're knitting flat and you're making a black field with a big yellow section, you'd knit with black, switch to yellow, knit across, then switch to a new strand of black and knit to the end of the row. Going back, you'd do the same thing, and each time you change colours, you do a little yarn wrapping trick to make sure there's no gaps. The result is, on the back, there is no black carried across the yellow section, which is very nice as it means you have to worry less about puckering and tension, etc.

Problem is, suppose you're knitting in the round. So you knit in black, switch to yellow, knit across, switch back to black, knit around… and then you're back to the yellow section. Problem: you now have two black strands, and the yellow is way over on the other side of the yellow section. What do you do? What do you do??

Well, in my pacman hat, I basically cheated. When I got to the section of colour, I switched from round knitting to back-and-forth, and when the coloured rows were done, I switched back to knitting in the round. Then, during the finishing stage, I just sewed up the little seam. Pretty simple, really, but it left a bulky little seam there, and a) I hate bulky little seams, and b) I just hate seams.

So, what's the real answer? Well, I could explain it, but instead, why don't I leave it to Sara to answer that question? In an explanation that's much better than anything I could compose, she outlines three different methods for dealing with the issue, one involving carrying strands around the piece, one using gapless short rows, and a third, far more ingenious technique that I really must try some time…

1 Comment on this page

Blog-2009-01-26

Here I am, part of the Men Who Knit webring, and I honestly can't remember the last time I posted about knitting. "Who cares, no one reads this anyway," you say? Okay, yeah, you're right. But who isn't up for a little linguistic masturbation from time to time, eh? If anything, at least it keeps my writing (read: rambling) skills bright and shiny. And, hey, at least Lenore probably reads this thing occasionally. Right?

Anyway, where was I? Oh, right, knitting. So, yeah, I haven't posted about knitting in a while, but I figured I'd share a little project I whipped up recently. It's a hat. Yeah, fine big deal, a hat. But it's a special hat. Wanna see it? Of course you do! You wouldn't be reading this if you didn't, right? Okay, here it is:

Pretty cool, eh? Cooler yet, I actually designed this thing myself! Though, admittedly, I didn't actually go through the effort of grabbing the graphics out of the game… a little search for "pacman ghosts" turned up this link, and voila! I was off to the races (oddly, that link is to a website called Sprite Stitch, a, quote, "Video game inspired craft weblog"… apparently I'm not the only one who had this idea). Once I had the graphics, it was a simple matter of charting out the pattern on graph paper, finding some yarn with the colours I needed, and then whipping the thing up.

Of course, charting the pattern did take a bit of effort. The trickiest thing when translating an image into a knitting pattern is altering the images to match your row/stitch gauge. You see, my knit stitches aren't perfectly square. In fact, they're a little wider than they are tall. But the images in your average video game are designed to be presented on a display with square pixels. The result is that, if you convert the images directly to a pattern, they come out distorted. So you have to either alter the images to stretch/squish them as necessary, or alter your row/stitch gauge. I opted to alter the images, squishing them horizontally, which was actually a bit challenging, as they're already very low resolution. But I think the result is pretty nice.

But the question now, is, what next? I'm thinking another classic video game of some kind. One of the Mario Bros. characters, maybe? Or maybe something a little more obscure… Opa Opa, anyone?

3 Comments on this page

Blog-2008-11-07

At work, I'm more or less the sole custodian of a major software component, and I've switched my day-to-day operations over to using git as a frontend to the corporate Subversion repository. Now, part of this work involves managing three different product branches (a trunk version, a legacy version, and a current stable), plus now that I'm using git, I've started creating lots of topic branches for features I want to include, but am not ready to commit yet.

Well, I got curious about disk space usage, as git is supposed to be really efficient. Here's what I found:

1. Trunk and current stable checked out from SVN. Total disk space, 118M.
2. Git tree containing complete code and history for trunk, legacy, current stable, and five topic branches: 42M.

Now that's what I call efficient!

1 Comment on this page

Blog-2008-10-23

So, Lenore complained that I haven't been blogging much lately, so I thought I'd throw together a little something that would bore her to tears. :) Now, as quick prelim, if you don't know what Git or Subversion is, I'd just skip this one.

Now, this whole thing is really more of a note-to-self, as I'm still getting used to git. But I figured it might be useful to other developers. Now I should say this isn't going to be a generic discussion about how to bridge Git to SVN. That's be done to death all over the web. What I'm particularly interested in is how to use git-svn when your Subversion repository has an… unusual topology. See, the typical Subversion repository is laid out something like this:

 projectA
   trunk
   branches
     projectA-1.0
   tags
 projectB
   trunk
   branches
     projectB-1.0
   tags

In a case like this, importing the tree into git-svn is trivial. However, at work, we have a Subversion repository that looks something like this:

 trunk
    projectA
    projectB
 branches
    projectA-1.0
    projectB-1.0

This layout requires some hacking to get git-svn working. First off, you need to initialize a standard git repository:

 mkdir git
 cd git
 git init

Note, you'll probably also want to use "git config" to set a few parameters while you're at it (if you're on Windows, setting "filemode" and "autocrlf" to false is a very good idea). Once the basic repo is set up, you can now add the SVN repositories you plan to fetch. For example, to pull projectA and projectA-1.0, we'd run these commands

 git config --add svn-remote.projectA.url svn+ssh://path/to/svn/
 git config --add svn-remote.projectA.fetch trunk/projectA:refs/remotes/projectA

 git config --add svn-remote.projectA-1.0.url svn+ssh://path/to/svn/
 git config --add svn-remote.projectA-1.0.fetch branches/projectA-1.0:refs/remotes/projectA-1.0

Basically, we instruct git-svn what the mappings are between various tree names and their SVN equivalents. This includes a URL to the repository, along with a definition of where to fetch the code from. Once this is done, you need to populate your repository. Note, I think the first fetch becomes the master branch (I'm not actually sure about this, but it seems that way), so it's best to yank trunk first (you can move the master moniker around, but why bother with such machinations if you can do it right the first time?):

 git svn fetch projectA
 git svn fetch projectA-1.0

Note, somehow, and I have no idea how, git even manages to figure out the 1.0 branch parent, so the essential structure is preserved, even though we perform separate fetches to populate the trees.

So now we have the trees downloaded, and as a bonus, the master tree is set up and tracking trunk. Next, we need to create local branches tracking any remote branches we're interested in:

 git checkout projectA-1.0    # Switch into the remote branch
 git checkout --track -b 1.0  # Create a local branch named 1.0 tracking the projectA-1.0 remote branch

There, the tree is populated. Finally, if you have svn:ignore properties set up, here's how you mirror them locally (note, you'll have to do this for each branch). Now, in git, the ignore rules are stored in .gitignore files. This is fine, except that, by default, git wants to include those files in the git repository, and thus they'd get pushed upstream in a dcommit. Thus, we have to go through a bit of gymnastics to make sure that doesn't happen, and that the .gitignore files remain local.

First, open up .git/info/exclude and add these lines:

 .gitignore
 .gitmodules

This instructs git to ignore the .gitignore files (and .gitmodule files) on "git status" calls and so forth. Next, create the ignore files.

 git checkout master
 git svn create-ignore

Of course, when this happens, git-svn goes and does a "git add" for all the .gitignore files. This is exactly what we don't want. :) So, last but not least, we undo the adds:

 git reset HEAD

And your tree should now be ready for hacking. Now for a few basic recipes. First, to switch between branches:

 git checkout 1.0             # Switch to our projectA-1.0 tracking branch
 git checkout master          # Switch back to master

Second, here's how we update the current local branch to sync up with it's corresponding remote SVN branch:

 git svn rebase

Third, to commit a change to the local git branch:

 git commit -a

Next, to push the changes in the local git branch out to the Subversion repository:

 git svn dcommit

Note, a dcommit pushes each individual local commit to the Subversion tree as individual SVN commits. However, there may be times when you want to roll together a series of local changes into a single SVN checkin (perhaps your code went through a lot of churn before the final version was reached). Luckily, git makes it possible to do just that. Imagine you've made some changes to trunk you want to check in as a single commit (I assume you've got the master branch checked out):

 git reset --soft refs/remotes/projectA  # Reset to the remote HEAD
 git commit -c ORIG_HEAD                 # Commit our original HEAD node into this tree.

Voila, the changes will now be combined into a single commit, and the old commits will be gone (well, technically they exist they're just orphaned). Note, this does change "the past", and of course fiddling around with history is generally not a good idea. But given we're talking about a local repository, here, I don't see a big problem with it.

Of course, a better alternative is to make all your changes in a local branch. Then, when you're ready, you can merge the changes into the originating branch, and then commit them there. That way, you can opt to delete the working branch if you don't care about the history, or keep it around if you think you might need it.

So there ya go. Basic git-svn bridging on a non-standard tree layout. And if you've read this sentence, congrats! Your ability to stay awake against all odds is, without a doubt, stunning.

2 Comments on this page

Blog-2008-06-16

Well, I did it! Granted, it took two attempts… the first loaf… well, let's just say it didn't go terribly well. But the second one turned out very good!

Looks pretty nice, eh? The crumb is a bit on the tight side, but the flavour is nicely sour, and the crust and crumb are chewy, which I kinda like, actually. Should make some mighty fine sandwiches!

0 Comments on this page

Blog-2008-06-14

Well, everyone, I'd like to introduce my new friend, Ted:

Yup, my starter lives! And his name is Ted.

For those interested in the gory details, I used the recipe from here. 24 hours in, things looked bubbly. 36 hours in, it was really bubbly. Then the drought of days 3-5… it smelled quite sour, but there was virtually no bubbling to be seen.

At this stage, it felt like things were settling in to a rut, so I made a few adjustments, modifying the feeding as follows:

1. Switched from 75%/25% white/rye ratio to 50%/50%.
2. Increased the hydration from 100% to 120%, give or take.

Two days later, and you can see the results. It smells lightly sour, yeasty, and it's doubling in 8 hours. Woo! So tomorrow, it's sour rye… I hope.

0 Comments on this page

Blog-2008-06-10

Well, I took the plunge over the weekend and dropped some hefty dollars to get me a copy of The Bread Baker's Apprentice, by Peter Reinhart. It is, without a doubt, a fantastic book covering the art and science of bread making, providing excellent pictures, illustrations, and formulae for creating great breads of many different styles, from sandwich to artisnal, yeasted to sourdough.

Of course, with a resource like that at my fingertips, it would be silly of me not to make some bread (despite the fact that I made a pair of sandwich loaves over the weekend (25/65/10 white/WW/rye… yummy!)). So, in anticipation of making some lasagna tonight, I decided to try and execute the Italian bread recipe in the book. The results speak for themselves:

Pretty nice, if I do say so myself! Nice colour, decent oven spring (though not great… the bread formed a bit of a skin during proofing which may have limited spring), reasonable scoring (though not on a proper angle, so no "ears"), and the crumb is just what I was looking for: big, irregular holes, with a nice, soft interior. And flavour-wise it's deliciously complex, without a hint of yeast. My only complaint is that it's rather salty, though I think that's a consequence of the recipe rather than botched execution (the formula has salt at 3.6% by weight… by contrast, French bread has just 1.9% salt).

Up next? Sourdough… eventually. The starter is percolating, and smells distinctly like yogurt, which would be the lactobacillus churning away and lowering the ph. Hopefully today or tomorrow it'll start smelling more like yeast.

0 Comments on this page