06.04.09
Posted in Flex, Programming at 9:42 am by Justin
In a current project of mine, I needed to capture when a user clicks on a DataGrid header to sort it (to track the column and sort order). The only good event to listen to is “headerRelease”. However, if you just add a declarative event listener to the DataGrid, you’ll find in your handler the sort hasn’t been applied yet. This is because your handler will complete before the sort ever takes place, due to DataGrid adding its own handler for the event with a priority of -50.
In order for DataGrid’s handler to complete so that the sort will be applied for your handler, you’ll need to add your handler with a lower priority:
dataGrid.addEventListener( DataGridEvent.HEADER_RELEASE, dataGridHeaderReleaseHandler, false, -100 );
I chose to use -100 in this instance. If you check out the class EventPriority, you’ll find where DataGrid’s -50 is defined (this is the value used for all internal handlers of Flex core components), along with some other priorities used for core Flex components such as Effects, Binding and CursorManager.
Depending on your scenario, you may want to always add your handlers at a lower priority than the component’s internal handlers, unless there’s a chance you need to call “preventDefault()” in order to stop the component from performing default behavior.
Permalink
05.21.09
Posted in Flex, Programming at 11:05 am by Justin
Suppose for some reason you have an ArrayCollection that will contain a set of Strings that you want to have sorted. Then, you’d like to add an entry to the beginning and another at the end, but you don’t necessarily want the sort to apply.
var collection:ArrayCollection = new ArrayCollection([”a”,”z”,”m”]);
collection.sort = new Sort();
collection.refresh();
collection.source = collection.toArray();
collection.sort = null;
collection.refresh();
collection.addItemAt( “first”, 0 );
collection.addItem( “last” )
The key above is the line:
collection.source = collection.toArray();
This “locks” the sort by creating an Array in the order you want, rather than simply returning the elements sorted as you use the collection. If you don’t do this, when you remove the sort and refresh(), your collection will revert to its original order. Also be sure to call refresh() after you remove the sort or you’ll run into strange errors trying to add more items.
Permalink
10.29.08
Posted in Uncategorized at 12:10 pm by Justin
Evidently, squirrels hate Boulevard. Who knew?
Permalink
10.25.08
Posted in Uncategorized at 3:49 pm by Justin
Well, it didn’t turn out as well as I would have liked, however it turned out better than I thought I was capable of. 
Unlit:
Lit (with our black cat Poco behind):
Permalink
09.07.08
Posted in Home Repair at 3:19 pm by Justin
Oh the joys of owning a house! $18 more dollars I wouldn’t have had to spend had I lived in an apartment!
Anyway, the washer was draining too fast, and thus overflowing the drain pipe. I found a good solution at FixItNow.com, which includes draining directly into one fork of a y-pipe, and extending the other fork much higher in the air as a “surge” pipe. Tried it out; works like a charm. I made the surge pipe higher than it needed to be (by about 1 foot), but it helps as the water being drained tends to come out at fairly high pressure, and since it’s now entering at an angle it tends to splash a bit.
I also ended up needing more parts than were necessary due to the hardware store not having everything. The y-pipe is 2ʺ at both vertical ends, and the fork is 1-1/2ʺ. The hardware store didn’t have a 1-1/2ʺ to 1ʺ threaded reducer (the washer drain hose is 1ʺ), only a 1-1/2ʺ to 1-1/4ʺ threaded, so I also had to buy a 1-1/4ʺ threaded to 1ʺ threaded to screw the hose adapter in.
Poor pictures taken with my cell phone below:
Permalink
07.29.08
Posted in Programming, Ruby at 9:40 am by Justin
We recently upgraded from rubygems 0.9.x to 1.2.0. Unfortunately, there doesn’t appear to be a working service init script for this new version, so I had to hand-craft a basic one to start/stop the service. You’ll find it below in all its glory (and probably under/incorrectly-implemented as I am in no way a linux guru, nor do I intend to be). It works for my use however, maybe it’ll help you.
#!/bin/bash
# chkconfig: 2345 20 80
# description: gem server
# processname: gem_server
# pidfile: /var/lock/subsys/gem_server
source /etc/rc.d/init.d/functions
prog=”/usr/local/bin/gem server –daemon”
start() {
pid=$(ps ax -o pid,command | grep “gem server” | grep daemon | awk ‘{print $1}’)
if test -n “$pid”
then
echo “gem server already running : PID $pid”
else
$prog
fi
}
stop() {
pid=$(ps ax -o pid,command | grep “gem server” | grep daemon | awk ‘{print $1}’)
if test -n “$pid”
then
echo “stopping gem server”
kill $pid
else
echo “gem server not running”
fi
}
case “$1″ in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo $”Usage: $0 {start|stop|restart}”
exit 1
esac
Permalink
10.09.07
Posted in Flex, Programming at 1:57 pm by Justin
If you’ve done much in flex, you may have used the “…” notation in a method signature to indicate that the function takes a dynamic number of arguments, such as:
private function doIt( ...args ):void
… then called the method:
doIt( 1 )
doIt( 1, 2 )
doIt( "some", "other", "stuff" )
The question is this: from within that method, how do you send those same arguments on to another method that accepts a dynamic argument array? You can’t just pass the “args” array, as the method called will only see 1 argument; the array you passed it. Instead, you need to “explode” the array into its’ original parts. Here’s the most simple way I’ve found to forward that array on to the next method:
public function doIt( ...args ):void
{
var someObject:SomeType = new SomeType()
someObject.someMethod.apply( someObject, args );
}
The “apply” method of Function does exactly what we need. Now “someMethod” will have it’s own argument array, and be able to access them the same way you were able to from within “doIt”.
This all came about when we began writing a wrapper of sorts for WebServices. We created our own RPC class, with a “call” method that accepts the parameters, and we needed to forward them on to Operation’s “send” method. Below is a much simplified example:
import mx.rpc.soap.Operation;
public class RPC
{
public static function call( operation, ...params ):void
{
//...code to initialize WebService "svc"
var op:Operation = Operation( svc.getOperation(operation) );
//...more code (unimportant)
var token:AsyncToken = op.send.apply( op, params );
//...code to hook up handlers
}
}
Permalink
09.28.07
Posted in Programming, Ruby at 8:07 pm by Justin
Math in programming just generally sucks. I come from a mainly Java background, and recently I’ve been using Ruby. But in both cases, the statement holds true. I know this isn’t really a new problem, but for god’s sake, it’s 2007; why is it still a problem?
Using Ruby, let’s suppose we have a simple math problem… and we want to check equality:
1.2 + 1.0 == 2.2 (returns true)
Yay, it’s correct! But that’s not really much to ask of a language is it now. Let’s switch it up just a little bit:
1.2 - 1.0 == 0.2 (returns false)
Uhh… Ruby? You OK? I really don’t understand how this is acceptable. I know the argument that we generally work and think in a base10 system, while computers generally store numbers in binary, and there’s no exact way to store many numbers. But shouldn’t that be fixed (and by fixed, I mean an easy way provided for us to perform exact base10 math), assuming once again, we generally work in base10? i.e. when I subtract 1 from 1.2, shouldn’t I get exactly 0.2?
Anyway, if you do a little research, you’ll find that BigDecimal is supposedly much more accurate when performing calculations, so let’s try that:
require 'bigdecimal'
BigDecimal.new('1.2') - BigDecimal.new('1') ==
BigDecimal.new('0.2') (returns true)
Yay, it worked! …but who wants to type ‘BigDecimal.new’ a thousand times? Dig a little further and you’ll find a BigDecimal utility, which adds functionality to other Ruby Numeric classes to convert them to BigDecimals:
require 'bigdecimal'
require 'bigdecimal/util'
1.2.to_d - 1.0.to_d == 0.2.to_d (returns true)
Still works, and it’s definitely cleaner, but remembering to append ‘.to_d’ may be somewhat of a pain (and unnecessarily ugly.) The innaccuracy of Float can still bite you, however; check this out:
require 'bigdecimal'
require 'bigdecimal/util'
x = 1.2000000000000000001.to_d
puts x.to_s('F') (prints 1.2)
Yep, our 1 in the 1/1000000000000000000th place at the end is lost. This is probably because BigDecimal is aware of the innaccuracy of Float, and since that was of such small value, it assumed it was just a precision issue and is dropped. Frustrating!
Another issue for us might be that using BigDecimal in place of Float probably has more overhead; I don’t personally have any benchmarks to compare the two. But, then again, I don’t really need them. For me, being precise far outweighs it being fast (to a point of course). If I was performing some super-intensive process, that did crazy math, and as a result I only needed an answer that was pretty close but not exact, I’d probably give Float a chance. But until then, it’s BigDecimal for me, despite it not being the easist/cleanest/prettiest solution.
At any rate, I can live (for now) with implementing BigDecimal in this way (or ‘new’ing them up when appropriate.) But if you happen to use ActionWebService in Rails, you have another problem. Currently (as of version 1.2.3), when you define your API, and use the :float datatype, you’ll find this does in fact use Float to convey numbers. Dig a little, and you’ll find that in their SVN repository they may be working on changing this to use BigDecimal instead. One can only hope!
A coworker and I attempted to dig in and try to convert it ourselves for use in a current project, but that attempt was fairly short-lived, and we instead use the “.to_d” method above to convert them to BigDecimals once inside the service method. This works for us, since we’re generally dealing with dollar amounts that aren’t terribly huge, so we’re only concerned with accuracy to the penny.
I fully intend, at some point, to revisit this issue and perhaps instead of replacing :float to use BigDecimal, using :decimal or :bigdecimal, thus leaving the ability to use Float if so desired. Hopefully by the time I get to it, they’ll release a new version with it already implemented. I can dream can’t I?
Permalink