> So it would be cool if some way were provided for me to gauge tweet
> volumes at regular intervals (currently every 2 minutes).

Take a look to Tweespeed http://www.tweespeed.com

But with the change annonced, this site is dead at term ...

pas...@tweespeed

On Mar 26, 10:01 pm, jerememonteau <m...@jmoe.com> wrote:
> Whoops, accidentally just replied to author the first time...but...
>
> I build this little site about 9 months ago, depending on the
> monotonically increasing nature of tweet IDs :
>
> http://www.tweelocity.com
>
> This is a fun graph :
>
> http://tweelocity.com/chart/60/300/
>
> So it would be cool if some way were provided for me to gauge tweet
> volumes at regular intervals (currently every 2 minutes).
>
> I also think it's super cool that the twitter team is even giving a
> heads up like this.
>
> On Mar 26, 1:41 pm, Taylor Singletary <taylorsinglet...@twitter.com>
> wrote:
>
> > Hi Developers,
>
> > It's no secret that Twitter is growing exponentially. The tweets keep coming
> > with ever increasing velocity, thanks in large part to your great
> > applications.
>
> > Twitter has adapted to the increasing number of tweets in ways that have
> > affected you in the past: We moved from 32 bit unsigned integers to 64-bit
> > unsigned integers for status IDs some time ago. You all weathered that storm
> > with ease. The tweetapoclypse was averted, and the tweets kept flowing.
>
> > Now we're reaching the scalability limit of our current tweet ID generation
> > scheme. Unlike the previous tweet ID migrations, the solution to the current
> > issue is significantly different. However, in most cases the new approach we
> > will take will not result in any noticeable differences to you the developer
> > or your users.
>
> > We are planning to replace our current sequential tweet ID generation
> > routine with a simple, more scalable solution. IDs will still be 64-bit
> > unsigned integers. However, this new solution is no longer guaranteed to
> > generate sequential IDs.  Instead IDs will be derived based on time: the
> > most significant bits being sourced from a timestamp and the least
> > significant bits will be effectively random.
>
> > Please don't depend on the exact format of the ID. As our infrastructure
> > needs evolve, we might need to tweak the generation algorithm again.
>
> > If you've been trying to divine meaning from status IDs aside from their
> > role as a primary key, you won't be able to anymore. Likewise for usage of
> > IDs in mathematical operations -- for instance, subtracting two status IDs
> > to determine the number of tweets in between will no longer be possible.
>
> > For the majority of applications we think this scheme switch will be a
> > non-event. Before implementing these changes, we'd like to know if your
> > applications currently depend on the sequential nature of IDs. Do you depend
> > on the density of the tweet sequence being constant?  Are you trying to
> > analyze the IDs as anything other than opaque, ordered identifiers? Aside
> > for guaranteed sequential tweet ID ordering, what APIs can we provide you to
> > accomplish your goals?
>
> > Taylor Singletary
> > Developer Advocate, Twitterhttp://twitter.com/episod

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words "REMOVE ME" as the subject.

Reply via email to