Manage all your tasks with TaskWarrior Paul ‘@pjf’ Fenwick
- Lots of task management software out there
- Tried lots
- Doesn’t like proprietary ones, but unable to add features he wants
- Likes command line
- Disclaimer: “Most systems do not work for most people”
- TaskWarrior
- Lots of features
- Learning cliff
Intro to TaskWarrior
- Command line
- Simple level can be just a todo list
- Can add tags
- unstructured many to many
- Added just put putting “+whatever” on command
- Great for searching
- Can put all people or all types of jobs togeather
- Meta Tags
- Automatic date related (eg due this week or today)
- Project
- A bunch of tasks
- Can be strung togeather
- eg Travel project, projects for each trip inside them
- Contexts (show only some projects and tasks)
- Work tasks
- Tasks for just a client
- Home stuff
- Annotation (Taking notes)
- $ task 31 annotate “extra stuff”
- has an auto timestamp
- show by default, or just show a count of them
- Tasks associated with dates
- “wait”
- Don’t show task until a date (approx)
- Hid a task for an amount of time
- Scheduled tasks urgency boasted at specific date
- Until
- delete a task after a certain date
- Relative to other tasks
- eg book flights 30 days before a conference
- good for scripting, create a whole bunch of related tasks for a project
- due dates
- All sorts of things give (see above) gives tasks higher priority
- Tasks can be manually changed
- Tools and plugins
- Taskopen – Opens resources in annotations (eg website, editor)
- Working with others
- Bugworrier – interfaces with github trello, gmail, jira, trac, bugzilla and lots of things
- Lots of settings
- Keeps all in sync
- Lots of extra stuff
- Paul updates his shell prompt to remind him things are busy
- Also has
- Graphical reports: burndown, calendar
- Hooks: Eg hooks to run all sort of stuff
- Online Sync
- Android client
- Web client
- Reminder it has a steep learning curve.
Love thy future self: making your systems ops-friendly Matt Palmer
- Instrumentation
- Instrumenting incoming requests
- Count of the total number of requests (broken down by requestor)
- Count of reponses (broken down by request/error)
- How long it took (broken down by sucess/errors
- How many right now
- Get number of in-progress requests, average time etc
- Instrumenting outgoing requests
- For each downstream component
- Number of request sent
- how many reponses we’ve received (broken down by success/err)
- How long it too to get the response (broken down by request/ error)
- How many right now
- Gives you
- incoming/outgoing ratio
- error rate = problem is downstream
- Logs
- Logs cost tends to be more than instrumentation
- Three Log priorities
- Error
- Need a full stack trace
- Add info don’t replace it
- Capture all the relivant variables
- Structure
- Information
- Startup messages
- Basic request info
- Sampling
- Debug
- printf debugging at webcale
- tag with module/method
- unique id for each request
- late-bind log data if possible.
- Allow selective activation at runtime (feature flag, special url, signals)
- Summary
- Visbility required
- Fault isolation
- Error
