Witter – a basic python twitter client for Maemo

So I wrote last week about developing a basic twitter client. And this week I got the main stuff done, and wanted to share the code example here.

In my looking for help developing apps for Maemo from a start of basically no GTK knowledge or python knowledge I found the examples either too trivial, or way over engineered. So I wrote this intending it to be useful (to me), contain only enough capability to basically read my timeline and tweet. I’ve intentionally not added bells and whistles (yet) and it’s a single ‘monolithic’ app. By which I mean it’s all in a single python file, there is no separation of gui and logic, no nice engineered constructs etc etc.

I hope that it does show an intermediate level example of writing an application for Maemo using Python. This is what it looks like in action

This was taken full screen. The app supports switching in and our of full screen. And it adjusts the width of the displayed text to fit. As you can see the shot was taken not long after completing the application.

It also sorts the tweets using the ListStore ability to just tell it which column to sort on. This is very useful as it means I don’t have to mess around myself. Originally I had it sorting on created_at, but since I was loading that as a String it would order Thursday below Wednesday. Rather than cast the string into a meaningful date object of some form, I just used ID instead, which is a Long. Still comparing as a string, but the number always increments so newer tweets always appear t the top.  Obviously if you prefer newer tweets at the bottom, just flip the sort order to Ascending.

So here is the code, it’s a little under 300 lines, but I’ve commented it pretty well (I think) to explain what it’s all doing.

# ============================================================================
# Name        : witter.py
# Author      : Daniel Would
# Version     : 0.1
# Description : Witter
# ============================================================================

#This is the bunch of things I wound up importing
#I think I need them all..
import gtk
import pygtk
import hildon
import urllib2
import urllib
import base64
import urlparse
import simplejson
import socket

#Initially I found I'd hang the whole interface if I was having network probs
#because by default there is an unlimited wait on connect so I set
#the timeout to 10 seconds afterwhich you get back a timeout error
# timeout in seconds
timeout = 10
socket.setdefaulttimeout(timeout)

