Archive | Tech
Blaine finally let the cat out of the bag – I’m finally doing a Django talk for the Omaha Dynamic Language Group. If you saw my Django talk for the Omaha Python Group, this one will be similar, only with a little more background and a small comparison with Ruby on Rails. The application will be pretty much the same.
So, see you on Tuesday night! See ODLG’s site for location information!
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!
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.
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.
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.