[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

Generally, the folks on the Platform Team aren't set up with accounts
for the user-facing support system. That's why we try to keep things
on the Google Code issue tracker - it's in public, it's easier for our
team to manage, and it's easier for other developers to discover bugs
so we get fewer duplicates.

On Wed, Sep 16, 2009 at 13:47, zippy_monster  wrote:
>
> On Sep 16, 1:41 pm, Alex Payne  wrote:
>
>> One thing I have noticed, though, is developers going through our user
>> support track (viahttp://help.twitter.com) rather than contacting the
>> Platform Team via a...@twitter.com or by filing an issue on our issue
>> tracker. Our user support folks try their best, but they're often not
>> able to answer developer questions and are likely to hand that issue
>> off to our team and close the ticket. Contacting us developer-facing
>> folks is a much better way to get your issue answered.
>
> Do developers not use or respond to the support tickets directly?
>
> - alex
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[zippy_monster]

On Sep 16, 1:41 pm, Alex Payne  wrote:

> One thing I have noticed, though, is developers going through our user
> support track (viahttp://help.twitter.com) rather than contacting the
> Platform Team via a...@twitter.com or by filing an issue on our issue
> tracker. Our user support folks try their best, but they're often not
> able to answer developer questions and are likely to hand that issue
> off to our team and close the ticket. Contacting us developer-facing
> folks is a much better way to get your issue answered.

Do developers not use or respond to the support tickets directly?

- alex

[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

I completely agree.

As I said, we can't always make someone's pet issue our top priority.
Given that we have basically 2.5 full-time engineers on our team, that
can mean waiting weeks or months for a fix to a lower-priority issue.
But we should absolutely be communicating during that wait, and the
author of that post has every right to be pissed.

One thing I have noticed, though, is developers going through our user
support track (via http://help.twitter.com) rather than contacting the
Platform Team via a...@twitter.com or by filing an issue on our issue
tracker. Our user support folks try their best, but they're often not
able to answer developer questions and are likely to hand that issue
off to our team and close the ticket. Contacting us developer-facing
folks is a much better way to get your issue answered.

On Wed, Sep 16, 2009 at 13:21, zippy_monster  wrote:
>
> On Sep 16, 10:37 am, Alex Payne  wrote:
>
>> Often times, we don't hear from unhappy developers until they're
>> already outraged and posting on their blogs or in this group. Please:
>> give us a chance to help you out first. We may not always be able to
>> make your particular issues our highest priority, but we'll give it
>> our best shot. If you're still pissed, then you can go vent :)
>
> Well take a look at the grumbling about the OAuth stuff.  Mixed in
> with complaints about OAuth are complaints about Twitter support being
> non-responsive.  Take a look at this from earlier this month:
>
>  problems-are-far.html>
>
> That person was waiting two months(!) for a response, only to have his
> support tickets deleted.  I suspect a lot of the unhappy bloggers have
> indeed tried to contact Twitter, and that this group (and the blogs)
> are an outlet of last resort.  Understaffed or not, that sucks for the
> developers.
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[zippy_monster]

On Sep 16, 10:37 am, Alex Payne  wrote:

> Often times, we don't hear from unhappy developers until they're
> already outraged and posting on their blogs or in this group. Please:
> give us a chance to help you out first. We may not always be able to
> make your particular issues our highest priority, but we'll give it
> our best shot. If you're still pissed, then you can go vent :)

Well take a look at the grumbling about the OAuth stuff.  Mixed in
with complaints about OAuth are complaints about Twitter support being
non-responsive.  Take a look at this from earlier this month:



That person was waiting two months(!) for a response, only to have his
support tickets deleted.  I suspect a lot of the unhappy bloggers have
indeed tried to contact Twitter, and that this group (and the blogs)
are an outlet of last resort.  Understaffed or not, that sucks for the
developers.

[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

For applications like yours, moving to the Streaming API will increase
the quality of service for you and decrease load for us. A big part of
building an effective application on our API is figuring out which
methods to use and what strategies to use for retrieving information
and sending updates and direct messages. If you reach out to us
(a...@twitter.com), we're happy to help with that.

Often times, we don't hear from unhappy developers until they're
already outraged and posting on their blogs or in this group. Please:
give us a chance to help you out first. We may not always be able to
make your particular issues our highest priority, but we'll give it
our best shot. If you're still pissed, then you can go vent :)

And yes, reporting bugs with detailed debugging output (HTTP requests
and responses with all headers and full response bodies) are
incredibly useful. We essentially can't help you without this
information for any non-trivial bugs.

Another huge help to us: if you know anyone who either wants to join
our team as an engineer or help us out with full- or part-time
developer support, please send them to http://twitter.com/jobs. We're
a very small team with a very big job, but we've got the funding to
add more people. Please, please, please send good people our way!
Every addition to the team helps us help you.

On Wed, Sep 16, 2009 at 03:13, Fabien Penso  wrote:
>
> On Wed, Sep 16, 2009 at 7:00 AM, Matthew Ranney  wrote:
>> Hey Alex, would you consider just giving everybody their money back if they
>> aren't 100% satisfied?
>
> Hi guys.
>
> I have been developing an iPhone application for push called
> notifications : www.appnotifications.com
>
> I've added Gmail push, RSS, Google voice, I provide an API for sending
> yourself notifications, and of course I've added Twitter too. I've had
> some support from some Twitter developers and I'm happy I did.
> However, to reply to the subject of this thread I also had many issues
> with the API, some tweets not showing up for example. The complains I
> get from users is all about the Twitter plugin I did, I almost regret
> to have added it.
>
> I might have done something wrong on my side, but I also have the
> feelings, like other people here, than the API is not always working
> well. And I don't blame anyone, I think with the number of tweets you
> have, and the massive number of new users you had within the last
> year, it must be a super exciting job to work at Twitter, but also
> such a stressed one :) I wouldn't want to be responsible for
> scalability there.
>
> Is there anything we can do to help you guys? Reporting specific bugs
> (they are sometimes hard to find and hard to reproduce as it's a
> stream).
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Waldron Faulkner]

Thanks API team for implementing the cursoring, really needed it
(could you tell!?). I have to go implement that right now.

On Sep 16, 9:24 am, citricsquid  wrote:
> This.
>
> I've always thought that the obvious path would be to have unique
> error codes that never change. So if there's an auth fail it returns
> 1234 and 1234 corresponds to a specific message that is called
> externally. So we send the error code we're getting and it replies
> with the message and a description. So say they decide to change "auth
> fail" to "auth has failed" developers see no changes, unless they're
> using the twitter error message and then the message changes. So we
> have unique error codes that, when requested, return an error message
> that can be changed whenever you guys like and has no affect on
> developers and their apps. So for debugging we can simply call the
> description and error message from the code, but in a live environment
> we can build our own error handling based upon the error code, without
> having to constantly watch out for changes.
>
> Apologies if that lacks sense, not very good at explaining.
>
> On Sep 15, 9:21 pm, PJB  wrote:
>
> > Please also stop willy-nilly changing the error codes and error
> > messages.  Since your error messages are so often inaccurate, some of
> > us have setup special rules to decipher what the errors actually are
> > -- when you change the text or code, our rules break.
>
> > For example, suspended users are/were getting rate limit warnings when
> > trying to authenticate as them.  Separately, a new "not authorized"
> > message appears for both failed authentication errors as well as
> > successfully authenticated users trying friends/ids on blocking
> > users.  Since the messages and codes are the same, it is hard to
> > distinguish between these error types to tell the user what is going
> > on.  There are about a half-dozen of these ambiguities and bad errors
> > that we've accounted for.  (Don't get me started on "200: OK" non-
> > errors.)
>
> > So, after much trial and error, we CAN figure out the actual
> > underlying problem based on the action and message you send us.  But
> > when you suddenly change the error code, or message, it throws our
> > rules into disarray.
>
> > (Of course, it would be nice if the actual error messages you sent
> > were themselves accurate, but for now we're just hoping you can
> > CONSISTENTLY send us the same inaccurate errors.)
>
> > On Sep 15, 12:29 pm, Alex Payne  wrote:
>
> > > We're planning on doing just that: communicating more, monitoring the
> > > API via a third-party service from a variety of locales, and providing
> > > better documentation. We've got more developer support hires lined up,
> > > and more.
>
> > > Thanks for the list of what you'd like to see, and thanks for bearing 
> > > with us.
>
> > > On Tue, Sep 15, 2009 at 12:13, zippy_monster  
> > > wrote:
>
> > > > On Sep 15, 11:04 am, Alex Payne  wrote:
>
> > > >> Please understand that the denormalized lists are currently provided
> > > >> to developers on a best-effort basis. For the vast majority of Twitter
> > > >> applications, this data isn't necessary. A specialized class of
> > > >> applications need this data, and we're doing our best to provide it.
>
> > > > As a developer, implementation details are mainly a recreational
> > > > interest.  My primary concern is the end result (does it work? or
> > > > not?).  Excuses and apologies are nice, but not a substitute for more
> > > > explicit testing and communication.  So far I've run into two
> > > > disruptive changes:
>
> > > > - Today, for a brief period, API queries were returning twice the
> > > > number of responses they should have.  Instead of showing the proper 6
> > > > DMs, I was getting 12 back.  Oops.
>
> > > > - Previously, the way POST + OAuth requests were being handled
> > > > changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
> > > > was sending GET arguments with every request (even POST).  For a while
> > > > this worked, but in the past few weeks this broke with no warning.
> > > > Yeah, that was sloppy client-side code, but the documentation was
> > > > silent on this, and certainly the error message (invalid/re-used
> > > > nonce) was not terribly helpful as a proper nonce was being generated
> > > > each time.
>
> > > > Additionally, Internet rumblings about how OAuth was handled lend
> > > > credence to the idea that the API just isn't terribly stable... both
> > > > from the idea that you're pushing people to use what is officially
> > > > considered an experimental API, and that it's being treated as an
> > > > experimental API (OAuth specific outages for instance).
>
> > > > Or, the current pagination problems.  The threads I see here seem to
> > > > all be started by API consumers.  What's missing from the picture is
> > > > an announcement from Twitter that some feature is broken.  That smacks
> > > > of really poor (well, non-existent) communicat

[twitter-dev] Re: Comments for the group and Twitter staff

[citricsquid]

This.

I've always thought that the obvious path would be to have unique
error codes that never change. So if there's an auth fail it returns
1234 and 1234 corresponds to a specific message that is called
externally. So we send the error code we're getting and it replies
with the message and a description. So say they decide to change "auth
fail" to "auth has failed" developers see no changes, unless they're
using the twitter error message and then the message changes. So we
have unique error codes that, when requested, return an error message
that can be changed whenever you guys like and has no affect on
developers and their apps. So for debugging we can simply call the
description and error message from the code, but in a live environment
we can build our own error handling based upon the error code, without
having to constantly watch out for changes.

Apologies if that lacks sense, not very good at explaining.

On Sep 15, 9:21 pm, PJB  wrote:
> Please also stop willy-nilly changing the error codes and error
> messages.  Since your error messages are so often inaccurate, some of
> us have setup special rules to decipher what the errors actually are
> -- when you change the text or code, our rules break.
>
> For example, suspended users are/were getting rate limit warnings when
> trying to authenticate as them.  Separately, a new "not authorized"
> message appears for both failed authentication errors as well as
> successfully authenticated users trying friends/ids on blocking
> users.  Since the messages and codes are the same, it is hard to
> distinguish between these error types to tell the user what is going
> on.  There are about a half-dozen of these ambiguities and bad errors
> that we've accounted for.  (Don't get me started on "200: OK" non-
> errors.)
>
> So, after much trial and error, we CAN figure out the actual
> underlying problem based on the action and message you send us.  But
> when you suddenly change the error code, or message, it throws our
> rules into disarray.
>
> (Of course, it would be nice if the actual error messages you sent
> were themselves accurate, but for now we're just hoping you can
> CONSISTENTLY send us the same inaccurate errors.)
>
> On Sep 15, 12:29 pm, Alex Payne  wrote:
>
> > We're planning on doing just that: communicating more, monitoring the
> > API via a third-party service from a variety of locales, and providing
> > better documentation. We've got more developer support hires lined up,
> > and more.
>
> > Thanks for the list of what you'd like to see, and thanks for bearing with 
> > us.
>
> > On Tue, Sep 15, 2009 at 12:13, zippy_monster  wrote:
>
> > > On Sep 15, 11:04 am, Alex Payne  wrote:
>
> > >> Please understand that the denormalized lists are currently provided
> > >> to developers on a best-effort basis. For the vast majority of Twitter
> > >> applications, this data isn't necessary. A specialized class of
> > >> applications need this data, and we're doing our best to provide it.
>
> > > As a developer, implementation details are mainly a recreational
> > > interest.  My primary concern is the end result (does it work? or
> > > not?).  Excuses and apologies are nice, but not a substitute for more
> > > explicit testing and communication.  So far I've run into two
> > > disruptive changes:
>
> > > - Today, for a brief period, API queries were returning twice the
> > > number of responses they should have.  Instead of showing the proper 6
> > > DMs, I was getting 12 back.  Oops.
>
> > > - Previously, the way POST + OAuth requests were being handled
> > > changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
> > > was sending GET arguments with every request (even POST).  For a while
> > > this worked, but in the past few weeks this broke with no warning.
> > > Yeah, that was sloppy client-side code, but the documentation was
> > > silent on this, and certainly the error message (invalid/re-used
> > > nonce) was not terribly helpful as a proper nonce was being generated
> > > each time.
>
> > > Additionally, Internet rumblings about how OAuth was handled lend
> > > credence to the idea that the API just isn't terribly stable... both
> > > from the idea that you're pushing people to use what is officially
> > > considered an experimental API, and that it's being treated as an
> > > experimental API (OAuth specific outages for instance).
>
> > > Or, the current pagination problems.  The threads I see here seem to
> > > all be started by API consumers.  What's missing from the picture is
> > > an announcement from Twitter that some feature is broken.  That smacks
> > > of really poor (well, non-existent) communication.
>
> > > So, yeah, after spending time tracking down the above problems, and
> > > reading general internet rumblings, my gut feeling is that the Twitter
> > > API simply isn't terribly stable.  Specifically, I wonder how serious
> > > Twitter is about testing things in a non-production environment.  If I
> > > had to p

[twitter-dev] Re: Comments for the group and Twitter staff

[WyoKnott]

I seem to have opened a door that let in something ugly. Apparently
I'm not the only one with concerns but at least I don't have a live
application running that requires constant massaging. I believe my
original question has been answered for now.

Twitter guys: Since I'm currently unemployed I might be able to do
some of your grunt work while you address the concerns of other
developers. Is there anything I can do to help?

WK

On Sep 11, 8:36 am, WyoKnott  wrote:
> A few months ago I was introduced to the Twitter API by a prospective
> client who wanted a custom application. I took the time to learn the
> API and wrote a quick and dirty standalone windows app. The project
> fell through (the client could not get financing) but I have continued
> to be a twitter user and have subscribed to this group email. I
> stopped development on the project because the API does not yet seem
> stable enough for me to try to produce a marketable product on my own
> while at the same time chasing an API around. Is my opinion way off
> the mark or are some of the other developers out there feeling the
> same way.
>
> I am considering restarting development on the project if the Twitter
> API is likely to get more stable in the near future.
>
> Thanks for tolerating my ravings
>
> WyoKnott

[twitter-dev] Re: Comments for the group and Twitter staff

[Fabien Penso]

On Wed, Sep 16, 2009 at 7:00 AM, Matthew Ranney  wrote:
> Hey Alex, would you consider just giving everybody their money back if they
> aren't 100% satisfied?

Hi guys.

I have been developing an iPhone application for push called
notifications : www.appnotifications.com

I've added Gmail push, RSS, Google voice, I provide an API for sending
yourself notifications, and of course I've added Twitter too. I've had
some support from some Twitter developers and I'm happy I did.
However, to reply to the subject of this thread I also had many issues
with the API, some tweets not showing up for example. The complains I
get from users is all about the Twitter plugin I did, I almost regret
to have added it.

I might have done something wrong on my side, but I also have the
feelings, like other people here, than the API is not always working
well. And I don't blame anyone, I think with the number of tweets you
have, and the massive number of new users you had within the last
year, it must be a super exciting job to work at Twitter, but also
such a stressed one :) I wouldn't want to be responsible for
scalability there.

Is there anything we can do to help you guys? Reporting specific bugs
(they are sometimes hard to find and hard to reproduce as it's a
stream).

[twitter-dev] Re: Comments for the group and Twitter staff

[Matthew Ranney]

Hey Alex, would you consider just giving everybody their money back if they
aren't 100% satisfied?

On Tue, Sep 15, 2009 at 2:16 PM, Alex Payne  wrote:

>
> The main twitter.com site already uses the API in some places. Our
> revised mobile site is built entirely on the API, and our Facebook
> application has been built off our API for some time.
>
> Dogfooding! We support it.
>
> On Tue, Sep 15, 2009 at 14:08, Jim Renkel  wrote:
> >
> > I emphatically second and support the idea of twitter.com having to use
> > the API.
> >
> > We had similar quality problems at a place I formerly worked, and they
> > were solved, completely, when such a policy was instituted.
> >
> > Yeah, it puts pressure on the API team and may inconvenience the UI
> > team, or whatever you call them, but in the long run it will be worth
> > it.
> >
> > Side effects that we saw were a simpler, cleaner, more consistent
> > architecture for the whole system, and lower total costs to develop and
> > maintain the system.
> >
> > Bite the bullet and do it now. The longer you wait, the more difficult
> > and expensive it will be.
> >
> > Jim Renkel
> >
> > -Original Message-
> > From: twitter-development-talk@googlegroups.com
> > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
> > Haneda
> > Sent: Tuesday, September 15, 2009 15:55
> > To: twitter-development-talk@googlegroups.com
> > Subject: [twitter-dev] Re: Comments for the group and Twitter staff
> >
> >
> > Probably too late for this, but perhaps moving forward, it could be
> > done...
> > Twitter.com should move to using their own API.  The tools they use to
> > power their own site should be the same tools we use and rely on.
> >
> > In all reality, this seems a simpler approach, rather than pushing out
> > code for their stuff, and then essentially backporting that to an API,
> > just work on making the API, and then integrate that into the
> > twitter.com site.
> >
> > As far as I can tell, this would solve pretty much every problem the
> > API has, as there can not be a case where twitter is down, but the API
> > is up, or the API is down, and twitter is up.
> >
> > Twitter should be eating their own dog food :)
> > --
> > Scott * If you contact me off list replace talklists@ with scott@ *
> >
> >
> >
>
>
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.
> http://twitter.com/al3x
>

