About Parking. Closest one near Twitter is Museum Parc Garage. It
closes at 11pm on Sat and 6pm on Sun.

There are other overnight parking but they charge $25-$32 for 12-24
hrs. Many parking options on 3rd Street between Harrison & Folsom Full
Day $8-10 on weekend. Some of them are outdoor so I don't think there
is issue on building being closed at night.

I am very surprise the parking situation near Twitter is better than
expected. Next time I would map other parking options so we can share
the info better on Tweet feed.

Museum Parc Garage
300 3rd St
(between Folsom St & Saint Francis Pl)
San Francisco, CA 94107
Neighborhood: SOMA
(415) 284-9553

Overnight Hotel Parking: $25.00 per night with In & Out Priveleges
    Mon-Fri 6 a.m. - 11 p.m.
    Sat 8 a.m. - 11 p.m.

On May 31, 12:56 pm, "zbowl...@gmail.com" <zbowl...@gmail.com> wrote:
> I was still waking up and recovering from yesterday when I wrote this
> so forgive the typos, grammar, and mixing up attributes as
> annotations.
> I also wanted to mention that I'm glad that twitter didn't confuse
> annotations by using the term namespace or providing some kind of
> mechanism that goes that direction. I originally was wondering about
> conflicting but this method is better. Namespace gives developers a
> sense of ownership with the data stored in that annotation type. You
> can easily still easily namespace your types if you want (possibly in
> the reverse DNS format used in Java) but you can't prevent other
> developers from using them and that needs to be conveyed. If you need
> to strongly store annotation data, you can use signatures, hashes,
> version markers, or whatever in the annotation that you want to
> provide that, but it's up to the developer to what they want to fit
> their needs.
> Also wanted to playfully rant that parking overnight on the weekend
> near Twitter HQ sucks, especially when there is a baseball game. The
> closest garages all close at night on the weekends, so I ended up
> moving my car 3 times. Next time I'm taking BART and riding my
> bike. :-)
> Also
> On May 31, 11:39 am, Zac Bowling <zbowl...@gmail.com> wrote:
> > This weekend's hackfest was at Twitter HQ was fun. About a couple dozen of 
> > us stayed awake for about 30 hours and still had enough to energy to 
> > present. Some pretty amazing things created and we helped identified a 
> > bunch of bugs.
> > Now that I've had a chance to go home and catch up on some sleep, here is a 
> > brain dump of my thoughts.
> > * One of the documented recommended types is place/location, but this data 
> > is similar to what we store in the geo fields. I'm not sure what issues we 
> > may run into privacy using it rather then storing the Geo fields (users can 
> > enable/disable geo and remove geo data from all previous status updates).
> > * We will always have twitter clients that will not understand or look even 
> > look at our attributes. This means that we can't can't have annotations 
> > that change the meaning of a tweet or make the meaning of the tweet 
> > useless. This is basically graceful degradation, and not progressive 
> > enhancement. We joked that want to see tweets that say: "This tweet can 
> > only be read in clients that support X annotations. Please upgrade your 
> > twitter client or try X client.".
> > * You have to treat annotations as potentially hostile attack vectors.  As 
> > was proved with some awesome cornfied and flashing unicorn injections this 
> > weekend, any raw data can be store in annotations. Just because you stored 
> > it there, anyone can do store any raw data and anyone can post tweets that 
> > copy your annotation format. Twitter may sanitize javascript injections, 
> > but it doesn't stop other types of injections from occurring if you don't 
> > check. It's extremely important to validate, html encode, or whatever you 
> > need to with the data stored in the annotations.
> > As I did with my twitter remote shell execution example, I added my own 
> > signature and noance of my own into the twitter annotation to validate the 
> > sender had my secret. It may be one solution.
> > * Attributes work at the time of creation because status updates are 
> > immutable. This may be obvious to most, but its a limitation that hits you 
> > a few times as you develop. Because of that we need to make sure that we 
> > can get most of the clients, including Twitter.com, support the most 
> > popular annotation formats. We can't fix update status updates after the 
> > fact so we have to get it right.  (Adding annotations to new style retweets 
> > is in theory possible)
> > * Can't remind people enough to switch from twitter.com to api.twitter.com. 
> >  A bunch of little differences between the two that give you headaches. Our 
> > "board of wasted time" at the hackfest summed it up pretty well.
> > * A good number of us spent a good deal of time on just getting past OAuth 
> > this weekend. We had a lot of people that understood the OAuth spec fairly 
> > well thankfully and @jmhodges was there to help (although not his area he 
> > deals with in the code). Since you update twitter with POST, it's optional 
> > to store the authentication data in the postdata instead of the 
> > authentication header according to the spec, and some our libraries were 
> > doing just that, but twitter only works with the Authentication header. We 
> > didn't know but this was documented on the Wiki and had to learned from 
> > trial and error. A bunch of us got caught up on using twitter.com instead 
> > of api.twitter.com. I think we all worked through it at about midnight late 
> > saturday.
> > In the end it was pretty awesome. I want to thank @jonashuckestein for the 
> > the bookmarklet. It was awesome and saved us all time.
> >http://jonashuckestein.github.com/Twitter.com-Annotations-Bookmarklet...my 
> >stream with ithttp://twitpic.com/1st8sd)
> > I won't cover the bugs. I'll leave twitter to document those if and when 
> > they open up annotations to more developers.
> > Thanks all!
> > Zac Bowling
> > @zbowling

Reply via email to