#the main witter application
class Witter(hildon.Program):
    #first an init method to set everything up
    def __init__(self):
        hildon.Program.__init__(self)
        #being lazy this just uses basic auth and I am not doing anything
        #yet to store uid/pwd so for the moment just put info here
        self.username = "YOUR_USERNAME"
        self.password = "YOUR_PASSWORD"
        #This being a hildon app we start with a hildon.Window
        self.window = hildon.Window()
        #connect the delete event for closing the window
        self.window.connect("delete_event", self.quit)
        #add window to self
        self.add_window(self.window)
        #For this app I wanted a scrollable area for the tweets to show up
        #so I create a gtk ScrolledWindow
        self.scrolled_window = gtk.ScrolledWindow(hadjustment=None, vadjustment=None)
        # as well as somewhere to show the tweets we need somewhere to write a tweet
        # this being twitter we cap the input at 140 chars
        self.tweetInput = gtk.Entry(max=140)
        # we also want a couple of control buttons to load up tweets and submit a tweet
        self.buttonloadTweets = gtk.Button(label="Load Tweets",stock=None, use_underline=None );
        # we connect out load tweets button to the getTweets method
        self.buttonloadTweets.connect("clicked", self.getTweets)
        self.buttonnewTweet = gtk.Button(label="Tweet",stock=None, use_underline=None );
        #we connect the Tweet button to the newTweet method
        self.buttonnewTweet.connect("clicked", self.newTweet, self.tweetInput)
        # a vertical box to set the scrollable window and the button box
        # in the display
        self.box1 = gtk.VBox(False, 0)
        #a horizontal box to put our tweet input box and two control buttons in
        self.buttonBox = gtk.HBox()
        # add the Vbox to the window
        self.window.add(self.box1)
        # create a menu object by calling a method to deine it
        menu = self.create_menu(self.scrolled_window)
        # add the menu to the window
        self.window.set_menu(menu)
        # define a liststore we use this to store our tweets and some associated data
        # the fields are : Name,nameColour,Tweet+timestamp,TweetColour,Id
        self.liststore = gtk.ListStore(str, str, str, str, str)
        # create the TreeView using treestore this is the object which displays the
        # info stored in the liststore
        self.treeview = gtk.TreeView(self.liststore)
        # create the TreeViewColumn to display the data, I decided on two colums
        # one for name and the other for the tweet
        self.tvcname = gtk.TreeViewColumn('Name')
        self.tvctweet = gtk.TreeViewColumn('Tweet')
        # add the two tree view columns to the treeview
        self.treeview.append_column(self.tvcname)
        self.treeview.append_column(self.tvctweet)
        # we need a CellRendererText to render the data
        self.cell = gtk.CellRendererText()
        # add the cell renderer to the columns
        self.tvcname.pack_start(self.cell, True)
        self.tvctweet.pack_start(self.cell,True)
        # set the cell "text" attribute to column 0 - retrieve text
        # from that column in liststore and treat it as the text to render
        # in this case it's the name of a tweeter
        self.tvcname.add_attribute(self.cell, 'text', 0)
        # we then use the second field of our liststore to hold the colour for
        # the 'name' text
        self.tvcname.add_attribute(self.cell, 'foreground', 1)
        # next we add a mapping to the tweet column, again the third field
        # in our list store is the tweet text
        self.tvctweet.add_attribute(self.cell, 'text',2)
        # and the fourth is the colour of the tweet text
        self.tvctweet.add_attribute(self.cell, 'foreground', 3)
        # we start up non-fullscreen, and we want the tweets to appear without
        # scrolling left-right (well I wanted that) so I set a wrap width for
        # the text being rendered
        self.cell.set_property('wrap-width', 500)
        # make it searchable (I found this in an example and thought I might use it
        # but currently I make no use of this setting
        self.treeview.set_search_column(0)
        # Allow sorting on the column. This is cool because no matter what order
        # we load tweets in, we always get a view which is sorted by the tweet id which
        # always increments, so we get them in order
        self.liststore.set_sort_column_id(4,gtk.SORT_DESCENDING)
        # I don't want to accidentally be dragging and dropping rows out of order
        self.treeview.set_reorderable(False)
        #with all that done I add the treeview to the scrolled window
        self.scrolled_window.add(self.treeview)
        # Then just 'pack# the scrolled window and a Hbox into the
        # V box
        self.box1.pack_start(self.scrolled_window, True, True, 0)
        self.box1.pack_start(self.buttonBox, False, True,0)
        #and pack the hbox with input field and buttons
        self.buttonBox.pack_start(self.tweetInput, True,True,0)
        self.buttonBox.pack_start(self.buttonnewTweet, False, False,0)
        self.buttonBox.pack_start(self.buttonloadTweets, False, False,0)
        #setup some urllib things to use to fetch twitter feeds
        self.last_id=None

    def quit(self, *args):
        #this is our end method called when window is closed
        print "Stop Wittering"
        gtk.main_quit()

    def create_menu(self, widget):
        #a fairly standard menu create
        #I put in the same options as I have buttons
        # and linked to the same methods
        menu = gtk.Menu()

        menuItemGetTweets = gtk.MenuItem("Get Tweets")
        menuItemGetTweets.connect("activate", self.getTweets )
        menuItemTweet = gtk.MenuItem("Tweet")
        menuItemTweet.connect("activate",self.newTweet)
        menuItemSeparator = gtk.SeparatorMenuItem()
        menuItemExit = gtk.MenuItem("Exit")
        menuItemExit.connect("activate", self.quit);
        menu.append(menuItemGetTweets)
        menu.append(menuItemTweet)
        menu.append(menuItemSeparator)
        menu.append(menuItemExit)
        menuItemFile = gtk.MenuItem("File")
        menuItemFile.set_submenu(menu)
        return menu

    def run(self):
        #this is the main execution method
        # we set things visible, connect a couple of event hooks to methods
        # specifically to handle switching in and our of fullscreen
        self.window.show_all()
        self.window.connect("key-press-event", self.on_key_press)
        self.window.connect("window-state-event", self.on_window_state_change)
        #this starts everything up
        gtk.main() 

    def getTweets(self, *args):
        #Now for the main logic...fetching tweets
        #at the moment I'm just using basic auth.
        #urllib2 provides all the HTTP handling stuff
        auth_handler = urllib2.HTTPBasicAuthHandler()
        #realm here is important. or at least it seemed to be
        #this info is on the login box if you go to the url in a browser
        auth_handler.add_password(realm='Twitter API',
                          uri='http://twitter.com/statuses/friends_timeline.json',
                          user=self.username,
                          passwd=self.password)
        #we create an 'opener' object with our auth_handler
        opener = urllib2.build_opener(auth_handler)
        # ...and install it globally so it can be used with urlopen.
        urllib2.install_opener(opener)
        #switch on whether this is an refresh or a first download
        if self.last_id == None:
            json = urllib2.urlopen('http://twitter.com/statuses/friends_timeline.json')
        else:
            #basically the twitter API will respond with just tweets newer than the ID we send
            json = urllib2.urlopen('http://twitter.com/statuses/friends_timeline.json?since_id='+str(self.last_id)+'L')
        #JSON is awesome stuff. we get given a long string of json encoded information
        #which contains all the tweets, with lots of info, we decode to a json object
        data = simplejson.loads(json.read())
        #then this line does all the hard work. Basicaly for evey top level object in the JSON
        #structure we call out getStatus method with the contents of the USER structure
        #and the values of top level values text/id/created_at
        [self.getStatus(x['user'],x['text'], x['id'], x['created_at']) for x in data]

    def getStatus(self, user,data, id, created_at):
        #at this point user is another JSON structure of lots more values of which we are currently
        #only interested in screen_name
        #append to our list store the values from the JSON data we've been passed for a tweet
        # the funny #NXNXNX type values are colours I chose a slightly blue for the name
        # and black for the tweet. At some point I intend to do some alternating colours for
        # cell backgrounds to make the display clearer
        self.liststore.append([ user['screen_name'],"#2E00B8",data+"\nposted on: "+created_at,"#000000", id])
        #now we process the id, this is so we can do a refresh with just the posts since the latest one we have
        #if we haven't stored the most recent id then store this one
        if self.last_id == None:
            self.last_id=id
        else:
            #if we have an id stored, check if this one is 'newer' if so then store it
            if long(self.last_id) < long(id):
                self.last_id=id

    def newTweet(self, widget, text_widget,*args):
        #The other main need of a twitter client
        #the ability to post an update
        #get the tweet text from the input box
        tweet = text_widget.get_text()
        #see if we have just an empty string (eg eroneous button press)
        if (tweet == ""):
            return

        #we get the text in the input box then we construct the outbound tweet
        #first we need to encode for utf-8
        tweet = unicode(tweet).encode('utf-8')
        #then we need to urlencode so that we can use twitter chars like @ without
        #causing problems
        post = urllib.urlencode({ 'status' : tweet })

        #build the request with the url and our post data
        req = urllib2.Request('http://twitter.com/statuses/update.json', post)
        #setup the auth stuff
        auth_handler = urllib2.HTTPBasicAuthHandler()
        auth_handler.add_password(realm='Twitter API',
                              uri='http://twitter.com/statuses/update.json',
                              user=self.username,
                              passwd=self.password)
        opener = urllib2.build_opener(auth_handler)
        # ...and install it globally so it can be used with urlopen.
        urllib2.install_opener(opener)
        json = urllib2.urlopen(req)
        data = simplejson.loads(json.read())
        #message sent, I'm assuming a failure to send would not continue
        #in this method? so it's safe to remove the tweet line
        # what I don't want is to lose the tweet I typed if we didn't
        # sucessfully send it to twitter. that would be annoying (I'm looking
        # at you Mauku)
        text_widget.set_text("");

    def on_window_state_change(self, widget, event, *args):
        #this just sets a flag to keep track of what state we're in
       if event.new_window_state & gtk.gdk.WINDOW_STATE_FULLSCREEN:
            self.window_in_fullscreen = True
       else:
            self.window_in_fullscreen = False 

    def on_key_press(self, widget, event, *args):
        #this picks up the press of the full screen key and toggles
        #from one mode to the other
       if event.keyval == gtk.keysyms.F6:
             # The "Full screen" hardware key has been pressed
             if self.window_in_fullscreen:
                 self.window.unfullscreen ()
                 #when we toggle off fullscreen set the cell render wrap
                 #to 500
                 self.cell.set_property('wrap-width', 500)
             else:
                self.window.fullscreen ()
                #when we toggle into fullscreen set the cell render wrap
                #wider
                self.cell.set_property('wrap-width', 630)

