I've just released Sqitch v0.20-TRIAL, the third testing release of Sqitch. Since last week, I've implemented add-step. So let's have a look-see at what all it can do. First, let's initialize a Sqitch project.
A quick update on Sqitch. I started implementation about a couple of weeks ago. It’s coming a long a bit more slowly than I'd like, given that I need to give a presentation on it soon. But I did things a little differently than I usually do with project like this: I wrote documentation first. In addition to the basic docs I posted a couple weeks back, I’ve written a tutorial. I put quite a lot of time into it, studying the Git interface as I did so, to try to develop useful workflows. The nice thing about this it that it will not only serve as the foundation for my presentation (PHEW! Half the work done already!), but it also serves as a design specification.
Last weekend, I was talking to a friend who works for a moderately-sized regional newspaper. We were talking about distribution. The guys upstairs, he told me, feel very comfortable, complacent even, with their position. They’re not worried about their future because, as they say, “Hey, we’re not the New York Times, we’re not going to have those kind of distribution problems, because we cover regional news, and there’s still a need for good regional coverage.” I guess they think that people in their region don’t read local news on the internet or their mobile devices?
After the Fireballing week before last, I put aside a bit of time to rejigger things. This blog now has a new home.
Back in January, I wrote three posts outlinining some ideas I had about a straight-forward, sane way of managing SQL change managment. The idea revolved around specifying scripts to deploy and revert in a plan file, and generating that plan file from VCS history. I still feel pretty good about the ideas there, and work has agreed to let me write it and open-source it. Here is the first step making it happen. I call it “Sqitch.”
I have more to say on the topic of iPad magazines, but I'm using the meager tuits I have to first make some infrastructural changes.
I really want to enjoy reading The New Yorker on my iPad. But for a rather large number of reasons, it's just unpleasant. Here's why.
In my previous post, I outlined the basics of a configuration-file and dependency-tracking SQL deployment architecture. But I left it off wanting to eliminate the need for such a file and still have it all work. This post outlines just how to do that by relying on VCS history to determine what changes need to be deployed or reverted.
I've been thinking a lot about SQL change management. I've written about this before, implemented a dubious implementation of SQL migrations, and used a dependency-tracking solution with its own set of challenges. Nothing has satisfied me. But I think I may finally have cracked this thing wide open.
Hey look everybody, I wrote today's Perl Advent Calendar post, Less Tedium, More Transactions. Go read it!
I've started using TestFlight to release DesignScene betas to testers. The documentation is thin, so I had to futz a bit, but fortunately it's a pretty simple app, so once I figured out that I just needed to stick to one "Team", I was off and running. And let me tell you, TestFlight is a far easier way to distribute betas than the convoluted methods suggested by Apple. Much more beta user-friendly.
