The fine line between “Code” and “Good Code”
I've been spending a fair bit of my spare time working on my current project, and one of the major issues I'm having right now is drawing the fine line between writing code, and writing good code.
How many times have you sat down with a good, solid idea, only to sit and stare at your monitor for 30 minutes because you're trying to think of 30 different ways to accomplish the same goal. You end up asking yourself 10 different questions, each with 10 pros and 10 cons, and you wind up with a very solid understanding of what the end product will do, but you've made no progress towards it.
"Is this going to be DRY enough?"
"Should I use List Comprehensions here?"
"Should these be params to the method, or passed in when the object is initialized?"
I find myself running into this problem quite often, and always come to the same conclusion. The conclusion that should be at the heart of as much as your logic as possible; Keep it simple, stupid.
When you're confronted with the "Mile-a-Minute Mind" scenario, just sit back and write whatever code comes to mind that gets the job done. You're not writing good code, you're just writing code. Wow, that was easy? It's ugly, but it was easy. Alright, what's next? Well, you could (and should) write any pertinent Unit Tests for the code you just wrote. Make them as solid as you can. Now you've got a product.
Congratulations, you fought through your own indecision, and wrote some code.
Now we're excited. What next!? Well, you wrote some code, and you wrote tests for your code. Now comes the fun part. Now you can get rid of that code, and replace it with what we've wanted all along; good code. Thanks to our wonderful Unit Tests, you'll know if your new code is up to the same dastardly deeds as your old code. Refactor your work of art to your hearts content, until it's as good as it can possibly be.
The moral of the story is that indecision is the bane of productivity. Don't worry about writing concise code. Don't worry about writing optimized code. Just worry about writing working code, then take it from there. As we say in the world of Test Driven Development, "Red, Green, Refactor."
Design Tools for Developers
One of the largest issues I face when doing Web Application development is finding a colour scheme that isn't monochrome. No matter how I start out, I always end up with varying shades of gray. After spending countless hours staring at Colour Code Charts, I stumbled across some tools to help the budding designer in all of us:
COLOURLovers.com
A community based site that hosts thousands of unique designs. It supports comments, user logins, and a forum system that allow you to get the info you need when trying to come up with a usable design. You can view some of their more popular Website designs here.
Kuler
Kuler is powered by Adobe, and while the site may use Flash, it can still carry it's own weight. Much like COLOURLovers.com, it supports creating and viewing themes in your browser, as well as comments on any given design. Where Kuler really shines is that it lets you export the swatches directly into the Adobe suite, and is fully integrated into Adobe Illustrator. It's worth checking out.
Color Scheme Designer 3
The newest player on the field, Color Scheme Designer 3 is an entirely HTML based tool that lets you build your colour palettes based on a few simple criteria (such as hue, base colour, and "general theme"). Simply choose your settings, and the tool will construct complimentary colours for you. It gives you all the information you need to know to turn what it gives you into a great looking site, but lacks the community aspect of the two alternatives mentioned above. For anyone who wants to quickly build their own theme, you can find this tool here.
Twisted: Static Content with Dynamic Pages
When I was first learning about the twisted.web server framework, I made the mistake of trying to include an external stylesheet from my server. Much to my dismay, it simply wouldn't load. Eventually I figured out that I wasn't telling Twisted to server those files, and since I wasn't going through any kind of encompassing server (nginx, Apache, etc), it made perfect sense that those files remained a mystery to the browser. The solution is simpler than you might assume. Let's define a nice, basic web page:
from twisted.web import resource
class Home(resource.Resource):
isLeaf = False
def getChild(self, name, request):
if name == '':
return self
return resource.Resource.geChild(self, name, request)
def render_GET(self, request):
return "<html>Hello, world!</html>"
Run the above script in your main method via something similar to the following:
if __name__ == "__main__":
from twisted.web import server
from twisted.internet import reactor
root = Home()
site = server.Site(root)
reactor.listenTCP(8080, site)
reactor.run()
Now if you run your script and access localhost:8080 in the browser, you'll see our nice "Hello, world!" message. If we wanted to have that method return a substantial chunk of HTML, rather than a simple string, there's a good chance that that HTML would point to external scripts and styles. To set up an external directory to server your files is as easy as changing your main method from the piece of code above, to the following:
if __name__ == "__main__":
from twisted.web import server, static
from twisted.internet import reactor
root = Home()
# We are adding static directories to our server
root.putChild('styles', static.File("./styles"))
root.putChild('scripts', static.File("./scripts"))
site = server.Site(root)
reactor.listenTCP(8080, site)
reactor.run()
You can tell Twisted to serve any directory on your filesystem (assuming permissions are correct), and can tell it to name it whatever you like. This makes it easy to host static content (HTML, CSS, and JavaScript), while integrating it with your Python scripts.
Integrating twisted.web and IRC
As a simple proof-of-concept to show that integration between the HTTP and IRC Protocols was not only possible, but easy, I wrote a small Python script that made use of Twisted to talk to the web and an IRC server.
First, we'll define our imports:
import sys from twisted.words.protocols import irc from twisted.web import server, resource from twisted.internet import protocol, reactor
Now that we've got all the requisite classes, we can define a basic web resource to act as our website:
class Home(resource.Resource):
isLeaf = True
def __init__(self, irc_factory):
self.irc_factory = irc_factory
def render_GET(self, request):
self.factory.send_msg("HTTP Access!")
return "<html>Welcome Home!</html>"
Notice that we're passing a factory into the constructor for our website. The reason for this will become apparent in the near future, so until we need to explain it, we'll go ahead and define a basic IRC Client:
class TalkBot(irc.IRCClient):
# The method below allows us to get the nickname from the factory
def _get_nickname(self):
return self.factory.nickname
nickname = property(_get_nickname)
def connectionMade(self):
# Since we override this method, we need to call the IRCClient one as well
irc.IRCClient.connectionMade(self)
# Add this instance to the client list
self.factory.clients.append(self)
def signedOn(self):
self.join(self.factory.channel)
print "Signed on as %s." % (self.nickname,)
def joined(self, channel):
print "Joined %s." % (channel,)
def privmsg(self, user, channel, msg):
print "#" + channel + " <" + user + "> " + msg
We'll now write a standard ClientFactory to create instances of our client:
class TalkBotFactory(protocol.ClientFactory):
protocol = TalkBot
def __init__(self, channel, nickname='talkbot'):
self.channel = channel
self.nickname = nickname
self.clients = []
def clientConnectionLost(self, connector, reason):
print "Lost connection (%s), reconnecting." % (reason,)
connector.connect()
def clientConnectionFailed(self, connector, reason):
print "Could not connect: %s" % (reason,)
def send_msg(self, msg):
for client in self.clients:
client.say(self.channel, msg)
With everything set up, we can now define the main function of our script:
if __name__ == "__main__":
chan = sys.argv[1]
factory = TalkBotFactory('#' + chan)
site = server.Site(Home(factory))
reactor.listenTCP(8080, site)
reactor.connectTCP('irc.freenode.net', 6667, factory)
reactor.run()
You'll notice that we create an instance of our TalkBotFactory by hand, rather than just passing the constructor into our reactor.connectTCP() method. This is because we need to pass the instance of the factory into our HTTP server, so it can perform the proper methods on it to send messages to all active clients.
This is just a rough concept, but it shows how simple it can be to combine a stateless protocol (HTTP) with a stateful one (IRC).
Starting Fresh
I've had mtrpcic.net for nearly two years now, and until today it's gone largely unmaintained, unmodified, and unloved. After two years, I decided to take down the static HTML and put up something productive. Interesting projects, helpful tips, and answers to hard problems will be shoved into the confines of this blog with the intention of giving back to the community that's helped me get to where I am today. Without any further ado; a brief introduction:
The Work
I am a Software Developer located in Southern Ontario specializing in Web Applications and Business Solutions. I've been working in a professional capacity for over 2 years, and have worked extensively with both PHP and Ruby on Rails (as well as with the appropriate client side libraries like jQuery and ExtJS). I am currently employed at Fluid Media Inc. where I build Web Applications to help make peoples lives easier.
The Play
Having been an avid gamer for over 17 years, I spend a fair bit of time in various virtual worlds. I'm currently suffering a severe addiction to Minecraft, but find time to break away and combat alien races in Starcraft or fight off terrorism in Modern Warfare. Gaming is a particular passion of mine that I'll never have enough time for, but will try to fit it in whenever possible.
The In Between
When not engrossed in work and play, I like to spend my time enjoying books and (very few) television shows. I often spend available time researching new and developing web technologies, while trying to conjure up real world applications for them.