[twitter-dev] Re: Comments for the group and Twitter staff

[PJB]

Would be good if Twitter.com used API to determine, e.g., DM count on
right-side.  Right now it is woefully wrong if we delete DMs via API.

On Sep 15, 2:16 pm, Alex Payne  wrote:
> The main twitter.com site already uses the API in some places. Our
> revised mobile site is built entirely on the API, and our Facebook
> application has been built off our API for some time.
>
> Dogfooding! We support it.
>
>
>
> On Tue, Sep 15, 2009 at 14:08, Jim Renkel  wrote:
>
> > I emphatically second and support the idea of twitter.com having to use
> > the API.
>
> > We had similar quality problems at a place I formerly worked, and they
> > were solved, completely, when such a policy was instituted.
>
> > Yeah, it puts pressure on the API team and may inconvenience the UI
> > team, or whatever you call them, but in the long run it will be worth
> > it.
>
> > Side effects that we saw were a simpler, cleaner, more consistent
> > architecture for the whole system, and lower total costs to develop and
> > maintain the system.
>
> > Bite the bullet and do it now. The longer you wait, the more difficult
> > and expensive it will be.
>
> > Jim Renkel
>
> > -Original Message-
> > From: twitter-development-talk@googlegroups.com
> > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
> > Haneda
> > Sent: Tuesday, September 15, 2009 15:55
> > To: twitter-development-talk@googlegroups.com
> > Subject: [twitter-dev] Re: Comments for the group and Twitter staff
>
> > Probably too late for this, but perhaps moving forward, it could be
> > done...
> > Twitter.com should move to using their own API.  The tools they use to
> > power their own site should be the same tools we use and rely on.
>
> > In all reality, this seems a simpler approach, rather than pushing out
> > code for their stuff, and then essentially backporting that to an API,
> > just work on making the API, and then integrate that into the
> > twitter.com site.
>
> > As far as I can tell, this would solve pretty much every problem the
> > API has, as there can not be a case where twitter is down, but the API
> > is up, or the API is down, and twitter is up.
>
> > Twitter should be eating their own dog food :)
> > --
> > Scott * If you contact me off list replace talklists@ with scott@ *
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Scott Haneda]

