MWRC Update and Roadmap

1 view
Skip to first unread message

Simon Chiang

unread,
Mar 23, 2009, 1:15:50 PM3/23/09
to Tap Forum
A number of people were interested in Tap at Mountain West Ruby Conf
and I wanted to give newcomers a brief sense of what is what in the
framework. Be sure to look at the hints if you're trying Tap for the
first time.

=== What's good ==============

Overall, the basic Tap functionality is there and working. These are
the main highlights:

* The task syntax appears to work well and should be considered stable
* Workflows work, joins work (but see what's bad)
* Distribution works well

= Roadmap

I am currently:

* increasing usability
* reworking dump/load tasks and building a module of common tasks,
given what I know now about 'best' practices for making workflows
* adding workflow debugging
* building a default web interface for tasks

Before a 1.0 release I want to define APIs a-la Merb, where the
guaranteed public/developer interfaces are specified.

= Hints

* add -d- at the end of a tap/rap invocation to increase debug output
* ArgumentErrors are often due to misformed joins
* when designing tasks, package functionality like they are little
executables
* take a look at the Tap Workflow slides for a primer on joins (http://
www.scribd.com/doc/13054288/Tap-Workflows)
* feel free to post or contact me about any issues

=== What's bad ================

= Syntax Flubs

I've found a number of annoyances in the current workflow schema. For
example merges use parenthesis and curly-brackets. While these have
good symmetry, they also are interpreted on the command line and they
have to be quoted out:

% rap -- a -- b -- c "--2{0,1}"

Yuck. Also bad, the sequence syntax (ex 0:1:2) gets interpreted funny
by YAML and likewise needs to be quoted:

- [a]
- [b]
- [c]
- '0:1:2'

I will be updating the join syntax in workflows sometime in the
future. Some workflows will break as a result, but the breakage will
be soft and easy to fix without updating Task code, for instance.

= Debugging and Recovery

Tasks are easy to test but command line workflows are hard to debug
and often produce cryptic, undocumented errors. ArgumentErrors, for
instance, arise when tasks aren't getting the correct inputs. This
often occurs when joins are messed up. I'm working on a system to
provide more helpful notice when the error is in how a join is
constructed.

When a workflow fails, you'd like to be able to recreate the failed
state, dig around, fix stuff, and resume a run. That's not possible
now but I'm actively working on it.

David Richards

unread,
Mar 23, 2009, 1:52:52 PM3/23/09
to ruby-...@googlegroups.com
Very cool, thank you.  I have an unfinished blog article for a tutorial for Tap.  I'll finish that one of these afternoons and put it up.  I'm still reading through your code, deciding if Tap becomes the compositional model for TeguGears.  We'll see.  Thanks, either way!!

Simon Chiang

unread,
Mar 24, 2009, 1:49:13 AM3/24/09
to ruby-...@googlegroups.com
 I have an unfinished blog article for a tutorial for Tap.  I'll finish that one of these afternoons and put it up.  I'm still reading through your code, deciding if Tap becomes the compositional model for TeguGears.

Awesome, keep me posted.


Reply all
Reply to author
Forward
0 new messages