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
www.museumparcgarage.com
Overnight Hotel Parking: $25.00 per night with In & Out Priveleges
Hours:
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
