Archive for the 'Uncategorized' Category

In the past, I’ve blogged many times about my ObjectHandles library, and today I’m starting an experiment in generating some revenue for it.

There is now a new web page at http://object-handles-examples.appspot.com/ that has 7 example applications intended as either a training resource, or as a starting point for more complex applications.  I’m charging a fee for the source code to those examples.  The fee is whatever you decide to pay (with a $15 minimum)

The more revenue that this generates, the more motivation I’ll have to spend time working on the core library and additional examples.

The core library will continue to remain free and under the MIT license.  It can always be downloaded from http://code.google.com/p/flex-object-handles/

There were a few reasons for me to do this including:

1. My motivation to work on the library has been very low lately.  I don’t have any current projects that are using it.
2. The donations link that I have has received a total of 3 donations over 2 and a half years.
3. By working on these examples, I was able to really exercise some of the core functionality.  While doing this I was able to

• Completely revamp the constraints mechanism and implement things like an Aspect Ratio constraint
• Find and fix a handful of bugs
• Figure out the answers to some questions others have asked that I just didn’t know the answer to
• Make several big performance improvements

P.S.  This gave me a chance to create a real site in Python/Django/Google App Engine for the first time, and I’m impressed.

Daniel McQuillen from www.simplediagrams.com emailed me last week to let me know about their use of ObjectHandles in the SimpleDiagrams product.  It’s an AIR application that lets you create chalkboard style diagrams in just a couple seconds.  It’s sort of Visio for people who need to get stuff done instead of diagram all day long.  I gave it a quick 10 minute try, and this might be an app I add to my arsenal of tools.

Daniel has been kind enough to offer me a small percentage of their sales as a thank-you for the ObjectHandles library.  It’s MIT Licensed, so he didn’t have to do that, but I’d like to send a big thank-you to him for that.  That’s a great way to support open source projects.

I’ve been playing around with a few things in ObjectHandles today. The first is multiple-selection. Last week Vlad Janvarev sent me a patch that got it working for non-rotated objects. I put that in, and spent most of my day today figuring out how to extend it to rotated objects as well (dealing with 3 coordinate spaces at once makes my head hurt!). To try it, press the shift key and select multiple objects on the screen, then you can move, rotate or resize them as a whole.

View-Source is enabled in it.

It’s not working 100%, and I’m not sure why. If anyone has any ideas, let me know. The broken part is if you rotate 2 objects, then select them both, then resize them really small. At some point they sometimes start getting bigger instead of smaller depending on the rotation. I’m baffled.

The second thing I played with is the idea of “Decorators” that can draw interesting info based on the state of the set of objects either being moved or currently selected. There’s a quick screenshot of a sample one I did below.

This is also in the link above under “Example 8″. This is just a proof of concept for now. If you want to try it, do it before trying the multi-select since the multi-select can leave objects on fractional pixel boundries which won’t line up perfectly.

Neither of these is ready for prime-time yet. The multi-select stuff is creating tons and tons of temporary objects so the GC kicks in periodically freezing the interface. That’ll need a little optimization.

Today, I’ve been experimenting with project structure and workflows.  I’ve got two major problems I want to solve.

Problem #1

When working in Flex Builder, if you have a lot of non-embedded assets, it can go really slow.  At seemingly random times Eclipse will decide it needs to delete all of your output files and re-copy them.  For our current project, that can take 10 minutes.  We have yet to figure out what triggers this behavior.

Problem #2

When working in Flex builder, if you have a lot of embedded assets, it can go really slow.  Especially on clean builds, or builds that touch a lot of modules.  This is an every-compile type thing, but is far less severe than problem #1.

Solution for Problem #1

Don’t let Eclipse do the copying for you.  Put your assets outside of your source tree, and turn off “Copy non-embedded assets”.  To the right is an example directory structure.  There are a few differences than most Flex/Flash builder projects.

1. My assets folder is a sibling of my src folder, instead of inside it.
2. My compiler is set to output to assets/bin-debug instead of just bin-debug

In your source, you’ll have to link to your assets a little bit differently.  Here’s an example from my TestProject.mxml that shows both an embedded and a runtime loaded asset.

Since the embed is relative to the source folder, we need to use paths in the form of ../assets/art/*

The runtime loaded assets are relative to the final compiled location, so those take the form ../art/*

Now, eclipse will never try to manage your assets.  This appears to completely solve problem #1.

Solution for Problem #2

A while back I blogged about turning a Flash Catalyst project into a .swc.  (Read that here)

I dusted off my script and tried it with the Beta-2 of Flash Builder and Catalyst.  And low-and-behold it worked without any changes.  The only thing I had to do was reset my FLEX_HOME environment variable to the new location.

So, if we were to move away from a model where we embed assets from designers into Flash Builder, and to a model where the Designer puts those assets into Catalyst, and then we run a script to compile the catalyst project into a .swc, I think that would completely solve problem #2.

A couple posts back I blogged about playing around with an Arduino.  Since then I’ve completed my first project, a Build Notification Board for work. It sits in my office window facing the main part of our office building.

At work, whenever a developer submits a change to a project we automatically make a build to make sure nothing goes wrong.  This board gives us the current status of four different automated builds that happen on those cruise control servers.  The green light indicates that the last build was successful (it switches to red if it failed).  The blue light lets us know if it’s currently building (it does a nice pulsing fade in/out).

On any failure, a flag is also risen from the top of the board.

There’s two meters at the top.  The first one shows an overall project completion (that’s manually entered by me right now).  The other one shows “communication density”.  Right now, it’s a random value that ticks up and down.  Eventually it’ll represent the volume of traffic on our project mailing lists.

The top gauge looks like this (The 0-180 scale is a bit of an internal joks that any fellow TSP employee would get):

The electronics are fairly simple.  4 pins of the arduino control the red/green lights.  4 pins control the blue lights.  One of them controls a servo that raises/lowers the flag, and two pins are for the two meters.

Besides that I have a switch on the back that activates “demo mode” that does some pretty flashing lights and raises the flag.  There are a couple status indicator lights that tell how the board is functioning back there as well.

The meters are 1970’s era amp-meters in the micro-amp range that I opened up and replaced the background label with customized print outs.  I was suprised to see that a simple resistor and PWM signal could control them accurately.  I was thinking I’d need a capactitor in there to even out the current.

Here’s the back of the board.  Normally, there is a panel that covers all this to make it look less like a fire hazard.  At the top you can see one of the meters.  Next to that is a small protoboard that the status lights, demo-switch and flag-servo are all soldered into.

If you follow the green wires down from there you’ll come to my Arduino board which is actually a lower-cost Seeduino that I bought so I could continue playing with my arduino for other projects.  One nice thing about the Seeduino is you can solder connectors directly to it.  I’ve got 2 8-pin connectors attached to it that connect all the lines I needed to the proto board below it through those rainbow-wires.  That second proto-board has the resistors for the blue lights and the connections for all of the lights on it.

To the left of all that is a structure that holds all of the lights, the lenses, and some dividers between the lights.  To control two lights with a single pin it was easier for me to put those resistors closer to the LEDs so that’s what you see there.

The black wire from the Seeduino to the foreground is a USB cable providing power and status updates.   On the computer it’s attached to there is an AIR application that queries status info from our cruise control servers and relays it to a program running on the seeduino.