By Andrew Price, 2011-03-25 16:38:42 in Twyt. (Permalink)
This is kind of an overdue announcement but I am discontinuing my development of Twyt. It has not worked properly since Twitter switched off basic auth in favour of OAuth and I have no interest in making it work again. The bzr repository is still available so if anybody does have any interest in making it work, feel free. Perhaps it could be turned into a StatusNet client.
Dear Laptop Vendors...
By Andrew Price, 2009-07-11 01:43:33 in Geekdom. (Permalink)
... my parents have set me the task of selecting a laptop for them to buy, to replace their ageing desktop machine. The time frame is fairly generous: early 2010. (At this point it may be useful to note that we live in the UK). Now, listen closely because here comes the tricky part. The desktop machine has been running Ubuntu for a few years, which means they want the new laptop to run Ubuntu. No ifs, no buts. That's what they want. They're happy with Ubuntu.
Reading about David Woodhouse's painful adventures in laptop purchasing (and others') left a sour taste in my mouth. I don't want to subject my parents to a similar experience. That is, I have no interest in advising them to buy a laptop with Windows installed on it, only to tell them they'll have to contact one or more companies to request a refund, forensically and photographically document the removal of Windows from the hard disk, threaten legal action when said refund doesn't materialise and jump through the other flaming hoops involved in buying a laptop without paying for an unused copy of Windows.
The fact that my parents want Ubuntu does not necessarily mean that they want it preinstalled; it simply means that they do not want to have to pay for Windows in the first instance. Focus on that small-but-important detail.
So, laptop vendors of the UK, you have until next year to offer my parents a good customer experience.
By Andrew Price, 2009-02-26 17:25:13 in Art. (Permalink)
There was nothing for her here. Past the template-punched houses she trudged, the old soldier staring through the same grey pavement. She had taken the bullet, and somehow the world was more silent now. A gust of wind blew and corrected her posture like a loyal friend. She stopped and leaned into the air, eyes softly shut. The air caressed and cradled her body as it passed her by. She smiled. It had whispered its secret to her. Arms straight at her sides, she caught the air and rose into it: the baby on Mother's shoulder, high above it all.
Twyt 0.9.1 - Under The Same Stars
By Andrew Price, 2009-02-17 22:01:50 in Twyt. (Permalink)
This release cycle has been pushed along by suggestions, patches and testing from users of the twyt command line client, so the twyt Twitter API module has only undergone some tweaks and just a few additions to the set of supported API methods.
Changes to the twyt client include:
- A 'namecache' subcommand, intended for making tab completion scripts more useful
- Better support for using twyt in pipelines (you can now pipe messages into 'twyt tweet')
- Now prints screen names instead of real names (by popular demand)
- A 'sing' subcommand (it's silly, but it gets used)
- Better non-ASCII character handling
The #twyt hashtag is getting used quite regularly now, but for bug reports and patches please stick to good, old-fashioned email.
Restoring Removed Files With Git
By Andrew Price, 2009-01-11 04:01:49 in Geekdom. (Permalink)
So you've accidentally rm'd a file in a git tree and you want it back. What to do?
$ git checkout HEAD -- path/to/removed/file
This tip was brought to you by Andy's determination to remember how to do it next time, in cooperation with wasted moments spent reading the wrong man page (git reset). Sigh.
Twyt 0.9.0 - Flowers On The Ceiling
By Andrew Price, 2009-01-04 09:20:12 in Twyt. (Permalink)
This release incorporates lots of little fixes, and updates which were required to keep up with changes to the Twitter API. Scripts which import previous versions of twyt may need updating.
The accompanying command line client, twyt, has also been improved. In particular it has better support for multiple Twitter accounts and allows you to flag one username as the default. It also now uses simplejson to store user configuration so the .ini-style config files generated with older versions of twyt will be ignored (apologies for the inconvenience, to the three people who use it).
Note that the number of Twitter API methods which twyt supports has not increased - I'll get around to adding support for more of them next time I'm in the mood. Meanwhile, if you're a Python coder and you've got nothing better to do, feel free to read the APITODO file to see what's missing and email me a patch, or the URL of your bzr branch. It's easy-peasy stuff.
Adobe In The 21st Century
By Andrew Price, 2008-11-17 17:56:29 in Geekdom. (Permalink)
andy@diogenes:~/.mozilla/plugins$ file libflashplayer.so
libflashplayer.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
Goodbye, nspluginwrapper. Thanks for being there when I needed you.
By Andrew Price, 2008-11-02 15:34:02 in General. (Permalink)
By Andrew Price, 2008-06-20 19:13:54 in News. (Permalink)
It seems to be a time of good/interesting news in the technology world:
- "I think the BBC can, and should, do more to support the Free and Open Source community" -- Ashley Highfield, Director, BBC Future Media & Technology
- "ODF has clearly won" -- Stuart McKee, Microsoft
- "The latest OpenJDK binary [...] passes the rigorous Java Test Compatibility Kit (TCK)" -- Rich Sharples, Director of Product Management for the JBoss EAP, Red Hat
- "MySQL code has been migrated from BitKeeper to Bazaar" -- Kaj Arnö, MySQL VP of Community Relations
- "One tonne 'Baby' marks its birth" -- Jonathan Fildes, Science and technology reporter, BBC News
- "BSc Computer Science with Lower Second Class Honours [...] subject to ratification by the University of Wales" -- The degree result letter I was given earlier by the Computer Science department.
I am a happy chap.
And Now, The End Is Near
By Andrew Price, 2008-05-27 03:08:38 in General. (Permalink)
It's gone 2:00am and my final exam of my entire degree course begins in about seven hours. What a strange feeling. My life is approaching one of those unsettling turning points where just about anything can happen. At least, it feels that way: the sky's the limit. Realistically my next days will be spent basking in the warm glow of relief that the course has ended, celebrating, and spending some proper happy-time with my friends, who I've missed greatly over the last I've-forgotten-how-long due to the CS Course From Hell effect.
After and during all that fun stuff, as I understand is traditional in these circumstances, I'll be looking for a job. I'm aware that advertising the kind of area I'd like to work in on my blog may be counterproductive but any Sharp-eyed Stanley could figure out my preferences from my website and the sites which syndicate my blog entries. Fingers crossed, anyway.
Somewhat less traditionally, I really want to get stuck in and push my open source projects along now. I've been neglecting Pybackpack terribly for the last academic year, and Gnome has gone and changed GnomeVFS into GVFS/GIO which means the crazy Gnome-dependent bits still remaining in Pybackpack are getting rotten. Its code base dates back to when Dave and I were first learning Python so there's some pretty shocking stuff in there too, and it's begging for a rewrite. Although lately I've been developing some ideas about abstracting away the commonalities of backup systems and encapsulating them in a framework so it may evolve into something different. I should mature those ideas and write them down out at some point.
This last academic year my main focus has been Askant, the Linux file system performance analysis tool I've been developing for my third year project and dissertation. It's not very pretty or useful right now but it'll get there with some love and elbow grease. Askant has been at the centre of one of the most interesting and challenging learning experiences I've had at university. While researching for it, I've learned a good deal about file systems (GFS2 in particular), block IO, the Linux kernel in general, C, extending Python, and to top things off, it taught me enough to let me contribute five whole characters of code in the kernel. There'll be more where they came from, I'm sure.
As for Twyt, well, that's simple and modular so I've been able to hack on it in stolen moments of relaxation. It shouldn't take long for it to reach full API support when I'm free to work on it. It's been attracting a fair amount of interest lately (I think more computer geeks are joining Twitter, you know).
Well, I'd better cut this short and get some sleep. That silly exam isn't going to write itself.
Synchronicity and Sharing
By Andrew Price, 2008-05-18 17:46:54 in Geekdom. (Permalink)
Dag Wieers' comments that "Mark Shuttleworth's recent pledge to join a synchronised release plan for Enterprise Linux distributions is no more than a wish to benefit from a lot of work that Novell and Red Hat are already doing in the Enterprise space" are strange.
There is one main reason why I think this is a strange way to argue against Mark's idea and it's this: Red Hat is a very successful company based upon the idea that there is value to be found in and around software which is freely available to modify and redistribute. This is a cornerstone of Red Hat's business model and thus any calls of "It's not fair to use the [freely available, modifiable and redistributable] products of Red Hat's efforts for your own profit." (my words, not Dag's) seem quite out-of-place.
Sure, Canonical is a tiny company by comparison, so it doesn't have a large workforce to make a huge number of upstream contributions, and it's not yet profitable so it needs to be clever in order to propel itself towards sustainability. But if anybody thinks that synchronizing release cycles to stabilize versions and focus efforts across distributions would not benefit Red Hat more than the added competition might damage their business, they might need to rethink the situation. But I guess this is the main question that Red Hat needs to ask itself before signing up to Mark's idea.
One thing Red Hat and Shuttleworth have in common is that they're good business players. They seem to get the idea that, whatever boosts the success of Linux-and-friends as a whole is good for expanding the Linux-and-friends market and other companies' opinions of it. Currently one of the factors holding back adoption of Linux-based solutions, from the point of view of potential customers, is that there's so much to choose from; so many distributions, packages and support possibilities. Judging from one of Red Hat's recent successes the deal clincher is the quality of technical support which is on offer. Technical support in this context presumably means killing bugs and making sure that hardware support for the deployments is top-notch. So having some kind of consistency between versions might make open source a larger target for enterprise customers and hardware manufacturers (two groups which are not distinct) and focus development and testing efforts onto those versions.
So it's really a level playing field. Whatever Canonical contributes to free/open source is available for Red Hat to benefit from and vice versa. The bad vibes I've been sensing lately (particularly surrounding the kernel) seem to be rooted in how Canonical isn't big or successful enough to contribute on the same scale as Red Hat yet. That's to be expected, for now. In reality, any business which enters the Linux distribution market really should know that the competition ultimately is not about having better software than the other guy, because the software belongs to all of us and none of us. The winner will be the company with the best people and the best business ideas and strategies. To me, Mark's idea is not one which is meant to give Canonical an advantage over other companies (especially an unfair advantage), it's an idea meant to map the century-tested assembly line approach which made Ford so successful onto the main components of several Linux-based distributions to push them all forwards. Whether it's a good, workable idea or not has yet to be tested, but I think it would be an interesting experiment.
Twyt 0.8.5 - Dancing Like Astley
By Andrew Price, 2008-05-18 00:44:09 in Twyt. (Permalink)
Twyt 0.8.5 has been unleashed. Twyt is a python Twitter API library and accompanying command line Twitter client.
This version improves greatly on the previous command line interface with added --help for each subcommand. The client code has been rejigged to use Python's optparse making it more scalable and flexible than before. It also has better local timezone and DST support. Here's a quick example:
andy@plato:~$ twyt --commands
Usage: twyt COMMAND [options] [args]
archive Shows 80 of your status messages ordered by date of posting
delete Deletes a tweet by ID
direct Sends a direct message to another user
directdel Delete a direct message which was sent to you
directsent Prints the 20 last direct messages sent by you
directtl Prints the 20 last direct messages sent to you
friendstl Returns 20 most recent statuses in your (or USERNAME's) friends timeline
publictl Shows the 20 most recent statuses in Twitter's public timeline
replies Show the Nth page of 20 replies (messages with @yourusername in them)
savepass Saves your username and password for subsequent use
show Show a single status message by ID
tweet Updates the authenticating user's Twitter status
usertl Show your timeline, or USERNAME's timeline
For command-specific help, use twyt COMMAND --help
andy@plato:~$ twyt tweet "Showing off Twyt's cool, new, helpful, optparsed interface"
 twytdev: Showing off Twyt's cool, new, helpful, optparsed interface (Sun May 18 00:13:00 2008 via <a href="http://andrewprice.me.uk/projects/twyt">Twyt</a>)
Next on the TODO list for Twyt are better support for multiple Twitter accounts and more complete support for the rest of the API functions. A handful of new API functions has appeared over the last few months so it'll be a challenge to catch up. My aim is to release version 1.0.0 once the whole API is supported in Twyt.
Updated python-twyt packages will hit Debian unstable very soon and Fedora as soon as I've finished upgrading to Fedora 9 (modulo studying for my final exams which start on Monday).
Generating Patch Emails With Git
By Andrew Price, 2008-04-07 19:20:58 in Geekdom. (Permalink)
Today was the first time I've used git to produce an email containing a patch that I'd written and I was impressed at how simple it is. I thought I'd share how it was done to help other git learners, and to help me remember it for next time. For this to make sense, assume that I had just cloned the git tree so that I'm working with a new, clean tree.
First I created a new branch to keep my work separate, using:
git checkout -b mybranch
Then I edited some code, tested that my fix worked, and committed my changes using:
git commit -a
When you commit, git opens an editor (in my case, vim) in which to enter your commit message. It's worth noting here that the first line of the commit message is used as the short log (the 'title' of the commit), and the rest is used as the body of the log message. The short log will become the 'subject' header of your email later.
Once my changes were committed, I used format-patch to produce the email with my patch in it, like so:
git format-patch -1 -s --subject-prefix='PATCH][BUILD'
This produced a nicely formatted email-able text file containing my patch. The file includes the 'From' email header which it generates using the email address and name stored in your git config. You can find information about all the possible format-patch options from the man page but the ones I used were:
- '-1' : Create a patch for the last 1 commit
- '-s' : Add a Signed-off-by line to the message
- '--subject-prefix=' : Specifies the beginning of the subject header
I then used mutt to send the patch by using its -H option which loads a template email:
mutt -H 0001-Example-patch-name.patch
Then all I needed to do was tell mutt which address to send the email to, and hit y to send. Simple as that.
Software From Universities For Schools
By Andrew Price, 2008-04-05 11:54:11 in General. (Permalink)
The idea is simple: computer science/software engineering departments in universities could initiate and host open source software projects to satisfy computer-based learning requirements of local schools. The flow would go something like:
- University and school communicate to establish the school's software requirements;
- Research is carried out to establish whether open source software already exists to satisfy requirements (no point in duplicating effort, right?);
- University sets up infrastructure and recruits interested staff and students to take on the project in their spare time or as part of an assessed course;
- The project is publicised to attract wider attention from potential developers and other schools;
- The software is developed and releases made, allowing teachers to evaluate it and report bugs and request features until it is good enough for use;
- The project hits 'maintenance mode' allowing the university to take on a new project;
- The school kids become computer geeks, end up in university and contribute software back to their old schools (ok, maybe just a few).
The obvious benefits here are financial and educational and it would help schools to improve their community ties with local universities while the open source software is distributed freely to benefit schools in other parts of the world. The kids could also take the software home with them. The lack of restrictions means that the possibilities are abundant.
Perhaps it could attract financial backing from local industry, motivated by the possibility of employing graduates with more experience of collaborating and working on useful software projects.
This is one of those spur-of-the-moment brainstorms which I haven't really thought through and it's probably not an original idea, but I'd like to see something like this happening in my local area. No doubt there is a bit of red tape and apathy to cut through to get projects like this established but it makes sense to me.
Tracking Commits With Twitter And Twyt
By Andrew Price, 2008-04-04 12:46:22 in Twyt. (Permalink)
The python-twyt package provides a Twitter client API library ('from twyt import twitter') and a command line client ('twyt') which uses the library. One way to use it is to integrate twyt into a shell script to automate your Twitter updates. Here's an example.
Sally the software maintainer wants to let her development team keep track of repository commits while they're away from their computers. She installs python-twyt, sets up a Twitter account for her project and tells twyt the username and password for that account. She then writes a shell script which parses from the email details such as the short commit log and the link to the commit diff in the repository's web interface and calls:
twyt tweet "$devname $shortlog $link"
Sally also sets up a procmail rule to pipe emails from her project's commits list into her script.
So when an email arrives from the commits list procmail triggers the script, sending the summary to Twitter. It then gets distributed to Sally's followers, whether they're using email, SMS or any of the other supported notification methods. The developers (who are clearly very dedicated) smile at being able to keep track of the project on their mobile devices while they're out grocery shopping or in the bath.
I'm not sure if this would be a highly desirable real-world application of twyt but it's one possibility. If anyone implements it, do let me know. It's worth noting, however, that Twitter does have usage limits and won't accept over a certain amount of updates per hour or send over a certain number of SMS messages to each user per week.
[Update: Dave Murphy has just reminded me that you can bypass the whole mailing list stage by using the commit hooks for your code repository to trigger the script]