As happens from time to time, the question of Trac hosting was raised on #trac

There are many options for  Trac Hosting. The issue is really figuring out which ones are good. I tried out  Repository Hosting today and I was impressed. Some of the features that impressed me are:

• Very nice theme work
• Nice and snappy response
• Running an acceptably recent version of  Trac:  0.11.4.
• Using XMLRPC plugin
• Various notification avenues (twitter, CIA, etc)
• Support for both Git and Subversion
• Nice price @ $6/mo

While I'm not in the market for hosting, I'd recommend  Repository Hosting for anyone that needs cheap Trac hosting. They have done a very nice job. To top things off, their  ToS are reasonable and lack any significant legal mumbo-jumbo and/or selling of any unborn children.

Another option for Trac hosting is  CodeResort.  osimons works on  CodeResort. Because of this I can recommend them as being professional and very capable. However, with  CodeResort's pricing, 125 EUR/mo, they seem to be going after more of the corporate market, rather than the hobbyist market.

 SQLAlchemy is generally a wonderful ORM and database toolkit for Python. Personally, I think it's the best one in the Python landscape. However, there are some things that tend to be a little troublesome.

Some of these are simply due to the difference between a relational database and an object oriented language. Others, however, are due to RDBMS specific quirks.

The problem I encountered recently was how to call a stored procedure in MS SQL from SQLAlchemy. In general, the problem isn't a hard one. One can simply import func and be on their way.

from sqlalchemy import func

sess.query(func.sum(TableObject.column)).first()

However, func is geared towards SELECT based functions. For example, the above would be roughly translated into:

SELECT sum(column) FROM TableObject;

Now, MS SQL has stored procedures that return values in the parameters. For example:

DECLARE @noteidx AS NUMERIC(19,5), @err AS SMALLINT;
exec DYNAMICS.[dbo].[smGetNextNoteIndex] dbid, sessid, @noteidx OUTPUT, @err OUTPUT;

This will perform some internal magic and afterwards, @noteidx will hold the next index, and @err will hold whatever error number was encounterd, if any.

This doesn't translate well into SQLAlchemy's idiom of SQL function calling. Though I don't believe it's all SQLAlchemy's fault. It appears that there is  some  support for out parameters in Oracle via SQLAlchemy. Additionally, it appears that PyODBC is lacking  support for out parameters.

However, not willing to roll over and die, there is a solution to be had.

Since SQLAlchemy contains sufficiently quantities of awesome, the solution is only slightly hackish. SQLAlchemy easily allows for the running of straight SQL using the text function. The solution to the above problem:

def get_next_note_index(s=None):
    """ Returns the next note index to use.
    
    Calls the `smGetNextNoteIndex` stored procedure to handle the query
    and increment of the company master NOTEINDX

    If a session object is passed, it will use the one specified.  Otherwise
    it will call get_session() to get a session to use.
    """
    txt = """
        SET NOCOUNT ON;
        DECLARE @db AS CHAR(5), @id AS SMALLINT, @noteidx AS NUMERIC(19,5), 
                @err AS INT;
        SELECT @db=CMPANYID 
          FROM DYNAMICS.[dbo].[SY01500]
         WHERE INTERID = DB_Name();
        SELECT @id=@@SPID;
        EXEC DYNAMICS.[dbo].[smGetNextNoteIndex] @db, @id, @noteidx OUTPUT,
                                                 @err OUTPUT;
        SELECT @noteidx, @err;
        SET NOCOUNT OFF;"""[1:]
    s = s and s or get_session()
    r = s.execute(text(txt)).fetchall()
    s.commit()
    return r[0][0]

The few special things to note about the above are:

• Since there is no direct support for output parameters, one needs to SELECT the values to get them via SQLAlchemy
• Due to all sorts of PyODBC/FreeTDS/*nix/SQLAlchemy  nastiness one needs the SET NOCOUNT ON to keep SQLAlchemy from barfing.

In the end, however, it works nicely. Thank you SQLAlchemy. Also, thank you  MichaelJ2 for the TSQL code to translate.

Digging through Dynamics: GP stored procedures is painful, to say the least.

When you pull the SQL out of the database via SQL Server Management Studio it is one LONG line. No formatting, nothing. Reading the TSQL as one line isn't really an option. Reformatting it by hand takes FOREVER.

Fortunately, there is a wonderful online formatter over at  TSQLTidy. It can transform the GP stored procedures into something that can actually be parsed by a human brain.  TSQLTidy also has a  web service. Theoretically this is a  SOAP interface that will allow the creation of scripts/programs that can then use  TSQLTidy for its formatting. I've been trying to get it to work via  Python using  ZSI. However, I have had no such luck yet. Eventually.

Having recently upgraded from GP8 to GP10 and having switched from Horizons Manufacturing to GP: Manufacturing, I wanted to lay out a few do's and don'ts for anyone else considering a switch. Hopefully the below will save you some of the headache.

1. Take The Defaults: As with pretty much all Microsoft products, accepting the defaults is prudent and nigh a necessity. If you simply take the defaults and use the software exactly as designed, you'll have an acceptable experience.
2. Do not customize: This may seem to be the same as above. It kind of is. However, it's more than that. Great Plains can be customized simply through the various settings and incomprehensible menus it offers. However, you can really customize Great Plains with VBA and/or Dynamics code. Don't. Just Don't. No, really, DON'T!
3. Do not integrate 3rd Party Products: They're not worth it. Great Plains is a black box. Even to Microsoft. You can't know what's it's doing. It's one of the universe's great mysteries.
4. Do not roll-your-own Product: If you are masochistic and really enjoy pain, go right ahead. We have specific manufacturing needs. One of which is integration with our hand-held barcode scanners. We are now on the second generation of hand-held software. The first was abominably designed. The second has a decent architecture, if you exclude the whole Great Plains part. As stated above, no one knows the innards of Great Plains. It's like a  Mord-sith. Once you start looking and turn your power over to it, it makes you writhe in pain forevermore. Doing a quick count, I turned up 1,988 tables in my Great Plains database. This excludes the tables it uses in the DYNAMICS database as well as master. It also does not take into account the hundreds of temporary tables it creates during normal usage. 1,988 tables! That's insane. One can not understand Great Plains. The whole concept of understanding is anathema to Great Plains.
5. Don't Use Lots of Work Centers: If you see yourself using lots of work centers, you're doing it wrong. Especially if you have lots of items. This can be partially mitigated as long as an item only has a small set of possible work centers. If you're like us, with >900 work centers and >6,000 items, you're simply in for a long wait.

I hope that these tips will help. If you're already a Great Plains user, and are considering upgrading, ask yourself if it's really worth it. It's probably less painful to upgrade than switch to a new system. It isn't, however, pain-free.

I am not a Great Plains expert. I'm just a poor hapless IT manager thrown into the woes of maintaining, upgrading, supporting, and developing against Great Plains. If you know of a true Great Plains expert, please let me know. My requirements for a Great Plains expert are as follows:

• Knows a majority of the Great Plains tables by their physical name
• Knows what these tables do and how they are related
• Proficient at reading TSQL
• Proficient at maintaining and managing MS SQL Server
• Knows what is happening behind the scenes for a majority of the windows in the GP interface
• Can explain why Microsoft decided to go against most every UI interface and interaction convention in existence
• Can explain why Dynamics presents you with the most misleading lists and scroll bars ever created (Since when do lists start in the middle with no indication that there are actually items above the one at the top of the list?)
• Can explain why Great Plains lets you do things that break the consistency of your data
• Can explain why more operations in Great Plains aren't atomic.
• Is not content with simple answers and must understand the why behind the answer.

If you are, or know of some one that fits the requirements, please contact me.

By the way, if you want to know how to list the number of tables in a MS SQL database, here you go:

select count(*) as TableCount from Information_Schema.Tables where Table_Type = 'BASE TABLE';

When you buy a Dell with Windows on it, you get a little program pre-installed that will tell you the service code of your machine. This is a handy little tool for tech support, especially if your machine is in a hard to reach location. Simply fire up the program and BAM! There is your service tag

Today I was cleaning up a PC today getting it ready to cycle it out of the company. In my hacking and slashing of data, I deleted the dell directory in which the Service Tag program resides. Not a huge deal. However, I do like the convenience of the program. So, as a quick fix, I copied the dell directory from another machine. I then started the program and it worked beautifully. Or at least it appeared to. Upon further inspection, I realized that the service tag it reported, was the service tag of the machine from which I copied the program. That seemed weird. I was under the impression that the program pulled the service tag from the BIOS as I have discussed previously. Apparently I was wrong. Let the digging being.

In the dell directory there is the EXPRESS.EXE program and an accompanying EXPRESS.INI file. Looking in the EXPRESS.INI file we find:

[ServiceTag]
# Set this to zero to disable searching for a service tag in BIOS. Only do this if you are having problems
# with GPFs.
LookForServiceTag=0
SysInfoFile=C:\DELL\SYSINFO.DAT

Dell programmed a way to read the service tag from a file instead of the BIOS. It looks as if they did this as a backup measure. However, after taking a sample of other Dell machines in the network. It appears that a value of 0 for the LookForServiceTag option is the default.

Next, we see what we can surmise to be the data file containing the service tag: SYSINFO.DAT. Hmm, a DAT file. Sounds important. Now, file extensions really don't mean a thing as far as how the actual file is structured, but it sounds as if this file might be a binary file. Opening it up in our trusty Notepad we find that not to be true. It appears to be a simple ini style file with the following:

[ServiceTag] 
ServiceTag=<service tag>

Now, why they decided to create a whole other file to store that, I haven't a clue. Seems to me they should have simply put it in EXPRESS.INI

Getting the feeling of bad design with regards to the EXPRESS.EXE program, I decided to see how well it reacted to different "environments".

1. Removing the EXPRESS.INI and SYSINFO.DAT files from the dell directory cause the program to fail on startup
2. Removing the SYSINFO.DAT file causes the program to not display any service tag
3. Setting LookForServiceTag to 1 had no effect. With the SYSINFO.DAT file present, the old service tag was returned. With it missing, the service tag was blank.

Why Dell decided to write such a broken program, I'm not sure. Perhaps there are some arcane incantations that can be performed with EXPRESS.EXE that actually make it useful. However, as I'm not in the Cult of the Dell, I'm not sure I'll ever know. If someone out there can divulge the secret, I'd be interested in finding out.

So, Chuck, over at  Cobra wanted to get his trac site up and running and was wondering about using the exisiting accounts that people had in the phpBB3 forums. Trac being Python, and  phpBB being, obviously, PHP, there was no stock way of accomplishing this.

First, Trac's authentication meme is basically: get someone else to do it. Generally speaking, this is the web server. That's all fine and dandy, but some people want a bit more. Thankfully,  Matt Good wrote the  Account Manager plugin. This neat little plugin lets you auth against the trac db, htpasswd files, htdigest files, etc. It also allows for easier management of accounts. The most wonderful thing about it, however, is the  IPasswordStore interface it defines. This little beauty lets you auth against just about anything where the input is a username and password.

Well, amazingly, phpBB manages to authenticate users via a username and password. Graciously,  Cobra sponsored me to write up an IPasswordStore implementation to use the existing phpBB database as the authentication store for the adjoining  Cobra trac site. Hence the birth of  PhpBbAuthPlugin. So, for all you phpBB junkies that need to run Trac sites, you now have an option where with you can keep your accounts one and the same.

Hey, phpBB guys, don't you think that 73 columns in your user table is a bit excessive?

Let's establish some facts.

• MS SQL Server 2005 allows the sa password to be longer than 15 characters.
• MS Windows XP allows a password longer than 15 characters.

Given these two facts, one would assume that Microsoft has a policy of allowing arbitrary length password (or at least really long ones). However, if one were to assume this, one would be wrong.

Microsoft's Business Solutions - Great Plains 8 does NOT allow passwords longer than 15 characters. I'll admit that GP8 is a bit out of date. It was released in 2003, I believe. But, really, was there a need to limit password lengths in 2003? I don't think so.

Once again, thank you Microsoft for such a wonderful piece of software. If anyone is considering Microsoft Dynamics:GP (as it is now called), save yourself the misery and check out  HansaWorld or some other product instead.

DIAF

 PyCon is March 14th through 16th with the 17th through 20th being open for sprints. PyCon was a blast last year, thanks to  Financial Aid from the  PSF. Thankfully, my  employer is sending me this year. I'll be taking the  SQLAlchemy tutorials along with  Automating Windows Applications with win32com. I'm horribly excited!

So, you should all sign up and attend PyCon. It's a great time to geek out with lots of other Python developers. Come join the  Trac sprint and have a good time. If you need a little assistance, shoot off an application to the PSF for  Financial Aid. Hope to see you there.

When configuring a  Trac environment, you can set the following option:

[ticket]
restrict_owner = true

This will change the Assign To ticket filed into a select box that only contains existing users. However as it says on the  TracTickets page, the user must have logged, in at least once, and set their email address.

If you run multiple Trac sites, and have a set of common users across all Trac sites, it gets annoying to have to log into each one and set the email.

So, what is one to do? Well, there are two things that need to be entered into the database: a session record, and an email record.

To enter a session record, we need to add a row to the session table. The schema for the session table looks like

         Table "session"
    Column     |  Type   | Modifiers 
---------------+---------+-----------
 sid           | text    | not null
 authenticated | integer | not null
 last_visit    | integer | 

The sid is the username, authenticated will simply be 1, and last_visit needs to be set to a date, expressed as seconds since the epoch.

For example:

INSERT INTO session (sid, authenticated, last_visit) VALUES ('pacopablo', 1, 1195926785);

Now, to set the actual email address. That will go in the session_attribute table.

The schema for the session_attribute table is as follows:

    Table "session_attribute"
    Column     |  Type   | Modifiers 
---------------+---------+-----------
 sid           | text    | not null
 authenticated | integer | not null
 name          | text    | not null
 value         | text    | 

Once again, sid is the username, authenticated will be 1, name refers to the type of attribute this is, email in this case, and value will be the actual email adress.

For example:

INSERT INTO session_attribute (sid, authenticated, name, value) VALUES ('pacopablo', 1, 'email', 'pacopablo@pacopablo.com');

There is also a name attribute that is used which can be set:

INSERT INTO session_attribute (sid, authenticated, name, value) VALUES ('pacopablo', 1, 'name', 'Pacopablo Parangaricutirimicuaro');

Of course, going into a SQL interface to do this isn't really any better than logging into the Trac site and setting it yourself. It's also more error prone.

 Python to the rescue! We'll just whip up a simple little script that parses a command line, loads up the Trac environment, and creates the records for us. Behold:

from trac.env import Environment
from optparse import OptionParser
import sys
import os

def doArgs():
    """Parse command line options"""
    description = "%prog is used to seed the user's full name and email."

    parser = OptionParser(usage="usage: %prog [options] [username]",
                          version="1.0", description=description)
    parser.add_option("-e", "--env", dest="envpath", type="string",
                      help="Path to Trac environment", metavar="<path>",
                      default=".")
    parser.add_option("-m", "--email", dest="email", type="string",
                      help="Emal address", metavar="<email>", default=" ")
    parser.add_option("-f", "--fullname", dest="fullname", type="string",
                      help="Full Name", metavar="<name>", default=" ")
    (options, args) = parser.parse_args()
    if len(args) < 1:
        print "You must specify a username"
        sys.exit(1)
    options.user = args[0]
    if not os.path.exists(options.envpath):
        print "The path >%s< does not exist.  Please specify an existing path." % options.envpath
        sys.exit(1)
    options.args = args
    return options


if __name__ == '__main__':
    opts = doArgs()
    env = Environment(opts.envpath)
    cnx = env.get_db_cnx()
    cur = cnx.cursor()
    cur.execute("INSERT INTO session (sid, authenticated, last_visit) "
                "VALUES (%s, 1, 1195926785)", [opts.user])
    cur.execute("INSERT INTO session_attribute (sid, authenticated, name, "
                "value) VALUES (%s, 1, 'name', %s)",
                [opts.user, opts.fullname])
    cur.execute("INSERT INTO session_attribute (sid, authenticated, name, "
                "value) VALUES (%s, 1, 'email', %s)",
                [opts.user, opts.email])
    cnx.commit()
    cnx.close()
    sys.exit()

Most of the script is doing validation on input, and even then, it's not that much. So, save the script as trac_set_email.py, or some other such memorable name, fire it up¹.

dev ~ # python trac_set_email.py -help                                                                                   
Usage: trac_set_email.py [options] [username]

trac_set_email.py is used to seed the user's full name and email.

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -e <path>, --env=<path>
                        Path to Trac environment
  -m <email>, --email=<email>
                        Emal address
  -f <name>, --fullname=<name>
                        Full Name


dev ~ # python trac_set_email.py --env /srv/trac/env/dev/ --fullname "Test User" --email pacopablo@pacopablo.com testuser

And there you have it. Enjoy²

As many  Apache users know, the htpasswd¹ is used to create a file with username/password pairs. The format for the file is simply a username, colon, encrypted password. For example:

foo:oNAU4bgeqQHt2

The username is foo and the password is bar encrypted with a salt of oN²

Now, there are good reason why an admin might not want to install apache in order to get htpasswd, yet still need to create a password file. Since there isn't a good reason against having  Python installed, we can simply use that to create the file.

The encryption used by htpasswd is the basic UNIX crypt(3) function. Python provides a very nice interface to this function³.

import crypt
print crypt.crypt('bar', 'oN')

This will print bar, encrypted with a salt of oN⁴

Obviously, the above code isn't incredibly complex. So below is a bit of code that might be a little more useful.

# Script should be passed two paramters
# username and password
import crypt
import sys

if len(sys.argv) == 3:
    print("%s:%s" % (sys.argv[1], crypt.crypt(sys.argv[2], sys.argv[2])))

To use the code, save it as htpasswd.py or something and then simply pass it two parameters, username then password, and redirect the output into a file. For example:

python htpasswd.py foo bar > passwd_file

There are obvious deficits in the above code, such as minimal input verification, and seeding the encryption with the first two letters of the password. However, I think it illustrates the idea and I encourage someone else to improve it.

And improve it they have. There is now a much better script in  http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py

In today's IT scene, it is important to know which products are enterprise ready. Cliff Wells provides a useful evaluation of certain popular technologies. He also sets the baseline for what enterprise ready really means. Go see if your technology is  Enterprise Ready.

Love or hate Dell, they do do a few things right. They provide a Service Tag on every PC with which you can get a host of information off their  support site. Drivers, manuals, you name it. The service tag is generally on a little black tag someplace on the case. On the tag there is also an Express Service Code. If ever you call for tech support on your Dell computer, you will be asked to enter this number to route your call correctly. Now, you don't actually need it, but it is handy to have.

The service tag is in the BIOS and can be extracted fairly easily, at least from a windows machine with WMI enabled. A simple little python script to do so would look like:

import win32com.client as w32c
comp = "."
wmi = w32c.Dispatch("WbemScripting.SWbemLocator")
wbem = wmi.ConnectServer(comp,"root\cimv2")
colItems = wbem.ExecQuery("Select * from Win32_SystemEnclosure")
for chassis in colItems:
    if 12 in chassis.ChassisTypes:
        continue
    print ("Service Tag: %s" % str(chassis.SerialNumber))
    continue

Not bad. Looks almost identical to it's VBScript  counterpart

Now, the real question is: If I have the service tag, but not the express service code, how do I get the express service code?

Good question. There are a few tools^{1 2} online that will generate an Express Service Code from a service tag.

Digging a bit deeper, we find that the service tag is simply a base 36 number. We also discover that the express service code is simply the bae 10 representation of the service tag. Ah ha! We can handle this! We could always use VBScript to do the  conversion³. But that would be too easy, so we'll use  Python

print ("Express Service Code: %s" % str(int(service_tag,36)))

Tough, wasn't it?

I like  Trac. That may have been obvious due to hosting the logs for the IRC channel. Or the fact that this site runs on trac¹. The simple fact is that  Trac is just plain hot.

In my day job, I have the wonderful opportunity to manage two similar, but distinct networks. All-in-all, it's not so bad. However, the older of the two networks, suffers from severe lack of documentation (left to me by The Predecessor). The newer network is still in its infancy. So while there is more documentation, it's still not complete. What's more challenging, is keeping the documentation that is there, up-to-date. Add to this the fact that I really hate "documenting" and it all adds up to a mess.

I've been thinking to myself: "Trac is hot, and documentation is good. There must be some way to merge documentation of a network with Trac". Now, it's easy to say: "Well, Trac has a wiki, just keep the documentation up to date". Great idea, except for the fact that I hate "documenting". On top of that, when things are busy, adjusting documentation is that last thing that I do (and first thing I forget to do).

I agree that Trac is a great start. It's got ticketing, a nice easy wiki, source control integration, just about everything one needs to have good documentation. However, it's lacking the automation. This isn't really Trac's fault, as that's not what it was originally designed for. However, it fits so well, and Trac has such a nice plugin system, it's just begging to be extended.

To this end, I will be starting a Trac network documentation project. Originally, it will be focused on managing a Windows environment with Dell machines, as that's what I'm dealing with. However, I will try to make it general enough to be used in a different network. Some of the features I'm planning are:

• Automatically pull system information and populate wiki pages. This will include the Dell Service Tag, machine specs, IP information, etc.
• Association of Asset numbers with wiki pages such that one can reference a machine via asset tag, or search via asset tag and get the relevant info
• Security for the wiki such that user accessible pages can be created for HOWTOs and other organization wide information
• Ticket security such that a user can only see their own tickets
• Automatic tag creation such that each user/system has a unique tag that can be used across the site
• Aggregate other system info such as:
  • Mail logs
  • Backup logs
  • Anti-virus logs

Basically, the Trac site should be a one stop shop for any network info that is required, be is software licensing, network diagrams, system information, etc.

If this is a project that you'd be interested in, especially if interested in helping out, drop me a line. pacopablo AT pacopablo DOT com

I'll keep you updated.

I'm not sure where it started, but the first place I saw it, was on  trac-hacks.org. I'm talking about the really cool green box that holds the "news". What's even cooler, is combining the green news box with the  blog plugin. This is what  trac-hacks.org is doing.

The green news box is a little mix of HTML and CSS, and it's dead sexy to have. zachtib was looking for instructions on how to set it up, so here we go

After installing the  blog plugin, add the following CSS to the site_css.cs file. It is located in the  Trac environment's templates directory.

#newsflash {
        border: solid 2px #8f8;
        width: 400px;
        float: right;
        background: #dfd;
        font-size: 0.8em;
        margin: 0em;
        padding: 0.5em 1em 0.5em 1em;
}

#newsflash h1 {
        font-size: 1.2em;
        padding: 0em;
        margin: 0em;
}

#newsflash .post hr {
        display: none;
}

Once the CSS is inplace, the green box can be created by placing the following at the top of the wiki page on which it should appear.

[[html(<div id="newsflash">)]]
[[BlogShow(blog,news,hidecal=true,num_posts=4)]]
[[html(</div>)]]

Obviously, the options passed to the [[BlogShow]] macro can be adjusted to taste.

Finally, after having done all that, I find a gem that coderanger has created:  NewsFlashMacro. While I haven't tested it out, this should provide exactly what the above does, and packaged in to a nice macro.

As everyone should know,  PyCon 2007 is in Addison, TX, February 23rd-25th. It's a time for  Python developers to get together and rub elbows.

As it happens, I, unfortunately, am not going. This would be due to a thing called life. Of course, there are going to be a few  Trac notables¹²³⁴ there, and  one, in particular, has been bugging⁵ me to go.

Oh how I would love to go to PyCon. However, it just isn't in the cards right now. Of course, that would all change if, by some miracle, someone paid for my air fare. So, if anyone out there wants to pay for my air fare, I would be ever so grateful. For that wonderful saint that wants to send me to PyCon, contact me at: pacopablo at pacopablo dot com

Here's to wishing! If not, well then perhaps next year.

It's finally official. I didn't get accepted to the Google's  Summer of Code. While disappointing, it's also a relief. Perhaps next year I'll take a bit more time to prepare my proposals.

The big question now is what's going to happen with my proposal? Is it going to sit around doing nothing? Or can I catually make something of it?

I definitely have the desire to make something of it. In fact, I have already gotten  tracd to run as a windows service. And we're not talking about via  InstSrv tracd SrvAny.exe either. So now the big questions are:

• Packaging via  py2exe
• Bakup interfaces and API
• Coding

So, we'll see what the summer brings, but I hope to be able to make more progress on Synecdoche.

About a week ago, I sat down to finally figure out how to get  Postfix to relay mail through a  server using SMTP AUTH. It turned out to be quite easy and straight forwad once I was willing to read through the  postconf manpage. However, after I was done I realized that I should write down my experience. Lately, my  cowoker has been nagging me to write down my adventures. So I went looking for some blog software. I basically had two requirements:

• Written in  Python
• Backend uses  PostgreSQL

I'm not picky, or anything. Needless to say, my journey down that path left a somewhat sour taste in my mouth. I couldn't believe the dearth of python powered blog software. What a shame! Because I have been working with  Trac lately, I decided to see what it had to offer. There did exist a  blog macro and I gave it a whirl, but I didn't like it much. I didn't like the fact that the post info (author, date, etc) was above the post instead of below it, and I didn't like summary stuff above the posts.

Now, while contemplating how I could hack the macro and modify it to my preferences, I found the wonderful  Tags Plugin. This got me to thinking that being able to tag arbitrary wiki pages and make them part of a blog was a great idea¹. After some encouragement from #trac on  freenode, I mustered up the will to start coding. Thus was the beginning of the  Trac Blog Plugin.

Onto the logs ...

Because of the blog plugin, I've been spending a bit more time in #trac than usual. As I try to be a good boy and share of my knowledge², I answer questions on the channel if possible. One such question was about an error when trying to load the  webadmin plugin. The strange thing about it was that the issue appeared to be in  setuptools rather than the plugin. What was more frustrating was the fact that another user had experienced this same issue, but I couldn't remmeber what the solution was³. It was then that I yearned for a log of #trac that I could search, but, alas, it did not exist.

Because of this sense of loss, I set out on yet another journey: find a bot for the #trac channel. Per the suggestion of nuge, I decided to try  SupyBot. The most wonderful thing about SupyBot is that it is written in Python. That means I can hack it. After a fairly painless install and a little help from #supybot, I was able to bring to life evil_twin. So now I have a bot that is logging #trac. All I have left is to make those logs accessible via the web. You know what that means, right?

Yup, more Trac integration!