Adwords4: access the Google Adwords API in ruby

For those of you who want to access the AdWords API from ruby.
http://blog.chanezon.com/articles/2006/05/03/adwords4r-0-4-released
I consider it beta quality.
It's a gem but I also provide an installer if you don't want to use ruby
gems (why wouldn't you;-)

sudo gem install adwords4r
should installl it.

It depends on soap4r from svn trunk, as well as http-access2.
Look at the sample in the examples directory.

It's open source, feel free to give me feedback or contribute to the
project.

P@

···

--
Patrick Chanezon, Google API Evangelist
http://blog.chanezon.com/

Because RubyGems is a solution to a problem that you only have when you
don't have a package manager. (Read: Windows). Using gems on Linux is
considered an evil. And the more that authors push out packages
with /only/ Gems support, the worse the situation gets. See here:

http://pkg-ruby-extras.alioth.debian.org/rubygems.html

···

On Sat, 2006-05-06 at 04:49 +0900, Patrick Chanezon wrote:

It's a gem but I also provide an installer if you don't want to use ruby
gems (why wouldn't you;-)

Patrick Chanezon wrote:

For those of you who want to access the AdWords API from ruby.
http://blog.chanezon.com/articles/2006/05/03/adwords4r-0-4-released
I consider it beta quality.
It's a gem but I also provide an installer if you don't want to use ruby
gems (why wouldn't you;-)

sudo gem install adwords4r
should installl it.

It depends on soap4r from svn trunk, as well as http-access2.
Look at the sample in the examples directory.

It's open source, feel free to give me feedback or contribute to the
project.

P@

Not to intrude on the hissy-fit over packaging schemes, but I'm
interested in the stuff inside the gem in this case. Would love to know
what the author and others would propose to do with this interesting
interface.

tnx,
jp

···

--
Posted via http://www.ruby-forum.com/\.

Because RubyGems is a solution to a problem that you only have when you
don't have a package manager. (Read: Windows). Using gems on Linux is
considered an evil.

Please do not try to speak for the entire Ruby community with a
statement like the above, which most here would agree is wrong.
RubyGems are not just for Windows, but for all supported Ruby
platforms.

And the more that authors push out packages with /only/
Gems support, the worse the situation gets. See here:

http://pkg-ruby-extras.alioth.debian.org/rubygems.html

From what I've seen only the Debian people make a big stink over
RubyGems, as shown above.

Ryan

···

On 5/8/06, Jason Clinton <me@jasonclinton.com> wrote:

[...]

Because RubyGems is a solution to a problem that you only have when you
don't have a package manager. (Read: Windows). Using gems on Linux is
considered an evil. And the more that authors push out packages with /only/
Gems support, the worse the situation gets. See here:

http://pkg-ruby-extras.alioth.debian.org/rubygems.html

Actually, RubyGems is a solution that is independent of the underlying
OS. This means that I do not have to make a deb, an rpm, a darwin
port, a pkg, an exe installer:
a gem will install on all linux distributions, mac os x, solaris, and
ms windows.

Sure, it is not perfect, but is portable.

The webpage that you linked only seems to complain that it is more
difficult for the debian packagers to redistribute ruby packages as
debs, which does not exactly mean that "Using gems on Linux is
considered an evil."

Ciao
Stefano

···

On 08/05/06, Jason Clinton <me@jasonclinton.com> wrote:

Jason Clinton wrote:

It's a gem but I also provide an installer if you don't want to use ruby gems (why wouldn't you;-)

Because RubyGems is a solution to a problem that you only have when you don't have a package manager. (Read: Windows). Using gems on Linux is considered an evil. And the more that authors push out packages with /only/ Gems support, the worse the situation gets. See here:

http://pkg-ruby-extras.alioth.debian.org/rubygems.html

BTW, not sure if this as been mentioned already (if it has I missed it; my apologies), but the information on that page is out of date. For example, there is no need for 'require_gem'; it's all 'require', with or without RubyGems.

Anyway, I am tending to the position that RubyGems is not used to install new applications (or packages) as such; it is a means for an application (ruby) to extend itself.

···

  On Sat, 2006-05-06 at 04:49 +0900, Patrick Chanezon wrote:

--
James Britt

Staying on topic? Heresy! :slight_smile:

Looking at the example scripts:

     adwords = AdWords::API.new

     res = adwords.getCampaign(6000213)
     puts dumpObj(res)
     res = adwords.getAllAdWordsCampaigns(123)
     res.each {|c| puts dumpObj(c)}
     #adwords.getAllAdWordsCampaigns(123).each {|c| puts dumpObj(c)}
     c = AdWords::Campaign.new
     c.dailyBudget = 10000
     c.status = 'Paused'
     c.name = "Test P@ #{rand(10000)}"
     puts dumpObj(adwords.addCampaign(c).addCampaignReturn)

You have to admit those 11 lines show an awful lot of promise for being able to help build better interfaces to replace Google's god-awful system right now. The only thing it appears to be missing is getting positional bid prices, or maybe I haven't looked closely enough.

What would be really useful is to make it ad-system agnostic - i.e. produce a standard library that understood how to manage campaigns and keywords over adwords, overture, and any other networks out there. At that point, really clever and innovative interfaces become possible. Do the other systems even have an API?

···

On 9 May 2006, at 15:54, Jeff Pritchard wrote:

Not to intrude on the hissy-fit over packaging schemes, but I'm
interested in the stuff inside the gem in this case. Would love to know
what the author and others would propose to do with this interesting
interface.

I disagree. RubyGems should only be used on Linux when a package is not
available from you distribution. Did you read the linked page?

···

On Mon, 2006-05-08 at 23:54 +0900, Ryan Leavengood wrote:

Please do not try to speak for the entire Ruby community with a
statement like the above, which most here would agree is wrong.
RubyGems are not just for Windows, but for all supported Ruby
platforms.

No, you misread the page, then. It's only more difficult when an author
chooses only to provide a Gems method. That's what that entire page is
about.

···

On Tue, 2006-05-09 at 02:31 +0900, Stefano Taschini wrote:

The webpage that you linked only seems to complain that it is more
difficult for the debian packagers to redistribute ruby packages as
debs, which does not exactly mean that "Using gems on Linux is
considered an evil."

So is the ultimate goal here to write something that will analyze the
results of a large number of campaigns and vary the bidding
automatically to maximize @bang/@buck?

I'm imagining an IDE for making money with adWords/adSense where you
cook up a bunch of web pages for high paying adsense, and then use the
IDE to develop a whole mess of ads for related keywords and then just
let 'er rip. The IDE would place all of the ad bids in small quantities
while testing away to find the best combinations and then increase the
flow on all profitable campaigns. This could take ALL of the drudgery
out of testing and spreadsheeting and trying different things.

I smell easy money. The main problem with something like this is that
you never know when the big 'G' might decide to pull the plug on the
API. Might do a bunch of work and then have the rug pulled out from
under you.

jp

Paul Robinson wrote:

···

On 9 May 2006, at 15:54, Jeff Pritchard wrote:

Not to intrude on the hissy-fit over packaging schemes, but I'm
interested in the stuff inside the gem in this case. Would love to
know
what the author and others would propose to do with this interesting
interface.

Staying on topic? Heresy! :slight_smile:

Looking at the example scripts:

     adwords = AdWords::API.new

     res = adwords.getCampaign(6000213)
     puts dumpObj(res)
     res = adwords.getAllAdWordsCampaigns(123)
     res.each {|c| puts dumpObj(c)}
     #adwords.getAllAdWordsCampaigns(123).each {|c| puts dumpObj(c)}
     c = AdWords::Campaign.new
     c.dailyBudget = 10000
     c.status = 'Paused'
     c.name = "Test P@ #{rand(10000)}"
     puts dumpObj(adwords.addCampaign(c).addCampaignReturn)

You have to admit those 11 lines show an awful lot of promise for
being able to help build better interfaces to replace Google's god-
awful system right now. The only thing it appears to be missing is
getting positional bid prices, or maybe I haven't looked closely enough.

What would be really useful is to make it ad-system agnostic - i.e.
produce a standard library that understood how to manage campaigns
and keywords over adwords, overture, and any other networks out
there. At that point, really clever and innovative interfaces become
possible. Do the other systems even have an API?

--
Posted via http://www.ruby-forum.com/\.

You are welcome to disagree. You are not welcome to speak for me.

James Edward Gray II

···

On May 8, 2006, at 10:04 AM, Jason Clinton wrote:

On Mon, 2006-05-08 at 23:54 +0900, Ryan Leavengood wrote:

Please do not try to speak for the entire Ruby community with a statement like the above, which most here would agree is wrong. RubyGems are not just for Windows, but for all supported Ruby platforms.

I disagree. RubyGems should only be used on Linux when a package is not available from you distribution. Did you read the linked page?

I agree with James. Do they have a similar rant about CPAN? I recall using CPAN on Debian back when I used Debian, and googling couldn't find anything similar to the page on rubygems about CPAN.

OTOH, I do believe that user applications probably should not be distributed as gems, or at least not only as gems. But that's another topic, with other reasoning.

···

On May 8, 2006, at 11:09 AM, James Edward Gray II wrote:

On May 8, 2006, at 10:04 AM, Jason Clinton wrote:

On Mon, 2006-05-08 at 23:54 +0900, Ryan Leavengood wrote:

Please do not try to speak for the entire Ruby community with a statement like the above, which most here would agree is wrong. RubyGems are not just for Windows, but for all supported Ruby platforms.

I disagree. RubyGems should only be used on Linux when a package is not available from you distribution. Did you read the linked page?

You are welcome to disagree. You are not welcome to speak for me.

James Edward Gray II

James Edward Gray II wrote:

Please do not try to speak for the entire Ruby community with a statement like the above, which most here would agree is wrong. RubyGems are not just for Windows, but for all supported Ruby platforms.

I disagree. RubyGems should only be used on Linux when a package is not available from you distribution. Did you read the linked page?

You are welcome to disagree. You are not welcome to speak for me.

Same here.

I've tried to follow the gems debate, and I think I understand most of the concerns, and way some prefer to use platform-specific package manager, and some feel the need to create a different, pure-Ruby package manager.

But after all is said and done, RubyGems is a big win for me, and has greatly simplified my Ruby life.

Ruby is all about choice.

···

On May 8, 2006, at 10:04 AM, Jason Clinton wrote:

On Mon, 2006-05-08 at 23:54 +0900, Ryan Leavengood wrote:

--
James Britt

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

Was I?

···

On Tue, 2006-05-09 at 00:09 +0900, James Edward Gray II wrote:

You are welcome to disagree. You are not welcome to speak for me.

I prefer gems and CPAN, although my sysadmin hates both. For him, it's
easier to create a rpm that he can install on the other 50 boxes.

Charlie Bowman
www.recentrambles.com

···

On Tue, 2006-05-09 at 01:51 +0900, Logan Capaldo wrote:

On May 8, 2006, at 11:09 AM, James Edward Gray II wrote:

> On May 8, 2006, at 10:04 AM, Jason Clinton wrote:
>
>> On Mon, 2006-05-08 at 23:54 +0900, Ryan Leavengood wrote:
>>> Please do not try to speak for the entire Ruby community with a
>>> statement like the above, which most here would agree is wrong.
>>> RubyGems are not just for Windows, but for all supported Ruby
>>> platforms.
>>
>> I disagree. RubyGems should only be used on Linux when a package
>> is not available from you distribution. Did you read the linked page?
>
> You are welcome to disagree. You are not welcome to speak for me.
>
> James Edward Gray II
>
>
>

I agree with James. Do they have a similar rant about CPAN? I recall
using CPAN on Debian back when I used Debian, and googling couldn't
find anything similar to the page on rubygems about CPAN.

OTOH, I do believe that user applications probably should not be
distributed as gems, or at least not only as gems. But that's another
topic, with other reasoning.
  

There is no choice available if the package author neglects to include
the standard extconf.rb, make, make install routine. All that Debian is
asking for (and I'm sure any other Linux packagers) is: please don't
forget to include those. That's it.

···

On Tue, 2006-05-09 at 02:32 +0900, James Britt wrote:

But after all is said and done, RubyGems is a big win for me, and has
greatly simplified my Ruby life.

Ruby is all about choice.

That's the only topic of any imporantance here. Applications depend on
libraries. Debian (or anyone else) cannot track and meet depends if the
libraries are _only_ available as Gems. All that they are asking for is
that both methods be equally maintained.

···

On Tue, 2006-05-09 at 01:51 +0900, Logan Capaldo wrote:

OTOH, I do believe that user applications probably should not be
distributed as gems, or at least not only as gems. But that's another
topic, with other reasoning.

Jason Clinton wrote:

But after all is said and done, RubyGems is a big win for me, and has greatly simplified my Ruby life.

Ruby is all about choice.

There is no choice available if the package author neglects to include the standard extconf.rb, make, make install routine.

Sure there is. People looking to repackage source code provided as a gem have the choice of untarring the gem and writing any additional installation code that is of value to them.

Yes, it would make lives easier for some people if developers always provided additional code for various tasks, but that's the developers' choice.

If there were a Rake task that automagically created extconf.rb and make for common gem source-code layouts, then people who prefer to distribute using only gems could include these extra files with no extra effort.

But, as it stands, it may be a tough sell to ask for them from people who do not see that value. It seems similar to asking people to provide a *.msi version of the code so that I can use the Windows package manager.

···

  On Tue, 2006-05-09 at 02:32 +0900, James Britt wrote:

--
James Britt

A more accurate analogy would be asking software vendors to continue to
insert themselves in the "Add/Remove Programs" list. It's been the
standard for decades. To be clear, Debian is NOT complaining about the
work required to adapt source distributions to Debian's FHS layout.
Packagers have been doing that for a decade and will continue to do so.
They are asking people to not make it any harder.

···

On Tue, 2006-05-09 at 04:08 +0900, James Britt wrote:

But, as it stands, it may be a tough sell to ask for them from people
who do not see that value. It seems similar to asking people to provide
  a *.msi version of the code so that I can use the Windows package manager.