if __name__ == "__main__":
    #this is just what initialises the app and calls run
    app = Witter()
    app.run()

And that’s it. I used esbox to develop and just had it using SCP/SSH to copy accross to my n810 and execute directly there, which was a pretty easy way to develop.

There are lots of things I will now go on to add to this client. Things like checking for replies/DMs. Being able to make easy reference to an URLs in tweets, and reply to people etc etc. But I wanted to show the code of the bare bones working in case it helped anyone else get started with developing apps for Maemo.

Developing applications for Maemo

When I first got my nokia 770 I intended to develop for it. I had a few ideas of what to write, but discovered apps already existing for just about everything I could think of. I also discovered that it’s not that easy developing for maemo. To write in C you need scratchbox and an emulated environment. It all looked very complicated and I never got into it.
When I got my n810 I figured it would be fun to try and write an app that could render openstreetmap data, as an alternative to maemo mapper which uses pre-rendered tiles. But again I found Navit, already very good.
I thought about getting involved with Navit development. But I have no C experience and the code is somewhat light on comments.

Recently I decided to have a go again. This time I chose to ignore existing apps. The point is to learn, so I have decided to work on my own twitter client. Yes very trendy…there are hundreds around, but only one really for Maemo, which is mauku.
Part of my reason for chosing to write a twitter client is that it’s pretty simple but covers some basics that will be helpful.
Writing a GUI app that displays data and can scroll
calling out to some webservice and processing the response

