Kudos to Mark Ramm...

I spent last night watching Mark's keynote at Djangocon.

http://www.youtube.com/watch?v=fipFKyW2FA4&feature=PlayList&p=D415FAF806EC47A1&index=12

I thought it was a great speech!  It really nailed my frustration at
the lost opportunity of Zope---and my fears about Django.

It also made me feel much better about the path Turbogears is taking.
Hopefully the speech will lead to Django decoupling some of its
elements, making Python web development better for everyone.

Mark was engaging throughout.  He really represented the Turbogears
community well.  I recommend everyone watch it.

Are there any other speeches from Djangocon that would be interesting
to me as a Turbogears developer?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Lukasz Szybalski]

On Tue, Sep 16, 2008 at 5:03 PM, samslists@...
<samslists@...> wrote:
>
> I spent last night watching Mark's keynote at Djangocon.
>
> http://www.youtube.com/watch?v=fipFKyW2FA4&feature=PlayList&p=D415FAF806EC47A1&index=12
>


What did you use to get the "dependency graph" ??? A recipe available?

Lucas

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Mark Ramm]

> I thought it was a great speech!  It really nailed my frustration at
> the lost opportunity of Zope---and my fears about Django.
>
> It also made me feel much better about the path Turbogears is taking.
> Hopefully the speech will lead to Django decoupling some of its
> elements, making Python web development better for everyone.
>
> Mark was engaging throughout.  He really represented the Turbogears
> community well.  I recommend everyone watch it.

Thanks!

> Are there any other speeches from Djangocon that would be interesting
> to me as a Turbogears developer?

I thought Malcom's talk on how to get a patch into Django was good,
and I was very impressed with Cal Henderson's talk called "Why I hate
Django"  which in spite of the title is even less critical of django
than my talk.

--Mark Ramm

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Mark Ramm]

> What did you use to get the "dependency graph" ??? A recipe available?

snakefood!

http://furius.ca/snakefood/

I hadn't used snakefood before showing up at djangocon and the
dependency graphs were a last minute addition to the presentation to
combat some misconceptions that I saw happening at the conference.
So, there are perhaps better ways of doing the diagrams that the ones
I used.

If you're trying to recreate, make sure you remove the tests directory
from both TG2 and from Django, as tests will really mess up your
dependency graph ;)

--Mark Ramm

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jorge Vargas]

yes indeed nice talk, good to know about snakefood, I was going to bet
my money on pycallgraph, but then I went to watch the video and didn't
embarace myself in public :)

snakefood seems to be a better algorithm than pycallgraph, although
the output (dot files) from pycallgraph seems more manageable.

But back to the subject, nice talk. I saw a little hostility from the
first question :) Other than that it turned out really good.

On Tue, Sep 16, 2008 at 9:45 PM, Mark Ramm <mark.mchristensen@...> wrote:

>
>> What did you use to get the "dependency graph" ??? A recipe available?
>
> snakefood!
>
> http://furius.ca/snakefood/
>
> I hadn't used snakefood before showing up at djangocon and the
> dependency graphs were a last minute addition to the presentation to
> combat some misconceptions that I saw happening at the conference.
> So, there are perhaps better ways of doing the diagrams that the ones
> I used.
>
> If you're trying to recreate, make sure you remove the tests directory
> from both TG2 and from Django, as tests will really mess up your
> dependency graph ;)
>
> --Mark Ramm
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sep 16, 9:39 pm, "Jorge Vargas" <jorge.var...@...> wrote:
> But back to the subject, nice talk. I saw a little hostility from the
> first question :) Other than that it turned out really good.

Who was the guy that asked the first question? One of the lead
developers of Django I assume?

Mark, how did they know to ask you?  I mean it was a great choice---
but a weird one.  Or did you volunteer?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Wavy Davy]

