Prepping for working on a feature at $work that involves limiting documents by relative time, I hashed out the following steps. Posting here in case they prove useful for anyone.
I want to be able to specify an arbitrary time, in english, relative to the current time, in my Cucumber steps. For example,
Scenario: Only posts from the last two months are shown
Given the following posts:
| title | posted_at |
| recent post | 2 days ago |
| recent post 2 | yesterday |
| older post | 2 months ago |
| really old post | 2 months, 1 day ago |
| tomorrow's post | 1 day from now |
When I go to the posts page
Then I should see 3 postsThe desire, there, is to be able to specify a date relative to the current time, in plain english. The tricky bit is being able to chain them together, as in 1 year, 3 months, 2 days ago
I got this worked out by stringing a few regular expressions together in my step definition helper. It depends on the 2.days.ago type dsl in ActiveSupport.
Given /^the following posts?:?/ do |table|
table.map_column!('posted_at'){|date| interpret_time(date) }
table.hashes.each{|hash| Factory :post, hash}
enddef interpret_time(time)
return nil if time.blank?
return time if time.kind_of?(Time) or time.kind_of?(Date)
named_time(time) || time_by_regex(time) || Time.parse(time)
end
def named_time(time)
case time.downcase
when "today" : Date.today
when "now" : Time.now
# etc ...
else nil
end
end
def time_by_regex(time)
directional_regex = /(ago|from now)/i
time_regex = /(\d+) (minute|hour|day|week|month|year)s?/i
direction = time.scan(directional_regex).flatten
shifts = time.scan(time_regex)
return nil if direction.empty? or shifts.empty?
forward = direction.first == "from now"
result = Time.now
shifts.each do |count, unit|
#depends on the 1.week type DSL for time measurements
adjust = count.to_i.send(unit)
# move time in correct direction
result = forward ? (result + adjust) : (result - adjust)
end
result
end
So, I finally pulled the trigger this weekend: Athas.org is no longer written in PHP.
I’ve been working on a Rails based re-write on-and-off for the last few months, and we’ve been using the new site internally, as I work through various different approaches to the project.
By far, one of the trickiest things was figuring out how to deal with file distribution and versioning. Shipping out files, PDFs primarily, is the entire reason for the site[0]. We tend to do multiple releases of the same product — beta/playtesting releases, followed by revisions, followed eventually by a “final” release. (I put final in quotes, because we can always go back and revisit a product) …
I wrestled for a long time with how to manage this versioning issue; I’m still not necessarily satisified with the current solution. Which is: A product (which contains multiple files) is what holds the current status — Internal, Beta, Final, Under Review. Files are associated with the product, but aren’t really tracked themselves. They’re either public or private (for purely internal development files) and can be archived. Basically, the product is a big bucket for all of the associated files, but the file records themselves are “dumb”.
It seems to work out well enough. Time, I suppose, will tell.
[0] For the moment; I do plan on making a much more web-based interface for distributing 4e material in development.
So … that was fun.
Bug report gets filed about the application at work. It seems that there’s an error that crops up when you print from IE. The error, of course, being the characteristically unhelpful dialog of garbage that IE likes to throw at you. After a bit of digging, it got even better. I was hoping I’d be able to respond with something technically snotty, like “Do you have your printer installed?”
But, I managed to reproduce the bug. Even better, I managed to narrow down it’s occurance. It turned out that when you were logged in, the error would occur, but only if you were logged in. Now that’s strange, since we’re using application level (cookie based) authentication — IE wouldn’t know anything about your logged in state. Everything works fine in Firefox (of course, the browser with good diagnostic tools doesn’t show the problem …)
So, in stumbling around trying to find some clue as to what the problem is, I came across this … It seems that id="tags" ends up conflicting with some builtin function in IE that’s used in printing. Sure enough, we had a field with <input name="tags" id="tags" type="text"> that was wrapped inside an if logged_in? check. Renamed the field, and printing now works like it’s supposed to.
So, what could have been really long and painful was short circuited by a lucky find in my net searches. No thanks to IE, it’s non-reserved reserved fields and opaque error messages. Have I mentioned lately how much I hate IE?
I’m working on a rewrite of Athas.org, converting from PHP to Rails. I’m migrating off the current database, so nothing really should be lost.
Aside from the fact that it looks like I’m going to need to upgrade apache to a version that’s not packaged for my OS (2.2, because I need a mod that’s only available in that version) there are a couple of other things that I’m planning on finishing before migrating the site. After that, I’ve got a few ideas for incremental addons.
Continue reading ‘Site plottings’
Published on
September 27, 2006 in
web. by
cflipse
I’ve been using Rojo for about a year. It’s a nice little web-based aggregator, and suits my usages better than bloglines did. Last week, they rolled out a major update to the site. And, last week, I was going to write something nice and excited about it. It seemed like they had fixed some of the speed issues, and the interface tweaks seem much more polished to me.
Clearly, I didn’t. Because after getting that first glimpse, all of my feeds vanished. Then they were back, but inconsistantly. And the only way that I could read anything was if I told it that I wanted to see all read and undread items in my feeds — not exactly the ideal way to read RSS feeds, especialy when you’re floating somewhere around the 50 or so that I track …
A week or so later, they seem to have gotten all the kinks worked out, though I’m still noticing occasional glitches. From what they say, it was a load thing — they had adapted the site to use a full-on SOA, with various bits of functionality being farmed out as web service calls. Like, for example, what feeds I read. Remarkably, I suppose, the authentication service never had a problem … Anyway, they ran a test environment, which didn’t managed to simulate their real usage loads, and the secondary servers collapsed under the full load.
I’m pretty sure there’s a lot of lessons to be pulled from this, not the least of which is that it seems they did a rather poor job of communicating what was going on, and that it would have been wise to roll back to the previous version after discovering the major (as in, broken core functionality) failures. I’m sure there are some other lessons to be gleaned from browing the reactions posted on their forums, but those strike me as two of the major ones.