Ben Hughes

In the FlexBuilder IDE using javadoc-style comments (/** …… */ ) behaves as it does for Java, but there’s nowhere in the FlexBuilder settings to specify that documentation should be produced. After a little investigation, it seems that ASDoc is a command line tool that has not yet been integrated with FlexBuilder.

Viewing the Adobe help for ASDoc doesn’t really give you the impression that it’s all that easy to use - it recommends running ASDoc from FlexBuilder’s bin directory, passing the location of your source folder as a parameter. If you want to create doco for all of your classes, you have to pass the location a second time. Annoyingly, the output is also created in the bin folder. Ugh.

After a small amount of fiddling I worked out an easier way. Create a Windows batch file and put the following line in it:

"C:\Program Files\Adobe\Flex Builder 3 Plug-in\sdks\3.0.0\bin\asdoc" -source-path . -doc-sources .

You can copy and paste this batch file into any of your source folders, run it, and the ASDoc output will be created in the src folder.

NB: in order to get ASDoc to work at all I had to use my admin ID to elevate the priveledges of my normal ID so that it had write access to the C:\Program Files\Adobe\FlexBuilder folder - ASDoc seems to update a config file there, and will fail if it doesn’t have access to do so.

On the bright side, the output from ASDoc is quite nice, and well worth the small amount of hassle to create.

Update To make life even easier you can import the batch file into your Flex project, then run it by double-clicking it

I’ve found some interesting behaviour when attempting to control the rendering of the vertical axis in a Flex chart. As with most UI elements in Flex, you can create charts either using MXML or ActionScript. Surprisingly, the properties of the chart are different depending on how they’re created.

The ActionScript generated graph is fairly logical to deal with: nothing is pre-created so you need to do it yourself:

var vAxisRenderer:AxisRenderer = new AxisRenderer();
vAxisRenderer.axis = vAxis;
vAxisRenderer.placement = "right";

_lineChart.verticalAxisRenderers.push(vAxisRenderer);

It’s worth noting that only need to instantiate your own axis renderer if you want to set non-default values, otherwise you can ignore it all together. At this point it’s worth noting that MXML is transformed into ActionScript at compile time. This is important in understanding the next part.

Charts generated with MXML seem to set several properties, despite actually setting them to the same value as the object’s default. That can be somewhat confusing - if for example you try to add an AxisRenderer to an MXML-generated chart (as you would for an AS-generated one) you end up with two axes displayed. Although marginally annoying, the solution is simple: rather than creating a new property object you get a handle on the existing one and modify that.

Unfortunately it seems that in the case of AxisRenderers (at least on the LineChart object) the MXML transformation process uses a depricated property object - LineChart.verticalAxisRenderer:AxisRenderer (rather than LineChart.verticalAxisRenderers:Array). In order to manipulate the current renderer, first you get a handle on it:

var vAxisRenderer:AxisRenderer = _lineChart.verticalAxisRenderer as AxisRenderer;

Then proceed as normal. Because the verticalAxisRenderer property is depricated you will end up with a compiler warning.

The bottom line: don’t always assume that the MXML transformation to ActionScript works as you would expect it to. Despite the apparent ease of using MXML as shorthand, it’s often less hassle in the long run to use ActionScript from the outset.

Over on the Headphonic forums someone asked me to give them a bit of a run-down on how capable a PA2V2 is for driving Beyerdynamic DT880s. Although the PA2 performed quite well with the Ultimate Ears SuperFi3 canalphones, the DT880s are notoriously hard to drive (at least according to most of the headphone-centric websites around the place) so I was expecting the little amp to struggle a bit.

I initially planned a 3-way test, driving the DT880s from

• the headphone socket of a 5th Gen iPod video
• a PA2V2 using line out from the iPod, and
• an O1 amp using line out from the iPod

The iPod headphone socket was intented as a baseline - most people have access to an iPod of some description so it could be used to put the other results in context. I started with iPod vs PA2, using my usual testing procedures. Read the rest of this entry »

I promised myself that I wouldn’t be drawn into blogging or tweeting about Twitter, but some of the comments flying around about #SXSW “information overload” highlighting the failure of Twitter to scale have irked me somewhat.