I figure if I can get those two then I’ll have a good grounding for lots of projects.

The other part of my reason is that mauku has some very annoying ‘features’ which are driving me crazy. Now I could just raise feature requests and bug reports etc. But again, the point is to learn, so I have to start somewhere. At least this way I don’t feel it’s a complete duplicated effort, I will scratch my personal itch and make a twitter client the way I want it.

I started off trying to write a c application. I found esbox which makes the whole developing with scratchbox thing a much nicer prospect than plain text editors. Being an eclipse tool, I feel right at home using it.

I got my C application as far as being able to display a window, with a menu. And in the menu was a fetch tweets option. When selected it would talk to twitter and fetch my friends timeline into memory, then parse each tweet into a simple structure of name:tweet. Which was then inserted into a list in the display. Hurrah.

However C is a horrible language to work in. I just don’t have time to learn memory management etc. I know I should, I know that the potential is to write a much faster application in C. But I got sick of segfaults. I have no idea how to debug C. I am truly a Java boy. Give me stack traces! Trying to debug why my C code would just randomly explode was impossible (for me) It seemed like sometimes something in the reponse from twitter would cause it to segfault. But more likely I was just memory management completely wrong and was just lucky that occassionally it didn’t explode in my face.

So I’ve decided life is too short for C. Instead I’ve moved on to python. I’ve never written any python before, but it at least saves me from managing memory, and it looks like it’s going to be much closer to things I do know, such as perl.

