<?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>david stanek's digressions</title>
    <link>http://traceback.org</link>
    <description>thoughts from the trenches</description>
    <pubDate>Thu, 17 Nov 2011 21:27:57 GMT</pubDate>
    <generator>Blogofile</generator>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <item>
      <title>My ToscaWidgets Experience</title>
      <link>http://traceback.org/2007/08/26/my-toscawidgets-experience/</link>
      <pubDate>Sun, 26 Aug 2007 16:36:39 EDT</pubDate>
      <category><![CDATA[turbogears]]></category>
      <guid>http://traceback.org/2007/08/26/my-toscawidgets-experience/</guid>
      <description>My ToscaWidgets Experience</description>
      <content:encoded><![CDATA[
When I first heard about <a href="http://toscawidgets.org">ToscaWidgets</a> I was excited to say the least. Through the grape vine I heard that it was a new implementation of widgets based on the existing <a href="http://docs.turbogears.org/1.0/Widgets">TurboGears widgets</a>. I was immediately drawn to it. I was hoping that it would fix some of the quirks of TG widgets. Unfortunately I wasted quite a few hours and now I still have to roll back to the old TG widgets.

Tosca may be well designed. It may be better, smarter and faster that TG widgets, but much like counting the licks on a Tootsie pop-the world may never know. I blame a lack of real documentation and a lack of examples. I could not find one real example on using forms with TurboGears.

Since I have too many projects on my plate right now I cannot commit to writing a new widget system. I do think it is really needed. Hell...maybe I'll put in a sleepless night or two to get it done. Either way, I want something with less configuration options and less features. I want dirt simple.

Do your experiences differ?<!--d751b1fb124c995072b6439ad360bbc6--><!--87d85216b1473faebf479fe67052239a--><!--997ea4677214f2c2770ed4998d1adcba-->]]></content:encoded>
    </item>
    <item>
      <title>Kid 0.9.3 Released</title>
      <link>http://traceback.org/2006/07/21/kid-093-released/</link>
      <pubDate>Fri, 21 Jul 2006 02:20:51 EDT</pubDate>
      <category><![CDATA[turbogears]]></category>
      <category><![CDATA[kid]]></category>
      <guid>http://traceback.org/2006/07/21/kid-093-released/</guid>
      <description>Kid 0.9.3 Released</description>
      <content:encoded><![CDATA[
This was somewhat of a rush job to fix the issue in ticket <a href="http://www.kid-templating.org/trac/ticket/66">#66</a>. For a more detailed list of changes check out the release <a href="http://www.kid-templating.org/notes.html#kid-0-9-3-release-notes">notes</a>.<!--24510cd9b576252c5cb5b11608fd567e-->]]></content:encoded>
    </item>
    <item>
      <title>New Kid Release Schedule</title>
      <link>http://traceback.org/2006/06/08/new-kid-release-schedule/</link>
      <pubDate>Thu, 08 Jun 2006 20:59:01 EDT</pubDate>
      <category><![CDATA[turbogears]]></category>
      <category><![CDATA[kid]]></category>
      <guid>http://traceback.org/2006/06/08/new-kid-release-schedule/</guid>
      <description>New Kid Release Schedule</description>
      <content:encoded><![CDATA[
Kid needed a more consistent release timeline. So in order to keep myself on track I added some new milestones and started to plan out the <a title="Kid Roadmap" href="http://kid.lesscode.org/trac/roadmap">roadmap</a>. If things go as planned I can start knocking out tickets and doing more frequent releases.

If you know of a ticket that you feel is important please make sure it is one of the scheduled 0.9.x milestones. The 0.10 really does not mean much at this point because there has not been any timeframe associated with it.<!--8a4a97c2d2a6e560f7d0ad91318a968a-->]]></content:encoded>
    </item>
    <item>
      <title>Kid Configuration Consolidation</title>
      <link>http://traceback.org/2006/05/18/kid-configuration-consolidation/</link>
      <pubDate>Thu, 18 May 2006 14:54:52 EDT</pubDate>
      <category><![CDATA[turbogears]]></category>
      <category><![CDATA[kid]]></category>
      <guid>http://traceback.org/2006/05/18/kid-configuration-consolidation/</guid>
      <description>Kid Configuration Consolidation</description>
      <content:encoded><![CDATA[
As the work to simplify the Kid code base continues it became obvious to me that there needs to be a unified way to handle configuration options. Currently there are four ways that default options are set:
<ol>
	<li>Environment variables (e.g. KID_OUTPUT_PY)</li>
	<li>String literals (e.g. 'utf-8' hard coded in KidParser.__init__)</li>
	<li>Global variables in a module  (e.g. assume_encoding in kid/__init__.py)</li>
	<li>Class attributes (e.g. Serializer.encoding)</li>
</ol>
Not only are there several ways to do the same thing, but there are subtle bugs lurking. For example, ticket <a href="http://kid.lesscode.org/trac/ticket/138">#138</a> reports an issue caused by the implementation of the class attribute default options.

I have already started down the path toward reconciliation by creating the kid.properties module. The API is light weight and simply consists of get, set and isset functions. The next step is to start refactoring the code to use the new API.<!--86729a452bd70fdce8c401295d7847ee-->]]></content:encoded>
    </item>
    <item>
      <title>Google Summer of Code 2006 Mentor</title>
      <link>http://traceback.org/2006/05/03/google-summer-of-code-2006-mentor/</link>
      <pubDate>Wed, 03 May 2006 07:59:20 EDT</pubDate>
      <category><![CDATA[python]]></category>
      <category><![CDATA[turbogears]]></category>
      <category><![CDATA[kid]]></category>
      <guid>http://traceback.org/2006/05/09/google-summer-of-code-2006-mentor/</guid>
      <description>Google Summer of Code 2006 Mentor</description>
      <content:encoded><![CDATA[
I have signed up to be a mentor and am looking to mentor projects related to <a href="http://kid.lesscode.org">Kid</a>. I may also be willing to mentor projects related to Python web application servers or Python web services. It really depends on the proposal.

I have had a few email conversations with students about some interesting Kid projects. So we'll see what happens next.<!--2ae420c3a4b47f5d6ed22ec0d4e1e62a-->]]></content:encoded>
    </item>
    <item>
      <title>Thoughts on Kid</title>
      <link>http://traceback.org/2006/03/11/thoughts-on-kid/</link>
      <pubDate>Sat, 11 Mar 2006 13:51:10 EST</pubDate>
      <category><![CDATA[turbogears]]></category>
      <category><![CDATA[kid]]></category>
      <guid>http://traceback.org/wordpress/2006/03/11/thoughts-on-kid/</guid>
      <description>Thoughts on Kid</description>
      <content:encoded><![CDATA[
In the last few months I have spent a lot of time patching and extending <a href="http://kid.lesscode.org">Kid</a>. During this time I have had to field lots of questions and complaints thrown at me.

The two things that seem to appear the most are concerns about Kid's speed and it's lack of good error messaging. I have given a lot of thought to the speed problems in the last few weeks and at <a href="http://us.pycon.org/TX2006/HomePage">PyCon 2006</a> I had the opportunity, along with <a href="http://exilejedi.livejournal.com">Mike Pirnat</a>, to start working on it.

We decided to focus on the speed issue, because that seems to be the thing that turns most people away. <a href="http://www.blueskyonmars.com">Kevin Dangoor</a> also brought up the fact that changes to Kid's internals may change the solution for the error reporting anyway.

I created a new <a href="http://kid.lesscode.org/trac/browser/branches/pycon-sprint-2006">branch</a> where we could break stuff and not anger any users. Although there is still lots of work two do there were two big wins:
<ol>
	<li>Another developer understands some of Kid's internals (which is not entirely easy!)</li>
	<li>Scripts and tests to help in determine the effect of changes</li>
</ol>
I have some other more interesting changes in my working copy of the pycon-sprint-2006 branch. After looking at the number of function calls and nested generators it is a pretty good assumption that this can be made faster. I am experimenting with unstreaming parts of Kid. Now since a rewrite Kid's internals would take a long time and the changes may not help, I wanted to identify things that can be done quickly.

The first step is to eliminate the use of TEXT in the streaming
process. Instead I am attaching the text nodes to the text and tail attributes of elements. This is essentially what ElementTree does. Ideally this will lower the number of times that data will need to go through all of the generators thus speeding up the template.

I am planning on committing code more frequently that I am doing right now. This means that there will be times when the branch is broken. So use it at your own risk!<!--102549d7b47efb59470c8632b028f6a5-->]]></content:encoded>
    </item>
    <item>
      <title>Easy Install Virtual Python</title>
      <link>http://traceback.org/2005/11/18/easy-install-virtual-python/</link>
      <pubDate>Fri, 18 Nov 2005 12:24:21 EST</pubDate>
      <category><![CDATA[python]]></category>
      <category><![CDATA[peak]]></category>
      <category><![CDATA[turbogears]]></category>
      <guid>http://traceback.org/wordpress/?p=8</guid>
      <description>Easy Install Virtual Python</description>
      <content:encoded><![CDATA[
There are always questions about non-root installations of <a href="http://www.turbogears.org">TurboGears</a>. Fortunately the Easy Install documentation has a <a href="http://peak.telecommunity.com/DevCenter/EasyInstall#non-root-installation">section</a> that explains the various options available. I chose to create a virtual Python in <em>~/vpython/</em>. This seems to work well for me except that to use the virtual Python interpreter I have to use <em>~/vpython/bin/python</em>. I have create 2 very simple Bash functions to allow me to quickly alias and unalias python.
<blockquote># Virtual Python
function virpy_on() { alias python=~/vpython/bin/python; }
function virpy_off() { unalias python; }
virpy_on # turn on by default</blockquote>
Typing 'virpy_on' or 'virpy_off' at the Bash prompt aliases or unaliases python respectively. The alias is on by default.<!--0914c10d80c888e899debe17eeb4fbdf--><!--c7d3f65e8371dee533ce9c748bfbdeb9--><!--b089be79f586c547fec73475c9bd4744-->]]></content:encoded>
    </item>
    <item>
      <title>A New Perspective On TurboGears Identity</title>
      <link>http://traceback.org/2005/10/28/a-new-perspective-on-turbogears-identity/</link>
      <pubDate>Fri, 28 Oct 2005 11:27:50 EDT</pubDate>
      <category><![CDATA[turbogears]]></category>
      <guid>http://traceback.org/wordpress/?p=7</guid>
      <description>A New Perspective On TurboGears Identity</description>
      <content:encoded><![CDATA[
When I read Jeff Watkin's post on <a href="http://metrocat.org/nerd/2005/10/identity-management-for-turbogears">identity management for turbogears</a> all the pieces of identity finally clicked. I had some <a href="http://groups.google.com/group/turbogears/tree/browse_frm/thread/de282258e3ec4739/5d0833484ce52faa?rnum=1&_done=%2Fgroup%2Fturbogears%2Fbrowse_frm%2Fthread%2Fde282258e3ec4739%2F785081a668982238%3F#doc_26a79b471f6bb9f7">ideas</a> that I sent to the <a href="http://groups.google.com/group/turbogears">TurboGears mailing list</a>, but I didn't fully understand identity so I could not see where my ideas fit in. Now I have a much better idea.

I spent a little time this morning creating a <a href="http://www.roninds.net/projects/turbogears/identity.patch">patch</a> to better illustrate my thoughts. It is incomplete, but in my opinion a valuable step forward. But then again everyone thinks their ideas are great :-) The patch is against revision 100.

Basically the patch tries to decouple the default behavior from the framework. I pulled it into a default module. Eventually I will post more details on the side effects of my changes, but I hope they will be brought up on the <a href="http://groups.google.com/group/turbogears">TurboGears mailing list</a>.

When the patch is applied only the dev.cfg changed from what Jeff had in his post. In my dev.cfg my identity entries look like:
<blockquote>identity.on = True
identity.filters = ["turbogears.identity.filter.IdentityFilter"]
identity.failure_url = "/login"</blockquote>
Thanks to Jeff for all the work he has put into this. I am really exited about this particular subsystem. This is essential to almost every application that I create.<!--5736cf007168e926c87063486f134106-->]]></content:encoded>
    </item>
    <item>
      <title>I Attended The First TurboGears Sprint</title>
      <link>http://traceback.org/2005/10/10/i-attended-the-first-turbogears-sprint/</link>
      <pubDate>Mon, 10 Oct 2005 13:27:00 EDT</pubDate>
      <category><![CDATA[turbogears]]></category>
      <guid>http://traceback.org/wordpress/?p=5</guid>
      <description>I Attended The First TurboGears Sprint</description>
      <content:encoded><![CDATA[
This past Saturday <a href="http://www.pirnat.com">Mike Pirnat</a> and I drove out to the first <a href="http://www.turbogears.com">TurboGears</a> sprint in Ann Arbor. The trip took a few hours, but our discussions kept it interesting. As we expected we arrived about a half hour late.

Basically <a href="http://www.blueskyonmars.com">Kevin Dangoor</a> (the creator of TurboGears) had created a set of <a href="http://trac.turbogears.org/turbogears/report/9">tickets</a> to be worked on during the sprint. A ticket is roughly the equivalent of a small project or task. The group separated into pairs and each picked a ticket to work on. Mike and I got there after the others had separated into pairs so we got paired together.

We were tasked with adding Javascript animation capabilities into <a href="http://www.mochikit.com">MochiKit</a>. We looked at <a href="http://script.aculo.us">Scriptaculous</a> and <a href="http://dojotoolkit.com">Dojo</a> as examples of what to add and decided on integrating Scriptaculous into MochiKit. It was a bit of a challenge because neither one of us had any experience with any of those projects.

Unfortunately we were not able to switch partners or tasks. By the time everyone got setup and really got rolling the sprint was over. There wasn't a ton of code produced, but the community was being built. I fully expect subsequent sprints to be very productive. It was definitely a worthwhile road trip.

Hopefully I will be able to get to the next sprint. The word out on the street is that it will probably stretch out over a couple of days. So I'd probably get a hotel room and bring the wife and kids. If a remote sprint ever happens I'll be there for sure.

Other opinions on the sprint:
<ul>
	<li>Kevin's blog entry on <a href="http://www.blueskyonmars.com/2005/10/08/turbogears-october-2005-mad-dash-sprint/">blueskyonmars.com</a></li>
	<li>Mike's blog entry on <a href="http://exilejedi.livejournal.com/131236.html">exilejedi.livejournal.com</a></li>
</ul><!--da2898694c0bb84550d766896fa07232-->]]></content:encoded>
    </item>
  </channel>
</rss>