This is a basic problem in any information management system: you need to adapt how informaton is managed based on the volume and other characteristics of the data. And it’s not necessarily something that can be automated, because information categorisation happens to be one of those things that humans are very good at.

If I ran a phpBB forum with a single forum for all posts, and saw a sudden increase in posts that made following the content difficult, I wouldn’t run around screaming about the inability of forum software to scale. I’d just split  the main forum into several sub-forums, based around the main topics.

If I had a single pile of papers on my desk and found it’d grown to a size where I could no longer find things quickly, rather than declaring that piles of paper were dead, I’d split the pile into several categorised smaller piles.

This is nothing new.

The issue seems to be that people have forgotten how the Twitter syntax has developed over time. @Replies (@<username>), retweets (RT<message>) and hashtags (#<topic>) were all conventions started by users, which virally became popular, and then started being supported by the various Twitter  clients. This is a demonstration of the power of twitter: it’s minialism means that people can use it in very different ways, and the community can extend and adapt it without needing to convince a central authority.

So calling for ‘new analytical infrastructure’, to me, is forgetting the essence of Twitter as a community driven medium.

So as a member of the wider Twitter community, what are my ideas for a solution? First you have to look at the problem a little closer. Hashtags are used in two ways: to allow your followers to easily access the wider context of your tweet, and to allow people following the wider context to find your contribution. The latter is a great information mining resource, and this is where the complaints around SXSW are stemming from.

I think the most obvious solution is similar to the examples above: either use multiple hastags to multi-categorise tweets, or use hierarchical hashtags to sub-categorise them. For a large event like SXSW, sub-tagging would allow much better filtering. For example, using #sxsw:social for social events. 

Why would someone be motivated to use up more valuable tweet space with extended tags? For the same reason they use hashtags now: to improve the quality and usefulness of their stream to followers, and to surface their tweets to a wider community. Category overload is as much a problem for contributors who want to be found as it is for consumers looking for data.

If you happen to be following a large number of people who are attending something like SXSW, some enhanced Twitter tools might be nice. For example, being able to filter out tweets with a particular hashtag, or in-built group support and the ability to temporarily ignore updates from a group. But it is possible to handle now, either by using a more powerful Twitter client like TweetDeck, or by actively managing the people you follow. 

Going forward, I think improved filtering is definitely going to be important when it comes to the usefulnesss of hashtagging, whether provied by Twitter or third parties. Right now though it seems silly to be saying that social media tools have failed to scale simply because people have dumped all of their content into a single category. There was a failure of users to anticipate and react to the volume of tweets, but nothing, I think, fundamentally flawed with the infrastructure itself.

A little while ago my main amp - a NAD 3150 integrated - developed a problem in the pre-amp stage which has meant that I’ve been using a PA2V2 portable amp in my main setup. As timing would have it, the PA2V2 never actually made it to work, which is what I bought it for. 

With the immenent arrival of my new headphone amp and DAC, the PA2 will be free to head to work. Before it does I wanted to do some quick tests to see if it actually improves sound quality at all.

The testing setup was pretty simple:

• 60Gb iPod video in a standard Apple dock, playing 320kbs CBR mp3s (lame –preset-insane)
• A/B switch box connected to the iPod’s headphone jack
• PA2V2 connected to the line out of the dock
• A/B switch connected to the PA2V2
• Ultimate Ears SuperFi3 canalphones

After level matching the volume by ear using a 400hz sine wave I started as I usually do: fully sighted subjective listening. It was immediately obvious that a simulated blind test wasn’t going to be needed - there was a very significant, easily detectable difference in the sound.

The first stand-out difference was in the quality and amount of bass. Initially I thought it may have been the amp adding some mid-bass EQ (which it may do) but the sound didn’t become muddy as is usual with in that case. In fact throughout the specturm instrument separation seemed to improve, and the soundstage widened appreciably. 

Best of all, the sound was much more dynamic and lively with the PA2V2. By comparison, the headphone socket sounded flat and dull. Given how little power the SuperFi3s require (I often listen to them on the ipod’s lowest volume setting at work) I was really surprised at the difference even a cheap amp like the PA2V2 made.

Is it enough of a difference for me to carry a LOD and amp for portable use? Nope - it’s just not worth the fuss to me. However it’s definitely worth the price of an iPod dock for work.