Python can still be developed in ESBOX with pluthon plugin. This basically lets me write an app then use SSH to dispatch it direct to my n810 to run. So I no longer test in a fake environment. It is probably much slower working this way, but the benefit is that I really know that the app runs on the device. Where as I think I’d always have a nagging fear with running in scratchbox that I might hit some difference in how I had it setup to the real device.

So I started my application again. I’ve been able to reuse at least some of what I had learned about GTK development. This is still the area that I know the least about. It took me ages to get to the point I had the ability to display items on the screen, in a TreeView pulling data from a ListStore. Figuring out how to use items that could be added to by triggered methods and generally getting my head around the scope of objects etc.

Having gotten some basic information appearing on the screen, it then took about 30mins to pick uip the liburl2 library and use it to call twitter to get my status feed.

Now I just need to write some code to parse it into some sensible structure and dislpay. I would point out that I have found that someone has already created a twitter API for python which I could just pick up. I’m sure it does way more, way better than my code will. However, I have to remind myself that the point of this exersise is for me to learn, not just for me to glue other peoples code together.
Also I may not bother with a lot of the things I could process from twitter, Instead just writing a fairly minimal application. At least to start with.

First impression of python is that it’s pretty weird the way it uses indentation to imply structure. If you get the indents wrong then the code won’t work. It feels like it was done by someone who got very upset about people having badly formatted code, so decided to invent a language in which the formatting is enforced because that’s the only way the language will work. Not that I have anything against nicely formatted code. But I’d just as soon have an editor do nice formatting for me to suit my preferences.

Once I feel I know what I’m doing a bit more, I shall write up a post with code fragments to explain what I’ve learned. I think if I put up the code I have right now it would just be confusing. I always find that my initial attempts to get something working are very badly commented and horribly structured. At the moment I’m just throwing stuff in based on API doc and examples and I’m not sure I understand the implications of everything yet. Once I understand it, I can comment it and make it presentable.

I’m hoping that given enough time I’ll understand what I’m doing enough that I can start turning out interesting little tools and hacks. And perhaps finally realise my original intention with my internet tablet to do some mobile development.

First steps in a new software project

This week I started a brand new project. This time it’s the start of product development, rather than just an internal project to get something running. And it really is new, so everyone is new and we’re setting up everything from scratch.

So this is my list of things to go from nothing to a fully fledged software engineering project.

Step one, getting the right tools installed for everyone off the bat makes things easier later on. Standardise upfront rather than try to merge half a dozen separate ideas about whats best later.
For this team we will be testing a GUI so Rational Functional Tester (RFT) with Rational Team Concert (RTC) is the basic tool set.

This gives us all the project management tools in RTC, plus source control, and easy collaboration. Then when we get as far as something to test RFT will already be there.

RTC is the best tool I’ve used for starting projects, it lets you start capturing requirements and high level ’stories’ and start hanging individual tasks off of them. Code sharing is very easy, and delivering code changes under tasks makes the project tracking pretty seamless.

Step two, a build server. It’s easy to link into RTC to have a build engine that allows you to schedule builds as frequently as you like. It also allows people to kick off builds of the mainline code plus their ‘local’ changes. So you can build and unit test changes before delivering them to the main codebase. The outline of this can be set up quickly, the detail of full build and kicking off unit tests takes longer but is a top priority.

Step three is a Rational Quality Manager (RQM) server. This can be linked to the RTC server so that it gets notified when builds complete and also allows you to create defects in RTC if tests fail. RTC can then view defects which block test cases. RQM lets you define what environments you will test in, how you will split things into test plans. And makes it easy to start defining test cases and where they will run. Ultimately it can be used to report on test status, with built in dashboards and report generation.

