“I’m not a businessman, I’m a business, man!”
“I’m not a businessman, I’m a business, man!”
We’re going to push out a couple of changes to the Tempo API tonight at 10pm EST. Last night we found a small bug that prompted us to address a pair of issues, and update our documentation:
A type attribute will be required for multi-value params in context search:
The /entries/search end-point allows you to post an XML document that we call a context. It’s a lot like the Tempo reporting interface, it allows you to specify a set of parameters and it will return the corresponding entries if the request is well-formed.
Certain parameters that you can send up in a context document are multi-valued and must be presented within a type=“array” set. These are tags, project-ids, user-ids, and exclude-tags. Here’s an example:
<?xml version="1.0" encoding="UTF-8"?>
<context>
<interval>lastmonth</interval>
<project-ids type="array">
<project-id type="integer">1024</project-id>
<project-id type="integer">2048</project-id>
<project-id type="integer">8192</project-id>
</project-ids>
<exclude-tags type="array">
<exclude-tag>discovery</exclude-tag>
<exclude-tag>internal</exclude-tag>
</exclude-tags>
</context>
This has actually always been the case, but our documentation did not reflect this.
The interval parameter will be supported in context search:
As shown the example above, you can use an interval shortcut string to avoid having to specify start-date and end-date. The list of currently available intervals is:
XML output includes type attribute hints:
For all non-string data in output from our XML API, a type attribute has been re-introduced. This shouldn’t break anybody’s compatibility with the API, as we haven’t had any attributes present in the past for you to look up, but please get in touch if you think this will be a problem for you. This is an example of what that looks like:
<entry>
<command nil="true" />
<created-at type="datetime">2008-03-31T15:06:46-04:00</created-at>
<creator-id type="integer">2048</creator-id>
<hours type="decimal">5.0</hours>
<id type="integer">8192</id>
<is-locked type="boolean">true</is-locked>
<is-timing type="boolean">false</is-timing>
<notes>client meeting in NYC to discuss project requirements</notes>
...
</entry>
As I wrote last week, I’m really interested in any piece of reading where artists discuss methods of process, or simply getting around to doing their work. Most of the challenge is actually sitting down and setting about doing what you intend without knowing how it’s going to turn out necessarily, and being okay with that.
That’s not quite how it works in programming, but sometimes it is! Sometimes here at Zetetic we set out to find a way to do something without knowing what we’ll find. In fact, new challenges and new ideas always push you in this direction, so it happens pretty often, and like sitting down to create something in the context of art (wherein you see yourself, maybe, as an “artist” or a “poet”), you have to be okay with not knowing exactly how it’s going to turn out, and trusting yourself to make decisions as you create.
There’s an article on the 37Signals blog today, titled, “The moment of truth is a real audience,” and here you find where the lines of art and entertainment cross-over in ways that are challenging to deal with for the artist, but it’s very straight forward for someone who sees himself as an entertainer, a producer, or a manufacturer of software. The article quotes playwright Matt Hart:
[Fellow playwright George S.] Kaufman did not hold with the theory or the practice of having run-throughs for his friends or friends of the cast, or even for people whose judgment he respected and trusted. He held firmly to the idea that no one person or collection of persons, no matter how wise in the ways of the theatre, could ever be as sound in their reactions as a regulation audience that had planked down their money at the box-office window, and in the main I think he was correct.
For the artist, acceptance and understanding of his work is not always in the bag, and the understandable fear of a lack of understanding or acceptance can be debilitating (whether the artist has ever gone out on that limb or not!) For the programmer, I think things are a lot simpler: you made something that does what you intended it to do, or you didn’t. It’s useful to people, or it’s not. But it’s still pretty disappointing when your software fails to gain wide appeal, when it doesn’t quite make the cut of your intended audience.
So, I think the trial by fire of a paying audience is a good thing. Even if you don’t get the acceptance and the understanding you hoped for. Maybe people aren’t ready for your cool idea, or maybe you need to build on your means of expression. YET, I think it’s crucial here to understand that with art, you can perfect your means and reach all your goals and never get critical acceptance, and you can’t expect to. I wonder if you can’t expect to with software either?
Speaking of trial-by-fire, great progress continues with Strip for the iPhone and we should be ready to beta the application very soon. Have you signed up for the beta mailing list? Scroll to the bottom of this page if you haven’t, and sign up! We’ll announce details on beta participation there within the next couple of weeks.
Palm appears to be making a real effort to re-establish the developer base for their platform. While I’m a skeptic, webOS is a pretty cool idea for an application development platform. Remains to be seen how well it works, and if the trade-off for ease of development is the capability of applications. I’d bet good money that it will be a lot easier to develop applications for webOS than it is for iPhone OS, but I’d also bet that you won’t be able to pull off some of the low-level graphics processing that enables cool games and animations.
The first chapter of an O’Reilly book on developing for the OS is up on the developer site, and it’s being written by the lead architect. Wouldn’t it be great if the API and documentation were up? I’m guessing that means it’s still under heavy revision.
Lately my subway-reading materials seem to broadly spin around what it means to be an artist, and processes, and what’s involved in actually setting about the doing of your work, the making of your art. I crunched through Haruki Murakami’s memoir What I Talk About When I Talk About Running so quickly that I think I need to read it again (I’m looking forward to it, and I rarely re-read books), and I’ve since moved on to Art & Fear by David Bayles and Ted Orland. This is a particularly interesting subject for me as a song-writer and a programmer, although for really different (and probably obvious) reasons that I’m not going to go into right now, save to pull some choice quotes that I’ve found to be really profound.
This one is from Art & Fear:
More often, though, fears rise in those entirely appropriate (and frequently recurring) moments when vision races ahead of execution. Consider the story of the young student – well, David Bayles, to be exact – who began piano studies with a Master. After a few months’ practice, David lamented to his teacher, “But I can hear the music so much better in my head than I can get out of my fingers.”To which the Master replied, “What makes you think that ever changes?”
That’s why they’re called Masters. When he raised David’s discovery from an expression of self-doubt to a simple observation of reality, uncertainty became an asset. Lessn for the day: vision is always ahead of execution — and it should be. Vision, Uncertainty, and Knowledge of Materials are inevitabilities that all artists must acknowledge and learn from: vision is always ahead of execution, knowledge of materials is your contact with reality, and uncertainty is a virtue.