Wednesday, July 1, 2009

Ants

The first thing to come in a long line of rants about ants.







In fact, here's the code to post it somewhere if you want:

Sunday, June 28, 2009

Development and Design Contracts

I've got a secret and it's kind of embarrassing - I don't normally work with contracts. Ok so I've definitely been in contact with some contracts, just nothing terribly extensive and nothing I've wrote. Today that changes, though, and while there have been times where I've had to learn a lesson or two the hard way the main factor is simply the increase in scope of the projects I've been dealing with. Contingencies are popping up too frequently to ignore, and with the way one job easily breaks down into many sometimes it's hard to know exactly where the onus or responsibility lie for certain aspects of a project. This latest project I speak of involves a number of special issues that need to be addressed ahead of time -

  • The fact that the business this site will serve is in a medical field (which will probably mean very stringent stipulations on how certain kinds of information are handled) may require I ensure a lack of liability if certain standards are not met that I've not been made aware of.
  • The fact that the design and development of this site may result in patents or copyrights and where the ownership of these properties lie, considering that ideas the client and I have had previous to this project somewhat overlap. How will these be managed in the near future? Do competing patents already exist?
  • This project may have the potential to generate publicity. I would like to have my name or my business' name in the mix where possible. I also want to make sure I retain the right to exhibit this work in my portfolio.

With all these things in mind, I got to googling and crawling wikipedia for information about intellectual property, software licenses (to possibly govern the use of software created as a result), and points covered in contracts by either software developers or graphic & web designers.

What I found was nothing less than ...perplexing. Apparently software falls under the protection of both copyright (as literature) and patent - definitely some sort of sign from the universe. Legal precedents also differ from state to state, which encouraged the shift of such matters to a national court, but even at that level there are competing bodies with differing opinions on how to manage these types of patents and whether they should even exist.

This makes the existence of other (somewhat) similar patents sting a bit less.

Anyways, here's a quick rundown of information I found pertaining to design work:

Keeping things I read at these sites and others in mind, as well as certain aspects particular to the project, I came up with the following list of bullet points I'd like to cover in my contract (as well as an example of each) -
  1. Functional definition of project
  2. Retain the right to use in portfolio
  3. Payment regardless of use
  4. Bonuses in penalties as they relate to deadlines
  5. The providing of documentation (from both parties)
  6. Ownership/licensing of copyrights and patents
  7. Procedure for enacting changes to approved designs
  8. Specific number of included (free) changes
  9. Shared-risk pricing scheme
  10. Explicit stating of independent contractor status
  11. Reimbursement of expenses
  12. Limited liability (concerning copyrighted materials and medical guidelines)
  13. Assignment of work - retaining the right to hire other designers
  14. Reservation of rights - retaining all rights to content not explicitly handled in contract (design sketches, class diagrams, notes, etc)
  15. Publication - specifying instances when I should be publicly credited with the work, what kinds of uses should be cleared with myself or the client first, etc

...and a couple of others. Once I feel I've enough reliable examples, I'll begin compiling them into one document which I'll then take to a lawyer to review for it's legality and presentation. So far this all looks pretty good to me but I'm sure there's something I'm leaving out, or at the very least that this will be something I'll speak on again in the future.

Monday, June 15, 2009

Sneak Peak @ new blog design

Blog Design w/ guides
Soon.

Using MonsterDebugger with AsUnit tests

So I've been using two new tools lately to develop my framework - De Monster Debugger and AsUnit. De Monster is a tool that allows for introspection of you running swf through their air front end. All methods and properties are exposed, and can be executed or edited right from their tree interface. You can find it here or watch Lee Brimelow's tutorial about it.

AsUnit is a unit testing framework for actionscript which allows you to run automated test suites on the smallest, indivisible pieces of your code to ensure integrity. In my opinion the real power of unit testing comes from two places - it formalizes the elimination of possible bug causes, (no more sloppy, randomly placed traces or commenting out code), and secondly it's no big deal to run your entire suite of tests every time you compile your swf, so you catch on when bugs in one class effect other classes in ways you didn't expect.

In essence, AsUnit is basically a framework for setting your classes and pieces of code on stilts for further examination, but to achieve this, it's standard practice to encapsulate your classes into the test suites in awkward - yet beneficial (to the unit testing) - ways. Let's examine these.

