Posted by Doug
Tue, 05 Feb 2008 21:35:00 GMT
I’ve just fixed a bug in production that took me more than eight hours to find. When I show you the code, you’ll wonder why it took me so long. I have lots of excuses, but it’s a fairly interesting bug to think about. It shows some of the weaknesses in my usual modus operandi. The code that looks something like this:
class Article
CURRENT="start_publish_on <= #{Date.today} AND stop_publish_on > #{Date.today}"
def self.find_latest
find(:all, :conditions => CURRENT)
end
end
In retrospect the bug is obvious and probably is obvious to you as well. The Article::CURRENT constant is dynamically generated using the date at the time the class is evaluated. With rails in production mode, that could be a long time; certainly more than a day. The conclusion to draw here is to be very, very careful about dynamically generating constant strings. As a rule, I might suggest not doing it.
The most interesting thing about this is you can’t write a test to catch this error. I think that’s the the biggest thing that took me so long to find the error. I tend to be over confident in our test suite. As the new guy to the project, I’m proud of them for how conscientious they are about testing their code. I’m trying to fix this bug by triggering it in a test. Well, it can’t be done. The difference is how the production environment cache classes versus how testing and development does it.
Here’s another tidbit that threw me off the trail for a long time. Our copy editor that is responsible for publishing articles says to fix it she simply back dates the articles by a day. So I spent a lot of time looking for off-by-one errors. I had recently fixed a problem with comparing times to dates and causing off-by-one, so I thought that might be it. As it turns out, this was a red herring. There’s such a tight loop for feature request, implement, deploy that the production environment gets restarted fairly regularly (like nearly every day).
I guess what prompted me to write about this particular bug was what it said about our testing. Clearly automated testing can’t find all the bugs. It also says something about our rapid development. As long as we’re really busy, this bug didn’t bite us. It’s not until our deployment slows down (like a weekend) that it showed up.
Posted in Programming, Ruby on Rails | 1 comment
Posted by Doug
Thu, 08 Nov 2007 02:58:00 GMT
OK, last emacs tip for a while. It’s ironic, but the last two years I’ve written some cool elisp while at RubyConf. I typically run emacs full screen and split buffers both vertically and horizontally to arrange bits of code. It’s not uncommon for me to end up with three, four, five or even six visible windows in emacs. The problem though is navigating between them.
The out-of-the-box solution is to use other-window (bound to C-x o) and just cycle through them. If you’re fancy you can give a prefix argument to other-window and go backwards. This window cycling is tedious to me though and I’d like something faster. Particularly when I’m mostly bouncing back and forth between two windows.
To solve this problem I wrote jump-to-buffer. Of course, right now I’m really enamored with the fuzzy matching in ido-completing-read. That’s what allows you to type non-sequential characters to match the buffer name. It’s very similar to TextMate’s pattern matching. So, jump-to-buffer uses ido-completing-read. The buffers it gives you as options for completion are only the buffers in visible windows. It also sorts those buffers in the order of the buffer-list; which is in the order of most recently accessed.
To make this work, I’ve written two helper functions: rotate-list, and sort-by-other-list. Without further ado:
(defun dka-sort-by-other-list (to-sort-list other-list)
(let* ((index 0)
(other-alist (mapcar (lambda (buffer)
(setq index (+ index 1))
(cons buffer index))
other-list))
(swartz (mapcar (lambda (item)
(cons (cdr (assoc item other-alist)) item))
to-sort-list))
(sorted-list (sort swartz (lambda (a b) (< (car a) (car b))))))
(mapcar 'cdr sorted-list)))
(defun rotate-list (list count)
"Rotate the LIST by COUNT elements"
(cond
((= count 0) list)
((not list) list)
(t
(rotate-list (nconc (cdr list) (list (car list)) '()) (1- count)))))
(defun dka-jump-to-window ()
"Interactively jump to another visible window based on it's `buffer-name' using `ido-completing-read'"
(interactive)
(let* ((visible-buffers (mapcar '(lambda (window) (window-buffer window)) (window-list)))
(sorted-visible-buffers (dka-sort-by-other-list visible-buffers (buffer-list)))
(rotated-buffer-list (rotate-list sorted-visible-buffers 1))
(visible-buffer-names (mapcar (lambda (buffer) (buffer-name buffer)) rotated-buffer-list))
(buffer-name (ido-completing-read "Enter buffer to jump to: "
visible-buffer-names
nil t))
(window-of-buffer
(delq nil
(mapcar '(lambda (window)
(if (equal buffer-name (buffer-name (window-buffer window)))
window nil)) (window-list)))))
(select-window (car window-of-buffer)))
)
I’m definitely interested in feedback on this code. The dka-sort-list-by-other-list method was particularly tricky for me to write. I think it’s both right and fast. I haven’t dove into elunit yet to know for sure if it’s right.
Posted in Emacs, Programming | Tags elisp, elunit, emacs, schwartz, sorting, transform | no comments
Posted by Doug
Wed, 07 Nov 2007 16:04:00 GMT
One of the things that’s really nice about TextMate is the Cmd-T navigation of files in your project. It pops up this little dialog with fancy pattern matching input to select one of the files in your project and then jumps to that file. There’s a similar command once your in a file to jump to symbols in that file. I’ve tried a couple things to achieve that behavior in emacs that I’d like to talk about.
The first thing I tried was a method called find-file-in-project. It was originally implemented by Phil Hagelberg as part of his “Another Ruby on Rails Mode” (arorem) and then also ported over to the current Rinari Is Not a Rails IDE. Basically, it indexes all the files in a “project” and then provides a nice interactive completing read to switch between them. It basically works just like Cmd-T in TextMat. I did quite a bit of work optimizing the completing read so that it would behave nicely. The problem is that emacs is slow to index the files in your project.
What I’m using now is the tried and true find-tag method which is part of etags.el. ETags depends on an external TAGS file as an index of all the symbols in your project. When you invoke find-tag (by default bound to M-.) it prompts you with completing read for the symbol to find. It then jumps directly to the file and location where that symbol is defined. It’s basically combining the find-file-in-project with find-symbol-in-buffer. It’s also very, very fast.
As an added bonus, you can use tags-search to search through your project finding places that tag is used. This is similar to TextMate’s slowly grep all the files and render a buffer with those results in it, but much faster.
The bad news is you have to manually build the TAGS file periodically. Emacs is pretty good about continuing to work when you’ve made modifications to the files, but if you add new methods, new files, or refactor significantly where thing are located then it gets confused. When that happens, simply rebuild the TAGS file.
Jim Weirich gave me a nice little rake task to do the job:
module Tags
RUBY_FILES = FileList['**/*.rb'].exclude("pkg")
end
namespace "tags" do
task :emacs => Tags::RUBY_FILES do
puts "Making Emacs TAGS file"
sh "xctags -e #{Tags::RUBY_FILES}", :verbose => false
end
end
task :tags => ["tags:emacs"]
Just put that in lib/tasks/tags.rake and then run rake tags:emacs when you invoke find-tag and it can’t find it. That shouldn’t happen very often. I’ve found it’s also very fast to build the TAGS file. I might consider putting that tags task as part of the normal run tests task, but I’m not sure that’s necessary.
The other catch here is that the rake task above calls out the exuberant ctags rather than the ctags that comes with emacs. The exuberant ctags knows how to parse ruby files whereas the ctags that comes with emacs can’t.
I’ve installed exuberant ctags from MacPorts. It is xctags even though MacPorts doesn’t install it that way. So (for better or worse) I’ve renamed the ctags files installed with ports to xctags. This also gets around the conflict that MacPorts thinks there is between the ctags installed with emacs and the exuberant ctags.
Give this a spin and let me know what you think. I’ve found it to be very accurate and very fast.
Posted in Emacs, Programming, Lisp, Ruby on Rails, Mac OS X | Tags emacs, etags, rinari, Ruby, TextMate, xctags | 4 comments
