| Subcribe via RSS
Something useful for FireFox/Mozilla users/Python hackers: Edgewall Software: Python Sidebar
A nifty sidebar that exposes a one click interface to the Python documentation, etc, etc. It's actually pretty nice. I typically have 1 tab dedicated in Safari to the PyDocs on my local machine, and this would be a perfect replacement.
If I didn't use Safari! D'oh.
I use growl on my mac - but I haven't browsed the site in ages. Today, from del.icio.us I found this gem: GrowlNotifier class (Python)
I am going to use the hell out of this. Python bindings for Growl? Heck yeah!
Some notes for myself: Make sure to view the scripts and Extras folders, and also enable "remote notification" in the preference pane.
This will be incredibly useful for tracking network events - also, it'll be kind of cool. I need to make a bugzilla growl plugin to tell me when new bugs hit my queue (but that's redundant with email notifications, I know.)
Taking an OS/X Moment here to share some cool apps I've found recently:
Check Off: A handy little to-do list app. Small, lightweight and simple. Now, if only I could maintain an actual todo list for longer than the time it takes me to think of (or be assigned) a new task. (Free)
Barquee: This is another small app - sits in your bar, and allows you to control iTunes from there. Nice for when I'm not using my iPod, and have another trillion apps running. (10$)
Terminalicious: A nice little app that allows you to launch commands in Terminal - and it keeps a history of the command you've ran. (Free)
TextMate: Ok, so I pimped what I think is the best editor for OS/X again. Sue me.
SQLGrinder: A damned nice SQL client - supports a wide range of functionality, including schema browsing/exporting/etc. Also supports a wide range of databases. A dang fine application.
So, one of the things I am beginning to test the waters on is writing actual GUI applications in Python - designing a GUI is not something I have ever done, nor have I ever had the need. However, as I develop more tools - distributed ones at that, I find that putting a decent UI around them would be handy for other users.
Let's throw in the fact I am also a Mac User. So in reality, I know I want to start with something like wxPython or PyGTK - I know that much at least.
But sitting in my bookmark list is an article (from Apple's site) on using Python to develop Mac application using PyObj - something that's been eating at the back of my head for a few months.
In any case, starting with PyObjC is a little beyond my GUI capabilities at the moment. So, instead I found PythonCard - a GUI construction kit for Py apps using wxPython.
The Python card site has an excellent starter walkthrough here which i figure I'll start chewing on.
I don't know when I'll be able to ramp up on this - right now I'm tapped out with everything else under the sun - but more information is good information.
I ran across this gem from Joel Spolsky about "web 2.0": Architecture Astronauts Are Back
He's dead right about "web 2.0". And hopefully, like him, this will be my last post on the subject. Until I get ran over by some AJAXWEB2.0SEMANTICWEB train and suffer brain trauma.
Yes, I blog. Yes, I read RSS feeds. A technological revolution this is not.
If anyone is doing a lot of Python on the Mac editing - I highly recommend using TextMate it's light, powerful (after you get the python bundle from SVN) and supports projects.
I have it integrated with Perforce, Subversion and CVS with syntax highlinting, custom keys.
Really, everything I look for in an editor. And given you can add your own bundles or extend existing ones, it's simple to add Bicycle Repair man integrations, etc.
The maintainer has a blog and he's been doing frequent nightly builds - each with noticeable improvements.
It's also not very memory intensive (a drag for me with other editors) and very responsive when editing large numbers of files.
Give it a try, buy a license!
For the Python/SSH/Distributed crowd: osh: Object-Oriented Shell
OSH is a Pythonic method of distributing commands across a series of hosts, among other things. The response from the hosts is placed into Python data structures, etc.
Yet another tool for the tool box!
I've spent an incredible amount of time dealing with a few hundred machines - and by dealing, I mean clustering, administering (simultaneously) QA'ing software on them, so on and so forth.
I've really ramped up my own experiences in this space over the last few years too, especially since I picked up the Python hat and started doing everything in well, Python.
One of the harder things to do when you're interacting with greater than 5 simultaneous machines include flow control, handling exceptions properly, managing return data - etc.
In a perfect world, you'd just make your own client and server - but why do that if you have something as ubiquitous as SSH?
So, I do all my work through SSH - this is a blessing, and a curse in a lot of respects. The first good thing is that, well, SSH runs everywhere. As long as I do the initial work of getting SSH Keyring information setup properly everyplace, I don't need to deal with user authentication and can strictly scope myself to command execution.
And here is where the curse comes in.
When you're writing applications that subprocess() or popen() on the local system, it's trivial to track the pid, exit status and other information of that spawned process from the local machine, generally speaking you don't have to worry about hang conditions or not getting a "rational" exit status.
SSH doesn't prevent that - not at all. However, it does make life a little more interesting. You have to worry about hang conditions a lot more, you have to worry how you pipe data back to the client - you have to be sure to close things like stdin() (otherwise the SSH process never returns - as long as a stdin() pipe exists, SSH just chills out), etc. Then when you throw the fact you have to manage this across a few hundred machines the situation gets even more messy.
It's not an impossible situation - use select() to manage the pipe from the spawned SSH process - make sure you're capturing the exist status of the command you're running through ssh - and the exit status of the ssh command itself (a process might exit 2 on the remote host, but ssh would always return an exit 1 - both are failures, but you have to harvest both) - make sure you handle simultaneous execution through threads - make sure those threads have timers on them, and that they can't bring down the parent process, etc, etc.
Overall, Python and SSH is a god-send for people like me who have to manage, script and test across large farms of machines. Luckily, I don't have to worry about the topology of each machine being different - mine are all clones.
Using Python and SSH together - intelligently can save you a ton of time, and ultimately make you more productive internally, as your code should be fairly portable (and cross platform). Like I said - SSH is everywhere.
Hopefully in the next few months I'll carve off some projects I can share with the world (time is always precious) that revolve around this. Until then, take a peek at these tools and utilities:
PuSSH - Pythonic, Ubiquitous SSH :
PuSSH is a relative newcomer to the space - and has a lot of good ideas inside the code, and well, it works. I've peeked at the code and gotten my hands dirty with it, hopefully I can get more runtime with it over the next few weeks to learn more about it.
PSSH:
PSSH is, in my mind, the de-facto tool in this space. It's flexible, and has a lot of thought and work put into it, making it incredibly flexible and useful. It does all the correct flow control, and is highly readable and flexible code.
Brent Chun (the creator) also has some other tools he's made (see the page I linked) in this space, so he knows what he's doing. He's also put out a lot of papers on the subject of large scale installations.
The Distribulator:
A type of distributed shell - another tool in the toolbox, but when I first used it, it was on its first release, and fairly bug-ridden. I've used it a few times since then, but the XML format of the configuration and a few other nits made me feel like it's a little heavier, and what it's trying to do could be in a lighter, more efficient manner.
