Tests all the way down
August 28th, 2008 by ymendel 0 comments »
UPDATE: An updated gist of the code in this article can be found here.
A recent project had us using ThinkingSphinx for the first time. We've done some with UltraSphinx, but we were open to new ideas. And ReinH was (at least tangentionally) involved, so we bowed to the heavy weight of authority that comes from writing a blog post.
I admit that defining indexes in ThinkingSphinx is nicer than UltraSphinx, but there are method_missing and state-keeping tricks that give me pause. For me, though, it all comes down to writing the spec. Being BDD-infected as we are, writing code without specs hurts. It's simple to say that a column is indexed
class User < ActiveRecord::Base
define_index do
indexes email
end
endBut how to write the failing test that passes when that code is put in?
Read the rest of this entryFight on, fight on for ol' Jax State
August 25th, 2008 by ymendel 0 comments »
That’s about a Jacksonville in a different state, but how can you resist any song containing the lyric “We’re proud that we’re from Alabama!”?
Maybe I’d be more impressed if the author bothered to rhyme it.
The boys of OG Consulting have returned to their homeland from another 3-2-1 excursion into Hashrocket territory. Posting about the previous time gave a look into the 3-2-1 experience. This time was similar, yet not exactly; different, yet not hugely so. There were some problems that came up in the post-mortem last time, and those were largely taken care of. Of course, we had different problems this time (isn’t that always the way?), and we tried to address those as quickly as possible in a mid-mortem instead of waiting until the effort was over.
And on top of that we had a big ol’ storm harassing us. I whipped up an image to give a feel for that adventure.
It looked like planning for an extra weekend on the beach and bringing bathing suits was going to end up a waste, but Fay passed us on Friday and we were able to enjoy Saturday outside. Rick and I have the sunburns to show for it.
Shout-outs this time to everyone mentioned in the last post, of course, and also Sandro, Carmelyne, Les, Wes, Esther, Lark, Alex, Corey, and Dan. And of course a special shout-out to Mark for putting us up again in that sweet condo. Three bedrooms, three guest stars, three members of OG Consulting. Maybe a third 3-2-1 is called for.
Ruby 1.9, Shmuby 1.sh9
August 13th, 2008 by ymendel 2 comments »
There’s a lot of buzz about Ruby 1.9, at least if you’re looking in the right places. Sam Ruby gave a presentation about what to expect at OSCON, and I just found the slides today. They have me seeing red.
Before anyone gets the wrong idea, that’s not all aimed at Sam. It’s not even mostly aimed at Sam. I know it’s hard to put a good presentation together, and like anything else, the mistakes that are obvious after the fact were hiding during all the preparations and preliminary run-throughs.
So, some … let’s say “observations” about the slides.
Read the rest of this entryDown-home Hoedown action
August 11th, 2008 by ymendel 5 comments »
We were in Hunstville for the Ruby Hoedown this past weekend, and let me just say that Jeremy McAnally knows how to put on a hoedown. All you people who didn’t come because of the location or the size or the timing or any other reason, you screwed up.
With two EVDO cards and a nice AP, Confreaks managed to give one of the best conference networks I’ve ever experienced. Granted, I don’t have a lot of conference experience, but I know enough to say Confreaks » O’Reilly. I think in general this was the best conference experience I’ve had, owing in large part to the regional aspects: smaller, more focused (as in there was only one track), less focused (schedule not completely nailed down, good hallway track action).
Obie catches us in a moment, probably thinking of ways to screw with Rein during his talk
Rick, being on the schedule, gave his talk on going through a major refactoring and adding tests to old code, focusing on the experience of turning flog into flame. I was inspired to give a lightning talk on truthy. Kevin managed to squeeze one day of the Hoedown in between other blocks on his busy schedule — legitimizing us with the presence of an iPhone — so this wasn’t the conference to get “the full OG monty”, as it were. Maybe we’ll have to break open the seal on that at something even more local than a regional conference. NashDL OGConf, anyone?
Other highlights:
- Hashrocket quoting me in their 3-2-1 ad on the back of the schedule
- Obie including our logo among many others, showing the consultancy marketplace in his “Hustle” presentation
- Getting a dollar from Joe Kutner for explaining why
!=isn’t a method - Finally seeing Giles (“Crakahashi Method”) Bowkett present
- Being disqualified from the RPSbot competition for cheating
It was a good time. What do you expect when testing, pizza, and bocce come together?
Rick’s talk on flog/flame: (get the code to follow along)
Rick giving Gregg Pollack from RailsEnvy the overview
My lightning talk on truthy:
Me giving Gregg Pollack from RailsEnvy the overview
How Can: Sharing Your Codes to the Git Hubs?
August 2nd, 2008 by rickbradley 2 comments »
These days it seems that everyone is on the github tip – cloning like a shitty star wars prequel, forking and pulling like a lobster banquet. With github’s success have come a few growing pains – GFS is evidently a rude ho, which means that sometimes you can’t always just take the bus and get there, metaphorically speaking.
Since git doesn’t rely on a centralized repository, github occasionally going pensive like a French actress shouldn’t really cramp one’s style as far as development is concerned. Just commit locally, gitjour with your friends, and when github is back up, git push github master. Badda bing.
It could conceivably be a bit of a headache if you’re hoping to deploy servers with capistrano or vlad and you’re relying on one single service to be up whenever you want to deploy. Since git is so decentralized, however, it seems only natural to just use that decentralization to our advantage and try to eliminate single points of failure. Redundancy, bitches!
So let’s talk about how OGC rolls.
We were hosting our own internal git repos on our own server before github was publicly available (well, to be fair it was Michael’s server, and we eventually broke the lock off the wallet and rented some slicehost action). Once github came along we hopped on and started pushing our open source projects over there as well. We were pushing to both repositories “by hand” for a while, meaning that we’d git push origin master and then git push github master.
First off: ass pain. We could make some aliases or shell scripts, or maybe use git push-all. Meh. Second off, this ain’t DRY – the opportunities for lost or mismatched codez on different servers are too-ubiquitous (“toobiquitous”, in fact) for my liking. Third off, this is clearly an open rabbit hole. Aren’t we obligated to climb into it?
So we made a number of changes. Among them, we started using gitosis to manage our repos (both public and private) on our slicehost. Then we made some configuration changes so that, once a project is setup, pushing to our slicehost repository for a project will automatically force a push to our github repository for the project. Sweet.
So, now, mirroring is easy, though setup on a per-project basis is still a bit cumbersome. We want to document what we’ve done, not because it’s beautiful (yet) but to get it out there and then improve it. Oh, and (to drop the Royal “we”) because ymendel keeps bitching that I need to write this damned blog article. [waves to Yossef.]
Here’s how we’re doing the mirroring… In the discussion that follows there are three machines involved: (1) a local workstation (or laptop, as the case actually is) where I’m doing development work, I’ll refer to it as “local”; (2) a git repository host under our control, which will be running gitosis, to which we push, and which then mirrors to github, called “internal”; and (3) github.com. Suggestions for process improvement are very welcome as there are still a few too many moving parts involved in setting up new projects.
Initial Setup
To get things set up initially, get yourself a unixy/linuxy host where you can set up gitosis for hosting. Slicehost, linode, some dude’s box, whatever.
Set up gitosis on this “internal” machine. We have a user named ‘git’ to run gitosis. The repositories are in
~git/repositories. I followed this article on gitosis.Make sure the internal repo user has an ssh key that can be used on github:
internal:~$ ssh-keygenAdd the public key (
~/.ssh/id_dsa.pub, for example) to your github account’s key list.
Per-project Setup
Set up a repository for your project on github.com.
Set up a repository for your project on your internal gitosis server:
local:~$ cd ~/git/gitosis-admin local:~/git/gitosis-admin$ git pull origin master local:~/git/gitosis-admin$ vim gitosis.conf ## add the project local:~/git/gitosis-admin$ git commit -a -v local:~/git/gitosis-admin$ git push origin masterActually make the internal repository by doing a push to it:
local:~/git/gitosis-admin$ cd ~/git/ local:~/git$ mkdir foo local:~/git$ cd foo local:~/git/foo$ git init local:~/git/foo$ touch README local:~/git/foo$ git commit -a -m "Initial repository push." local:~/git/foo$ git remote add origin git@internal:foo.git local:~/git/foo$ git push origin master:refs/heads/masterSet up a remote called “github” on the internal gitosis repo pointing to github (use your username instead of flogic, duh):
internal:~git/repositories/foo.git$ git remote add github git@github.com:flogic/foo.gitSet up a hook in the internal repository so that when your commits come in to your internal repository they will be pushed out to the corresponding github repository. We used post-update, but post-receive should work as well (discussion of the various hooks git understands). Thanks to Evan Phoenix for the kick-start to get this working:
#!/bin/sh # # An example hook script to prepare a packed repository for use over # dumb transports. # # To enable this hook, make this file executable by "chmod +x post-update". git-update-server-info exec git push --mirror github >> ~/github.log 2>&1Make sure the new hook is runnable:
internal:~git/repositories/foo.git$ chmod +x hooks/post-update
(One question I have is, is there a way to do this with gitosis that doesn’t involve logging in on the server to add the remote and setup the hook?)
We still set two remotes in our git configs, in case we ever want to manually push straight to github – our server could go down too, y’know (again, substitute your github username for “flogic”):
local$ git remote add origin git@ogtastic.com:foo.git local$ git remote add github git@github.com:flogic/foo.git local$ git config --list | grep ^remote remote.origin.url=git@ogtastic.com:foo.git remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.github.url=git@github.com:flogic/foo.git remote.github.fetch=+refs/heads/*:refs/remotes/origin/*Push to the internal server … it should just magically show up on github:
local:~/git/foo$ echo "test" > README local:~/git/foo$ git commit -a -m "testing mirrored push to github" local:~/git/foo$ git push origin master
For troubleshooting, we adopted Evan’s idea and have a log file in the home directory of our internal server’s git user. The log file will show the output of attempting to git push --mirror to github.
Anyway, happy codes sharings!