The last step are some test servers which run adapters which connect to the RQM server. For our needs some of these will use a command line adapter, others will use RFT. This allows RQM to kick off tests against the systems and gather the results.

As a set of tools they are not light weight. Requiring at least 4 servers (RTC, RQM, build, test) but then they are a very powerful combination. I don’t expect to have any spreadsheets or hand-crafted chart generation being done by the team. All of the information we require comes straight from the tools, when we report project status we will use the tools not hand-made slides or spreadsheets. I also expect to be able to get tests automated and managed from the start. So no trying to retro-fit automation onto manual tests.

After one week we have RTC setup with the first wave of requirements stories and tasks, and a code base setup with components for our new product. We have an RQM connected and being told about builds. We have the skeleton of a build system. It’s not doing much other than defining the build types we will have, but the framework is in place.

Next week I’ll setup my first test server. Hopefully in a very short space of time we will have everything we need to develop and test a product. Complete with project tracking and reporting, all while most of the team are focussed on what we will produce, not tied up with figuring out infastructure.

Pen turning

Well it had to happen eventually. Given a lathe for enough time eventually you’ll give in to the allure of pen turning.

I had started talking about giving it a go, and not long after Kat found herself in Turners Retreat with her dad. Being awesome, she bought me some supplies for turning pens.

One cigar pen kit, one sierra pen kit, two pen blanks, and a pen turning mandrel, as well as some other wood for other projects.

Interestingly Turners Retreat did not supply any instructions with any of the items. I would have thought that seeing the selection of things being purchased they could have mentioned the need for bushings, to go with the pen sets. They could have indicated the existence of other associated tools even if they didn’t push them too hard.

As it was I placed an order to get a few extra bits and bobs so that I was ready to roll.

First job, cut the blanks to the tube lengths. For this I just used the tubes to set the fence of my bandsaw, and cut each blank. Easy peasy.

Second job, drill the blanks. I picked up one of the inner tubes for the cigar pen and sized it against my drill bits, and needed a 10mm bit. I clamped each section of blank, set up on centre by eye, and drilled.

The cigar pen blanks first, then the blank for the sierra.

Uh-oh…the tube for the sierra didn’t fit in the hole. Stupidly I had assumed that all tubes would be the same. They are not.
Luckily the sierra tube was bigger, not smaller – so no harm done. However, the 10mm bit is already the biggest before I jump up to much bigger Forstner bits. Damn.

Turns out that some pen kits cunningly require a bit just a little out of the normal range. And wouldn’t you know it, they’ll sell you one for £20!! So I put that aside for now, and moved on with the cigar pen.

I tried to square off the ends on my disc sander holding the tubes in place for reference. There are special tools for this, of course, but there are limits to how many custom tools I want to buy(or get bought ) just to get started.

I glued the tubes into the blanks and left them to dry.

Next comes the fun bit, I looked up instructions for the cigar pen and set up the mandrel and bushings as described.

Now for my first real mistake….
The mandrel is adjustable, and I’d played with it a little. So when I setup the blanks I had lengthened the shaft just long enough to tighten the end piece on to clamp everything tightly.
This meant a largely flat surface at the tailstock end, which I attempted to support with a cup centre.

This was hopeless, and didn’t centre the end properly. I should have realised and done something, but like a fool I carried on.

I shaped the pieces, and sanded, but found that closer to the tailstock meant more off centre from the metal shaft. Correspondingly it was hard to get a good finish on the ends with either tools or sanding.

The results were ok, but not great. I realised later I could have lengthened the mandrel shaft, screwed the end piece down much further, and let the screw threaded end of the mandrel shaft centre in the back of the cup centre. Next time.

Having finished the sections as well as I could, I enthusiastically set about constructing the pen. Using some wood blocks in my vice to protect the ends, I squeezed the bits into the ends.

