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@
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;-)
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 Mon, 2006-05-08 at 23:54 +0900, Ryan L. 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?
On 5/8/06, Jason C. [email protected] 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.
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 May 8, 2006, at 10:04 AM, Jason C. wrote:
On Mon, 2006-05-08 at 23:54 +0900, Ryan L. 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 G. II
On May 8, 2006, at 11:09 AM, James Edward G. II wrote:
You are welcome to disagree. You are not welcome to speak for me.
James Edward G. 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.
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 B.
www.recentrambles.com
On 08/05/06, Jason C. [email protected] 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
Jason C. wrote:
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.
James Edward G. II wrote:
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.
–
James B.
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
On Tue, 2006-05-09 at 00:09 +0900, James Edward G. II wrote:
You are welcome to disagree. You are not welcome to speak for me.
Was I?
On Tue, 2006-05-09 at 02:32 +0900, James B. 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. 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 01:51 +0900, Logan C. 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.
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 02:31 +0900, Stefano T. 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.”
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 04:08 +0900, James B. 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.
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.
Jason C. wrote:
On Tue, 2006-05-09 at 02:32 +0900, James B. 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 9 May 2006, at 15:54, Jeff P. 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! 
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?
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 R. wrote:
On 9 May 2006, at 15:54, Jeff P. 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!
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?
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