Disqus - Latest Comments for tav

Re: Why App Engine Is Not Appropriate For Bootstrap

tav — Mon, 26 Oct 2009 04:40:02 -0000

Ryan Barrett — the man behind App Engine's datastore posted a really nice reply a few months ago. For some reason, Disqus sent the reply via e-mail but never showed it here, so here it is for the sake of completeness:

--------------------------------------

thanks for the post! we're always interested in well-reasoned feedback like this.

it probably won't surprise you that most of the answers here boil down to priorities. we'd love to implement most of these, but we're not a big team, so we have to prioritize ruthlessly. i can address a few points specifically, though.

2) agreed! unfortunately, datastore backend support for this is unlikely due to the underlying implementation on bigtable. happily, this is entirely possible in userland. my groups post has more details: http://groups.google.com/group/google-appengine... . brett slatkin's recent i/o talk is also related, specifically the relation indexes/entities part: http://code.google.com/events/io/sessions/Build... .

3) we actually considered this, and we may reconsider it in the future. the actual savings would be negligible in most cases, though. the only meaningful part we could remove is some of the protocol buffer encoding decoding and maybe one or two of the RPCs. the bulk of it, including the underlying datastore cost, would be unchanged.

5) i'm very much looking forward to offering more async support in our APIs. in the meantime, check out vendasta's asynctools project, http://squeeville.com/2009/07/24/asynctools/ .

6) we actually posted an in-depth postmortem less than a week afterward: http://groups.google.com/group/google-appengine... . regardless, agreed, we hate outages as much as everyone else. we're continually working to avoid and minimize them.

Re: foursquare - Announcing the foursquare angel roster...

tav — Fri, 09 Oct 2009 18:52:07 -0000

Well done again guys -- that's an impressive list and I hope it comes together well for you.

-- tav

Re: Tav Describes Pecus

tav — Fri, 25 Sep 2009 00:54:50 -0000

Hey boggle,

Perhaps age is getting to you already ;p

If you recall the conversation we had in the park last year, you already convinced me of limiting Pecu lifetimes! And if you go to the post above, you'll see that the pseudo-structure of a Pecu allocation already has a shiny "valid_until" field =)

So, yes, I agree with you that limiting Pecu lifetimes has a lot of value. Regarding Liquid Democracy, see the link in the post above about Plex Democracy... it's even better!

As for dilution, there are two separate issues. One is the constant dilution that happens through people making Pecu allocations. This is the very nature of Pecu allocations and designed to be so! It encourages people to (a) do things that have lasting value and (b) invest in efforts which will have a high "yield" (i.e. return on investment of their efforts).

The other issue is of someone throwing their Pecu allocations totally out of whack by suddenly diluting everyone else close to nil. Given the existence of valid_until, there should a very good explanation for this OR there'd be a lot of social backlash against the individual.

In contrast to the current frame where we rely on the law and regulation to ensure good behaviour, Pecus relies on people's social networks. And as the last year has clearly shown, laws and regulations are easily circumvented. In contrast, social pressure is much harder to work around...

And, finally, regarding retirement, I thought the idea was to live fast, die young and leave a good looking corpse? ;p

Just kidding -- there's a retirement plan awaiting you sir =)

Sorry for the long delay in replying, but hope the above makes sense.

Re: Support Espra: Create Weapons of Mass Construction!

tav — Wed, 23 Sep 2009 12:32:37 -0000

Another test post -- please ignore

Re: Sanitising JSONP Callback Identifiers For Security

pilif — Mon, 07 Sep 2009 17:20:12 -0000

what you are describing is just the standard case of any XSS.

But there is no difference what so ever between

<script>alert(document.cookies)</script>

and

<script src="http://othersite.com/jsonp?callback=alert(document.cookies);foo">

while I agree that XSS must be avoided at all cost, this is not the job of the remote site. It's the job of the local site.

PS: let's hope my sample code goes through :-)

Re: Sanitising JSONP Callback Identifiers For Security

tav — Mon, 07 Sep 2009 13:42:54 -0000

Thanks for the comment btw -- I've updated the article in response too. Cheers!

Re: Sanitising JSONP Callback Identifiers For Security

tav — Mon, 07 Sep 2009 13:34:26 -0000

Hey Philip,

You are right, the code is executed in the context of the CALLERs page. But that is the problem...

Imagine the scenario, where a client-side web application allows arbitrary data sources to be added... it's not too implausible a future where instead of adding RSS feeds to an RSS Reader, one adds JSON feeds to such an application...

In this context, if the user is tricked into adding a maliciously crafted URL, then everything from their identity to their data is accessible... not to mention being able to abuse the account to spread a worm even...

I believe the possibilities of using JSONP haven't been explored much yet, and for it to go further in the context of interesting mashups/applications, it's important that it not be a security hole...

Hope that makes sense!

Re: Board Of Mentors

tav — Wed, 02 Sep 2009 02:02:09 -0000

Good call with Stephen Fry -- can you add him via Git?

Re: tr.im R.I.P.

tav — Sun, 09 Aug 2009 23:41:53 -0000

Sorry to hear about your current condition.

Good job though and thanks for providing the service this long!

Re: Ruby-style Blocks in Python