I think the important part here is "in some places".  The problem is,  
twitter.com probably has 75% or more of the exposure.  The lowly app  
developer hits a bug in the API, and people say "wtf, works on  
twitter.com, this app sucks".


Good to know that facebook and the mobile site are using the API, but  
I suspect that when you say "some places", while great news, it needs  
to be all places.


If twitter.com is up, and super app for iphone is not, twitter.com  
gets no heat from that, the developer does.


Thank you for the explanation though.
--
Scott * If you contact me off list replace talklists@ with scott@ *

On Sep 15, 2009, at 2:16 PM, Alex Payne wrote:


The main twitter.com site already uses the API in some places. Our
revised mobile site is built entirely on the API, and our Facebook
application has been built off our API for some time.

[twitter-dev] Re: Comments for the group and Twitter staff

[Dean Collins]

Hmmm so was does twitter.com work when the API is down.?

How long exactly do you think twitter.com has been using the api for? 

 


-Original Message-
From: twitter-development-talk@googlegroups.com 
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Alex Payne
Sent: Tuesday, September 15, 2009 5:16 PM
To: twitter-development-talk@googlegroups.com
Subject: [twitter-dev] Re: Comments for the group and Twitter staff


The main twitter.com site already uses the API in some places. Our
revised mobile site is built entirely on the API, and our Facebook
application has been built off our API for some time.