But in my haste and enthusiasm I didn’t make sure I knew where all the bits went. Without instructions I went on what seemed right based on where threads seemed to fit etc. And boy was I wrong.
I think I got just about every fitting wrong! First I got the fittings for the bottom half the wrong way around. And at length had to figure out how to get them out again. (Mostly the shafts of drill bits that where just the right diameter to hammer out the fittings from the opposite side)

Having fixed the lower piece I set the ends for the top piece, only to find nothing held together. Stupidly I had set what should have been the very top fitting, as the very bottom fitting, and vice versa.

Lessons learned – get the instructions, read the instructions…*then* fit things together.

Also, as I’ve said before….*don’t panic* I screwed up everything, damaged some threads whilst trying to undo some mistakes, and ultimately still wound up with this:

Not fantastic, but I’m happy enough for a first try. I think I got quiet a few mistakes out of the way, so I can learn from them next time

The Mallet of many mistakes

In last months woodturning magazine there was a project-in-a-day feature for making a mallet. I caught my eye because the head of the mallet was made from lignum vitae, a very dense hard wood which is normally found in the balls used for lawn bowls. As it happens I was recently given a couple of these by my Grandfather for the specific purpose of using the wood in a turning project.
The handle in the project was made from ash, and I had a similar dimensioned block of sycamore which I figured would do just as well. And so it seemed destined to be my next project.

And here is the finished piece

The eagle eyed woodturner might now be saying…”that doesn’t look like sycamore”. They would be right, and this is because it is in fact applewood. The reason why lies amongst the many things that went wrong trying to do this project.

So I had the materials I needed, and I had step by step instructions in the magazine. So what could possibly go wrong?

The first job was to drill through the centre of the lignum ball with a forstner bit. See the magazine image here

Easy right, just use a clamp to hold the thing still, and away you go.

Not so much. I probably could have spent much more time making a proper base to sit the sphere in which would have kept it stable. But I was trying to follow the magazine, and wanting to make progress. So I got the smallest clamp that I had, that would clamp around the size of the sphere. This is not a small clamp. It was rather difficult to hold it in place, much of the weight of the clamp is not over the drill press, and so I needed to hold it as best I could in place to try and get a good line through the centre of the sphere. Within moments of starting to drill another thing became clear. Removing dense wood with a 35mm forstner bit creates a lot of sawdust. Which makes things difficult to see,k and also jams up the drilling process unless you can remove it. So Wheeled across my dust extractor. But I currently have no way to mount it for the drill press, so I had to try and hold it nearby. This means I am now holding a clamp and a extractor hose, and trying to operate the drill press. Not easy, but not impossible. Then I hit a point that should have been apparent from the outset. My forstner bit is not long enough to go through the whole ball. The chuck of the drill is wider that the bit, so I could drill a little over half way and that was it.

Hmm, the article did not mention this challenge. ‘Obviously’ all I needed to do was turn the ball up the other way, and drill in from the other side. So now I’m trying to hold a vice and a extractor hose, whilst working the drill press, AND I need to be accurate enough to get the lines to meet perfectly.

What actually happened was that I made it connect almost perfectly, but not quite. I wasn’t sure how much of a problem the slight misalignment would cause me. I used a few tools to try and minimise the step between the two drill shafts. At this point I figured it was as good as it was going to get. So it would have to do.

Ok, then onto the handle. The steps said to turn between centres, shape the handle, and the tenon.

And so that is what I did, carefully setting the tenon the correct diameter for the hole I had drilled. I decided not to go too crazy with the finishing at this stage, so I sanded it down but didn’t apply any finish.
The next step was to take the handle off the lath, and use a bandsaw to cut a cross down the tenon. This is so that it fits easier through the hole in the mallet head. Then at the end you insert wedges to hold everything in place and make for a nice feature at the head end.

Keen eyed observes will not there are no wedges in the end of my mallet.