2008/9/17 ockman@... <ockman@...>:
>
> On Sep 16, 9:39 pm, "Jorge Vargas" <jorge.var...@...> wrote:
>> But back to the subject, nice talk. I saw a little hostility from the
>> first question :) Other than that it turned out really good.
>
> Who was the guy that asked the first question? One of the lead
> developers of Django I assume?

I'm guessing James Tauber? Of cloud27/Pinax fame? Definitely trying to
"picking holes", IMO (although he chose straw men - he could have
picked some serious holes!).

> Mark, how did they know to ask you?  I mean it was a great choice---
> but a weird one.  Or did you volunteer?

I agreed, it was an inspired choice.

I attended PyCon UK last week, and it was excellent. Django has a
heavy presence there (Jacob KM+ Simon Willison, two django leads were
there giving talks), the django BOF had a good 25 people doing some
really interesting things. There was some Pylons stuff, but little TG
presence (Ian from ShowMeDo was there asking me questions about how to
upgrade from TG1 to TG2).

I hadn't seen any djangocon videos before I went, I've just watch Cal
Henderson's and Mark's, and they completely define the conversations I
had with django people at PyCon UK.

django user: I would love cookie based sessions.
me: Beaker?
django user: When are we going to get multiple DB support?
me: SQLAlchemy?

I think Mark provided answers for 80% of the technical limitations of
Django raised by Cal Henderson, maybe.

Basically - great job Mark!

You said exactly what I had been thinking (plus some!), with
conviction and authority, without unnecessary antagonism. Brilliant. I
had conversations with Jacob KM about exactly the things you talked
about (e.g. WSGI<->Django middleware wrapper), and they are thinking
of doing this, I think largely as a result of your talk. He confessed
embarrassment as an engineer about the dependency graph, and was
interested to learn more about how TG has handled easy_install (he
didn't know you can supply your own egg repo via a html page).

I was punching the air on the bus this morning as I watched your talk :)

Two things I learned that Django does better than TG/Pylons, IMO:

Style:

Django stuff looks good. The culture in Django is more design
orientated than TG, and I think that is a factor in their success. At
PyCon UK, Stephen Emslie demo'd a nice interactive WSGI profiler
module[1], and one the Django folk's comments was "Sweet! But you
Pylons guys always make things so ugly - get a designer to give you a
style sheet already". They have a point IMHO.

Apps:

Django has a large amount of plugin apps
(wiki/forums/openid/tagging/notifications/IM/IRC/etc) that add
functionality to the whole stack (views, controllers, middleware,
model). They can do this because they know the whole stack in advance.
The included admin interface is a classic example.

Pylons doesn't dictate the whole stack, so its more difficult for
people to write plugin apps that need top-to-bottom access. However,
TG does make some choices, which might enable us to do more plugins
apps, but we still value choice.

RUM is likely the way forward here - if we write things to the RUM
Factory apis[2], controller/model interactions can be abstracted to
allow plugin apps to work with any stack component, in theory.

That's all, sorry for the length!

[1] http://pypi.python.org/pypi/WSGIProfile/0.1dev
[2] http://toscawidgets.org/documentation/rum/developer/architecture.html#architecture

--
Simon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Mark Ramm]

> Who was the guy that asked the first question? One of the lead
> developers of Django I assume?

James Bennet.  He's the Release Manager for django these days.

> Mark, how did they know to ask you?  I mean it was a great choice---
> but a weird one.  Or did you volunteer?

I've knows Jacob and Adrian for a couple of years, and have spent a
good amount of time hanging out with Jacob at various post-pycon trips
to the bar.   And one infamous evening of drinking in the pycon sprint
rooms, the evidence of which can be found here:

http://www.flickr.com/photos/jacobian/408225687/

Which resulted in some drunken additions to an ERD diagram, that in
hindsight seem a bit strange:

http://www.flickr.com/photos/jacobian/408225703/

Sorry, I just discovered those pictures last night, and thought they
where hilarious.

--Mark Ramm

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Mark Ramm]

