Is ack a better grep?

I’ve been playing with ack the past couple of days and, really, it’s pretty cool.  It automatically recurses into directories, only searching through files it knows about, and ignores VCS files and directories, like .svn, .cvs, .hg, etc.  You can easily tell it your filetypes with –python, –java, etc. on the command line. It’s in Perl, but it’s also fast.  Very fast.   And, because it’s Perl, it will run on Windows if you have Perl installed there. I live my Windows life in Cygwin, though, so that is nothing special to me.

So searching a Java project becomes “ack –java thing”.  This is better than doing something like

“find . -name *.java|grep -v .svn|xargs grep thing”.

If you put no file path to search on, it will try the files types it “knows” about.  Unfortunately for me, it doesn’t know about files that end in “.log”.  Know biggie — I just put “*.log” as the search path.

One gotcha is that ack searches with regular expressions, which may be good or it may be bad.  It’s good because it provides that power instead of adding an “e” or “-e” to the command.  Bad because regular expressions by default may bite you when you least expect it.  Like when searching for characters like *,?, etc.

I’ve been using it in my normal work this week and it has proven to be useful.  It would be hard to replace grep, but this is a great attempt.

Update  Andy Lester, ack’s author, emailed me and said:

 You can use –type-set log=.log and ack will recognize it.  Or, you can add that to your ~/.ackrc or ACK_OPTIONS.

As to the regexes, if you don’t want to think about which characters are special metacharacters, just add the -Q switch.

Thanks Andy, for the hints and the script!

Using Version Control in Emacs

I’ve recently discovered another wonderful thing about Emacs – Version Control

Let’s say you are working on a project that is under some version control system.  You are editing a file and you type “C-x v v”.  Then Emacs will do the next logical thing with that file.  If the file is not on version control, it will be added.  If it is, it will ask for a comment and check-in the file.  Note that no where do you actually tell Emacs which version control you are using.  It knows. I’ve done this successfully with Mercurial and Subversion and apparently their are many more.  I haven’t tried it under MKS, but that’s okay, because I refuse to use it anyway.

If you use Dired, then you can do “C-x v d” which is Dired under VCS.  See here for more about that.

The Accidental Feature

My manager was able to squeeze in another last-minute feature into this sprint.  When he told me what it was, I wasn’t too happy about it.  That part of the code isn’t the greatest, and I knew that we have some issues in that part of the functionality anyway.  I scheduled about 3 days for that task, which is quite a long time for me.

So, this morning, I decided to get it over with.  Thought about just changing the code, and I decided that I needed to walk the talk and wrote the unit test first.  I ran it, thinking that things would go up in flames. The results shocked me.

The test pass.  The feature was already there!!

I wasn’t sure how or why.  I took a look at the code and figured that it was wrong it how it did things, but it must have been wrong in the right way.  Or two wrongs made a right or something, because the feature was already in there.  I decided that I shouldn’t just cross all three days off my list, but instead cleaned the code up some, re-ran my test and it still worked.  So I checked it in and I was done.

Thus is the beauty of Test-Driven Development — you know when you are done.  And, with the unit test checked in, I knew that the Accidental Feature would always work.

Even when it shouldn’t.

The Pains of Upgrading WordPress

I hate upgrading WordPress. I was reminded of that a week or so ago when I tried to get to WordPress 2.5.1. It’s not WordPress’s fault — it’s my provider.

I’m not going to rant against them, but I will point out that, whenever I try to FTP a lot of files, the FTP stalls about 1/3 of the way through. I’ve been using LFTP for that, however, and that seems to be only client that can handle whatever my webhost is doing to the protocol. But its still slow. Once that is finally completed, I can do the upgrade with no problems.

I’ve had a couple of users tell me that my blog can load up painfully slow. I know the problem — it’s my webhost again. They freely admit that their MySQL servers are overloaded but never seems to truly fix it. Jeff Atwood had a great post on WP-Cache and I decided to install it when I got my WordPress finally upgraded. And I so after the long, laborious upload and the super-simple WP upgrade, I tried to install WP-Cache. And failed, because WP-Cache won’t run with gzip turned on and my provider doesn’t allow a way to shut it off.

So I decided to try WP Super Cache and that works. Nicely. Lovingly so, in fact. I would recommend that it to any WordPress users out there.

But this doesn’t change the fact that my provider sucks. I’ve known it for a while, but since I’m approaching the end of my contract, I can now finally do something about it. Expect changes around the end of the summer, if not before then.

Behold! The ScrumMaster comes!

One recent event I haven’t blogged about is that I was recently asked to be ScrumMaster by my manager.  That sounds sorta like a title from a D&D game gone horribly wrong, but once you know what it is, it’s not that bad.  It may help to know that Scrum is a methodology for developing software, and is not unlike what Scrum is in Rugby, which is where it got it’s name.

It’s been about a month, and the first sprint under my watch is almost over and I can say that things have gotten better.  While it’s true that, once again, we aren’t going to get everything done that we scheduled for this sprint, we are going to accomplish the goal that our manager has set for us and that is something new.

While I have some issues to what ScrumMaster means at my employer,  I’m not going to talk about that aspect.  I do want to talk about how I tried to make this sprint go better:

• Our daily meetings were generally about 30 minutes, sometimes 45 and, once in a while, a whole hour!  The first thing I did was to shorten them.  They are generally now 15 minutes, sometimes 20, and are only about what people just finished or what they are working on now.  Any strategy talk is now done outside of the daily meeting.
• I have told everyone that, if they have questions or problems let me know.  And I always follow up — even at the expense of my own tasks.  This has made people feel that they can ask questions and get help, so no one is sitting around for a day waiting for help to come.
• I’ve been trying to instill in people’s minds that having two or three easy tasks completed is better than having one hard task half-done. Getting those easy, little things done and out of the way helps build the rhythm that an agile development team so desperately needs.

I do want to do things differently next sprint.  I really think we need to do two week sprints instead of four, but management overruled that.  Instead, we have compromised on three weeks, which is still shorter.  And, while we generally have one overall goal, we always have a ton of tasks that have nothing do to with the goal of the sprint.  While it’s true they all need to be done, it takes some of the focus from our immediate goal (that’s why I want to do two week sprints –so all we can focus on is our goal).  I am going to make that that better in our next sprint.