Dogfooding! We support it.

On Tue, Sep 15, 2009 at 14:08, Jim Renkel  wrote:
>
> I emphatically second and support the idea of twitter.com having to use
> the API.
>
> We had similar quality problems at a place I formerly worked, and they
> were solved, completely, when such a policy was instituted.
>
> Yeah, it puts pressure on the API team and may inconvenience the UI
> team, or whatever you call them, but in the long run it will be worth
> it.
>
> Side effects that we saw were a simpler, cleaner, more consistent
> architecture for the whole system, and lower total costs to develop and
> maintain the system.
>
> Bite the bullet and do it now. The longer you wait, the more difficult
> and expensive it will be.
>
> Jim Renkel
>
> -Original Message-
> From: twitter-development-talk@googlegroups.com
> [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
> Haneda
> Sent: Tuesday, September 15, 2009 15:55
> To: twitter-development-talk@googlegroups.com
> Subject: [twitter-dev] Re: Comments for the group and Twitter staff
>
>
> Probably too late for this, but perhaps moving forward, it could be
> done...
> Twitter.com should move to using their own API.  The tools they use to
> power their own site should be the same tools we use and rely on.
>
> In all reality, this seems a simpler approach, rather than pushing out
> code for their stuff, and then essentially backporting that to an API,
> just work on making the API, and then integrate that into the
> twitter.com site.
>
> As far as I can tell, this would solve pretty much every problem the
> API has, as there can not be a case where twitter is down, but the API
> is up, or the API is down, and twitter is up.
>
> Twitter should be eating their own dog food :)
> --
> Scott * If you contact me off list replace talklists@ with scott@ *
>
>
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

