The next MichiPUG meeting will be on Thursday, July 2nd at 7PM. Ryan Burns will talk about the Impressive presentation software (which was used at Tuesday’s Ignite Ann Arbor) and Terry Howald will talk about Python’s use in scripting visual effects.We may also talk about the Python 3.1 release.
The meeting will be in downtown Ann Arbor at the SRT Solutions office.
Zattoo’s Marshall Weir will be talking at this week’s MichiPUG (Thursday evening at 7PM at SRT Solutions in downtown Ann Arbor). In his own words:
I’ve been working on a python module for running reports in Hadoop. Its sort of a wrapper around the pig data processing language and some smarts for running reports on a hadoop cluster and pushing and pulling data to it. It’s designed primarily to make it easier and more efficient to run complex sets of interdependent reports - I’ve been using it to do business reporting on our customer behavior at Zattoo.
This should be very interesting for folks like me who have never seen Hadoop in action!
MacSpeech Dictate 1.5 has just been released. In the process, they made a major product management blunder: they chose the wrong version number. How can you mess up with a version number? Simple: you misalign your own expectations with those of your customers.
MacSpeech Dictate is really the only viable speech recognition software for the Mac today. Their original iListen project wasn’t so hot. So, they licensed the Dragon NaturallySpeaking engine and put a Mac UI on top to produce Dictate. The first version that came out was somewhat incomplete, in that there was no way to train the program and improve its accuracy. In October 2008, they released Dictate 1.2 as a free upgrade, adding the training features. In February 2009, Dictate 1.3 added features to make dictation work better with other apps and add some other features. Dictate 1.3 was also a free upgrade.
Now, three months later, they have released Dictate 1.5 as a $55 upgrade. Two of the major features listed are “better accuracy” and “faster performance”, which I think to many people come across as fixes more than features. Just take a look at the comments on the forum thread. The Vocabulary Editor is a true new feature, and the “New Commands” bit sounds like a minor thing they tossed in.
Based on the feature list they presented, “1.5″ sounds like the right version number. It doesn’t seem any greater in scope than 1.2 or 1.3. And yet, for the MacSpeech folks themselves, it probably seems like a long time since 1.0 came out and perhaps they’re feeling the pinch of the current economy. Certainly, the amount of work they’ve done on the product between 1.0 and 1.5 is significant. I’m sure they feel entitled to an additional $55.
Release early, release often is a phrase used a lot in the open source world. For commercial software, however, if you want to offer a paid upgrade, you can’t follow that rule. By doing relatively quick releases of similar scope, MacSpeech inadvertently set the expectation that 1.5 should be a free upgrade. Had they spent 3-6 more months adding new features and then released it as “2.0″, I’m certain they would have had fewer complaints about the upgrade being a paid upgrade.
As far as I know, MacSpeech Dictate doesn’t have any strong competition. From that perspective, they could have waited a few months more. It is possible that they’ve been hit by the economy, though, and couldn’t wait several more months for the additional revenue. If so, that’s a tough spot, and I wish them luck. Regardless, I doubt they were expecting this kind of reaction to a new release, and they may not get the kind of revenue they’re hoping for. HarvidMD in the forum thread:
With upgrade policies like this, I think that I’ll save my pennies and wait for MacSpeech Dictate 3.0 in about five years so that I’ll be able to get a voice recognition package that actually performs as advertised.
The next MichiPUG meeting will be on Thursday, May 7th at 7PM. The topic for this week is newfangled non-relational databases (with demos of Couch DB, Mongo DB, Tokyo Cabinet, Persevere, and Redis promised)
via Welcome - Michigan Python Users Group | Google Groups.
As usual, the meeting will be at the SRT Solutions office in downtown Ann Arbor.
(sorry for the lack of links in here. I wrote this on a plane and haven’t had a chance to do anything else to it…)
I just returned from JSConf 2009, the first JSConf conference. It was possibly even the first conference to feature JavaScript as a general scripting language in the same vein as Python or Ruby.
Overall, it was a very good conference. The organizers did a terrific job and paid great attention to detail. The sponsored evening events were an awesome idea and well-executed. (At least, Friday night’s was, I flew home Saturday evening). It was a relatively small conference at 130 people. I think they can easily have double that number next year, if they want to. But, that would require a change of venue, because the Hotel Palomar’s meeting rooms were filled almost to overflowing. From talking with Chris Williams on Friday evening, it doesn’t sound like they’re interested in changing venues next year, which is a shame because a lot of people will have to miss out on a great conference.
Francisco Tolmasky from 280 North gave the perfect kind of talk to kick things off. I’ve been following Cappucino’s development, so I was not surprised in the least with what I saw. But, Francisco is a polished speaker and many people had not seen Apple’s Interface Builder used to create webapps (via Cappucino’s nib2cib tool). We didn’t get a demo of Atlas, which would certainly have wowed this audience.
One thing that pleased a great many people in the audience, myself included, was word that Safari’s debugger would start looking at a “displayName” on functions to determine what name to show in the debugger/profiler. JavaScript has many places where it’s impossible to guess a reasonable name, and it’s nice to have a way to give the debugger a hint like this. Let’s hope we get this in Firebug soon.
Toward the end of the second day, there was a talk about SproutCore, so we had a chance to two different ways to apply the style of Apple’s Cocoa to building webapps. As with anything, there are tradeoffs. Cappucino builds on Objective-J, which gives you a more concise syntax than straight JavaScript for things like Key Value Observing. If JavaScript today had getters and setters, then this particular benefit of Objective J would go away. For now, though, using SproutCore effectively means calling get* and set* methods to get variable values rather than just looking up the value directly.
There were two presentations on server side JavaScript, a topic that people who know me know that I am currently very into. Nick Campbell showed off the Axiom Stack, which builds on Helma. Axiom is presently AGPL-licensed, which means I won’t go anywhere near it. But, that’s just me. On the plus side, Nick has been peripherally following the activity on ServerJS and is quite in tune with our goals. Nick’s company, by the way, has a unique and useful sounding web marketing-related product coming out soon, so keep an eye on those folks if you’re a marketer.
The second Track A presentation about server side JS was James Duncan’s presentation about Joyent’s Smart platform. I must say that this looks like an excellent offering, and I’m looking forward to seeing a lot more of it as it hits general availability. The best parallel I can draw is “App Engine on JavaScript”, but that doesn’t really do it justice. They have a key-value store that they will scale transparently for you. No more manual sharding! Just start tossing data in. Of course, that’s the promise… and the devil’s in the details with such things. I came in a bit late to James’ presentation and I forgot to ask him afterwards about their data store’s indexing capabilities and whether it is eventual-consistency based or more immediate than that.
The Smart platform is SpiderMonkey-based, and they pull some interesting tricks to overcome the lack of a decent stack of libraries for SpiderMonkey. Their web server interface looked very much like Jack, which is a bonus. It would be nice if we can harmonize it with Jack in some fashion. Intriguingly, their web framework, which is apparently based on Sinatra, looks an awful lot like the home grown one that I made for Bespin in Python and then duplicated in JavaScript.
I didn’t lump my former SitePen colleague Kris Zyp’s talk in with the other server side JS talks, because Kris was talking a lot more about JS that spans from client to server and using standards such as JSON Path, JSON Query, Persistent JS, and JSON object referencing to move data around seamlessly. Of course, he used Dojo and Persevere as his demo platform, but the ideas he presented can be applied anywhere.
Brian LaRoux’s talk on PhoneGap was quite interesting and entertaining. Brian’s talk had a refreshing lack of gravity, while still providing useful content. For one, he mentioned that Dashcode actually offers good tools for making iPhone web apps. He talked about a variety of iPhone-related JS toolkits, and gave a demo of Nitobi’s iPhone “stimulator” which does a better job of representing how an iPhone app will behave than Apple’s own simulator.
I should note that there were probably 50% fewer bullet points than what I have seen at some other tech conferences I’ve been to. I think the message is sinking in that bullet points suck (except for actual lists of things).
My Mozilla colleague, John Resig gave a wide-ranging talk about JavaScript performance testing, games and his project of the moment, TestSwarm. TestSwarm looks fantastic and fills a gap: it will provide a way to do cross-browser continuous integration tests. People join the test swarm by opening their browser up to the TestSwarm page, and the server will send them test jobs as they come in. So, for example, a revision gets checked into jQuery, and the TestSwarm server will pull out the tests and send them down the wire to a collection of testers who are using different browsers. The results from all of the browsers will come back and get logged. This tool will be useful for a lot more than just jQuery, and John offered help connecting it up with, say, DOH for Dojo’s tests.
Another former SitePen colleague, Pete Higgins gave a Dojo roundup at the very end of the conference. I saw half of his talk before I had to go to the airport. There are lots of good things afoot in Dojo-land. The new conditional compilation stuff seems useful for a variety of things. For example, Dojo can be built in a super-slim variety (6K) that loads everything dynamically. Or you can dump all of the IE compatibility stuff. With the Bespin project, we have a plan to ship a variety of packagings, and I can see this being useful for that as well.
Pete’s Plugd (which he pronounces “plug-dee” as opposed to “plugged”) project provides a bunch of extra convenient ways to use Dojo and I do hope to see that stuff included in 1.4. Pete says that Plugd will likely add 4K to Dojo’s gzipped size, but I think it’s likely worth it.
Malte Ubi likely takes the prize for JSConf attendee who came the longest distance to attend, having flown in all the way from Hamburg, Germany. Malte has been doing some fantastic work on Bespin. Actually, the things he’s been doing go beyond the realm of fantastic and into “crazy”: using Narcissus (JavaScript parser in JavaScript) to read your JavaScript file in a web worker to provide completely client-based outline views and code completion. Awesome.
Malte did a Track B talk on Joose, his JS object system that is built on ideas from Perl’s Moose. It looks like a very powerful system that provides things like type coercion and traits (called roles here) that you don’t find in the type systems that typically come with JS toolkits. If I recall correctly, Joose weighs in at about 16K gzipped, so it’s not a small package.
Nick Carter gave a Track B talk on his JS ORM, JazzRecord It’s a direct descendant of Rails’ ActiveRecord. It looks like a nice enough package, but seeing his samples made me that much more convinced that Atul is right: SQL does not belong in the browser. The sqlite storage engine may very well, but SQL itself does not. TaffyDB, dojo.data, CouchDB, whatever… just as long as the principal form of expression, persistence and querying is JS. The needs of a typical web client are very different from the kinds of things to which we apply SQL on the server. And, even then, people are starting to realize that SQL is not the best tool for every job.
I spoke on Track B about ServerJS. I called the session “a standard library for JavaScript in non-browser contexts”, or something catchy like that, because it is clear that what we’re building applies just as much to command line tools and other kinds of non-browser programs as it does to the server side of web apps.
My talk came immediately after James Duncan spoke about dynamic loading of C code into a SpiderMonkey environment. I lamely brought up ctypes as one approach, but dynamic loading of binaries is not my strength. I suggested that James would get useful feedback for his idea on the ServerJS list, given the number of people who are linking C/C++ libraries up with SpiderMonkey and v8.
As for ServerJS itself, I spoke about the project in general and our biggest milestone to date: the “SecurableModule”. I had a simple “math.js” module with a fibonacci function in it. I picked a lovely O(n^2) function to show the performance difference between Rhino and v8 which is considerable. Since math.js is a “pure JavaScript” module, I was able to demo that module being loaded into: Narwhal on Rhino, Narwhal on k7, Persevere, Helma NG (as a Jack app, no less) and GPSEE. I also demonstrated how with Narwhal/Rhino, I could “forget” to put a “var” in and my variable would not suddenly leak into the global namespace.
I also mentioned that we’re working on binary objects and files and that Jack (the interface) has good prospects given how proven the technique is in Python and Ruby.
I hope that at JSConf 2010, we’ll be able to see some significant apps built on a fairly complete platform.
Conference co-organizer Chris Williams thanked me for my endorsement of the conference, saying that I pushed Mozilla over the edge on sponsoring the conference. I had no idea I had such pull :). Anyhow, Mozilla’s sponsorship apparently had a direct impact on the conference food, which was quite beyond typical conference fare. Thanks to whomever it was at Mozilla who gave the a-ok on this.
As with any conference, the hallway track is among the most important, and I had a good time meeting new people and talking about a range of things. Community-driven conferences do bring in a good collection of people to meet.
I am doubtless leaving people out of this roundup, and I apologize for that. I am sure there are some other JSConf roundups that will provide additional insight. Also, the videos will be showing up online over time, so keep an eye out for that.
JSConf is coming up on Friday, and I’ll be there. I was too late to get a normal “track A” talk in, but I am scheduled in the “track B” room for Saturday at 1:45PM to talk about a standard library for JavaScript development outside of the browser. It’ll be a 30 minute session, and I’m hoping to have some cool stuff to show!
I hope to see you there!
At long last, I’ve released Paver 1.0. Here’s the announcement that I sent to python-announce:
After months of use in production and about two months of public testing for 1.0, Paver 1.0 has been released. The changes between Paver 0.8.1, the most recent stable release, and 1.0 are quite significant. Paver 1.0 is easier, cleaner, less magical and just better all around. The backwards compatibility breaks should be easy enough to work around, are described in DeprecationWarnings and were introduced in 1.0a1 back in January.
Paver’s home page: http://www.blueskyonmars.com/projects/paver/
Paver is a Python-based software project scripting tool along the lines of Make or Rake. It is not designed to handle the dependency tracking requirements of, for example, a C program. It *is* designed to help out with all of your other repetitive tasks (run documentation
generators, moving files about, downloading things), all with the convenience of Python’s syntax and massive library of code.
If you’re developing applications in Python, you get even more… Most public Python projects use distutils or setuptools to create source tarballs for distribution. (Private projects can take advantage of this, too!) Have you ever wanted to generate the docs before building the source distribution? With Paver, you can, trivially. Here’s a complete pavement.py::
from paver.easy import * from paver.setuputils import setup setup( name="MyCoolProject", packages=['mycool'], version="1.0", url="http://www.blueskyonmars.com/", author="Kevin Dangoor", author_email="dangoor@gmail.com" ) @task @needs(['html', "distutils.command.sdist"]) def sdist(): """Generate docs and source distribution.""" pass
With that pavement file, you can just run “paver sdist“, and your docs will be rebuilt automatically before creating the source distribution. It’s also easy to move the generated docs into some other directory (and, of course, you can tell Paver where your docs are stored, if they’re not in the default location.)
The easiest way to get Paver is if you have setuptools_ installed.
easy_install Paver
Without setuptools, it’s still pretty easy. Download the Paver .tgz file from Paver’s Cheeseshop page, untar it and run:
python setup.py install
You can get help from the mailing list.
If you’d like to help out with Paver, you can check the code out from Googlecode:
svn checkout http://paver.googlecode.com/svn/trunk/ paver-read-only
You can also take a look at Paver’s project page on Googlecode.
I’ve just released Paver 1.0b1. This new release adds a fun little feature. A typical setup.py script looks like this:
from distutils.core import setup setup(name="Foo", ...)
With the new version of Paver, you can now rename setup.py to pavement.py (or run paver -f setup.py) and then do:
from paver.setuputils import setup setup(name="Foo", ...)
That gets you going quite quickly, doesn’t it? Of course, you’d likely want to add from paver.easy import * and to start making tasks that take advantage of Paver.
1.0b1 includes some other bug fixes, brings back the call_task function (particularly useful for distutils tasks), and makes the help output more consistent.
There’s one more bug on my list to fix (the distutils output is not showing up), and then I need to rework the docs for Paver 1.0.
Update: It occurred to me a bit later that my example above doesn’t work, because you need to call install_distutils_tasks to get Paver to pick up all of the distutils/setuptools commands. However, this will be fixed in rc1.
I have just released Paver 1.0a3. This has some good refinements on the way to 1.0 final and a couple of nice, new features (the “auto” task and the “pushd” context manager):
Added automatic running of “auto” task. If there’s a task with the name “auto”, it is run automatically. Using this mechanism, you can write code that sets up the options any way you wish, and without using globals at all (because the auto task can be given options as a parameter).
When generating egg_info running “paver”, the full path to the Paver script was getting included in egg-info/SOURCES.txt. This causes installation problems on Windows, at the very least. Paver will now instead place the pavement that is being run in there. This likely has the beneficial side effect of not requiring a MANIFEST.in file just to include the pavement.
the options help provided via the cmdopts decorator now appears
pavements can now refer to __file__ to get their own filename. You can also just declare pavement_file as an argument to your task function, if you wish.
call_pavement now switches directories to the location of the pavement and then switches back when returning
if you try to run a function as a task, you’ll now get a more appropriate and descriptive BuildFailure, rather than an AttributeError
paver can now again run tasks even when there is no pavement present. any task accessible via paver.easy (which now also includes misctasks) will work.
added the pushd context manager (Python 2.5+). This will switch into another directory on the way in and then change back to the old directory on the way out. Suggested by Steve Howe, with the additional suggestion from Juergen Hermann to return the old directory:
<span class="k">with</span> <span class="n">pushd</span><span class="p">(</span><span class="s">'newdirectory'</span><span class="p">)</span> <span class="k">as</span> <span class="n">olddirectory</span><span class="p">:</span><br /> <span class="o">...</span><span class="n">do</span> <span class="n">something</span><span class="o">...</span><br /><br />
The monthly Michigan Python Users Group (MichiPUG) meeting is coming up tomorrow! This month, we’re going to do something a little different: sprinting on a project to help out a new coworking space that is being set up in downtown Ann Arbor (see below for the full description from Bob Kuehne).
As usual, the meeting starts at 7PM at SRT Solutions.
proposal for 03/02/09 - Michigan Python Users Group | Google Groups
background:* a guy named mike kessler is opening a co-working space on main
street, tween washington and huron, in the
old arcadian too space, right next door to (south) vinology. the
space is designed as a place where people
can pop in for a day, hang out, work with other people, get a
permanent desk, host trainings, etc. it’s
going to be pretty cool.* as part of that, he needed some sort of door lock/authentication
system. i volunteered to put one
together, and it’s coming along fine, from the hardware and
software side. it’s basically a bag of
scripts (python, natch), and some csv files for manager users,
logging, whatever. oh, and a door latch
that gets controlled by the above.* but from a ui perspective, i know better things could be done, and
this is where you come in.pug topic/sprint:
* if people are up for it, i’d like to do three things:
* 30m : setup tasks, review / design schema
* 60m : split into groups and build an interactive site to do a few
tasks
* 30m : each group discuss results, demonstrate (10-15m@)