Having cut the cross through the tenon section it did indeed fit through the hole of the head section. And then I just needed to remount between centres. The magazine said that the prongs of the drive centre would fit into the cuts from the bandsaw.

Something I should have noticed is that they talked about a four prong drive centre. I only have a 2 prong drive centre. Though I suspect I would have had similar issues even with the 4 prong, I found it was basically impossible to get the thing remounted centrally. The handle was now turning a little off it’s previous axis.

I started to shape the head of the mallet anyway, I figured that it might not be too bad, slightly off centre only really shows when it’s rapidly spinning.
However the magazine steps said to blend the handle with the head a little. I was starting to shape the head, and noticing that things were not looking as they should. In a moment of madness I thought I might be able to blend the handle down to it’s new axis, and it wouldn’t matter. But of course there was not enough width in the shoulder of the tenon to cope with being turned off centre. A hasty cut and the whole thing was ruined. I also realised that there was no way I would get the mallet head shape in the article without cutting a chunk from the bottom of the ball, to being a wider part close to the handle. The article didn’t mention that either. Of course it would have made things much easier on the drill press if I had STARTED by cutting a chunk from the bottom, and making a parallel flat at the top.

At this point I left it with disgust for a few days. The handle was ruined, and I didn’t think I had anything else of the right dimensions available.

At this point I contemplated how I *should* have approached this.
Step 1 cut a section from one side of the ball, to bring a reasonable width to what will be the bottom of the mallet.
Step 2, cut a parallel shallow flat at the top. Step two, with the ball resting flat on the drill press, with a vice just to stop it spinning, drill as deep as I could go from one end.
Step 3 mount the ball on my expanding jaw chuck, the narrow jaws should fit inside the 35mm hole, I could then put the forstner bit in my tailstock chuck. And drill from the other side with a much better chance of true alignment.

For the handle I figured I should have turned such that the tenon was at the headstock end, and left a piece on the end for the drive centre. Turning the drive centre waste narrower than the tenon I could pass the whole lot through the mallet head without cutting any wedges and remount exactly on the same drive points as turned the handle.

I discovered that I had a piece of applewood that I turned down to a cylinder about a year ago, and left drying inside some paper bags. It was just about the perfect size for the project and I figured I was back in business. But I kept the mallet head from before rather than attempt to start again.
I also didn’t bother to do any handle shaping before I put the mallet head in place. I just turned the tenon. I wanted to be sure that if I had any trouble getting things back on a central axis that I had more material to play with.

I put some work into sheering the base of the mallet head flat and in line with the shoulder of the tenon. To get a nice tight fit. The tenon was just the right width that I needed to hammer it through the lignum.

And so I could proceed to shape the lignum to the mallet shape I wanted. This went mostly ok, though I had far too many catches trying to shape the ends. I still struggle to avoid causing spiral catches, even when I think I’m being careful.

Once shaped, sanded and finished. IT just remained to shape the bottom of the handle which I did eventually parting it off. This then left me with a stub of wood above the top of the mallet that needed to be removed.

So I took it to the bandsaw to remove most of the waste. And decided to sand the remainder on my belt and disc sander.
This was another mistake. The disc sander is very aggressive and difficult to present things at it square on. And so I wound up with an off-centre flat spot on top. I evened it up as much as I could, but in doing so I found I had revealed a gap where the rough hole through the lignum was not perfectly round and the tenon passing through did not fill it.

At this point I figured the easiest thing to do would be to just fill the hole with sawdust and glue. Which is less obvious than a hole, but still not as nice as doing the job right.

The finished article is actually very nice. In some ways I’m loathe to actually use it as a mallet because I don’t want to damage the beautiful lignum mallet head. However this project was a stark reminder that I am still such a novice. So many things went wrong. Blindly following the steps in teh article without thinking it through myself was a mistake. I’m almost tempted to try again from scratch, just to see if I can make it right, or whether I’d just hit another slew of problems. Maybe one day.