The main twitter.com site already uses the API in some places. Our
revised mobile site is built entirely on the API, and our Facebook
application has been built off our API for some time.

Dogfooding! We support it.

On Tue, Sep 15, 2009 at 14:08, Jim Renkel  wrote:
>
> I emphatically second and support the idea of twitter.com having to use
> the API.
>
> We had similar quality problems at a place I formerly worked, and they
> were solved, completely, when such a policy was instituted.
>
> Yeah, it puts pressure on the API team and may inconvenience the UI
> team, or whatever you call them, but in the long run it will be worth
> it.
>
> Side effects that we saw were a simpler, cleaner, more consistent
> architecture for the whole system, and lower total costs to develop and
> maintain the system.
>
> Bite the bullet and do it now. The longer you wait, the more difficult
> and expensive it will be.
>
> Jim Renkel
>
> -Original Message-
> From: twitter-development-talk@googlegroups.com
> [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
> Haneda
> Sent: Tuesday, September 15, 2009 15:55
> To: twitter-development-talk@googlegroups.com
> Subject: [twitter-dev] Re: Comments for the group and Twitter staff
>
>
> Probably too late for this, but perhaps moving forward, it could be
> done...
> Twitter.com should move to using their own API.  The tools they use to
> power their own site should be the same tools we use and rely on.
>
> In all reality, this seems a simpler approach, rather than pushing out
> code for their stuff, and then essentially backporting that to an API,
> just work on making the API, and then integrate that into the
> twitter.com site.
>
> As far as I can tell, this would solve pretty much every problem the
> API has, as there can not be a case where twitter is down, but the API
> is up, or the API is down, and twitter is up.
>
> Twitter should be eating their own dog food :)
> --
> Scott * If you contact me off list replace talklists@ with scott@ *
>
>
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Jim Renkel]

I emphatically second and support the idea of twitter.com having to use
the API.

We had similar quality problems at a place I formerly worked, and they
were solved, completely, when such a policy was instituted.

Yeah, it puts pressure on the API team and may inconvenience the UI
team, or whatever you call them, but in the long run it will be worth
it.

Side effects that we saw were a simpler, cleaner, more consistent
architecture for the whole system, and lower total costs to develop and
maintain the system.

Bite the bullet and do it now. The longer you wait, the more difficult
and expensive it will be. 

Jim Renkel

-Original Message-
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
Haneda
Sent: Tuesday, September 15, 2009 15:55
To: twitter-development-talk@googlegroups.com
Subject: [twitter-dev] Re: Comments for the group and Twitter staff


Probably too late for this, but perhaps moving forward, it could be  
done...
Twitter.com should move to using their own API.  The tools they use to  
power their own site should be the same tools we use and rely on.

In all reality, this seems a simpler approach, rather than pushing out  
code for their stuff, and then essentially backporting that to an API,  
just work on making the API, and then integrate that into the  
twitter.com site.

As far as I can tell, this would solve pretty much every problem the  
API has, as there can not be a case where twitter is down, but the API  
is up, or the API is down, and twitter is up.

Twitter should be eating their own dog food :)
-- 
Scott * If you contact me off list replace talklists@ with scott@ *

[twitter-dev] Re: Comments for the group and Twitter staff

[Scott Haneda]

Probably too late for this, but perhaps moving forward, it could be  
done...
Twitter.com should move to using their own API.  The tools they use to  
power their own site should be the same tools we use and rely on.


In all reality, this seems a simpler approach, rather than pushing out  
code for their stuff, and then essentially backporting that to an API,  
just work on making the API, and then integrate that into the  
twitter.com site.


As far as I can tell, this would solve pretty much every problem the  
API has, as there can not be a case where twitter is down, but the API  
is up, or the API is down, and twitter is up.


Twitter should be eating their own dog food :)
--
Scott * If you contact me off list replace talklists@ with scott@ *

[twitter-dev] Re: Comments for the group and Twitter staff

[Scott Haneda]

Then maybe mark it in the docs as "highly experimental", this way,  
people do not build their business plans around something.  Make it  
clear, this feature could go away at any time.


On Sep 15, 2009, at 11:04 AM, Alex Payne wrote:


Please understand that the denormalized lists are currently provided
to developers on a best-effort basis. For the vast majority of Twitter
applications, this data isn't necessary. A specialized class of
applications need this data, and we're doing our best to provide it.


--
Scott * If you contact me off list replace talklists@ with scott@ *

[twitter-dev] Re: Comments for the group and Twitter staff

[PJB]

Please also stop willy-nilly changing the error codes and error
messages.  Since your error messages are so often inaccurate, some of
us have setup special rules to decipher what the errors actually are
-- when you change the text or code, our rules break.

For example, suspended users are/were getting rate limit warnings when
trying to authenticate as them.  Separately, a new "not authorized"
message appears for both failed authentication errors as well as
successfully authenticated users trying friends/ids on blocking
users.  Since the messages and codes are the same, it is hard to
distinguish between these error types to tell the user what is going
on.  There are about a half-dozen of these ambiguities and bad errors
that we've accounted for.  (Don't get me started on "200: OK" non-
errors.)

So, after much trial and error, we CAN figure out the actual
underlying problem based on the action and message you send us.  But
when you suddenly change the error code, or message, it throws our
rules into disarray.

(Of course, it would be nice if the actual error messages you sent
were themselves accurate, but for now we're just hoping you can
CONSISTENTLY send us the same inaccurate errors.)


