<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:wfw="http://wellformedweb.org/CommentAPI/"
     >
  <channel>
    <title>Let’s Discuss the Matter Further</title>
    <link>http://rhodesmill.org/brandon</link>
    <description>Thoughts and ideas from Brandon Rhodes</description>
    <pubDate>Tue, 08 May 2012 02:01:57 GMT</pubDate>
    <generator>Blogofile</generator>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <item>
      <title>Grok has book. Book good!</title>
      <link>http://rhodesmill.org/brandon/2010/grok-has-book-book-good/</link>
      <pubDate>Thu, 10 Jun 2010 22:32:52 EDT</pubDate>
      <category><![CDATA[python]]></category>
      <category><![CDATA[grok]]></category>
      <category><![CDATA[books]]></category>
      <category><![CDATA[zope]]></category>
      <category><![CDATA[computing]]></category>
      <guid>http://rhodesmill.org/brandon/2010/grok-has-book-book-good/</guid>
      <description>Grok has book. Book good!</description>

      <content:encoded><![CDATA[
<p>
  I little suspected the great chasm that lies
  between the simple act of agreeing to review a book,
  and the actual exercise of sitting down later to write the review.
  It feels quite pleasant, really,
  to jot off a positive reply to the publisher's polite question.
  One feels magnanimous for agreeing to help advance our civilization
  by reviewing a book about Python,
  and for helping out the publisher in what,
  after all, are such hard economic times.
  It is fun when the free copy arrives,
  crisp and smartly bound.
</p>
<p>
  But then, eventually, one has to write the actual review.
</p>
<a class="image-reference" href="http://www.amazon.com/gp/product/1847197485?ie=UTF8&tag=letsdisthemat-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1847197485"><img border="0" src="http://rhodesmill.org/brandon/static/2010/grok-book.jpg"></a><img src="http://www.assoc-amazon.com/e/ir?t=letsdisthemat-20&l=as2&o=1&a=1847197485" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />
<p>
  And so,
  a full four months after that friendly email from Packt Publishing,
  it is time that I sit down
  and put together some thoughts
  about Carlos de la Guardia's first book,
  <a href="http://www.amazon.com/gp/product/1847197485?ie=UTF8&tag=letsdisthemat-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1847197485"
     >Grok 1.0 Web Development</a>.
  Carlos is a long-time veteran of the Zope and Plone communities,
  and <a href="http://grok.zope.org/">Grok</a>,
  of course,
  is the web framework
  that places a simple and agile convention-driven engine
  atop the otherwise notoriously XML-ridden Zope application framework.
  Grok is an important project,
  because it packages the technology of Python's oldest
  and most experienced community of web developers
  in a way that makes it easy to extend and use.
</p>
<p><a href="http://rhodesmill.org/brandon/2010/grok-has-book-book-good/">Read more</a></p>]]></content:encoded>
    </item>
    <item>
      <title>The July 2009 issue of Python Magazine</title>
      <link>http://rhodesmill.org/brandon/2009/pymag-july/</link>
      <pubDate>Sat, 15 Aug 2009 03:50:14 EDT</pubDate>
      <category><![CDATA[python]]></category>
      <category><![CDATA[grok]]></category>
      <category><![CDATA[zope]]></category>
      <category><![CDATA[computing]]></category>
      <guid>http://rhodesmill.org/brandon/2009/pymag-july/</guid>
      <description>The July 2009 issue of Python Magazine</description>

      <content:encoded><![CDATA[
<a class="image-reference">
  <img src="http://rhodesmill.org/brandon/static/2009/pymag-july.jpg"
       alt="Cover of July 2009 Python Magazine"
       width="200" height="258" />
</a>
<p>
  I am home from a relaxing vacation to the Midwest,
  and while I was gone last week my excellent publishing team
  released the July issue <i>Python Magazine</i> to the world.
  I am particularly pleased that two of the feature articles in this issue
  come from important segments of the Python world
  that we have not heard much from in previous issues.
</p>
<p>
  First,
  <a href="http://www.codeplex.com/IronPython"
     >IronPython, the .NET version of Python for Windows</a>,
  is the topic of Jonathan Hartley's article about acceptance testing.
  He illustrates that,
  regardless of the language
  in which you write your .NET application,
  you can deploy simple strategies
  to make your application testable
  through a Python test harness,
  and thereby bring Python's strong flexibility as a testing language
  to bear on a product
  that you might be writing in another .NET language.
</p>
<p>
  Second, Malthe Borch, a veteran of the Zope community,
  shares how he has written
  <a href="http://chameleon.repoze.org/">Chameleon,
  one of the fastest template language
  implementations available for Python</a>.
  By processing each template
  and turning it into Python bytecode
  before it is ever used to render a single page,
  Malthe eliminates a huge amount of redundant processing
  as that same code is used over and over again.
  His library is a key ingredient
  in the new high-efficiency web frameworks
  appearing in the Zope world.
  His work might even (fingers crossed) become one of the components
  that the Plone community uses
  as they streamline their framework
  and move towards a lighter and more agile “Plone 4”.
</p>
<p>
  Other technical topics covered are: the
  <a href="http://hadoop.apache.org/">Hadoop</a> map-reduce framework;
  the concept of hash functions, and how they apply to Python;
  and the new
  <a href="http://docs.python.org/library/string.html#format-string-syntax"
     >string formatting operator</a>
  which Guido hopes will replace all of the percent-signs
  that currently litter our code.
  Wrap it all up with an editorial by Steve Holden
  about <a href="http://www.europython.eu/">EuroPython 2009</a>
  and an editorial by me,
  and you have a complete issue!
  If you do not find Python Magazine
  sitting on your local newsstand,
  then I hope you will avail yourself of a subscription
  and, as always, let me know what topics
  you would like to see covered in future issues.
  Enjoy!
</p>
]]></content:encoded>
    </item>
    <item>
      <title>Porting a C extension module to Python 3.0</title>
      <link>http://rhodesmill.org/brandon/2008/porting-a-c-extension-module-to-python-30/</link>
      <pubDate>Tue, 09 Dec 2008 04:18:16 EST</pubDate>
      <category><![CDATA[python]]></category>
      <category><![CDATA[grok]]></category>
      <category><![CDATA[pyephem]]></category>
      <category><![CDATA[zope]]></category>
      <category><![CDATA[computing]]></category>
      <guid>http://rhodesmill.org/brandon/2008/porting-a-c-extension-module-to-python-30/</guid>
      <description>Porting a C extension module to Python 3.0</description>

      <content:encoded><![CDATA[
<p>
With several packages already advertising
<a href="http://pypi.python.org/pypi?:action=browse&c=214&c=534"
 >Python 3.0 compatibility</a>,
it seemed high time to look into releasing my
<a href="http://rhodesmill.org/pyephem/">PyEphem astronomy package</a>
in an edition compatible with the new language.
But I hesitated:
how difficult is it <i>really</i>,
and how many hours of work will it consume,
to port a C-language extension module to Python 3.0?
</p>
<p>
The answer is that,
while the necessary changes were surprisingly easy,
they took lots of time to figure out
because I did not find them documented in any one place.
I offer the following notes to assist
any other adventurers who want to experiment
with porting their extension modules to 3.0.
These notes might also suggest
useful additions to the official documentation.
</p>
<p>
But, first, I need to issue three cautions.
To develop under 3.0, you may have to forego several Python tools
that you probably thought you could no longer do without.
The world of 3.0 is a windswept and icy landscape
from which the glaciers have just receded,
and you will find the stone tools rather primitive
when compared to the comforts of civilization
that you enjoy under Python 2.
To wit:
</p>
<ul>
<li>I cannot find
 <a href="http://pypi.python.org/pypi/virtualenv/1.3.1">virtualenv</a>
 for 3.0,
 which is a disaster.
 This means that you have to create a separate Python 3.0 install,
 built with a different <tt>--prefix</tt> option to <tt>./configure</tt>,
 for each development environment you want to create on your box.
</li>
<li>I cannot find a version of the
 <a href="http://peak.telecommunity.com/DevCenter/setuptools">setuptools</a>
 available for 3.0.
 This means limiting your <tt>setup.py</tt> instructions
 to the primitive vocabulary of the <tt>distutils</tt> package.
 For example,
 I find myself unable to run the PyEphem test suite at this late hour
 because I have been running it for so long with:
 <pre>$ python setup.py test</pre>
 that I am not sure how to get it running otherwise.
</li>
<li>Should you succeed in porting your extension module,
 it is not at <i>all</i> clear how to distribute it.
 I had expected either a new PyPI to spring into being —
 since every package will need an entirely different version under 3.0 —
 or for a sophisticated scheme to appear
 for registering one <tt>pyephem.tar.gz</tt> as the Python 2 version
 and another <tt>pyephem.tar.gz</tt> for 3.0.
 But while the most recent version of your package can
 mark itself as
 <a href="http://pypi.python.org/pypi?:action=browse&c=214&c=527"
  >2-compatible</a> or
 <a href="http://pypi.python.org/pypi?:action=browse&c=214&c=533"
  >3-compatible</a> (or both)
 using classifiers,
 there is no way to have <i>two</i> “most recent” versions
 of a package.
 Are we supposed to start distributing a single <tt>tar.gz</tt>
 that includes the source code for both Python series,
 and that selects the right code by detecting the interpreter version
 at the top of the <tt>setup.py</tt> file?
</li>
</ul>
<p>
So if you make the effort to port your code right now,
you might find that the shiny new version of your module
is all dressed up, but has no place to go.
If you experiment with the following steps, though,
you will at least be ready
when an official distribution channel does appear
for releasing your package into the wilds of 3.0.
</p>
<p><a href="http://rhodesmill.org/brandon/2008/porting-a-c-extension-module-to-python-30/">Read more</a></p>]]></content:encoded>
    </item>
    <item>
      <title>My NOLA Plone Symposium talk, “the Zope 3 Component Architecture”</title>
      <link>http://rhodesmill.org/brandon/2008/nola-plone-symposium-talk/</link>
      <pubDate>Thu, 05 Jun 2008 23:44:02 EDT</pubDate>
      <category><![CDATA[python]]></category>
      <category><![CDATA[grok]]></category>
      <category><![CDATA[zope]]></category>
      <category><![CDATA[computing]]></category>
      <guid>http://rhodesmill.org/brandon/2008/nola-plone-symposium-talk/</guid>
      <description>My NOLA Plone Symposium talk, “the Zope 3 Component Architecture”</description>

      <content:encoded><![CDATA[
<p>
I have delivered my “Zope 3 Component Architecture” talk
to the <a href="http://plone.org/events/regional/nola08">2008 North American
Plone Symposium</a> meeting here in New Orleans.
I want to thank the folks at
<a href="http://enfoldsystems.com/">Enfold Systems</a>
both for hosting the Symposium, inviting me to speak,
and for generously making it possible for me to attend!
Here are my slides:
</p>

<div class="caption">
<a href="http://rhodesmill.org/brandon/static/2008/nola-zope3-talk.pdf">
<img src="http://rhodesmill.org/brandon/static/2008/nola-zope3-talk.jpg" alt="opening slide" /></a>
<a href="http://rhodesmill.org/brandon/static/2008/nola-zope3-talk.pdf"
 >Download slides as PDF</a>
</div>

<p>
They had asked me to attend so that I could present
the <a href="http://rhodesmill.org/brandon/adapters/">Using Grok
to Walk Like a Duck</a> talk that I gave at PyCon 2008
back in March.
They changed the title, I suppose, to better highlight
why it would be of interest to the Plone community;
but the change actually helped me to rethink the presentation.
I wound up using only the first half of my PyCon slides.
For the second half of the talk,
which at PyCon had consisted of a crazy sequence
of hints and tips about using adapters in your own applications,
I instead did a much more successful series of slides
about how adapters are actually used in Zope 3
to suit up objects for presentation on the web.
I think this made the idea more concrete,
and thus much easier to understand
for people seeing adapters for the first time.
</p>
<p>
The talk was well enough received
that I should perhaps think seriously about finding further opportunities
to share Zope 3 technologies with the Plone community.
</p>
]]></content:encoded>
    </item>
    <item>
      <title>Presentations on Buildout and KSS</title>
      <link>http://rhodesmill.org/brandon/2008/presentations-on-buildout-and-kss/</link>
      <pubDate>Sat, 23 Feb 2008 23:29:13 EST</pubDate>
      <category><![CDATA[python]]></category>
      <category><![CDATA[grok]]></category>
      <category><![CDATA[zope]]></category>
      <category><![CDATA[computing]]></category>
      <guid>http://rhodesmill.org/brandon/2008/presentations-on-buildout-and-kss/</guid>
      <description>Presentations on Buildout and KSS</description>

      <content:encoded><![CDATA[
<p>
After several frustrating weeks learning how to create, edit, and publish a screencast under Linux (about which I will write a separate post), I have now published screencasts of both presentations that I gave at the PyAtl meetup in January. I opened with a talk about the <tt>import</tt> statement, and where Python packages lived before egg files were invented:
</p>

<div class="caption"><a href="http://video.google.com/videoplay?docid=5996823626349389448"><b>Python Before Eggs</b></a>

<embed style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=5996823626349389448&hl=en" flashvars=""> </embed>

</div>

<p>
The audience seemed most interested in the last section of the talk, where I discuss three techiques for debugging problems with Python's <tt>import</tt> statement; fast-forward to around 3:00 if you want to catch that part by itself.
</p>

<p>
Next, Jeremy Jones spoke about eggs, Noah Gift introduced virtualenv, and, finally, I got back up to talk about buildout. This was probably <b>my own favorite</b> among the recent presentations I have given, and it's the one I've worked hardest to adapt to a competent screencast:
</p>

<div class="caption"><a href="http://video.google.com/videoplay?docid=3428163188647461098&hl=en"><b>Introduction to Buildout</b></a>

<embed style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=3428163188647461098&hl=en" flashvars=""> </embed>

</div>

<p>
I have prepared a supplement to the above screencast that <a href="/brandon/buildout/">gives additional hints and tips about using buildout</a>, as well as a link to the source code of the module that I use as my example.
</p>

<p>
Finally, if you're ready to see something a little less polished — something that instead of being a screencast is actually a film of me talking in front of a live audience, and gesturing and jumping around — I filled a vacant lightning-talk slot at our February PyAtl meeting with an impromptu introduction to <a href="http://kssproject.org/">Kinetic Style Sheets</a> (KSS), using an example application that was still sitting on my laptop after at a Georgia Tech developer's luncheon earlier that week:
</p>

<div class="caption"><a href="http://video.google.com/videoplay?docid=3829442611478268688"><b>Introduction to KSS</b></a>

<embed style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=3829442611478268688&hl=en" flashvars=""> </embed>

</div>

<p>
Now I can finally turn my attention to preparing for my upcoming talk at PyCon 2008 in Chicago! I will be talking about the basic “adapter” design pattern, and how a framework like Zope 3 can facilitate its use. Stay tuned for more information!
</p>
]]></content:encoded>
    </item>
    <item>
      <title>My November Grok Presentation</title>
      <link>http://rhodesmill.org/brandon/2007/my-november-grok-presentation/</link>
      <pubDate>Fri, 09 Nov 2007 19:06:24 EST</pubDate>
      <category><![CDATA[python]]></category>
      <category><![CDATA[grok]]></category>
      <category><![CDATA[zope]]></category>
      <category><![CDATA[computing]]></category>
      <guid>http://rhodesmill.org/brandon/2007/my-november-grok-presentation/</guid>
      <description>My November Grok Presentation</description>

      <content:encoded><![CDATA[
<p>
In this post, I provide the slides and examples from a recent talk that I gave to some fellow software developers at Georgia Tech. Many of them were not familiar with web frameworks, and I wanted to introduce them to two common concepts: the idea of “convention over configuration,” and the practice of passing inert data structures to a page template rather than letting it access live objects directly.
</p>
<p>
But because I am also really enjoying my work with the new Python web framework <a href="http://grok.zope.org/">Grok</a>, I decided to make it the centerpiece of my presentation<p><a href="http://rhodesmill.org/brandon/2007/my-november-grok-presentation/">Read more</a></p>]]></content:encoded>
    </item>
  </channel>
</rss>