Name — Tue, 14 Jul 2009 06:27:14 -0000

Sorry to hear that. I'm not familiar with the intrinsics of the PEP process, but maybe there is a chance of publishing what you have so far, and open the door for others to work on it. Maybe someone else has a solution.

Re: Ruby-style Blocks in Python

tav — Mon, 13 Jul 2009 12:31:49 -0000

Thanks man -- unfortunately I got stuck in terms of figuring out how to make exceptions raised inside blocks be Pythonic...

Without solving that, not much use in putting together a PEP =(

Re: Logrep: A Simple Apache Log Analysis Script

tav — Mon, 13 Jul 2009 12:23:14 -0000

@tavis: defaultdict is part of Python 2.5 and later -- you'd need to use a more recent version of Python with logrep.py

Re: Why App Engine Is Not Appropriate

tav — Sun, 05 Jul 2009 04:35:46 -0000

Testing...

Re: Ruby-style Blocks in Python

Verte — Thu, 19 Mar 2009 04:52:32 -0000

How about 'let' or 'let .. in' ? we could even have letrec.

Re: Say No to Google's Intrusion of Privacy

tav — Thu, 12 Mar 2009 21:25:40 -0000

Hey Hannah,

Thanks for that. I've updated the instructions slightly -- is it clearer now?

I think it would be good to actually specify the location of the hosts file, but I fear that might get a bit too technical too quickly -- especially given the different platforms/routers/etc. =(

Hopefully the link to the Wikipedia article is good enough?

Re: Say No to Google's Intrusion of Privacy

tav — Thu, 12 Mar 2009 21:21:43 -0000

Hey Nils,

Like the cam-detector!!

Thanks for pointing out NoScript -- I only worry that it might be a bit too technical for *most* users =(

But good idea for the technical readers of this blog to try out...

PS. Sorry we didn't get a chance to chat the other day...

Re: Happy Birthday Matthieu!

tav — Thu, 12 Mar 2009 21:19:15 -0000

Hey Andrius, great to hear that you'll be coming to London -- would be good to meet up. Email me tav@espians.com to fix up specific dates.

As for Zenonas and Irena, unfortunately both of our spare rooms are currently taken -- some other time perhaps =(

Re: Logrep: A Simple Apache Log Analysis Script

tav — Thu, 12 Mar 2009 21:12:15 -0000

Hey Marius,

Because the format I use with single-dash followed by word and arbitrary parameters is rather cumbersome to do with optparse..

I do like optparse and have been using it since the days of Optik, so highly recommend it for any public facing projects.

Re: Update on Securing the Python Interpreter

tav — Wed, 11 Mar 2009 10:24:42 -0000

Mark, I've fixed up safelite.py and made the documentation in this article now only support the explicit version of Namespace(). Thanks again!

Re: Update on Securing the Python Interpreter

tav — Wed, 11 Mar 2009 10:11:34 -0000

Hey Mark,

Thank you for this!

Sorry that I missed the discussion on e-lang -- wasn't aware that a similar approach was being explored on there! I see both were inspired by Ka-Ping Yee's post years ago...

The Namespace function initially only supported the explicit:

Namespace(get_x=get_x, get_y=get_y)
Namespace(get_x, get_y) # using __name__

It still supports this format. But, as you rightly pointed out in that email, it quickly got tedious and I streamlined it ;p

By removing the implicit format the attack you show goes away... and we go back to a pure capability base. Perhaps we could start from there?

As for your concerns of efficiency in the email, in my C/Cython implementation of Namespace:

http://github.com/tav/plexnet/blob/9f2ca9505e57...

I use a trick from the PyPy guys and share the dictionary *keys* amongst the various Namespace objects. This is still nowhere near as efficient as Python classes, but it at least saves on memory -- which could be considerable when lots of similar Namespace objects are created.

And speaking of PyPy, I'm increasingly tending towards using it as a showcase:

* Fork the Python implementation on PyPy
* Add native support for object capability and some distributed features
* Bootstrap from that point and demonstrate the viability/utility of the ideas

We could perhaps even take a leaf from Allen Short's C implementation of E (ecru) where he builds it as an extension type for Python -- allowing it to be bootstrapped off existing Python libraries...

In an ideal case, the ideas would then get folded back into mainline Python -- but failing that, we would still have a Python-esque object-capability language that should be useful on its own...

What do you think of this?

--
Thanks again for taking the time to share your thoughts, tav

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 11:41:53 -0000

Multi-line lambdas would be nice, but one step at a time =)

And thanks for the blog article!

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 08:57:26 -0000

Thanks Joeri -- fixed.

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 08:55:47 -0000

Thanks for catching the mistake Mark -- fixed.

I agree that {} and shorter code would be better. Unfortunately I haven't been able to come with a Pythonic way of doing that.

This proposal was about trying to come with a Pythonic equivalent.

As for a better language, I agree -- and perhaps I should just do that -- there would be a lot less resistance! =)

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 08:47:57 -0000

Thanks sjs, perhaps an accompanying decorator would help too?

Re: Ruby-style Blocks in Python

tav — Mon, 09 Mar 2009 08:34:06 -0000

Thanks Todd! That fits the bill quite nicely -- despite being slightly longer to type...

Will update this proposal now.