To give everyone another update, we are still on track to trigger Twitpocalypse II tomorrow (Tuesday 9/22) at 11:30am PST. We are trying to do it as early in the day as we can on our side to accommodate developers in other timezones.
For those of you unaware of what the Twitpocalypse is (hopefully no one by now), Alex previously noted "the Twitter operations team will artificially increase the maximum status ID to 4294967296 ... If your Twitter API application stores status IDs, please be sure that your datastore is configured to handle integers of that size."
A few of us will be available in IRC if you need live support, otherwise email the list with any questions you may have.
> To give everyone another update, we are still on track to trigger > Twitpocalypse II tomorrow (Tuesday 9/22) at 11:30am PST. We are trying > to do it as early in the day as we can on our side to accommodate > developers in other timezones.
> For those of you unaware of what the Twitpocalypse is (hopefully no > one by now), Alex previously noted "the Twitter operations team will > artificially increase the maximum status ID to 4294967296 ... If your > Twitter API application stores status IDs, please be sure that your > datastore is configured to handle integers of that size."
> A few of us will be available in IRC if you need live support, > otherwise email the list with any questions you may have.
On Mon, Sep 21, 2009 at 14:22, Michael Steuer <mste...@gmail.com> wrote:
> With all your developer partners at TC140 tomorrow???
> On Sep 21, 2009, at 11:36 AM, Ryan Sarver <rsar...@twitter.com> wrote:
>> To give everyone another update, we are still on track to trigger >> Twitpocalypse II tomorrow (Tuesday 9/22) at 11:30am PST. We are trying >> to do it as early in the day as we can on our side to accommodate >> developers in other timezones.
>> For those of you unaware of what the Twitpocalypse is (hopefully no >> one by now), Alex previously noted "the Twitter operations team will >> artificially increase the maximum status ID to 4294967296 ... If your >> Twitter API application stores status IDs, please be sure that your >> datastore is configured to handle integers of that size."
>> A few of us will be available in IRC if you need live support, >> otherwise email the list with any questions you may have.
On Mon, Sep 21, 2009 at 1:42 PM, JDG <ghil...@gmail.com> wrote:
> Why wouldn't said developer partners have updated their code 2 weeks ago > when this was announced?
Three reasons.
A. Irresponsibility. Paying no attention to anything, they have no clue this is happening and indeed will not even find out what's going on until after it happens.
B. Laziness. Knowing it is easier to fix something that has broken than predict where something is going to break, they voluntarily decided to let their application break and fix it then.
C. Discipline. Having already fixed everything they thought was going to break, they are standing by to make sure they didn't miss anything.
Contrary to popular belief, option B is not necessarily bad. We'd all prefer option C, and option A is clearly the Wrong Thing, but option B is actually a smart response to some business conditions.
On Mon, Sep 21, 2009 at 14:52, Caliban Darklock <cdarkl...@gmail.com> wrote:
> On Mon, Sep 21, 2009 at 1:42 PM, JDG <ghil...@gmail.com> wrote:
> > Why wouldn't said developer partners have updated their code 2 weeks ago > > when this was announced?
> Three reasons.
> A. Irresponsibility. Paying no attention to anything, they have no > clue this is happening and indeed will not even find out what's going > on until after it happens.
> B. Laziness. Knowing it is easier to fix something that has broken > than predict where something is going to break, they voluntarily > decided to let their application break and fix it then.
> C. Discipline. Having already fixed everything they thought was going > to break, they are standing by to make sure they didn't miss anything.
> Contrary to popular belief, option B is not necessarily bad. We'd all > prefer option C, and option A is clearly the Wrong Thing, but option B > is actually a smart response to some business conditions.
On Mon, Sep 21, 2009 at 1:55 PM, JDG <ghil...@gmail.com> wrote: > Agreed, but then they're probably aware of the situation and have made plans > to mitigate if they're going to be attending TC140.
> On Mon, Sep 21, 2009 at 14:52, Caliban Darklock <cdarkl...@gmail.com> wrote:
>> On Mon, Sep 21, 2009 at 1:42 PM, JDG <ghil...@gmail.com> wrote:
>> > Why wouldn't said developer partners have updated their code 2 weeks ago >> > when this was announced?
>> Three reasons.
>> A. Irresponsibility. Paying no attention to anything, they have no >> clue this is happening and indeed will not even find out what's going >> on until after it happens.
>> B. Laziness. Knowing it is easier to fix something that has broken >> than predict where something is going to break, they voluntarily >> decided to let their application break and fix it then.
>> C. Discipline. Having already fixed everything they thought was going >> to break, they are standing by to make sure they didn't miss anything.
>> Contrary to popular belief, option B is not necessarily bad. We'd all >> prefer option C, and option A is clearly the Wrong Thing, but option B >> is actually a smart response to some business conditions.
|
