
“Apple Keyboard Kit” (Apple Computer)
I’m fixing up my home office a bit, and I was using a dirt cheap eMachines keyboard with my MacBook Pro. That keyboard had a PS/2 connector which I ran to a KVM switch (I did have two computers hooked up at one point). So, the first problem was that that keyboard was contributing the my overall cabling mess because of the KVM switch. The other problem was that my current desk, which I bought a few months back, has a much smaller keyboard tray and I’d have to peer under the edge of the desk to see the function keys. It’s also kind of annoying having the wrong meta key arrangement… I’ve been a Mac user for years now, and it would be nice to use a keyboard with Mac keys.
So, I went out and bought an Apple keyboard. It obviously fits much better on my desk. I have no problem seeing all of the keys on this little guy. Additionally, I’ve got to say that I really like the feel. I wasn’t sure that I would, but the keys of this keyboard have a nice tactile response while still requiring very little key pressure or finger travel.
Of course, the Apple keyboard is still a conventional layout keyboard, rather than an ergonomic one. I might be better off with an ergonomic keyboard layout, but for a standard layout keyboard I’m much happier with the feel of this one.
Reviews, Technology
apple
I’m delighted to release Paver 0.7. If you missed my original announcement, the short story is that Paver is a new build, distribution and deployment scripting tool geared toward Python projects. My original announcement and the new foreword to the docs explain the motivation.
Ben Bangert and others pointed out a giant documentation bug in 0.4: there was a fair bit of reference doc but no doc that said “here’s how you get started with Paver”. Now there is: Paver’s Getting Started Guide.
Paver 0.7 is a big step up from 0.4 (hence the version number bump). I implemented one of the two major features I had planned for 1.0: distutils/setuptools integration. It’s really cool. Have you ever wanted to just slightly change how “sdist” or “upload” or “develop” worked? Now you can, just by writing a function in your pavement.py file. And don’t worry, you don’t need to duplicate anything between setup.py and pavement.py. It all just moves into pavement.py and Paver can even generate a setup.py file for you, since most people are use to the common “python setup.py install” command.
I’ve gone even farther than that with making it easy to use Paver and not annoy users that don’t yet have Paver. Paver can create a small zip file of Paver’s core bits so that “python setup.py install” will work just fine even for users who don’t have Paver installed. Paver can also create a virtualenv bootstrap script for you, so that users don’t necessarily need to install your package on their systems in order to use it.
Paver’s got new documentation tools that work great with Sphinx. It’s now easy to mark sections of sample code files and then include those sections in your documentation, using the built-in version of Ned Batchelder’s Cog.
And I’m definitely eating my own dogfood. Paver is built using Paver itself and the source distribution includes the paver-minilib so that setup.py install should work fine (let me know if it doesn’t!) The new Getting Started Guide uses the new documentation tools.
There are even more changes than these, and you can look at the changelog for the full list. Note that if you’re using Paver 0.4, there are a couple of trivial breaking changes.
Python
Paver
My latest blog post is up on the SitePen blog:
Mark Ramm-Christensen posed some questions about using the JVM as a platform for dynamic languages. Many people do, in fact, use dynamic languages on the JVM (Groovy, Beanshell, Rhino, Jython, JRuby are some big ones… and don’t forget Scala, Nice and other “non-dynamic” languages that target the JVM). But Java the platform has not gotten widespread or serious attention until recently (witness the recent resurgence of Jython, the rise of JRuby and the coming of the Da Vinci Machine).
[From Why Java remains the most popular language on the JVM]
Answering the question “Why Java remains the most popular language on the JVM” gives clues as to what might be the next most popular language on that platform.
Java, JavaScript, Software Development
jruby, jython, scala
Seeing this on Bob Ippolito’s blog might seem a little odd to many:
Rewrote test suite with unittest and doctest (no more nosetest dependency)
[From simplejson 1.9]
Why on Earth would someone change from nose-style tests to unittest tests? How about so that the library can go into the Python Standard Library?
simplejson will be a great addition. Thanks to Bob and the others who are working to get simplejson in!
Python
json