On Sep 15, 12:29 pm, Alex Payne  wrote:
> We're planning on doing just that: communicating more, monitoring the
> API via a third-party service from a variety of locales, and providing
> better documentation. We've got more developer support hires lined up,
> and more.
>
> Thanks for the list of what you'd like to see, and thanks for bearing with us.
>
>
>
> On Tue, Sep 15, 2009 at 12:13, zippy_monster  wrote:
>
> > On Sep 15, 11:04 am, Alex Payne  wrote:
>
> >> Please understand that the denormalized lists are currently provided
> >> to developers on a best-effort basis. For the vast majority of Twitter
> >> applications, this data isn't necessary. A specialized class of
> >> applications need this data, and we're doing our best to provide it.
>
> > As a developer, implementation details are mainly a recreational
> > interest.  My primary concern is the end result (does it work? or
> > not?).  Excuses and apologies are nice, but not a substitute for more
> > explicit testing and communication.  So far I've run into two
> > disruptive changes:
>
> > - Today, for a brief period, API queries were returning twice the
> > number of responses they should have.  Instead of showing the proper 6
> > DMs, I was getting 12 back.  Oops.
>
> > - Previously, the way POST + OAuth requests were being handled
> > changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
> > was sending GET arguments with every request (even POST).  For a while
> > this worked, but in the past few weeks this broke with no warning.
> > Yeah, that was sloppy client-side code, but the documentation was
> > silent on this, and certainly the error message (invalid/re-used
> > nonce) was not terribly helpful as a proper nonce was being generated
> > each time.
>
> > Additionally, Internet rumblings about how OAuth was handled lend
> > credence to the idea that the API just isn't terribly stable... both
> > from the idea that you're pushing people to use what is officially
> > considered an experimental API, and that it's being treated as an
> > experimental API (OAuth specific outages for instance).
>
> > Or, the current pagination problems.  The threads I see here seem to
> > all be started by API consumers.  What's missing from the picture is
> > an announcement from Twitter that some feature is broken.  That smacks
> > of really poor (well, non-existent) communication.
>
> > So, yeah, after spending time tracking down the above problems, and
> > reading general internet rumblings, my gut feeling is that the Twitter
> > API simply isn't terribly stable.  Specifically, I wonder how serious
> > Twitter is about testing things in a non-production environment.  If I
> > had to propose a solution, it would be to keep a more explicit list
> > (blog, regular group postings, whatever) of what changes... even if
> > you think it's insignificant.  When something breaks, no matter how
> > small, a formal announcement would be great.  If such a thing exists,
> > I sure don't know about it.
>
> > The API blog hasn't been updated since July.  The third hit on Google
> > for "twitter api" is a post to this group begging for documentation.
> > The API changelog is out there, but it too seems like it's not
> > consistently updated.
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

We're planning on doing just that: communicating more, monitoring the
API via a third-party service from a variety of locales, and providing
better documentation. We've got more developer support hires lined up,
and more.

Thanks for the list of what you'd like to see, and thanks for bearing with us.

On Tue, Sep 15, 2009 at 12:13, zippy_monster  wrote:
>
> On Sep 15, 11:04 am, Alex Payne  wrote:
>
>> Please understand that the denormalized lists are currently provided
>> to developers on a best-effort basis. For the vast majority of Twitter
>> applications, this data isn't necessary. A specialized class of
>> applications need this data, and we're doing our best to provide it.
>
> As a developer, implementation details are mainly a recreational
> interest.  My primary concern is the end result (does it work? or
> not?).  Excuses and apologies are nice, but not a substitute for more
> explicit testing and communication.  So far I've run into two
> disruptive changes:
>
> - Today, for a brief period, API queries were returning twice the
> number of responses they should have.  Instead of showing the proper 6
> DMs, I was getting 12 back.  Oops.
>
> - Previously, the way POST + OAuth requests were being handled
> changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
> was sending GET arguments with every request (even POST).  For a while
> this worked, but in the past few weeks this broke with no warning.
> Yeah, that was sloppy client-side code, but the documentation was
> silent on this, and certainly the error message (invalid/re-used
> nonce) was not terribly helpful as a proper nonce was being generated
> each time.
>
> Additionally, Internet rumblings about how OAuth was handled lend
> credence to the idea that the API just isn't terribly stable... both
> from the idea that you're pushing people to use what is officially
> considered an experimental API, and that it's being treated as an
> experimental API (OAuth specific outages for instance).
>
> Or, the current pagination problems.  The threads I see here seem to
> all be started by API consumers.  What's missing from the picture is
> an announcement from Twitter that some feature is broken.  That smacks
> of really poor (well, non-existent) communication.
>
> So, yeah, after spending time tracking down the above problems, and
> reading general internet rumblings, my gut feeling is that the Twitter
> API simply isn't terribly stable.  Specifically, I wonder how serious
> Twitter is about testing things in a non-production environment.  If I
> had to propose a solution, it would be to keep a more explicit list
> (blog, regular group postings, whatever) of what changes... even if
> you think it's insignificant.  When something breaks, no matter how
> small, a formal announcement would be great.  If such a thing exists,
> I sure don't know about it.
>
> The API blog hasn't been updated since July.  The third hit on Google
> for "twitter api" is a post to this group begging for documentation.
> The API changelog is out there, but it too seems like it's not
> consistently updated.
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[zippy_monster]

On Sep 15, 11:04 am, Alex Payne  wrote:

> Please understand that the denormalized lists are currently provided
> to developers on a best-effort basis. For the vast majority of Twitter
> applications, this data isn't necessary. A specialized class of
> applications need this data, and we're doing our best to provide it.

As a developer, implementation details are mainly a recreational
interest.  My primary concern is the end result (does it work? or
not?).  Excuses and apologies are nice, but not a substitute for more
explicit testing and communication.  So far I've run into two
disruptive changes:

- Today, for a brief period, API queries were returning twice the
number of responses they should have.  Instead of showing the proper 6
DMs, I was getting 12 back.  Oops.

- Previously, the way POST + OAuth requests were being handled
changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
was sending GET arguments with every request (even POST).  For a while
this worked, but in the past few weeks this broke with no warning.
Yeah, that was sloppy client-side code, but the documentation was
silent on this, and certainly the error message (invalid/re-used
nonce) was not terribly helpful as a proper nonce was being generated
each time.

