I’ve never been too excited about OS X’s Mail for GMail as I use tags extensively for GTD (based on this) and Mail seemed so… Outlook. My main reason for this is that Mail uses folders to represent tags, forcing me to choose just one tag instead of a Reference, Project, Context and Action. Overall, Google spends lots of time fine-tuning their web interface for GMail, and I’ve been pretty happy.
Then I came across an interesting OS X client for GMail: Sparrow.app. Sparrow aims to be lightweight but have the “right” features, integrates with things like Growl seamlessly, and allows me to monitor and quickly “do, delegate, delay or delete” things that hit my inbox. I’ve liked it so much that I ended up buying it from the App Store.
It’s not without it’s faults, and after reading Alan Hogan’s article about the improvements to Mail in Lion, I may play around with Mail again. I’m not sure that I can get over the tags-are-folders nature of Mail, but it’s good to see there are options.
Posted in:
Productivity, Reviews
by
damon
/
Comments Off
I just wrote a blog article for my company’s website based on work I did with the Limonade micro-framework. Check it out:
http://www.newsignature.com/blog/2011/08/09/easy-rest-servers-with-microframework/
Posted in:
Coding
by
damon
/
Tags: php, rest
2 Comments
I learned an important lesson today. The quick summary is “bundler makes freezing gems unnecessary, use ‘bundle install –deployment‘”. But for those who like a good, geeky story:
I’ve been updating/upgrading/refactoring a Rails 2 project as a Rails 3 project. We’d used the method described here to ensure that developer, testing & production environments would be synched with regards to gems, particularly Rails itself.
Rails 3 introduces the use of bundler, a sweet gem management tool. In a googling of “rails 3 freeze gems” I came across a post on Stack Overflow describing a bundle option to set the BUNDLE_PATH variable. I ran it and voila: all my gems were in the vendor/gems folder. Seemed to do the trick.
When trying in vain to get the app building in Hudson, I came to realize that the –path option had not worked. Instead, using ‘bundle install –deployment’ on the hudson machine (vs sending it all the gems as part of a Git checkout) was the REAL trick.
The moral of the story: don’t believe everything you read on the internet and RTFM.
Posted in:
Coding
by
damon
/
Tags: rails
Comments Off
Have a web service which needs requires authentication, but you’re testing a completely different part of the application? Again, FakeWeb & Regex help you out here. If you’re testing a model extended from ActiveResource by using FakeWeb, the url will look something like this:
1
| http://user:pass@example.com/someService |
To mock the request, use a regular expression like so:
1
| FakeWeb.register_uri :get, %r|http:(.*)example.com/someService|, :body => 'foo' |
Now you don’t have to worry about how you are authenticated. Of course you could use a more advanced regular expression, but we’re not testing that ActiveResource knows how to authenticate with a source, right?
Posted in:
Coding
by
damon
/
Tags: fakeweb, rspec, ruby, testing
Comments Off
I’ve been using a lot of FakeWeb + Rspec for creating ActiveResource models BDD-style without hitting my RESTful source. I keep on figuring out little things with FakeWeb that I feel like I should share.
When you register uri’s with FakeWeb, and you’re using regular expressions, you might be building layers of access like this:
1
2
| FakeWeb.register_uri(:get, %r|http://example.com/posts|, :body => {:post => {:id => 1, :tile => 'foo'}})
FakeWeb.register_uri(:get, %r|http://example.com/posts/1/comments|, :body => {:comment => {:id => 1, :post_id => 1, :tile => 'bar'}}) |
All good, right? No. When you try to get comments, FakeWeb will give you an error:
1
| More than one registered URI matched this request: GET http://example.com/posts/1/comments |
Fear not, fair citizen. Regular Expressions Anchors to the rescue. See, FakeWeb is using the first registered uri regexp to match all calls past
1
| http://example.com/posts |
so your comments url is already matched. By using the ^ (pattern start) and $ (pattern stop) anchors, you can be a little more precise in your matching. Observe:
1
2
| FakeWeb.register_uri(:get, %r|^http://example.com/posts$|, :body => {:post => {:id => 1, :tile => 'foo'}})
FakeWeb.register_uri(:get, %r|^http://example.com/posts/1/comments$|, :body => {:comment => {:id => 1, :post_id => 1, :tile => 'bar'}}) |
Tune in later for more: authentication edition.
Posted in:
Coding
by
damon
/
Tags: fakeweb, ruby, testing
1 Comment
I’ve been using HAML and SASS a lot lately because it’s kind of the best thing since sliced bread and ZenCode. I’ve also been using Mathew James Taylor‘s no-quirks-mode 3 column holy grail layout because: why re-invent the wheel (or in this case the Rube Goldberg Machine that is column layout in CSS).
Matthew’s code says it’s free to use (thanks, Matthew!), so I’m doing my OSS-part by providing you HAML/SASS versions of the layout:
3 Column HAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| !!! 5
%html
%head
%body
#header
#colmask.three-column
#colmid
#colright
#col1wrap
#col1pad
#col1
-# Main content goes here
#col2
-# Left column here
#col3
-# Right column here
#footer |
3 Column SASS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| $left_col_width: 170px
$right_col_width: 170px
$padding: 15px
#colmask.three-column
position: relative
clear: both
float: left
width: 100%
overflow: hidden
#colmid
float: left
width: 200%
position: relative
left: ($left_col_width + $padding + $padding)
#colright
float: left
width: 100%
position: relative
left: 50%
margin-left: -1 * ($left_col_width + $padding + $padding + $right_col_width + $padding + $padding)
#col1wrap
float: right
width: 50%
position: relative
right: 100%
#col1pad
margin: 0 $padding 0 ($left_col_width + $padding + $padding + $right_col_width + $padding + $padding)
overflow: hidden
#col1
width: 100%
overflow: hidden
#col2
float: left
width: $left_col_width
position: relative
margin-left: -50%
left: 215px
overflow: hidden
#col3
float: left
width: $right_col_width
position: relative
left: 15px
overflow: hidden |
As a bonus: his 2 column layout
2-column HAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
| !!! 5
%html
%head
%body
#header
.colmask.leftmenu
.colright
.col1wrap
.col1
-# Main body goes here
.col2
-# Left Column goes here
#footer |
2-column SASS:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
| >$left_col_width: 10em
$padding: 1em
$left_col_top_padding: $padding
$left_col_left_padding: $padding
$left_col_right_padding: $padding
$right_col_top_padding: $padding
$right_col_left_padding: $padding
$right_col_right_padding: $padding
// Header styles
#header
clear: both
float: left
width: 100%
.colmask
position: relative
clear: both
float: left
width: 100%
overflow: hidden
// 2 column left menu settings
.leftmenu
.colright
float: left
width: 200%
position: relative
left: $left_col_width+$left_col_left_padding+$right_col_left_padding
.col1wrap
float: right
width: 50%
position: relative
right: $left_col_width+$left_col_right_padding+$right_col_right_padding
padding-bottom: 1em
.col1
margin: $right_col_top_padding $right_col_right_padding 0 $left_col_width+$left_col_left_padding+$left_col_right_padding+$right_col_left_padding
position: relative
right: 100%
overflow: hidden
.col2
float: left
width: $left_col_width
position: relative
right: $left_col_width+$left_col_left_padding
// Footer styles
#footer
clear: both
float: left
width: 100% |
Enjoy
Posted in:
Coding
by
damon
/
Tags: css, haml, ruby, sass
4 Comments
For a long time now, I’ve known I needed to get better at testing. Not smoke testing, but real unit testing, test driven development (TDD), or better yet behavior driven development (BDD). I’d read papers, API’s and even wrote some after-the-fact unit tests for a CakePHP project. It always seamed overly laborious and time consuming.
My second-most recent project at work is a fairly complex/robust Ruby on Rails application which consumes and provides a front-end for our REST services. Under the gun to get features out quickly, we skipped over BDD and went right for a system of “live prototyping”. Devoid of tests, this app quickly became a game of Jenga where fixing one thing jeopardized the functionality of another. Implementing Cucumber tests after the fact stopped some of the bleeding, but I was finally starting to see the light.
Which brings me to my most current project. Also a Ruby on Rails application, I had the chance to do ground-up development so I decided to do it right. At the suggestion of a co-worker who knows better, I replaced Rails’ default testing framework with RSpec for true BDD. The going has been slow, but here’s what I’ve found:
- By starting with behavior I’ve stuck to the “fat model, skinny controller” model where most of my functionality is in the model. It’s easier to test functionality on a model and then string the resulting data together in the controller.
- After the initial delays from learning rspec and getting the initial models and model tests written, the views come together really quickly
- I often re-factor my methods several times durring my initial writing. Using Autotest not only checks that I update all affected code, but I start anticipating where I need to update much faster than if I were doing it solo.
I hope someone comes across this article and it provides the final push to get on board with BDD. I truly believe that in the last month of development I’ve improved my MVC development skills as much as I have over the past 3 years. It’s provided a lot of “a ha” moments, and I’m writing better code.
Posted in:
Coding
by
damon
/
Tags: ruby, testing
Comments Off
In my effort to be a better BDD/TDD (Behavior-Driven and Test-Driven Development) Developer, I’ve been diving into writing apps using RSpec for testing. The nature of my work has me writing test where, in a non-automated-test environment, I would be using web services (SOAP and/or REST) to get and post data. Now, obviously I don’t want to use a live web services to do this, so enter FakeWeb. I won’t go into the details of what FakeWeb is other than it allows me to fake responses to a given HTTP call.
So, I think I’m pretty slick, having found this nifty tool, but I keep getting schooled when I try to use a regular expression to register an HTTP query string like such:
1
2
3
4
5
| FakeWeb.register_uri(
:get, %r|http:\/\/example\.com\/search\.html\?query=.*&collection=.*|,
:body => file )
My thought is that this will return 'file' every time I request something like:[cc]http://example.com/search.html?query=foo&collection=bar |
. I’d be wrong.
After much monkey-patching-as-debugging of FakeWeb, I find out that when Ruby parses an incoming URI, it’s broken into parts such as protocol, host, path and query (there are more, but you get my point). When FakeWeb tries to match the incoming URI against my regular expression above, it key-sorts the query, so
1
| http://example.com/search.html?query=foo&collection=bar |
1
| becomes http://example.com/search.html?collection=bar&query=foo |
and FakeWeb throws it out as an unregistered URI. Fun!
Simply re-arranging the regular expression in the register call makes it all happy.
1
2
3
4
| FakeWeb.register_uri(
:get,
%r|http:\/\/example\.com\/search\.html\?collection=.*&query=.*|,
:body => file ) |
Posted in:
Coding
by
damon
/
Tags: fakeweb, ruby, testing
Comments Off
I’m sorry it’s come to this. I sent this email to Vibram 2 weeks ago, but have not heard a response. I suppose they don’t have to care because of the popularity of their FiveFingers product. Well, I’d be curious to hear from others about durability issues.
Here was my letter:
Hello,
I’ve been wearing Vibram FiveFingers for about a year now. I love *almost* everything about them. They’re comfortable. I enjoy barefoot movement without having to develop pads on my feet. I even met my girlfriend because of them.
However, they just don’t hold up. I now own 4 pairs: 1 Sprint, 1 KSO Trek, and 2 KSO’s. I exchanged my first pair of KSO’s within 30 days of use because of a hole & stitching coming apart on the big toes, and the pinky toes were separating from the rubber. The replacement KSO’s (8 months) and the Treks (6 months) are both falling apart: the KSO’s have the same big toe issues (holes & stitching). Both big toes on the Treks have separated from the rubber and one has a hole on the outside. I wear my shoes every day (though I do rotate for smell reasons), but don’t do anything that’s not pictured in your promotional materials. Though some people have had their VFF’s for years, others I speak to have had similar problems.
It is very hard to support and evangelize Vibram FiveFingers when they fall apart so quickly. I tell up to 10 people a day and blog regularly about them. I say that I love the product but durability has been an issue. It’s hard to take the “ripoff” arguments Vibram uses about durability seriously. If my shoes are going to last < 6 months, $30 is much better than $85.
In addition to feeling that some sort of warranty is in order, I would be happy to act as a “wear & durability” consultant for your company in exchange for shoes. I lead a relatively active lifestyle that includes trail running, hiking, backpacking and hanging out in public in the FiveFingers. I practically AM the guy in your brochure. I’m sure Vibram does a fair amount of testing, but this would give you an opportunity to see how the shoes wear in the real world and improve an already great–if fragile–product.
Let me know if Vibram is interested, or at least whether you’re willing to warrantee my used shoes.
Damon Toal-Rossi
Posted in:
Reviews
by
damon
/
Tags: vibram fivefingers
Comments Off
As I drove in to work in Santa Fe this rainy October morning, I was craving a breakfast burrito. I pulled out my BlackBerry and a quick Google search rendered some site called BooRah with a page about breakfast burritos in Santa Fe. If you’ve ever tried using your BlackBerry web browser for any site not designed for 1st generation cell phone browsers, you’ll understand that I really couldn’t figure out what it was saying.
So I texted my friend who lives in “the city different” who recommended Tia Sophia, Santa Fe Baking Company and some other place. Having gotten food poisoning from a (very tasty) burrito from Santa Fe Baking Co, I opted for Tia Sophia.
Located off the plaza, I was lucky to find parking right in front. I owe the rare rainstorm and 8 AM arrival. The ambiance is cozy New Mexican; not over done, but clean and authentic. I was surprised that their breakfast burrito does not come with eggs by default. I joked that a breakfast burrito without an egg was just a burrito. The woman–who I gather is the owner–replied that they invented the breakfast burrito in 1975 (a “fact” reported by the NY Times), and lots of people ask for it without an egg. Still, it’s just a burrito without the egg. I’m also a bit fan of carne adovada breakfast burritos, but have learned to not discount a place that sticks to more gringo meats.
Anyway, my order was a bacon breakfast burrito with an egg, smothered Christmas. With a coffee, it ended up being ~$11. The burrito was by no means large, but I wasn’t worried about starving. The green was tasty and relatively mild. The red was a little too flour-y but not bad. The potatoes were the shredded hash-brown style, and well cooked. The bacon was thick, cooked just right (well cooked but a bit chewy).
Overall, I’d go back to this place and sit down. Though expensive by Albuquerque standards, it was reasonable for a place spitting distance from the Santa Fe Plaza. The atmosphere and staff were great and the burrito was good.
Posted in:
Reviews
by
damon
/
Tags: Breakfast Burrito
Comments Off
