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