package com.framework.tests.units {

import asunit.framework.TestSuite;
import com.framework.tests.units.LinkNodeTest;
import com.framework.tests.units.LinkedListTest;

/**
* @author Will Saunders
*
* Unit Test Suite for the framework
*
*/

public class AllTests extends TestSuite {

public function AllTests() {

super();

// Link Node Tests
addTest(new LinkNodeTest("testInstantiated"));
addTest(new LinkNodeTest("testAutoAddChild"));
addTest(new LinkNodeTest("testManualAddChild"));
addTest(new LinkNodeTest("testRemoveChild"));

This is an example TestSuite for AsUnit. Test classes - LinkNodeTest in this case - contain the logic for administering and checking the tests, while TestSuites group all the tests together. If you look closely, however, you'll notice that each of these tests happen independently of one another - one test does not run on the same data objects as the ones before or after because a new instance of LinkNodeTest is established for each test. Furthermore their syntax abstracts the inner parts of the Test classes from us. While this method is mostly always a good thing (for the sake of maintaining granular, "blank slate starts" in the tests), but if you want to look into the tests with Monster Debugger to see what's actually happening or what the data looks like after your tests have run you'll have to jump through a few hoops.

First we will add a lasting reference to the particular instance we'd like to examine more closely. I only set aside one of these at a time and to encourage myself not to get too far away from the point of unit testing. We will also add the necessary classes for the debugger: 

package com.framework.tests.units {

import asunit.framework.TestSuite;
import com.framework.tests.units.LinkNodeTest;
import com.framework.tests.units.LinkedListTest;

import nl.demonsters.debugger.MonsterDebugger;

/**
* @author Will Saunders
*
* Unit Test Suite for the framework
*
*/

public class AllTests extends TestSuite {

public var failedTest:LinkedListTest = new LinkedListTest("testRemoveChild");
public var bugger:MonsterDebugger = new MonsterDebugger( this );

public function AllTests() {

super();

// Link Node Tests
addTest(new LinkNodeTest("testInstantiated"));
addTest(new LinkNodeTest("testAutoAddChild"));
addTest(new LinkNodeTest("testManualAddChild"));
addTest( failedTest );

Now through this reference to the test, we may inspect the inner contents. In the following picture you can see the failedTest reference and the data inside of it :) - AsUnit and DeMonster

Sunday, June 14, 2009

Typecast slip up in with Numbers in As3

I always seem to run into the same problem with Actionscript 3 when typecasting (converting an object from one type to another). It has to do with the use of the as keyword because I've fallen into the habit of doing all typecasting this way - the benefit being that it will fail gracefully and return the default value for the type you're trying to cast to (usually this is a null).

The trickiness comes when I try to typecast something to a number like this:

var testString:String = "77";
trace( testString as Number );
// Traces null

var testNumber:Number = testString as Number;
trace( testNumber );
// Traces 0

This is a problem because this particular syntax will always return a null, which sometimes leads me to spend too much time tracing this down because sometimes I'm writing code that handles null values gracefully. Anyways, the proper way is:

var testString:String = "77";
trace( Number(testString) );
// Traces 77
Because you're actually utilizing conversion functions for Top Level classes like Number, String, Array, which override casting one might do with the Number(object) kind of syntax when using non-top level classes. These can also lead to unexpected results if you aren't careful.

Friday, June 12, 2009

The making of Bjork's Wanderlust

I recently came across this behind the scenes look at the Bjork 3d video, Wanderlust. It's by a group named Encyclopedia Pictura, and it's an amazing feat of multidisciplinary creativity (and mushrooms). Some time last year they gave a talk at Horizons - a conference on psychedelic drugs that I arranged some videography for. They incorporate 3d recording and playback, large scale puppetry, clay, choreography, green screening, and 3d compositing to achieve an amazing texture and visual quality.


Wednesday, June 10, 2009

Images on Jet Propulsion Lab site open for use

I spent some time working on a site design for someone where the theme of space was tossed around a bit. I did some research and found that the Jet Propulsion Labs (a branch of NASA) - perhaps because they're publicly funded or something - allow for the open use of images gathered from satellite and robotics missions. There are a few stipulations, but giving someone a credit line for some amazing images seems like a more than fair price to pay. They even have a nice little flex gallery for browsing their collection and offer both high rez Jpgs and Tiffs.



I'm pretty sure that - within these stipulations - an artist would even be able to use these images as source material to photoshop to their hearts content, but rather than give you incorrect legal information here I'll just direct you over to the JPL's Image Use Policy so you can see for yourself :)