Additionally, Internet rumblings about how OAuth was handled lend
credence to the idea that the API just isn't terribly stable... both
from the idea that you're pushing people to use what is officially
considered an experimental API, and that it's being treated as an
experimental API (OAuth specific outages for instance).

Or, the current pagination problems.  The threads I see here seem to
all be started by API consumers.  What's missing from the picture is
an announcement from Twitter that some feature is broken.  That smacks
of really poor (well, non-existent) communication.

So, yeah, after spending time tracking down the above problems, and
reading general internet rumblings, my gut feeling is that the Twitter
API simply isn't terribly stable.  Specifically, I wonder how serious
Twitter is about testing things in a non-production environment.  If I
had to propose a solution, it would be to keep a more explicit list
(blog, regular group postings, whatever) of what changes... even if
you think it's insignificant.  When something breaks, no matter how
small, a formal announcement would be great.  If such a thing exists,
I sure don't know about it.

The API blog hasn't been updated since July.  The third hit on Google
for "twitter api" is a post to this group begging for documentation.
The API changelog is out there, but it too seems like it's not
consistently updated.

[twitter-dev] Re: Comments for the group and Twitter staff

[Waldron Faulkner]

OK Alex, thanks for that insight. I'm trying hard to be patient, but I
hope you can understand that this issue is strangling my new business.

Also, I don't see anything in the documentation which differentiates
these social graph calls from those rising above support on a "best-
effort basis". I'm not trying to be argumentative, but it would help
me tremendously with prioritization of ongoing development if I knew
which other API calls won't receive priority support if they should
suddenly fail. If there is some internal prioritization, I think the
community needs to know what it is. I know I do!

Thanks,

- Waldron

On Sep 15, 2:04 pm, Alex Payne  wrote:
> Waldron,
>
> We're looking into this issue, but it requires a great deal of
> coordination with the folks who work on our back-end infrastructure.
> When you ask for a list of denormalized IDs, that request spends very
> little time in "API code", and most of its time talking to a back-end
> system that my team has no control over. We're working with the folks
> in charge of that on reliability and better ways for developers to
> access that data.
>
> Please understand that the denormalized lists are currently provided
> to developers on a best-effort basis. For the vast majority of Twitter
> applications, this data isn't necessary. A specialized class of
> applications need this data, and we're doing our best to provide it.
>
> On Tue, Sep 15, 2009 at 00:21, Waldron Faulkner
>
>
>
>  wrote:
>
> > Ryan, please look no further than existing, accepted issues in the
> > issues list for examples as to how this platform is not yet ready. One
> > of your primary API calls, followers/ids (and friends/ids) is broken,
> > and has been for more than a week now. Since paging is not working,
> > and un-paged requests on accounts with many followers yields fail
> > whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
> > it doesn't feel like it's getting any kind of response.
>
> > As I have said repeatedly in this forum and in the issues list, this
> > has frozen business development for my fledgling business, which I
> > have trusted to the Twitter API. I can't show a broken product. At
> > some point, you will put this little dream of mine out of business.
> > I'm up late working on my project, which will ultimately add value to
> > Twitter's business. I hope your team isn't leaving me high and dry.
> > Please tell me I don't have to go do a Facebook app instead. Please
> > tell me that someone was working on this over the weekend.
>
> > I'd love to have some solid, no-nonsense response to this, with hard
> > dates. So far we've had well-meaning but empty words.
>
> > Thanks,
>
> > - Waldron Faulkner
> > Founder, GraphEdge LLC.
> >http://graphedge.com
>
> > On Sep 15, 2:59 am, Ryan Sarver  wrote:
> >> WyoKnott,
>
> >> Thanks for your email. We really appreciate the candid feedback and
> >> definitely is not something we want to see happening. I would like to
> >> hear more about what you mean by "not stable enough" and what specific
> >> issues we can work on that would get you to consider Twitter a
> >> platform worthy of building your business on.
>
> >> I look forward to your feedback.
>
> >> Best, Ryan
>
> >> On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott  
> >> wrote:
>
> >> > A few months ago I was introduced to the Twitter API by a prospective
> >> > client who wanted a custom application. I took the time to learn the
> >> > API and wrote a quick and dirty standalone windows app. The project
> >> > fell through (the client could not get financing) but I have continued
> >> > to be a twitter user and have subscribed to this group email. I
> >> > stopped development on the project because the API does not yet seem
> >> > stable enough for me to try to produce a marketable product on my own
> >> > while at the same time chasing an API around. Is my opinion way off
> >> > the mark or are some of the other developers out there feeling the
> >> > same way.
>
> >> > I am considering restarting development on the project if the Twitter
> >> > API is likely to get more stable in the near future.
>
> >> > Thanks for tolerating my ravings
>
> >> > WyoKnott
>
> --
> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[Alex Payne]

Waldron,

We're looking into this issue, but it requires a great deal of
coordination with the folks who work on our back-end infrastructure.
When you ask for a list of denormalized IDs, that request spends very
little time in "API code", and most of its time talking to a back-end
system that my team has no control over. We're working with the folks
in charge of that on reliability and better ways for developers to
access that data.

Please understand that the denormalized lists are currently provided
to developers on a best-effort basis. For the vast majority of Twitter
applications, this data isn't necessary. A specialized class of
applications need this data, and we're doing our best to provide it.

On Tue, Sep 15, 2009 at 00:21, Waldron Faulkner
 wrote:
