Why I Still Refuse To Use Pixelmator Part II

Observations — Tags: , , — Ardekantur @ 9:39 pm

Pixelmator’s lasso tool is all or nothing. That is to say, if you wish to select something with it, you must hold down your mouse button the entirety of the time you are making your selection. This makes it impossible to do anything but the most basic of selections. Nothing refined or nuanced. This is extremely frustrating.

Taskomaly Keeps Chugging Along

Code Projects — Tags: , — Ardekantur @ 12:26 pm

Straight from the readme:

you need to clean your room

make it a project

 proj = Taskomaly::Project.new 'Room Cleaning'

add some tasks to it

 proj.add 'put away clean laundry'
 proj.add 'wash dirty dishes'

tag those suckas up

 proj.add 'file taxes @april @15'
 proj.tasks.last.tags                   # [:april, :"15"]
 
 proj.add 'organize shelf'
 proj.tasks.last.tag :knickknacks, 1000, 'september'
 proj.tasks.last.tags                   # [:knickknacks, :"1000", :september]

EDIT As usual, I omit all the pertinent information. You can see the code here and attempt to install the gem with instructions from my previous blog entry.

Taskomaly is a Gem

Code Projects — Tags: , , , — Ardekantur @ 5:59 pm

GitHub is awesome:

$ gem sources -a http://gems.github.com
$ sudo gem install ardekantur-taskomaly

Please to be enjoying.

Tasko/TaskPaper + Ruby = Awesome

This is the first release of an evolving library that interacts with the online todo-list thingie Tasko. If you’ve never heard of it, or its brother-in-spirit TaskPaper, you’re in for a treat.

Plain text files, converted to To Do lists with simple formatting rules. Lines that end with a colon are project names. Lines with a hyphen starting them are tasks. Use tags on lines to categorize them. @today, @home, whatever. Tag a line @done to cross it out. Simple!

Taskpaper Screen

So now we have Taskomaly, which works on your local machine, interacts with task lists, and can upload them to Tasko using its API. Tasko provides both an API key and a user ID when you register. You need both of these things. Register, then go to your settings page to retrieve them. I suggest placing them in a file in YAML format, like so:

  user: 9999
  key: d9cca721a735dac4efe709e0f3518373

Then, off to irb!

  t = Taskomaly::From '~/.tasks.yml'

Now, get the information you want. Your papers! Make a change, then save them back to the website.

  t.request :papers # ['Paper One', 'Paper Two']
  p = t.papers.first
 
  puts p.name # 'Paper One'
  puts p.body # duh
 
  p.body["@today"] = "@tomorrow"
  p.save # true if groovy, false if failed

This is the first real project I’ve put a huge emphasis on TDD, guided along by the simple principles espoused by Adam Wiggins during his work with the rush shell.

So, yeah. That’s that. Work (and specs) are coming along soon to help you with individual projects inside task papers, searching and using tags, and all kinds of other fun stuff.

EDIT Jesus I forgot to put a link to the project. Here it is. On GitHub. Duh.

“TDD”.reverse

Stagger in disbelief if you’d like, but I’ve found an instance where it is more beneficial to not begin testing a piece of software until a measurable way through its development.

You no doubt remember my fabulous, in-development command-line NewsGator client, bulletin. I’ve extracted the NewsGator-specific code to a gem called WonderCroc. The README provides a small glimpse of what’s possible with the library now:

wondercroc

A gem that provides…

In any event, I haven’t written any tests for it yet. A lot of the initial programming was screwing around with Ruby’s RSS parser and running requests through in IRB. At this point, however, I’d like to start throwing specs at it as I refactor it and extend it to become a modular library.

So what?

Well, here’s the thing. I want to know that the library responds correctly to the XML responses sent by NewsGator’s server. I assume the correct way to test this is to mock the responses accurately. The NewsGator REST API documentation provides several partial samples, but they’re not complete or complex enough to give me a full range of parsing opportunities. So why not use actual responses?

So that’s my plan. Extend my WonderCroc::Client class to log the XML responses to a file, and use those in my mocks — something I can’t think of a good way to do if I hadn’t written the code in the first place.

Thoughts?

« Previous PageNext Page »
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
(c) 2008 Ardekantur | powered by WordPress with Barecity