>> Who was the guy that asked the first question? One of the lead
>> developers of Django I assume?
>
> I'm guessing James Tauber? Of cloud27/Pinax fame? Definitely trying to
> "picking holes", IMO (although he chose straw men - he could have
> picked some serious holes!).

James is correct, but it was Bennet not Tauber.   ;)

>> Mark, how did they know to ask you?  I mean it was a great choice---
>> but a weird one.  Or did you volunteer?
>
> I agreed, it was an inspired choice.

As I mentioned you'll have to thank Jacob for that one -- he's the one
who asked me to do it, and encouraged me not to pull my punches, but
to say what I really thought.
> You said exactly what I had been thinking (plus some!), with
> conviction and authority, without unnecessary antagonism. Brilliant. I
> had conversations with Jacob KM about exactly the things you talked
> about (e.g. WSGI<->Django middleware wrapper), and they are thinking
> of doing this, I think largely as a result of your talk. He confessed
> embarrassment as an engineer about the dependency graph, and was
> interested to learn more about how TG has handled easy_install (he
> didn't know you can supply your own egg repo via a html page).
       
Kevin Teague has a great blog post abut the package installation
infrastructure that's available in python.  He pretty much charts all
the options.

http://www.bud.ca/blog/pony

Though I do think it might be worth mentioning in the context of
Django that you could do something like distribute a tarball with all
of the packages django needs included and a paver script that lets you
install all the django dependencies before you install django itself.

> Two things I learned that Django does better than TG/Pylons, IMO:
>
> Style:
>
> Django stuff looks good. The culture in Django is more design
> orientated than TG, and I think that is a factor in their success. At
> PyCon UK, Stephen Emslie demo'd a nice interactive WSGI profiler
> module[1], and one the Django folk's comments was "Sweet! But you
> Pylons guys always make things so ugly - get a designer to give you a
> style sheet already". They have a point IMHO.

Well, we need to attract more designers ;)   But seriously, this is a
point well taken, and we're trying to improve the out of the box
design experience for many TG related projects.   And in the
particular case of the WSGI profiler, I think that Armin may be
getting involved, and he has some design sense.

> Apps:
>
> Django has a large amount of plugin apps
> (wiki/forums/openid/tagging/notifications/IM/IRC/etc) that add
> functionality to the whole stack (views, controllers, middleware,
> model). They can do this because they know the whole stack in advance.
> The included admin interface is a classic example.
>
> Pylons doesn't dictate the whole stack, so its more difficult for
> people to write plugin apps that need top-to-bottom access. However,
> TG does make some choices, which might enable us to do more plugins
> apps, but we still value choice.
>
> RUM is likely the way forward here - if we write things to the RUM
> Factory apis[2], controller/model interactions can be abstracted to
> allow plugin apps to work with any stack component, in theory.

One that TurboGears exists, is that we want to allow people to write
plugin apps that assume the existence of SQLAlchemy, can be mounted
easily by instantiating an object, and can assume that you have other
necessary components like Beaker sessions, automatic cross-database
transactions, genshi, mako and/or jinja.

I think it would be interesting to create some of those plugins
towards the RUM data abstraction layer, but I don't at all think it's
necessary for most pluggable apps -- a very large majority of our
users are going to be using SQLAlchemy.   And if they aren't we can
still use SA in plugins and have the transaction manager manage the
interactions between the plugin database commits and the ones that the
app does itself.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Wavy Davy]

2008/9/17 Mark Ramm <mark.mchristensen@...>:
> As I mentioned you'll have to thank Jacob for that one -- he's the one
> who asked me to do it, and encouraged me not to pull my punches, but
> to say what I really thought.

Fair play.

[snip]

> Kevin Teague has a great blog post abut the package installation
> infrastructure that's available in python.  He pretty much charts all
> the options.
>
> http://www.bud.ca/blog/pony
>
> Though I do think it might be worth mentioning in the context of
> Django that you could do something like distribute a tarball with all
> of the packages django needs included and a paver script that lets you
> install all the django dependencies before you install django itself.

