Tempo API Update 18-FEB-09

2009-02-17 19:00:00 -0500

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"?>
<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>
<exclude-tags type="array">

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:

  • today
  • yesterday
  • thisweek
  • lastweek
  • last7days
  • thismonth
  • lastmonth
  • thisquarter
  • lastquarter
  • thisyear
  • lastyear
  • alltime

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:

<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>

Process and Execution

2009-02-16 19:00:00 -0500

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.

Hey, Look

2009-02-15 19:00:00 -0500

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.

Uncertainty is a Virtue

2009-02-11 19:00:00 -0500

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:

Vision & Execution

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.

Implementing asmSelect in Oracle APEX

2009-02-11 19:00:00 -0500

I’ve been a big fan of jQuery for some time now, and one of my favorite plug-ins is Ryan Cramer’s asmSelect, which is a really cool alternative implementation of a multiple select control. There’s no swing tables, there’s no explaining to users how they need to hold down control (or command for mac users) while they click their desired options. There’s just a nice manageable list, to which you add selections using a drop down. There’s a nice example here, if you’re unfamiliar with this interface.

In any event, some of our clients were not really digging the Shuttle control available in Oracle’s Application Express. “Shuttle” is really just a pair of swing tables. So I figured, “why not set those back to normal select[multiple] elements and run the asmSelect plugin?” However, it wasn’t that easy, so I’ve written up how to get it going. I’m working in APEX 3.1.2, if you decide to follow along.

First you need to make sure you’ve got the select element set to multiple in the interface:

Apex Select Multiple Item

Next, add the needed jQuery libs to your application. There are a number of ways to do this, but since I’m not going for anything fancy, I went with the latest version of jQuery (1.3), the latest version of the asmSelect plugin, the included CSS, and avoiding any jQuery UI animation options:

  • jquery-1.3.1.min.js
  • jquery.asmselect.js
  • jquery.asmselect.css
  • jquery.noconflict.js

That last one is actually a quick little file I threw together to allow for jquery to be compatible with apex’s built-in use of prototype:

/ jquery no-conflict script, sets $() function to $j() /var $j = jQuery.noConflict();

Not much to it, pretty standard.

I attached them to the application itself (Shared Components → Static Files → Create, then select your app for the association). Once they are uploaded, you need to link them in from your page template. Head over to Shared Components → Templates and select your default page template for editing. You can jam this into the head section of the document template:

<link rel="stylesheet" href="#APP_IMAGES#jquery.asmselect.css" type="text/css" />
<script src="#APP_IMAGES#jquery-1.3.1.min.js" type="text/javascript"></script>
<script src="#APP_IMAGES#jquery.asmselect.js" type="text/javascript"></script>
<script src="#APP_IMAGES#jquery.noconflict.js" type="text/javascript"></script>

These statements will include the javascript and css files we uploaded into our app as static files. Below these, in the header template (or in the html header area of a specific page), we can add a script block and some code to activate the asmSelect plugin on every select[multiple] on our page:

<script type="text/javascript">
$j(document).ready(function() {
// wire up the select multiples to be asmSelects
$j("select[multiple]").asmSelect({ });

At this point, if you reload your application page, having saved your changes and such and there are no errors in the setup, you’ll see:

  1. the original select show up and quickly disappear (asmSelect hides it)
  2. the new asmSelect element

However, if you attempt to submit your form, it will explode on you. You’ll get a pretty heinous 404 error message saying that the page couldn’t be found. What’s happening here?

Not Found
The requested URL /pls/apex/wwv_flow.accept was not found on this server.

Oracle-Application-Server-10g/ Oracle-HTTP-Server Server at apex.example.com Port 80

APEX is at heart a set of complex stored procedures made accessible over the web via mod_plsql running in Apache. If you’ve ever written a stored procedure for mod_plsql (htp.prn and all that), you’ve probably run into this problem before: if you send any params that the procedure doesn’t expect, mod_plsql will bomb out with a 404 error.

What’s happening to us here is that by using asmSelect we’ve added a parameter that’s not being expected by APEX. Every form element on the apex page matches an ITEM that you created on the page (like P1_PRODUCT_TYPE above). In this case, asmSelect hides the element represented by P1_PRODUCT_TYPE and drops select#asmSelect0 right next to it in the DOM.

So what do we do?

What can be added to the DOM can be taken away!

I tried faking out APEX by creating a corresponding page-level item with the same name and that didn’t work, so I just moved on to the next obvious thing: remove the asmSelect element when the form’s submit element fires. Here’s how I first tried it:

<script type="text/javascript">
$j(document).ready(function() {
// wire up the select multiples to be asmSelects
$j("select[multiple]").asmSelect({ });
$j("#wwvFormFlow").submit(function() {

That didn’t quite work out, because APEX already has its own ideas about the form’s submit event. And honestly, I don’t really want to mess with APEX, I just want to work around it. So I decided on another trick we worked out some time ago, intercepting the submit event and then letting APEX do its thing afterward:

<script type="text/javascript">
$j(document).ready(function() {
// wire up the select multiples to be asmSelects
$j("select[multiple]").asmSelect({ });

// subordinate the submit function in apex so we can supplant it
function submitOverride(event) {
// remove the asmSelects from the DOM so they don't mess up submitted params

// execute the original submit
document.wwv_flow._submit = document.wwv_flow.submit;
document.wwv_flow.submit = submitOverride;


This really did the trick, removing the asmSelect right after submit fires, sending up the correct form elements. And since asmSelect manages the original selection list as your are making changes, the selected items are preserved.

For one last bit of finesse, hide the original select element (in our case the item P1_PRODUCT_TYPE) on page load by setting style="display:none;" on the element, which makes your page load a bit smoother:

Apex hide selected item

Works like a charm!

Salesperson Criteria