Bob Zurek, the Chief Technology Officer at EnterpriseDB interviewed me a few months ago for their new Database Radio podcast. It finally was published last week. Bob and I had a nice conversation about PostgreSQL and itâs community, our use of PostgreSQL with Ruby, Ruby on Rails, and development tools/methods.
::: thumbnail
:::
You can listen to the podcast mp3 and/or read the transcript.
After releasing the new RubyURL API, I decided that it was time to look around at libraries to interact with it. I came across a new Ruby gem from John Nunemaker named, HTTParty, which aims to make it easy to talk to XML and JSON-based web services. Be sure to read Johnâs announcement of HTTParty.
So, I decided it might be fun to introduce more people to the gem by showing you all how to use it to talk to the new RubyURL API.
Before we get started, youâll need to install the HTTParty gem with the following command:
~ : sudo gem install httparty
Password:
When you HTTParty, you must party hard!
Successfully installed httparty-0.1.6
1 gem installed
Installing ri documentation for httparty-0.1.6...
Installing RDoc documentation for httparty-0.1.6...
```shell
Great! Now that **we're ready to party hard**, let's build something.
## Talking to the RubyURL API
The [RubyURL API](http://rubyurl.com/api) currently supports both XML
and JSON, which are each supported by HTTParty. The great thing about
HTTParty is that all you need to do is include it in a class and you're
able to quickly talk to remote services.
In this following example, we're going to create a new class called
`Rubyurl`.
````ruby
class Rubyurl
end
````ruby
What we'll want to do now is include the HTTParty library. (**note:**
you'll need to require both rubygems and httparty gems and I'll skip
those lines in following code samples)
````ruby
class Rubyurl
include HTTParty
end
```text
The HTTParty provides [a few class
methods](http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb),
which we can use to configure our library. We'll go ahead and specify
the `base_uri`, which we'll set to `rubyurl.com`.
````ruby
class Rubyurl
include HTTParty
base_uri 'rubyurl.com'
end
```bash
Now that our class is setup to talk to the
[Rubyurl.com](http://rubyurl.com) site, we'll want to add a new method
which we can use to communicate with the RubyURL API. We'll call this
`shorten` as we're using RubyURL to shorten long URLs... right?
````ruby
class Rubyurl
include HTTParty
base_uri 'localhost:3000'
def self.shorten(website_url)
end
end
```yaml
Our new `shorten` method will expect us to provide it with a website
url, which we'll want RubyURL to return a shortened URL for. The PATH
for the API that we'll want to talk to is: `/api/links`, which we're
expected to pass XML or JSON to.
Here are two examples of using the RubyURL API with HTTParty.
### RubyURL via JSON w/HTTParty
We're going to use the `post` method that is provided with HTTParty to
send a request to `/api/links.json`. As you can see, we're providing the
original website url to the web service.
````ruby
class Rubyurl
include HTTParty
base_uri 'rubyurl.com'
def self.shorten(website_url)
```javascript
post('/api/links.json', :query => { :link => { :website_url => website_url } })
```text
end
end
```yaml
When ran, it'll produce the following:
````ruby
>> Rubyurl.shorten('http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb').inspect
=> {"link"=>{"permalink"=>"http://rubyurl.com/uJVu", "website_url"=>"http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb"}}
```shell
Pretty simple, eh?
### RubyURL via XML w/HTTParty
The great thing about HTTParty is that you can use XML without changing
much.
````ruby
class Rubyurl
include HTTParty
base_uri 'rubyurl.com'
def self.shorten(website_url)
```javascript
post('/api/links.xml', :query => { :link => { :website_url => website_url } })
```text
end
end
```text
Produces the following
```ruby
http://github.com/jnunemaker/httparty/tree/master/lib/httparty.rb
http://rubyurl.com/uJVu
So⌠there you have it. HTTParty makes it extremely easy to interact with various web services that work over HTTP. Iâd encourage you all to take a few minutes to experiment with it and see what crazy ideas that come to mind during the process. :-)
Our team has been working our way into the Git world. One of our big client projects is now 100% git while the other is still on Subversion for another month or so. (Iâm getting by with git-svn, the gateway drug on that). Weâve had pretty much nothing but success with Git for quite some time, but recently this repository started to get chaotic, which has eaten up time⌠which isnât conducive to productivity.
So, I wanted to share a quick lesson that we learned today after scratching our head for a while. Itâs important that you avoid having a branch on a remote repository that shares the name of a tag in your local and/or remote repository.
I REPEAT.
Itâs bad mojo to have a tag and branch share the same name. Things that youâd expect to just work⌠donât. This was causing us to see warnings and errors like the following, which we werenât really sure what to make of it.
âwarning: refname âstagingâ is ambiguous.
âerror: src refspec staging matches more than one.â
This started about two weeks ago when we started a few new remote
branches: staging and design. It seemed to be going okay but we
managed to muck up things when we merged those two together and some of
us were having success fetching/pulling/pushing to staging and others
were having to specify :heads/staging and couldnât have a local branch
named staging. Needless to say, it was causing some problems and
slowing us down.
This afternoon, we finally noticed in the GitHub interface that there
was a tag named staging. Hmm⌠interesting. We verified this by using
git show-ref.
::: thumbnail
:::
Are you using PostgreSQL? EnterpriseDB wantâs to hear your story at Postgres Rocks
Alex Malinovich decided to take some time this afternoon to write a Ubiquity command for RubyURL using the new RubyURL API. You can take a look at Alexâs Ubiquity code for RubyURL. Heâs taking advantage of the JSON support that I added to RubyURL this weekend and JQuery. Be sure to read Alexâs blog post, which includes a screencast! =)
Also! We added this to RubyURL so that if you have Ubiquity installed, youâll be presented with the following the next time you visit: http://rubyurl.com.
::: thumbnail
:::
API](http://www.robbyonrails.com/articles/2008/08/31/the-new-rubyurl-api)
```text
- [RubyURL through
```text
QuickSilver](http://www.robbyonrails.com/articles/2008/01/06/rubyurl-through-quicksilver)
```text
- [RubyURL bookmarklet
```text
screencast](http://www.robbyonrails.com/articles/2007/08/09/rubyurl-bookmarklet-screencast)
Iâm sure that most of you heard the news that Google is releasing a new web browser named Chrome. Their comic for the announcement was very refreshing and entertaining read. Granted⌠nobody that I know has seen it (as of today)âŚ
For me, Iâm really interested in seeing what theyâve done to hopefully improve some of the short-comings of the user experience through their interaction design process. For example, tabs containing their own url/search fields sounds refreshing (I really dislike the hierarchy currently). Also, Iâm really looking forward to their dashboard-like default page.
::: thumbnail
:::
From a web development standpoint, it definitely raises questions about what weâll be able to do in the coming year(s).
What are your initial thoughts on this? DiscussâŚ
Update: Gary came across this amusing quote from a response by a representative at Microsoft.
âThe browser landscape is highly competitive, but people will choose Internet Explorer 8 for the way it puts the services they want right at their fingertips ⌠and, more than any other browsing technology, puts them in control of their personal data on-line,â Hachamovitch said. (read article on CNN)
Iâm really not sure what that even means. Donât we already have our online services at our fingertips? I suspect CNN interviewed the wrong person.. because this person said nothing.
Update #2: Only a PC version available⌠OSX / Linux are in development. Oh wellâŚ
Weâve just deployed the initial version of an API for RubyURL. It makes it really easy to create RubyURLs and is now open to the public. Should it end up being abused, weâll consider introducing an API KEY for authenticating and tracking abuse.
In the meantime, you can now start to use the RubyURL API.
For example, the followingâŚ
After wrestling with some git-remote-branching-merge-problems⌠I remembered this songâŚ
If youâre using git, you might add this to your [alias] section in
.gitconfig.
(notice the up-on-this alias)
Do you find yourself copying and pasting the same code from Rails application-to-application as new projects start? Our team has a handful of projects in development right now and we notice that some of these reusable components tend to get out of sync when we bounce between projects. So, weâre making an effort to spot these and are creating a handful of plugins so that we can keep them updated between projects. (Iâm sure that a lot of you do this as well)
In an effort to share some of our patterns, weâll try to release them into the wild for others to use and perhaps if you have better patterns to offer, weâre always interested in improving our approach.
Over the years, our designers and developers have approached the management of flash messages several different ways. In Rails, the default way to add something to a flash message is to do something like this in your controller.
flash[:message] = âYou have successfully signed in to your account.â``ruby\
What we began doing a while back is to create a few controller helper methods:
add_message( âYou have successfully signed in to your account.â )ruby\
`add_notice( âYouâve Got Mail!â )ruby\
add_error( âOops! Something got fucked up!â )```ruby\
Really, nothing too crazy here, just a pattern that our developers have preferred to managing our applicationâs flash messages.
Okay, so now for the part of the puzzle that we aimed to make consistent across our projects. Rendering flash messages would usually result in several lines of conditionals in our application layout to check if the flash had any values assigned to it. As we worked with our HTML/CSS designers to define a consistent pattern, we moved our code into a helper for rendering flash messages.
With Flash Message Conductor, we just need to pop in the following into our application layout.
<%= render_flash_messages %>``ruby\
If we had called add_message, itâd render the following:
::: {#flash_messages} You have successfully done XYZ⌠:::
Or, should you have called add_error, itâd render the following:
::: {#flash_messages} Oops! Something went bonkers! :::
What weâve done here is defined a consistent pattern for our designers
and developers to follow. Weâll always have a div container that will
use a p tag to display the flash messages with a CSS class value that
maps to the type of flash message that weâre displaying. This makes it
easier for us to reuse the same flash message styling (and tweak if
necessary), but we know that itâll produce the same HTML across our
applications.
Like most modern Rails applications, you can install with:
I was going through an older project of ours and cleaning up some specs and noticed how often we were doing the same thing in several places. When we started the project, we didnât get the benefits of shared groups. Now that we have some time to go through and update some of our older specs, Iâve been trying to take advantage of the features currently available in RSpec. One feature that I havenât seen a lot of mention of by people is shared groups, so I thought Iâd take a few minutes to write up a quick intro to using it.
To pick some low-hanging fruit, letâs take an all-too-familiar method,
which you might be familiar with⌠login_required. Sound familiar?
Have you found yourself stubbing login_required over and over
throughout your specs?
describe Admin::DohickiesController, âindexâ do
before( :each ) do
controller.stub!( :login_required )
Dohicky.should_receive( :paginate ).and_return( Array.new )
get :index
end
âŚ
end\
If youâre requiring that a user should be logged in when interacting
with most of the application (as in the case of an administration
section/namespace), you might want to consolidate some of your work into
one shared specification group. The basic premise behind this is that
you can write a typical describe block and load it into any other spec
groups that you need. For example, in our case, weâll need to stub
login_required in several places. We can set this up in one shared
group and reference it wherever necessary.
For example, here is what weâll start off with.
describe âan admin user is signed inâ do
before( :each ) do
controller.stub!( :login_required )
end
end
describe Admin::DohickiesController, âindexâ do
âŚ\
However, the new describe block isnât accessible from the block at the
bottom of the example⌠yet. To do this, we just need to pass the
option: :shared => true as youâll see in the following example.
describe âan admin user is signed inâ, :shared => true doruby\
`before( :each ) doruby\
controller.stub!( :login_required )ruby\
`endruby
end``ruby\
Great, now we can reference it by referring to it with:
it_should_behave_like SharedGroupName. In our example above, this
would look like:
describe âan admin user is signed inâ do
before( :each ) do
controller.stub!( :login_required )
end
end
describe Admin::DohickiesController, âindexâ do
it_should_behave_like âan admin user is signed inâ
before( :each ) do
Dohicky.should_receive( :paginate ).and_return( Array.new )
get :index
end
âŚ
end
describe Admin::DohickiesController, ânewâ do
it_should_behave_like âan admin user is signed inâ
before( :each ) do
dohicky = mock_model( Dohicky ) Dohicky.should_receive( :new ).and_return( dohicky
)
get :new
end
âŚ\
Thatâs it! Pretty simple, eh? We can now reference this shared group in
any describe blocks that we want to. A benefit to this approach is that
we can make change the authentication system (say, we decide to switch
it entirely and/or even just change method names, set any other
prerequisites necessary when an admin is signed in), weâll have a single
place to change in our specs. (tip: you can put these in your
spec_helper file)
You can learn more about it_should_behave_like and other helpful
features on the RSpec documentation
site.
If you have any suggestions on better ways of handling things like this, please follow up and share your solutions. Iâm always looking to sharpen my tools. :-)
In response, Bryan Helmkamp suggests that a
better solution is to define a method in our specs like, for example:
build_mock_user_and_login. then calling it in our before(:each). So,
maybe the approach above isnât the most ideal method but I did wantt o
draw some attention to it_should_behave_like. I suppose that I need a
better example.. another post, perhaps? :-)
Also, Ed Spencer has posted an article titled, DRYing up your CRUD
controller
RSpecs,
which will introduce you mor to it_should_behave_like.
Thanks for feedback people!
Toe](http://www.robbyonrails.com/articles/2007/02/13/be-careful-that-you-dont-stub-your-big-toe)
```text
- [Spec Your
```text
Views](http://www.robbyonrails.com/articles/2007/08/02/spec-your-views)
Awesome. Things 1.1 for the iPhone was just pushed to the Apple iTunes Store, which means⌠I can finally sync my Things.app with my iPhone!
Iâve been using Things for quite a while to manage my life (work and personal) and bringing this to my phone definitely makes my day.
For more information about Things, visit the following sites:
(iPhone)
Iâll post a review in the coming days as I get a chance to play with it. Just wanted to share the news. :-)
Alan Cooper, author of About Face, has slides from his presentation at Agile 2008 online.
If anybody knows if there is video of this talk, please let me know. :-)
Here are a few skitches from the slideshow.
::: thumbnail
:::
::: thumbnail
:::
::: thumbnail
:::
::: thumbnail
:::
::: thumbnail
:::