Yeah I saw that, and Jacob mentioned the egg tarball option.

>> 2008/9/17 Simon Davy <bloodearnest@...>:
>> Two things I learned that Django does better than TG/Pylons, IMO:
>>
>> Style:
>>
>> Django stuff looks good. The culture in Django is more design
>> orientated than TG, and I think that is a factor in their success. At
>> PyCon UK, Stephen Emslie demo'd a nice interactive WSGI profiler
>> module[1], and one the Django folk's comments was "Sweet! But you
>> Pylons guys always make things so ugly - get a designer to give you a
>> style sheet already". They have a point IMHO.
>
> Well, we need to attract more designers ;)   But seriously, this is a
> point well taken, and we're trying to improve the out of the box
> design experience for many TG related projects.   And in the
> particular case of the WSGI profiler, I think that Armin may be
> getting involved, and he has some design sense.

Hmm, I might try getting some designer friends interested in contributing...

>> Apps:
[SNIP]
>> RUM is likely the way forward here - if we write things to the RUM
>> Factory apis[2], controller/model interactions can be abstracted to
>> allow plugin apps to work with any stack component, in theory.
>
> One that TurboGears exists, is that we want to allow people to write
> plugin apps that assume the existence of SQLAlchemy, can be mounted
> easily by instantiating an object, and can assume that you have other
> necessary components like Beaker sessions, automatic cross-database
> transactions, genshi, mako and/or jinja.

Fair enough, but all the Django apps "assume" you have the django
stack, so we're not getting any closer to app reuse between frameworks
(which may be an ambitious goal, I agree)

> I think it would be interesting to create some of those plugins
> towards the RUM data abstraction layer, but I don't at all think it's
> necessary for most pluggable apps -- a very large majority of our
> users are going to be using SQLAlchemy.   And if they aren't we can
> still use SA in plugins and have the transaction manager manage the
> interactions between the plugin database commits and the ones that the
> app does itself.

I didn't realise SA could do that, but that might go a long way to
solving the problem.

SA is great, as 99% agree, but if we start assuming it for the
TG/Pylons app ecosystem, we could very quickly end up like Django -
all that functionality lost unless you use a particular stack (in the
case SA).

Having said that, at least we're only building to the ORM, not the
entire view/controller/middleware stack.

And who doesn't use SA, really (he says as his SQLObject TG1 apps
soldier on...)?

--
Simon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christopher Arndt]

Wavy Davy schrieb:

> Two things I learned that Django does better than TG/Pylons, IMO:
>
> Style:
>
> Django stuff looks good. The culture in Django is more design
> orientated than TG, and I think that is a factor in their success. At
> PyCon UK, Stephen Emslie demo'd a nice interactive WSGI profiler
> module[1], and one the Django folk's comments was "Sweet! But you
> Pylons guys always make things so ugly - get a designer to give you a
> style sheet already". They have a point IMHO.

Yes, there is indeed a lack of contributions from good designers to
TurboGears. There were some people who created good looking logos,
quickstart templates etc. when TG was new but apparently they have left
the project. We are aware of this lack but so far our appeals for
contributions in this respect have not yielded much success. My
suspicion is that TG is regarded as "uncool" because it doesn't have the
marketing clout of RoR or django and you know how these designer types
are ;)

It's not that I personally wouldn't be able to create good looking
websites or maybe even artwork that is not unpleasant to look at but
there is always some coding to do which seems more important. I suspect
it is similar for many TG core developers.

Chris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Sanjiv]

Congratulations Mark. That was awesome stuff.

And thanks for making a mention of tg.ext.geo ;)

Regards
Sanjiv

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jorge Godoy-2]

Em Wednesday 17 September 2008 12:27:27 Christopher Arndt escreveu:
>
> It's not that I personally wouldn't be able to create good looking
> websites or maybe even artwork that is not unpleasant to look at but
> there is always some coding to do which seems more important. I suspect
> it is similar for many TG core developers.