>
> Ryan, please look no further than existing, accepted issues in the
> issues list for examples as to how this platform is not yet ready. One
> of your primary API calls, followers/ids (and friends/ids) is broken,
> and has been for more than a week now. Since paging is not working,
> and un-paged requests on accounts with many followers yields fail
> whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
> it doesn't feel like it's getting any kind of response.
>
> As I have said repeatedly in this forum and in the issues list, this
> has frozen business development for my fledgling business, which I
> have trusted to the Twitter API. I can't show a broken product. At
> some point, you will put this little dream of mine out of business.
> I'm up late working on my project, which will ultimately add value to
> Twitter's business. I hope your team isn't leaving me high and dry.
> Please tell me I don't have to go do a Facebook app instead. Please
> tell me that someone was working on this over the weekend.
>
> I'd love to have some solid, no-nonsense response to this, with hard
> dates. So far we've had well-meaning but empty words.
>
> Thanks,
>
> - Waldron Faulkner
> Founder, GraphEdge LLC.
> http://graphedge.com
>
> On Sep 15, 2:59 am, Ryan Sarver  wrote:
>> WyoKnott,
>>
>> Thanks for your email. We really appreciate the candid feedback and
>> definitely is not something we want to see happening. I would like to
>> hear more about what you mean by "not stable enough" and what specific
>> issues we can work on that would get you to consider Twitter a
>> platform worthy of building your business on.
>>
>> I look forward to your feedback.
>>
>> Best, Ryan
>>
>> On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott  
>> wrote:
>>
>> > A few months ago I was introduced to the Twitter API by a prospective
>> > client who wanted a custom application. I took the time to learn the
>> > API and wrote a quick and dirty standalone windows app. The project
>> > fell through (the client could not get financing) but I have continued
>> > to be a twitter user and have subscribed to this group email. I
>> > stopped development on the project because the API does not yet seem
>> > stable enough for me to try to produce a marketable product on my own
>> > while at the same time chasing an API around. Is my opinion way off
>> > the mark or are some of the other developers out there feeling the
>> > same way.
>>
>> > I am considering restarting development on the project if the Twitter
>> > API is likely to get more stable in the near future.
>>
>> > Thanks for tolerating my ravings
>>
>> > WyoKnott
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[twitter-dev] Re: Comments for the group and Twitter staff

[mycroftt]

I am only one person with too many irons in the fire. During the month or so that I spent actively working on the Twitter API project I had to go back and change parts my code more than once, not because of my errors (plenty of those but not the subject of this communication), but because of changes or proposed changes in the API. I would love to be in a position where I could focus exclusvely on this one project but I am not. As well as an ongoing job search I have a couple other projects showing promise. I cannot justify more time on Twitter when I see no point where the project graduates from in-development to live and in maintenance mode.
 

 Original Message Subject: [twitter-dev] Re: Comments for the group and Twitter staffFrom: Ryan Sarver Date: Mon, September 14, 2009 11:59 pmTo: twitter-development-talk@googlegroups.comWyoKnott,Thanks for your email. We really appreciate the candid feedback anddefinitely is not something we want to see happening. I would like tohear more about what you mean by "not stable enough" and what specificissues we can work on that would get you to consider Twitter aplatform worthy of building your business on.I look forward to your feedback.Best, Ryan

[twitter-dev] Re: Comments for the group and Twitter staff

[Waldron Faulkner]

Ryan, please look no further than existing, accepted issues in the
issues list for examples as to how this platform is not yet ready. One
of your primary API calls, followers/ids (and friends/ids) is broken,
and has been for more than a week now. Since paging is not working,
and un-paged requests on accounts with many followers yields fail
whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
it doesn't feel like it's getting any kind of response.

As I have said repeatedly in this forum and in the issues list, this
has frozen business development for my fledgling business, which I
have trusted to the Twitter API. I can't show a broken product. At
some point, you will put this little dream of mine out of business.
I'm up late working on my project, which will ultimately add value to
Twitter's business. I hope your team isn't leaving me high and dry.
Please tell me I don't have to go do a Facebook app instead. Please
tell me that someone was working on this over the weekend.

I'd love to have some solid, no-nonsense response to this, with hard
dates. So far we've had well-meaning but empty words.

Thanks,

- Waldron Faulkner
Founder, GraphEdge LLC.
http://graphedge.com

On Sep 15, 2:59 am, Ryan Sarver  wrote:
> WyoKnott,
>
> Thanks for your email. We really appreciate the candid feedback and
> definitely is not something we want to see happening. I would like to
> hear more about what you mean by "not stable enough" and what specific
> issues we can work on that would get you to consider Twitter a
> platform worthy of building your business on.
>
> I look forward to your feedback.
>
> Best, Ryan
>
> On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott  
> wrote:
>
> > A few months ago I was introduced to the Twitter API by a prospective
> > client who wanted a custom application. I took the time to learn the
> > API and wrote a quick and dirty standalone windows app. The project
> > fell through (the client could not get financing) but I have continued
> > to be a twitter user and have subscribed to this group email. I
> > stopped development on the project because the API does not yet seem
> > stable enough for me to try to produce a marketable product on my own
> > while at the same time chasing an API around. Is my opinion way off
> > the mark or are some of the other developers out there feeling the
> > same way.
>
> > I am considering restarting development on the project if the Twitter
> > API is likely to get more stable in the near future.
>
> > Thanks for tolerating my ravings
>
> > WyoKnott

[twitter-dev] Re: Comments for the group and Twitter staff

[Ryan Sarver]

WyoKnott,

Thanks for your email. We really appreciate the candid feedback and
definitely is not something we want to see happening. I would like to
hear more about what you mean by "not stable enough" and what specific
issues we can work on that would get you to consider Twitter a
platform worthy of building your business on.

I look forward to your feedback.

Best, Ryan

On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott  wrote:
>
> A few months ago I was introduced to the Twitter API by a prospective
> client who wanted a custom application. I took the time to learn the
> API and wrote a quick and dirty standalone windows app. The project
> fell through (the client could not get financing) but I have continued
> to be a twitter user and have subscribed to this group email. I
> stopped development on the project because the API does not yet seem
> stable enough for me to try to produce a marketable product on my own
> while at the same time chasing an API around. Is my opinion way off
> the mark or are some of the other developers out there feeling the
> same way.
>
> I am considering restarting development on the project if the Twitter
> API is likely to get more stable in the near future.
>
> Thanks for tolerating my ravings
>
> WyoKnott
>