I vote for styling our default templates in a way that CSS from the CSS Zen
Garden (http://www.csszengarden.com/) works out of the box.

Or maybe using something from http://www.oswd.org/ 


Regards,
--
Jorge Godoy      <jgodoy@...>

[iain duncan]

> > I think it would be interesting to create some of those plugins
> > towards the RUM data abstraction layer, but I don't at all think it's
> > necessary for most pluggable apps -- a very large majority of our
> > users are going to be using SQLAlchemy.   And if they aren't we can
> > still use SA in plugins and have the transaction manager manage the
> > interactions between the plugin database commits and the ones that the
> > app does itself.
>
> I didn't realise SA could do that, but that might go a long way to
> solving the problem.
>
> SA is great, as 99% agree, but if we start assuming it for the
> TG/Pylons app ecosystem, we could very quickly end up like Django -
> all that functionality lost unless you use a particular stack (in the
> case SA).

I made my own rumish thing ( much more primitive, no introspection ),
and to tell you the truth, I think eliminating SA dependency is not
hard. SA and storm and dejavu are well designed so that you can pretty
much write an interface in one page of code to do you updates and
selects that would be fine in 90% of use cases.

If you limit your use to:
- get by id
- get by dictionary
  - list, one with exception, one with none
- update by dictionary
You just don't really need to call the orm interface in your
rest-admin-controller.

I don't think it would be at all hard to add an adapter to allow the app
to work with dejavu, storm, so, etc.

So, yeah, I agree with mark, the extra complexity of adding that
abstraction layer is absolutely and utterly worth it.

Iain



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[Florent Aide]

On Wed, Sep 17, 2008 at 8:16 PM, Jorge Godoy <jgodoy@...> wrote:

> Em Wednesday 17 September 2008 12:27:27 Christopher Arndt escreveu:
>>
>> It's not that I personally wouldn't be able to create good looking
>> websites or maybe even artwork that is not unpleasant to look at but
>> there is always some coding to do which seems more important. I suspect
>> it is similar for many TG core developers.
>
> I vote for styling our default templates in a way that CSS from the CSS Zen
> Garden (http://www.csszengarden.com/) works out of the box.
>
> Or maybe using something from http://www.oswd.org/
>
>

You're right. I had this in mind for some time now. I think we should
have even in 1.1 a new quickstart CSS that make people look at it with
envy :)
I'll spend some time on this before 1.1 stable is out.

And I definitely encourage someone to integrate a cool looking and
different CSS for the 2.0 stable release. Anyone ?

Florent.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

[half.italian]

On Sep 16, 8:42 pm, "Mark Ramm" <mark.mchristen...@...> wrote:

> > I thought it was a great speech!  It really nailed my frustration at
> > the lost opportunity of Zope---and my fears about Django.
>
> > It also made me feel much better about the path Turbogears is taking.
> > Hopefully the speech will lead to Django decoupling some of its
> > elements, making Python web development better for everyone.
>
> > Mark was engaging throughout.  He really represented the Turbogears
> > community well.  I recommend everyone watch it.
>
> Thanks!
>
> > Are there any other speeches from Djangocon that would be interesting
> > to me as a Turbogears developer?
>
> I thought Malcom's talk on how to get a patch into Django was good,
> and I was very impressed with Cal Henderson's talk called "Why I hate
> Django"  which in spite of the title is even less critical of django
> than my talk.
>
> --Mark Ramm

Great speech.  Looking back, I think I made the right choice in
frameworks.

Why spend extra time developing things that other people are already
doing?  Not to mention the other developers will be stoked, and more
apt to keep up/develop the software, when it is used in many more
apps.

You have the right path.  Make sure TG2, when stable, is ready to
stick with the components for an extended period of time.

~Sean
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbogears@...
To unsubscribe from this group, send email to turbogears+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---