Welcome to edgylogic, drive:activated visitors. This is my new home on the net.

drive:activated archive

  • Apple USB ethernet adapter with the new Chumby software

    UPDATE (17/07/2009): Chumby has just released software 1.7.1, and have fixed the codes for the Apple USB Ethernet Adapter. The following should no longer be required for software 1.7.1. It now works 'out of the box'.

    Since Chumby unleashed their new software 1.7, I've gotten a few emails from people reporting that my previous hack for getting the Apple USB Ethernet Adapter working on their Chumbys no longer worked anymore. This is because Chumby changed a lot of low-level stuff (moved to EABI) in their new software. They also added in-built wired ethernet support, however the module that the Apple adapter requires doesn't have the right codes, hence it still doesn't work 'out of the box'.

    Anyway, I've recompiled the module, and things generally work again. Here are the same instructions as before, with some modifications.

    NOTE: Only follow these instructions once you have upgraded your Chumby to software 1.7 - it has been deployed as an automatic update, but still requires you to allow it to do so. You can check your current software version by tapping Settings -> Chumby Info and looking at the 'SW' value.

    1. Insert your Chumby's USB drive into your computer.
       
    2. Download the newly patched module and the loading 'debugchumby' script here (Patched driver for Apple USB-to-Ethernet Adapter for Chumby FW 1.7), and place both files at the root of a USB drive (overwriting any existing asix.ko file, but keep reading about the debugchumby file). Because your Chumby has no usable in-built memory, you will need a USB drive attached to Chumby (in theory, you could remove it after it has started up, but I just leave mine in) for this trick to work.

      If you used the previous hack for the Apple adapter, you will need to remove the lines for the previous hack in your debugchumby file (including the ifconfig, DHCP and fbwrite lines), and use the lines in the included debugchumby file instead.

      If you have already done some hacks with Chumby using the debugchumby file (if you don't know what that is, you probably haven't), you will need to manually merge the debugchumby files. Be careful when extracting the files above so you don't overwrite your existing debugchumby file. Also, if you're on Windows, remember that you need a program that keeps Unix-style line endings to edit debugchumby, otherwise it won't work. Try Notepad++.
       
    3. Remove the USB drive from your computer, and while Chumby is off, plug it into the USB A port. Plug the Apple USB-to-Ethernet adapter into the USB B port and connect the ethernet cable to it. The port in which each device is plugged into is important, as the script relies on the USB drive being at /mnt/usb, and hopefully plugging it into USB A will ensure that.
       
    4. Turn your Chumby on.
       
    5. Once it has finished the booting process, you'll see the following familiar screen for network selection. For the first time, select "create a new connection" and click OK.


       
    6. If everything has gone right, after it has finished 'scanning for network adapters', you should see the following screen. Select 'Wired'.


       
    7. Then go through the usual network configuration steps. When it knows all the details, it will try connecting, and will hopefully succeed. No more flaky wireless connection!

    The next time you need to go through network configuration, all you need to do is select 'use an existing connection' on the 'new or existing connection?' screen, then select Ethernet and follow the usual steps.

    Note that I'm using the 'beta control panel' here (you can enable this at chumby.com), not sure if that makes a difference. This setup works on my Chumby; I'd appreciate it if you would post a comment if it either works or doesn't with yours.

     
  • Adding wired ethernet to Chumby, the stylish way

    UPDATE (01/07/2009): If you have updated your Chumby to software version 1.7, see this post to get it working instead.

    UPDATE (12/02/2009): There seems to be some kind of intermittent dropout happening with the wired connection using this adapter. A reboot will fix the problem, but it is annoying. Can't quite pinpoint why though.

    My Chumby hasn't been very happy for a while now - its connection to the world just isn't stable enough for it to do anything. All it could do was fetch a news article or a picture, two if you were lucky, before its wifi connection dropped out again. Chumby, just to recap, is an internet widget alarm clock which is now officially available in Australia too, via Internode. It connects via a wireless connection, but with a fairly tiny antenna in an area of high radio interference (no idea what it is), it can't hold on to a wifi signal for long (neither can my mobile, but my laptop works fine).

    Luckily, it has a couple of USB ports on it and runs on Linux, so I looked around to see if it supported any USB-to-Ethernet adapters. It did, in particularly it had been tested with the Trendnet TU-ET100C, Linksys USB200M and AirLink101 ASOHOUSB. In fact, it works out-of-the-box with those that use the Ralink RT73 chipset or the ASIX AX88172/AX88772 chipsets, provided the driver included with Chumby knew about those devices.

    Because none of the adapters mentioned above are available in Australia (as far as I know), knowing the supported chipsets opened up the selection a bit. Ones that are technically supported (but untested) and available in Australia include the Belkin F5D5050 and D-Link DUB-E100. I wasn't impressed though - these things were big, utilitarian and worst of all, ugly.

    The ones that are available overseas aren't much better either in the looks department (Airlink, Trendnet and Linksys respectively).

     


    The people behind these abominations must be wired differently to me - even if these things were designed to be out of sight, would it hurt that much just to make them look ok at least?

    Then I stumbled across this.

     


    Had to come from Apple of course. Finally, something that isn't enormous and is actually nice to look at. Some further googling told me that it used the same chipset as the Linksys USB200M, so it should be supported. Unfortunately, while the chipset was supported, the IDs for this were only added into the driver recently, and I suspected it was after the v1.6 firmware release. After downloading the Chumby Linux source, I confirmed it - the chipset was supported, but without the IDs, Linux could not detect the adapter and match it up with the driver.

    I had two options - get the IDs added into the driver within Chumby, or suck it up and get the ugly but supported and detectable alternatives. To add to this, the Apple USB-to-Ethernet adapter was actually cheaper (shock horror!) than the Belkin and D-Link alternatives ($39 compared to $44 and $55). Also, it has no flashing lights, which is perfect for use with the Chumby - the last thing you want is an annoying randomly flashing light illuminating your room while you sleep.

    Choosing the ugly option just didn't cut it, and given the Apple adapter was actually cheaper, I decided to get the IDs added in. I submitted a request to add the Apple adapter IDs into the official Chumby firmware, but I couldn't wait, so I took the plunge and got my hands dirty with the Linux kernel source code.

    As if compiling the Linux kernel wasn't enough, I had to cross-compile as the Chumby has an ARM processor, not an x86 (Intel/AMD/VIA) processor. Fortunately, the toolchain as well as detailed instructions were available, so it actually went a lot smoother than I expected. I merged the new IDs with the appropriate source file (drivers/usb/net/asix.c), made a wish that the process will go without obscure/unintelligible errors, ran the make command and sat and waited for a few long minutes while it did a whole lot of stuff. When it was done, I copied the compiled driver (drivers/usb/net/asix.ko) to a USB drive, and plugged it into Chumby.

    Of course, you could do the whole compilation thing and go through the experience of setting up the environment, the lows of watching, praying that the compilation would work, and the ecstatic highs of seeing the compilation complete without an error, or just download the compiled file below. Your choice Smile

    1. Download the patched driver and the loading 'debugchumby' script here (Patched driver for Apple USB-to-Ethernet Adapter for Chumby), and place both files at the root of a USB drive. Because your Chumby has no usable in-built memory, you will need a USB drive attached to Chumby (in theory, you could remove it after it has started up, but I just leave mine in) for this trick to work.

      If you have already done some hacks with Chumby using the debugchumby file (if you don't know what that is, you probably haven't), you will need to manually merge the debugchumby files. Be careful when extracting the files above so you don't overwrite your existing debugchumby file. Also, if you're on Windows, remember that you need a program that keeps Unix-style line endings to edit debugchumby, otherwise it won't work. Try Notepad++.

      Note: This script assumes you use DHCP on your network (if you don't know what that is, you probably do). If you don't, you will have to edit the debugchumby file to set the IP address.
    2. Remove the USB drive from the computer, and while Chumby is off, plug it into the USB A port. Plug the Apple USB-to-Ethernet adapter into the USB B port and connect the ethernet cable to it. The port in which each device is plugged into is important, as the script relies on the USB drive being at /mnt/usb, and hopefully plugging it into USB A will ensure that.
    3. Turn Chumby on. It should go through the usual process, and you should not be prompted for network configuration. Within seconds, your Chumby should be online via its new ethernet connection!

    Some things to note -

    • On startup, the wireless configuration is tricked into disabling itself. However you can easily re-enable it (for whatever reason) by going into the Control Panel -> Settings -> Network and selecting a wireless network. Nothing has been changed on the Chumby itself, so if you ever need to remove the adapter, just turn it off, remove the adapter, and turn it back on.
    • Because the wireless configuration is tricked into disabling itself, and the Chumby UI has no way of reading the details of the wired ethernet connection, it makes it quite difficult to connect to it if you ever need to. So to make things slightly easier, Chumby will flash the IP address it got via the wired connection at startup, like the picture below. It doesn't stay on the screen for long, so you need to be quick.


    • Hopefully in the future, the driver within Chumby will be updated so the patched driver won't be needed. However, you will still need the USB drive to trick the Chumby into working, otherwise it won't know it has a network connection. Apparently, official wired ethernet support is coming in the next firmware release though, eliminating that.
    Now my Chumby can actually be usable, and can actually play my alarm stream in the morning, instead of the incredibly annoying (but very effective) high-pitched beeps. And seeing as my Chumby is always AC-powered, the extra dongle/cable isn't much of a problem anyway. I think it's happy again Smile


     
  • JavaFX possibly making Java interesting again

    I'm not a fan of Java. Specifically, the language more than anything else.

    I spent this year learning Java because I had to (I don't think there's a CS course in the world that doesn't use Java somewhere in it), and admittedly, am far from an expert in it, but for the most part it is painful. Not the frustrating 'we do things differently here' painful, but the 'no this isn't possible, here's a long workaround' painful (no properties, no event handling without listener boilerplate every time, APIs without commonly used functions, confusing and subtly changing API, no delegates, no switch on strings, no anonymous functions, complicated UI toolkits, odd access modifiers ... the list goes on).

    Maybe this is because I've been spoilt with C#, and the various new and productive constructs it has to make it significantly different to Java. Or maybe I've been fiddling too much in dynamic languages like JavaScript and Python. These languages have also evolved way faster, finding new ways to allow the developer to be more productive, and for the resultant code to be more elegant. The last significant languages changes for Java was in Java 5, released 5 years ago now. 

    The Java philosophy, and the hardcore followers don't want anything to change, which is fine if it was perfect, but I don't think it is - it certainly isn't something I'd pick to be productive in if it was on language alone. I don't want Java to be C#, Python, Ruby or everything thrown in together - I just want to see solutions to such common pain points in my lifetime (and no, code generation tools are not a solution).

    Which brings me to the point of this post - JavaFX.

    This is the new language the Java guys created, purportedly because it makes creating RIAs a lot easier, but I suspect it is also because the Java guys themselves know there are many improvements that can be made to Java, but they weren't able to for fear of incurring the wrath and alienating large sections of the Java community.

    What makes it cool?

    Well, it incorporates a lot of the productivity enhancing constructs perfected over the years, all while still being very Java-like, statically typed and compiled, and with the full Java library at its disposal.

    Type inference

    This is actually both a blessing and a curse. It allows you to not repeat yourself when you're declaring and instantiating a variable, while keeping clarity. However, if it is used everywhere without thought, it could end up being real messy.

    Declarative construction syntax

    This is JavaFX's answer to MXML (Flex) and XAML (Silverlight/WPF). Instead of using XML, it is a JSON-like (but not entirely JSON) syntax. See here for some examples.

    To be honest, I'm not entirely sold on this. It isn't exactly easier to read, but maybe that's just my eyes being trained on XML over the years. The lack of the new keyword for constructing objects is unsettling too. I guess it is redundant, but it does emphasise the construction part, particularly useful if you have a JavaScript or python mindset and start thinking of dictionaries/anonymous objects.

    Inline string expressions

    So you can do things like:

    var s1 = "java";
    var s2 = "fx";
    var is_fx = true;
    var s3 = "{s1}{if (is_fx) s2}";

    Time literals

    typing 5m will mean 5 minutes to the code automatically - no more thinking in milliseconds!

    Sequences

    This is one of the best new features yet. It is basically list comprehension in Python, or in a restricted manner, LINQ in .NET.

    You can filter arrays of objects by:

    var names = ["Matt", "Peter", "Craig", "Andrew"];  //note the array literal syntax!
    var namesLongerThan4Characters = names[n | n.length() > 4];

    //alternately...

    namesLongerThan4Characters = for (n in names where n.length() > 4) n;

    Inserting objects in arrays:

    insert "Alex" before names[0]; //insert Alex at the start of the array

    Slicing arrays:

    var first3Names = names[0..<3]; //note the slice syntax

    Binding

    Binding in an integral part of the language. To bind something to something else, simply use the bind keyword, e.g.

    var s1 = "hello";
    var s2 = bind s1;
    //s1 and s2 == "hello"

    s1 = "world";
    //s1 and s2 == "world"

    It even works for function arguments, and if a function is a bound function (prefixed with the keyword bound), any instance variables utilised within the function too.

    On replace trigger and new access modifiers

    There still aren't properties in JavaFX as far as I know, but this helps. When you declare a variable, you can declare an anonymous function that gets called when the variable is changed, like so:

    var myName = "Sam" on replace oldName { println("old: {oldName}, new: {myName}"); };

    Combined with this there are new access modifiers, allowing you to designate a public variable as read-only using the public-read modifier, instead of the public one when declaring.

    Closures

    Yay! Finally, no more writing ugly inner classes boilerplate code for Swing. Anonymous functions can now be created in code, and passed around by variables.

    This example explains the concept, and how it can be used. That wasn't a Swing example though, and I'm not sure what the case is there, given Swing expects Listener classes, not anonymous functions.

    EDIT: Looking at the Stopwatch sample, it doesn't seem like you can use closures/anonymous functions in place of ActionListeners. Back to ugly, boilerplate code again. Wasted opportunity, Sun.

    More?

    Check out the official tutorial here. The API reference has some nice stuff too - particularly the effects. It looks a billion times better than Sun's usual API doc style too. And finally, the language reference, back in the typical ugly Sun style.

    So everything's cool right?

    I'd love to say yes, but sadly it isn't. Sun has a history of shooting itself in the foot with Java, and this is no exception.

    (Below is from what I gather on the net - I have not tested the code to see if it actually is missing, so I could be wrong.)

    JavaFX was announced prematurely - bits were released too early. In between releases, there have been very significant changes, enough to break most samples and guides out there. Then apparently, Sun had a change of heart, and decided they didn't like it being an intrepreted language anymore, and it should be compiled instead. Along with this change, brought a huge range of language feature cuts, rendering many, many more samples and guides out there useless (or soon to be if/when the interpreted version is stripped out).

    Just look at this post from Sun themselves, and compare it to the official JavaFX 1.0 tutorial to see what's been cut.There were some really neat features there too, like the select keyword, triggers, and the do loops. Documentation was and still is on the thin side - those blog posts out there really helped, but now many are basically useless because of the changes, yet the average developer googling for help won't know, because to them, it is all still JavaFX Script and will become an exercise in frustration.

    And from what I see on the net, it seems like this change was unexpected, apart from the beta tag, which has lost its meaning anyway.

    On top of this, Sun is stretching the cross-platform marketing point by not releasing a Linux version. Yes - JavaFX only works on Windows and Mac at the moment, disappointing masses of developers out there who were betting on Linux availability as a major advantage. Depending on how Sun works, Moonlight 2.0 and Eclipse4SL might even be out before JavaFX for Linux is. Of course, Flex Builder 3, Flash and AIR are all available on Linux, now.

    Then there's the persistent problem of Java's performance and stability woes. Java has never been very smooth for me, and it is particularly bad inside browsers. It has a uncanning ability to crash your browser just when you need it least, or just freeze it for ages, leaving you to ponder - do I kill it and lose all my tabs and sessions, or wait, and pray that it comes back to life.

    Even with Java 6 Update 11, which promised performance and stability fixes, the sample JavaFX applets consistently killed the tab in Google Chrome, and only 2 of the 4 applets I tested loaded in Firefox, both after rather long waiting periods when compared to something of similar functionality in Flash/SL. And the security restriction dialogs - maybe that's where Microsoft drew their inspiration for UAC from. The drag to break out of the browser trick is cool though.

    One final thing - they've decided to allow JavaFX to play video in a selected set of cross-platform codecs, and also platform-dependent codecs. Yes - you can use JavaFX to play Windows Media Video files, but only on a Windows computer. I hope they make this clear to developers, but seriously, why even offer this option - it only allows developers to create platform-dependence, the exact problem Java has been claiming to help solve all these years.

    So who's happy?

    I'm struggling here. They've thrown up numerous walls to stop newcomers from trying it out, particularly when compared to their stiff competition, Flex and SL. Many old timers dislike change, and probably won't like the new syntax and way of doing things. Some might. And a few open source fanatics might jump on board, just because it is open source (even though it isn't completely yet, and as I mentioned before, there's no Linux version).

    Yes it has cool tricks, can do things neither Flash/Flex/AIR or Silverlight can do, has the large Java community it can leverage, and has a wide range of components and libraries from Java to support it already, but that all means nothing if there's insufficient/confusing documentation, and the user experience sucks.

    Here's hoping that the community helps you out Sun, and the next iteration of JavaFX is massively improved upon, because JavaFX just doesn't seem like the magic bullet you needed to stay ahead of the game.

    Then again, maybe I haven't drunk enough of the Java kool-aid Smile

    UPDATE: Changed the starting paragraph - sounded way too harsh and set the wrong tone.

    UPDATE (07/01/2009): Looks like Java 7's been pushed back to 2010, and the list of new features is... rather short and boring. At least I'm not the only one disappointed with Java's development. http://www.infoq.com/news/2009/01/java7-updated

     
  • Connecting to the Internet over Bluetooth with 3

    I recently had the need to connect to the Internet on my laptop, but really didn't want to load the whole Nokia PC Suite on to it. I don't have an issue with it, in fact, of all the mobile phone companion software I've used, it's the best of the lot (compared to the LG one... shudders). I just didn't need all that functionality.

    I vaguely remembered that Windows has a generic Bluetooth Modem driver in-built, so here goes that experiment. This was done on a Windows Vista machine, but the details should be the same on any OS, just have to adapt the steps. And this is for the 3 Network in Australia, although apparently the details are similar if not the same for other networks. It should also work with any phone with Bluetooth that supports the Dial-up Networking profile - that means most phones except all iPhone users - you can go cry, because you don't have it. Ha.

    I bonded my phone with my laptop (double-click on the Bluetooth icon in your system tray or Start -> Control Panel --> Bluetooth Devices, then click Add to start bonding), and the whole device driver thing kicked off. When it had done all it could, I got this dialog.

    Whatever, and expected, given I hadn't installed the Nokia drivers. But importantly, the Standard Modem over Bluetooth link device was installed.

    So time to create a new connection and see how this works. Click on the network icon in the system tray (or Start -> Control Panel -> Network and Sharing Center), and click the Connect to a network option.

    Click Set up a connection or network.

     

    Yes, your Bluetooth modem is considered a dial-up connection. Remember those, the days when you had to leave it on overnight to download a 1MB file? Hopefully, your mobile internet is faster.

    If you have multiple modems, select the Bluetooth one.

    Enter the dial-up phone number as you see above (*99#). This is the magic number to make this all work.

    Leave the user name and password fields empty, and give the connection a name.

    Click Connect.

    This screen will pop up. Turn up your speakers and hear those dial-up modem sounds you haven't heard for so long!

    With any luck, the following screen will appear in a few seconds...

    And that's it - you are now connected to the Internet via your mobile over Bluetooth, all without downloading and installing any software, which would be a tad difficult given you don't have Internet access in the first place.

    The wonders of technology.

    Of course, if you already have the Nokia PC Suite installed, just open the Nokia PC Suite, select the Connect to the Internet icon (globe with two opposing arrows), and it should do it automatically. If it fails, it's probably because it doesn't know which network you're on, so click the spanner icon, and tell it which network you're on, then try again.

     
  • Flexing backwards

    For the last few weeks I've been working on a project built with Adobe Flex on Adobe AIR. A quick rundown - Flex is Adobe's (well, Macromedia's really) solution to make building form-based apps in Flash (as opposed to animations) easier, and AIR is Adobe's way of expanding its influence off the web on to the desktop by allowing Flash and HTML/JS/CSS apps run as if they were desktop apps.

    This is my first foray into the world of Flex, and might as well be a first into Flash and ActionScript (the last time I fiddled with this stuff was ages ago, and it was nowhere near as in-depth as this project). I chose it for this project because I was bored of HTML/CSS/JS and its quirks, and how rough it is when it comes to building apps without the HTTP model. My main need was that it need to support spiffy, animated interfaces out of the box. The alternatives were WPF, which isn't cross-platform... and, that's about it (Java's ugly and clunky).

    I approached this project as if it were a desktop app, and had those expectations in mind. I had nothing against Flex/AIR prior to this - in fact, I was even excited to use it initially. And even now, Flex/AIR still holds a unique set of capabilities that others do not have, so there are definitely cases where I would still consider using this combination.

    All that said, there is clearly a bit of work to be done to make this combination work better, and be a lot more appealing, unique capabilities aside.

    Language

    The constructor and casting syntax is very similar and hence can be confusing. But to be honest, this didn't bother me too much, and there is alternative syntax for casting, however it does work slightly differently.

    Construction -
    var ac:ArrayCollection = new ArrayCollection(a);

    Casting -
    var ac:ArrayCollection = ArrayCollection(ac);

    Properties must have the same visibility. This was a big one for me - there were plenty of situations where it made perfect sense to have a public getter, and a private setter, but no, this can't be done in ActionScript(AS) 3. One workaround is to use a method instead, losing the advantages of the properties syntax.

    The this keyword, combined with dynamic anonymous classes can lead to insidious bugs. This isn't really a fault of AS3, but the combination of the two means your intention is easily mistaken.

    For example,

    public class ThisTester
    {
        var _testValue:Boolean = false;

        public function get testValue():Boolean
        {
            return _testValue;
        }

        public function set testValue(value:Boolean):void
        {
            _testValue = value;
        }

        public function test():void
        {
            var f:Function = function():void
                {
                    this.testValue = true;
                }
           
            f();
        }
    }

    If you called test(), then did trace(testValue), you will see that the testValue still == false. Yet, if you add a trace right after the this.testValue = true line, e.g. trace(this.testValue), it will return true. 

    Why? Because when you declare an inline function, a new scope is given to it. By explicitly specifying using the this keyword, you are in fact specifying the scope to be the new one, rather than the enclosing ThisTester scope, and when it can't find a testValue member in the new scope, it defines a new one as a dynamic member.

    No block-level scope. This is weird, but one I can deal with I guess. In AS3, variables defined inside a for loop, if block, try-catch block, or some other block, is accessible outside of that block as well (but within the same function). So if you define the same variable in different for loops in the same method, the compiler will warn you of declaring a variable twice, something different to C# and Java.

    No generic types. Maybe I'm just spoilt with C# and Java, but if AS3 wants to be a typed language (and it does), it really needs generics so types can be checked at compile time. See update at the bottom.

    Tries too hard to be a typed and untyped language. AS3 would've been better if they could just decide on what it should be. Right now, you can use it as a fully typed language, or as an untyped language. However, judging by the libraries, it seems Adobe is pushing developers to the typed route. That said, it is missing some of the things that make typed languages good (e.g. generics), and personally, I think the untyped nature of AS was one of its strengths, yet Adobe seem intent on taking dynamic/untyped language features away from it.

    Has language features only usable by internal classes. For example, abstract classes are not supported, yet some classes are inherently abstract, e.g. flash.display.DisplayObject (see here). The E4X XML syntax is another, e.g. xdoc..name. To be fair though, it isn't the only language to have in-built support for something that cannot be replicated by developers (VB.NET's literal XML support is another). It would be nice if it was possible though.

    Classes and constructors cannot be private. Prevents the use of the singleton pattern without ugly hacks.

    The so called CSS support is subpar. It doesn't support binding, only works with certain properties (e.g. width and height can't be set in CSS), and one of the most annoying issue - you can't refer to items in MXML using their ID in CSS. The one good thing about the CSS in MXML is that you can apply the same set of styles to multiple elements, and it is a neater syntax than specifying the attributes in MXML (less angle-bracket tax).

    There is no threading support even though the Flash Player itself is threaded apparently. Not entirely impossible, but there are times where synchronous behaviour is desired, and it makes it difficult. Also, because it is single-threaded, long-running intensive operations may hold up the UI thread, even with callbacks.

    Libraries

    The in-built libraries are, to say the least, lacking. Among other things, there is no reflection API at all, even though all the bits for it are there, and hence there are some excellent third-party libraries out there (Spicelib is one example). There is no method to round numbers to a certain degree of accuracy either - only round to the nearest integer. The workaround is to raise the number to a certain power first, use the in-built round, then reverse the initial operation (credit here), but this is just basic stuff that should be in-built.

    There are plenty of libraries out there that fix these shortcomings and more, but at the end of the day, it all just adds bloat to apps when the functionality should just be in-built. Don't go all out and implement obscure functionality that few people would use, but I think it is time to consider widening the in-built libraries. I'm pretty sure users would rather a once-off larger download, compared to a longer download every time they load the app (obviously less of an issue with AIR apps, but more so with Flex in browser apps).

    Some methods have weird quirks. This is probably not an AS3 thing, but rather part of the ECMAScript spec, but still - why does the date method assume months are zero-based, but other parameters (day, year etc.) are not?

    The lack of local system APIs in AIR apps is ridiculous. Why can my app have full access to the filesystem (to the extent that the user does), yet it cannot run another app on the desktop? I suspect Adobe are trying to prevent the whole ActiveX debacle, but there are much better ways of doing that than restricting the ability for your platform to do what it should be able to. Or maybe cross-platform issues; hopefully something they have resolved in AIR 2.0.

    The organisation of the in-built APIs are annoying and confusing. I understand the need to separate Flash and Flex namespaces (hopefully, this won't be an issue in the future if/when Flex is integrated into the Flash distribution), but it really doesn't help the discoverability of classes when you have to look in multiple places for things, e.g. the flash namespace, and the mx namespace. From my perspective, they're the same thing, so put them together. Also, sticking things in the utils namespace is the same as sticking them in the miscellaneous namespace - what's wrong with giving them their own namespace?

    There is also a lack of open-source libraries for common desktop app tasks, like data objects management and persistence.

    Documentation

    The AIR security restrictions are still not documented well. I have yet to find a document that explains when a cross-domain policy file is needed for URLLoader requests, and when a socket policy file is needed for Socket requests. There are also apparently sockets that I can't use, even if there is a socket policy file (below port 1024 I think). I understand there is a difference between the AIR app running from the AIR package, as opposed to code loaded from the net (e.g. another SWF file). All I want is a nice table describing what remote request APIs I can use in what situation.

    Javadocs-style docs suck. Admit it. I know AS3 and Java have a close relationship, but I hope you are not blind because of that. In case you are, I'll tell you - Javadocs are useless, and the ASdocs, while they're slightly better, they could be much better.

    • There is no information about which version of Flex the particular API is available in, the differences if any, or which one it was introduced in. This is important, particularly if you're just searching for APIs on google, and stumble across something, or need to use a certain version of Flex/AS. The way that MSDN does it with .NET Framework APIs is one way. This is one thing that has irked me to no end when I was using Java, and needed to know if a certain method was available in a certain JRE version.
    • The constructor is not highlighted in the docs. It is there, under methods, but given its particular importance, I think it should be given its own section.
    • There are still many areas that are missing examples and detail, and links to the Programming ActionScript 3.0 or the Flex 3 Help site with more information, e.g. http://livedocs.adobe.com/flex/3/langref/mx/rpc/xml/SimpleXMLEncoder.html - how is it encoded, what does it look like, any metadata tags to control serialization?
    • The 'comments' section doesn't have enough direction. There are many pages where the comments are people asking for help, rather than the intended purpose, which is to add to the content on that page.
    • The pages on Flex visual components lack visual diagrams. In fact, the entire API docs set is lacking in diagrams, but it is most needed in visual component pages. I know the books and help site have them, so maybe better linkage is one solution, but is there much harm is visually describing concepts in the API docs?
    • There is a tendency to use big convoluted words to describe things, just because you can.

    LiveDocs search is crap. If I am on a Flex 3.2 API page, and I run a search for XML, I expect the results to be for Flex 3.2, not Flex 2.01, which all the results on the first results page are. Sure give me an option to widen my search, but I think that is a reasonable assumption.

    LiveDocs is slooooow. I don't know why, but being new to Flex, and having to look up so many pages on it has gotten me quite annoyed at the delay. Any chance you can make it Google speed?

    There are no coding guidelines (that I can find). Where are they? Found them - http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions. Not complete, but quite extensive, although some reasoning in certain areas would be nice.

    Editor

    Of all the sections I'm complaining about, this is the BIGGEST PAIN POINT. If there is a better IDE out there, with similar support for Flex features, I would dump Flex Builder in a heartbeat.

    Eclipse is sloooow. I have never experienced good performance with Eclipse-based IDEs, and this is no exception. The startup time is ridiculous. Other IDEs (Visual Studio, Komodo) all load and work faster. Maybe I need to tweak my Java settings...

    The compiler is very, very, slow. Because I'm using a few open-source components from the SVN trunk, I don't have the compiled SWC, and I haven't found a handy way of compiling them into SWC without having to do -include-classes and listing all of them manually. No thanks. So every compilation of my fairly simple app takes at least a minute. It drove me up the wall until I found the 'build automatically' setting and turned it off - it took minutes every time I saved a file. Again, maybe my Java settings need to be tweaked...

    Apparently, improvements are in the pipeline for Flex 4 (Gumbo).

    The code checking mechanism seems to be dependent on the compiler, which is slow as I have already mentioned. This means that any errors (or warnings) in my code are not picked up until I compile the project, which takes minutes. Why can C# and Java IDEs detect these things without compiling, while Flex Builder can't? And I'm not talking complicated things here, but simple things like including the var keyword in a catch block (why it shouldn't be there, when it is needed in for each loops is another mystery).

    Classes that the compiler doesn't think are referenced, are not compiled. I can understand the rationale here, but I use an IoC container (Parsley to be precise) that uses XML for configuration, and it is very annoying to have to use -include-classes (which is long and annoying), or use a useless class to hold references just so all the classes compile. There should be an option to make all classes within a folder compile.

    Eclipse is too imposing. Why do I have to specify a workspace? I like to have my projects all over the place, in my own perfectly organised world, who are you to tell me where I should put them? I should just be able to open any project I have, in any instance of Eclipse. It took me ages to discover that I apparently had to 'import' projects into my workspace before using them if they were in a different location. Why can't I just open them? To make things worse, apparently Eclipse is so cool it can rewrite the meaning of the word 'import' - import doesn't necessarily mean it will copy the project into the current workspace, as it does in every other program. Oh, and did I say that the Import dialog is confusing as hell? What's the difference between importing a Flex Project, and an Existing Project into Workspace?

    No refactoring support (renaming a file doesn't count). Adobe, I'm sick of typing all the boilerplate property getters and setters. Why can't your IDE do them for me, like all other IDEs, and while we're at it, how about extracting interfaces, extracting methods, promoting variables, converting between loops, and all the other convenient things other IDEs do out of the box (although they do it even better with commercial addons).

    Does not offer fixes for errors it can determine potential solutions for. If I forget to implement an interface method, I expect to be able to click on the red X and select 'implement method' and have the method signature added to the current class, ready for me to implement. If I forget to import a class before using it, I expect to click on the red X and be able to select which class I mean, and have the import declaration added for me automatically. Eclipse Java does all this and more.

    From Eclipse,

    Find does not wrap around. I don't know about anyone else, but most of the time when I'm searching for something in a class, I generally want to search the whole thing. There is no such option in Flex Builder, and worst of all, the search does not know how to wrap. So if you're expecting it to wrap if it does not find any results in the selected direction, as you are quite allowed  to expect given most other apps do it, you will be surprised, then annoyed after you realise.

    Code completion is very hit and miss. I don't know how to replicate this because it is very random, but it is extremely frustrating when you need code completion to appear and it doesn't, particularly when you're still learning the APIs and using code completion to discover APIs. This is in both AS3 and MXML, although MXML is much better. If they could add support for code completion before the dot is entered, I would be over the moon, e.g. if I type in Simp, code completion should show me matches including the SimpleXMLEncoder and the SimpleXMLDecoder. Alternatively, because I use _ for instance variables, I would like them to show as soon as I type _. 

    From VS,

    There is no code completion for CSS attributes. What were they thinking? Too difficult?

    There is no ASDoc or Flex doc integration for code completion. Apparently they think their methods are so descriptive, that even a one-liner describing them are unnecessary. Seriously guys, take a look at Visual Studio, where one-liners are given for each member of a class, and when you use a method, one-liners are given for each parameter in the signature. Even better, take a look at Eclipse Java or Netbeans, where a shortened version of the Javadocs is shown, with full working links. I was very impressed when I saw that.

    From Netbeans,

    Properties don't have type information in code completion, but everything else does. WTF?


    Object Browser anyone? I have missed this every time I leave the .NET universe. Why does no one else think it is useful to have the entire API (and any loaded libraries) shown in your IDE as a tree, so you can browse through it, find methods, and get basic information on them? This is so much better than browsing through the web-based API docs. You can even browse through the current project's classes. Even better would be the class view in .NET Reflector, which shows all inherited types, and classes that inherit from it, among other useful bits.

    From VS,

    I know my errors are important, but really, I don't need to be told twice. For some odd reason, every error and warning I get in Flex Builder is repeated twice.


    Where are my inherited members? Why doesn't the Outline panel give me the option of showing inherited members? Sometimes it is useful to know what they are, to know what I should call or whatever.


    Custom code folding regions, please. Another thing I miss when I leave the .NET universe. I like being able to define regions in my code, e.g. for properties, overridden methods, private methods, etc. and be able to shrink and hide them when I want to.


    If I don't want the debug perspective, I don't want it. Sometimes when I debug code, I would rather do it in the Flex Development perspective. Yet Flex Builder get angry, and when I step through code, it asks me on every line, if I want to open the Flex Debugging perspective, even if I had already clicked No. Why don't I click the 'don't ask me again' box? Because I want it to, but the next time I start debugging, not this debugging session. Oh, and it would be nice if it would return me to the Flex Development perspective when I've terminated the debugging session.

    Anti-aliasing in the editor. All my usual coding fonts look funny in Flex Builder, except the default Courier New, which sucks.

    More precise context menus, less hidden keyboard shortcuts. The right-click menu for a doc is way too big, and some things are not applicable. Run As, Debug As, Profile As? They belong in the Run/Debug menu, or the right-click menu of the project, not the current coding file.

    More surprises. I want to right-click somewhere, or do something, and have an option to do exactly what I was thinking, like the first time I discovered the 'generate getters/setters' option in Eclipse Smile

    Ok, I think I'm done. There's probably more, but this is plenty. Just needed to vent all that steam that has been building up over the last few weeks.

    But seriously, Flex/AIR is a platform with a promising future, and maybe I am being unfairly harsh on it, given it is relatively new. It still has some way to go before it will be the slick desktop app platform that its marketing material proclaims it to be, but the momentum is definitely there. Indeed, it definitely has a passionate developer base that is willing to overlook and workaround the shortcomings of Flex, and still produce stunning stuff. This experience has just told me though, how important every part of the link is in the platform, and the weakest link really drags it down.

    At the end of the day, do I regret using Flex/AIR for this project? No. In hindsight, would I pick another set of tools? No. Would I consider Flex/AIR for a project in the future? Yes. Would I be a happier camper if they fixed all the above and more? Definitely Smile.

    And if anyone knows of solutions to any of the issues above, I'd love to hear them.

    P.S. I'm running the free educational version of Flex Builder 3 Professional (available at http://freeriatools.adobe.com), and unlike other student editions of stuff, Adobe allows users of this version to create commercial apps too. Nice one.

    UPDATE (31/12/2008): I stand corrected - Flex 3.2 has a some kind of in-built generics support in it for Vectors (the java.utils.Vector type of Vector, i.e. a typed ArrayCollection in AS3 terms). Unfortunately, it doesn't seem like you can use it in your own code though.

    UPDATE (03/01/2009): While I'm complaining - it would be nice if AIR apps defaulted to an icon, say the AIR icon, if no icon is specified, instead of the default OS no-icon icon, which in Windows, is not the prettiest icon out there, particularly the icon in the start bar, which for some reason is different to the others.

    UPDATE (04/01/2009): What, there's no dispose event? How the hell am I supposed to do cleanup? The removedFromStage event fires when I minimise the app, or if I move the component around the display tree; very helpful. 

    And the accordion doesn't fire the CHANGE event if I change the selected panel programmatically, only if it was changed the user in the UI. I really fail to see the logic here. Apparently we're supposed to use the ValueCommit event, which is very helpful, because it only tells me some value has changed on the Accordion control, not which one - not.

    UPDATE (09/01/2009): Found the coding conventions. See entry in post above.

     
  • Death to the desktop as we know it

    While I'm talking about operating systems, I have another gripe to vent. It has to do with one of the most integral parts of operating system interfaces. Yes, as the title suggests, I'm talking about the desktop.

    Conceived as a virtual replica of our desk, the concept works if you are the super-organised type in real life, where your real desk is neat and tidy, as opposed to being piles of paper everywhere. But even for these people, it is a struggle to keep order, especially with the ever growing amount of digital information being created/shared/collected on a daily basis. What's more, unlike any other storage location on your computer, there is a limit to how much stuff you can have on your desktop - anything that does not fit on the desktop may as well be lost forever (yes, you can navigate to the desktop directory, but defeats the purpose of the desktop).

    For most people, the desktop is our virtual miscellaneous folder, our virtual dumping ground, our virtual inbox, or a place we go to remind ourselves of how much crap we have.

    On top of trying to organise your own stuff, it doesn't help that so many applications seem to have an inferiority complex and need to compensate by adding icons to your desktop, wasting precious space. (Yes Adobe, I am looking at you - why the hell would I want a link to Adobe Reader and Acrobat.com on my desktop!!?! Firstly, who loads the Reader on its own, and not through opening a PDF file? It provides no functionality without a PDF file. And Acrobat.com - my desktop isn't an advertising billboard, bugger off. It's bad enough in my start menu, but this is just crossing the line.) I do realise this is more a Windows developer mentality issue more than anything.

    Somewhere along the way, Microsoft, Apple, KDE, Gnome and other desktop shell makers realised that our desktops never look as tidy and neat as they do in the marketing material. So they come up with all kinds of ideas to help us keep things off the desktop, with OSX introducing Stacks, KDE building various applets, and Vista ushering in various folders for stuff we commonly place on the desktop by default, among other things.

    So now, instead of cluttering our desktops, we clutter our user folders instead (another problem operating systems are struggling to fix), and now have to click 2-3 times more to get to that file. Great.

    My question is - why don't we make use of the desktop space, and make it better at organising our work, instead of pushing everything elsewhere? I don't know about you, but I have better things to do than stare are my desktop background all day, as mesmerising as some pictures can be.

    One thing that helps reduce desktop clutter is having virtual desktops, as is the case with OSX's Spaces, and most *nix desktop environments (these two environments are really crap at marketing - where the hell is the features page!?!!). Windows still doesn't, and doesn't seem like it will, have support virtual desktops out of the box (there are programs that offer this functionality though).

    But that does not go far enough - that only helps taskbar/application window clutter, not desktop clutter.

    Rather than having the desktop as a dumping ground for files, it should not be a storage location at all. Instead, it should be split into two sections - a task manager and a file browser. The task manager would list all the applications (thumbnail + name) running in the current virtual desktop. For every application loaded in that virtual desktop, related folders would be shown in the file browser area, sorted by the last modified file/folder first, with files modified in this virtual desktop highlighted. The file browser area should include shortcuts to commonly used folders (e.g. Downloads, Documents, Photos) as well as any devices (e.g. CDs, USB drives, phones) and hopefully web services (e.g. xDrive or Skydrive). To make it more visually appealing, copious amounts of transparency should be used, and a background picture allowed to show through.

    So for example, if I had Chrome open, the Downloads folder would be shown in the file browser area. Later I open Microsoft Word and start a document. I save the document inside the Work folder inside my Documents folder. As I do this, the Work folder is now shown on my desktop, along with the Downloads folder from before. I now close Chrome. The Downloads folder stays on my desktop, but over time, as other folders are needing to be shown, it becomes minimized down the bottom, showing the path and the files used in it only. I now insert a USB drive into my computer, click on the new icon on my desktop and the drive's contents is now shown on my desktop, along with the other folders. I double-click on a spreadsheet, Excel fires up, and away I go.

    Folders can also be pinned to the virtual desktop, so they stay there, even if the related application is not running inside that virtual desktop. Applications however cannot - application launching is the responsibility of the taskbar/dock.

    Of course, if applications are dragged into a particular virtual desktop, the related folders go with it.

    Because the Desktop is no longer a storage location, users and/or applications are now strongly encouraged to organize their files when saving them. Of course, the user can just specify a single folder for everything, defeating the purpose, so the UI should be made simple enough such that it is easier to organise now, than to dump and organise later.

    The concept can be expanded so that each virtual desktop becomes tied to a certain task/outcome. For example, I may have a virtual desktop for when I am coding an application. This virtual desktop would have my development folders pinned. When I am no longer coding, I should be able to suspend that virtual desktop, which should suspend all application instances within it, freeing up resources. Later, when I start coding again, I should be able to activate that desktop again, which will wake up all the applications within it and restore it to the state prior to suspension.

    I'd be really interested in seeing something like this. Or actually, anything willing to challenge the ubiquitous desktop concept, which none of the developers of desktop environments across any operating system seems willing to radically change. (Why I have no idea.) Because right now, there is nothing good about the desktop - it's way too easy to use as a dumping ground, and way too useless to be productive in (unless spending minutes visually searching through the various icons over and over again is part of your job description). 

    P.S. The worst desktop organisation I had ever seen was my materials engineering lecturer at Monash - his OSX desktop was full, so full that his desktop icons all overlap each other. I wish I had a photo, you had to see it to believe it.

     
  • Access *nix on Windows as if it were a local drive

    Wow, its been a long time since I last posted. I blame uni assignments, way too many 21sts (including my own), and my own desire to sleep way more than I ever need. There are quite a few posts I've been meaning to write, so fingers-crossed posts will be a tad more frequent for the next while. But I did say posts will be somewhat sporadic, didn't I? Smile

    One of the assignments I've had to do this semester involved writing a website in PHP (ick, but I digress). It had to work on the uni server for assessment, and the suggestion was that we should download something like XAMPP, develop on our own computers, then when we're done, upload to the uni server (running Solaris) and debug all over again (due to potential differences in PHP version - PHP seems to change syntax with every release - and PHP settings).

    That seemed pointless - why develop on a different machine, when it has to fit the constraints of another, whose configuration is not fully known (the development to staging to production server argument doesn't apply here). Why don't we just develop on the uni server? One way to do that is to upload the changed files every time we made a change, but that was tedious and boring.

    I knew you could mount another *nix system on Linux thanks to FUSE and SSH/SCP, so I set about finding a similar solution on Windows, which would let me mount a *nix system as if it were a local drive.

    Enter the Dokan library and DokanSSHFS.

    The library is effectively an implementation of the Linux FUSE concept on Windows, making it easier for developers to create drives on Windows that interacted with something else. DokanSSHFS builds on the Dokan library and allows you to mount your *nix system as a drive on Windows. You can browse through all the files, create new ones, delete, modify... everything you can do with a local drive. Most programs will work with it, as it is exposed as a standard drive. As a bonus, you can even modify *nix file permissions right from the properties dialog.

    There are a few steps to get this working, but if you do anything that requires constant transferring between *nix and Windows machines, this is a lifesaver. You do need to be using Windows XP or Vista (or the server equivalents I assume), and the *nix server needs to have SSH enabled and running.

    1. Download the Dokan Library. It is available from here http://dokan-dev.net/en/download/ - first link after the Dokan library header; download the version appropriate to your computer's architecture; do not download the source.
    2. Unzip it, and run the MSI file inside to install it. The installer might open the installation folder during the installation process; just close it when the install is done.
    3. Check that you have Microsoft .NET Framework 2.0 installed. If you have Vista, you already have it installed. If you are running XP, check your Add/Remove Programs dialog in the Control Panel for it. If you have any of the later versions installed (e.g. 3.0 or 3.5), you have it. Otherwise, download it from http://www.microsoft.com/downloads/details.aspx?familyid=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en.
    4. Download and install this (unless you are sure you have it) - http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en
    5. Download Dokan SSHFS. It is available here http://dokan-dev.net/en/download/ - first link under the Dokan SSHFS header.
    6. Unzip Dokan SSHFS and double-click the MSI file inside to install. The installer might open the installation folder during the installation process; just close it when the install is done.
    7. Once that is done, you will have an icon on your desktop (and start menu) named DokanSSHFS. Double-click on it.
    8. When it has loaded, you need to enter in the details for your *nix server. It should be fairly self-explanatory.

      For Server Root, this is the folder on the server that you want mounted as the root when navigating on Windows. So if you enter in /, when you navigate to your SSHFS drive, you will get all the standard *nix root folders, e.g. home, etc, bin, usr. If you enter in /home/yourusername/ though, then when you navigate to your SSHFS drive, you will get your home folder's contents instead. You will not be able to navigate upwards to any parent folder, e.g. /etc, in this case.

      For drive, you need to select a drive letter that doesn't currently exist (Z drive is usually a safe bet). It usually automatically picks the next unused one anyway.


    9. Give it a name up the top and click save so you don't have to type the details in each time.
    10. Click Connect.
    11. When it has connected, a dialog will pop up saying 'sshfs start'. Click ok.
    12. Open up My Computer, and you'll see a new drive there, named DOKAN with the drive letter you specified earlier. Double-click it, and voila! there's your *nix server.


    When you're done, right-click on the SSH icon in your system tray and click Exit to close the connection and unmount the drive.

    To start the connection next time, start with step 7 onwards, ignoring step 8 and 9, although you will need to enter your password.

    At the time of writing, there are a few issues with it - make sure your internet connection is fairly solid, otherwise you will encounter errors when trying to save files back to the *nix server. Also some programs don't seem to work very well with it, but on the whole, it generally works quite well as it is just exposed as a standard drive.

    If you're on a Mac, your life is a bit easier - check out http://www.macfusionapp.org/about.html. That's the easy part. You'll also need some bits from http://code.google.com/p/macfuse/. Download the MacFUSE download first and install it, then follow the instructions here - http://code.google.com/p/macfuse/wiki/MACFUSE_FS_SSHFS.

     
  • Metlink is going mobile!

    UPDATE (31/12/2008): It seems like Metlink has broken this trick, so this won't work anymore. There is however, a neat site out there called iTransit that does something similar. It does favour the iPhone, but that's the only option I can think of at the moment.

    I never thought this day would come, and it still isn't really here yet, but it's a promising start. I stumbled on to it while trying out their new 'beta' timetables (which are horribly broken in Firefox 3), so I assume it will be improved and officially announced soon.

    It works a lot better than trying to use their main 'for desktops' website on a phone, even on the iPhone. Rather than giving you the full timetable, it gives you the next 8 or so departures from that stop. That's generally all you want to know when you're out and about (although it means you can't plan ahead, e.g. work out when the last train is until it is too late). You can even choose to get the departure time, or in 'countdown' form, i.e. departing in 5 minutes.

    It is basically similar to the SMS services available from Yarra Trams and Connex Melbourne. Those existing services are in fact much more powerful than Metlink mobile. However, there is no such service on any of the bus lines, so it is new for them.

    Accessing Metlink timetable information on your mobile

    1. Open up your mobile's web browser. Of course, make sure you are connected to the internet blah blah.
    2. Navigate to - http://tt.metlinkmelbourne.com.au
    3. Here's where it gets tricky. It obviously is a prototype at the moment, so it asks you for the 'Stop ID'. See below for instructions on how to find out the Stop ID of your stop. For now, let's try a bus stop (9663 - Chadstone/Warrigal Rd/Holmesglen TAFE), a tram stop (18194 - Southern Cross/Spencer St), and a train station (19854 - Flinders St Station). Enter one of those Stop IDs into the Stop ID box.

    4. Select whether you want 'Monitor' or 'Countdown'. 'Monitor' means that it returns the time of the next few services departing from that stop. 'Countdown' means it returns the number of minutes until the service departs from that stop. The examples below will explain the difference.
    5. Click Submit.

    And that's it! There's not much more information available yet (e.g. no platform numbers for trains); although I presume they're working on it. Here are some sample results from the service (the tram example is using the countdown mode; all others are in monitor mode):

            

    Discovering the Stop ID of your stop

    Direct method - use this method if you know the name of your stop (generally its location)

    1. On your computer, open your browser and navigate to http://www.metlinkmelbourne.com.au/maps_stations_stops/station_stop_information
    2. Select which mode of transport you want to get on at that stop. Note - if that stop services more than one mode of transport (e.g. Flinders St Station has both trams and trains), it will have multiple Stop IDs, one for each mode of transport.
    3. Using the dropdown boxes in the 'Stop Search' section, find your stop.
    4. Now under the new 'Stop Profiles' section, you should see your stop. Click on the link.

    5. Now either,
      • look at the URL of the current page - the Stop ID is the number at the end of the URL, e.g.

      • or, look at the new 'Services from this Station' section (this is part of the new Beta timetable project) - the Stop ID is displayed at the top-right of that box, e.g.

    Via the route method - use this method if you don't know the name of your stop, but know the route that services it.

    1. Find the timetable page for the route that services the desired stop, e.g. http://www.metlinkmelbourne.com.au/index.php/route/view/956. The beta timetable pages work fine as well.
    2. Click on the desired stop to go to the Stop Profile.
    3. Follow step 5 in the direct method above.

    For the lazy people, here are the Stop IDs for City Loop train stations:

    • Southern Cross (Spencer St was a much better name) - 22180
    • Flagstaff - 19841
    • Melbourne Central - 19842
    • Parliament - 19843
    • Flinders St  - 19854

    Where to from here?

    At least Metlink is finally listening to their frequent customers and fixing their website and mobile access. The Metlink website is great for occasional use, but absolutely sucks for frequent travellers (I think I can subconsciously type in my stops into Journey Planner now that I've done it so many times). So among other things, can we have RSS feeds soon, please? Timetables and service updates are perfect candidates for feeds.Your view engine seems to be based on XML and XSLT anyway, so it won't be that hard to apply an XSLT to produce RSS.

    Oh, and the URLs for the new beta timetables are ridiculous. There has to be a better way of doing things. And My Way seems to be dead, not that it was ever very useful anyway. And please fix journey planner too - it sometimes produces incorrect times.

    And I hope you intend to have platform numbers, stop information, journey planner and service updates on the mobile as well.

    I could go on, but I think that's enough for now Smile

     
  • 10-feet is not 1 foot x 10

    TV just isn't what it used to be. It isn't just an idiot box where we can flick it on, channel surf mindlessly, change the volume, and turn it off when we're done.

     

     

    It's not just about tuning in to some pre-programmed channel anymore - its about gaming (PS3, 360, Wii), movies (DVDs, divx), videos (YouTube), photos, and plain old TV (FTA, Foxtel). Manufacturers have been working to make these increasingly complex devices easy to use; most significantly is what has been coined the 10-foot interface.

    The 10-foot interface refers to the user interface that's built into devices to allow users to access the variety of functions it has without having a button for every one of them on the remote (even though it feels like it does). 10-foot refers to the general distance the user will be from the screen. Most new TVs have menu systems, as do DVD and HD recorders, DVD players, and set top boxes to name a few.

    The most complex of all however, are the media center interfaces, e.g. MythTV, Windows Media Center (MCE), Tivo, Netgear's Digital Entertainer HD and Apple TV. These devices have enormous capabilities, able to watch/timeshift/record TV, watch DVDs, surf the net, watch YouTube videos, play music, control lighting, launch nuclear weapons at your neighbour for being too noisy... you name it, it can probably do it. To let you access all these features, these devices present layers upon layers of menus, all with a smattering of big-sized buttons (and more hidden by a keypress), all accessed via a remote from the 90s except with the number of buttons multiplied by a billion. Effectively, they've taken computer user interfaces, blown them up so we can see it from 10-feet away, added a splash of paint, polish and shine, and thought "that'll do".

    These devices are supposed to make our lives easier. Try finding a particular song on them and playing it. You'll either spend ages scrolling through your massive list of music, or you'll throw the remote at it in rage trying to key in the song title using the on-screen keyboard. My favourite exercise in frustration is trying to enter your wireless security key into them using a remote Smile.

    The humble remote is the weakest link in the whole experience. It started failing when VCRs became programmable, and just went downhill from there. Using it with a 10-foot interface makes me feel like a puppeteer - helpless and frustrated. While manufacturers upgraded almost everything else, the remote has conceptually stayed the same, and given minimal attention. Does anyone still use the number pad on it? Does any one actually remember channel numbers anymore?

    There have been third-party attempts to revitalize the remote, like the Logitech Harmony 1000 Universal Remote. But without proper manufacturer support, it's an uphill battle.

    However, the remote I believe, also holds the key to resolving the problem of operating these devices.

    Instead of jamming the whole user interface on to the screen, it should be separated - the presentation side (i.e. playing videos, music visualizations etc.) should be on the TV, while the operation side should be on the remote.

    Let's start with the remote. It should have minimal physical buttons, with the majority of the functions accessible via a touchscreen... with multi-touch, why the hell not Smile. The display should not show the content on TV, but rather the details of it, and the possible operations. It doesn't necessarily have to be in sync with the TV (i.e. linked so it shows the information related to what's on the TV) - what's important is that it controls it.

    In the music only world, there's already a few early examples of this:

     

    So in effect, the user interface, except the content, is moved on to something a lot more usable, practical and accessible.

    But that doesn't mean the TV should be devoid of any user interface. The problem with a setup as described above is that there is no longer a social component to consuming content (damn I hate that phrase). I'm not talking social over the net, but rather with the people in the same room. At max you could have about 2 other people squinting at the remote, and that's boring. 

    The TV should instead be both a presenter of content, and a secondary screen for the remote. So if I'm scrolling through YouTube videos on the remote, everyone else in the room should be able to see what I'm scrolling through on the TV. No buttons, options or anything superfluous - just the content I'm going through on the remote.

    Apple TV + a nicer looking interface + iPod Touch + a few more buttons would be a good start. But of course, Apple TV is only a 'side project'.

    It really isn't such a hard concept to bring to fruition, and would make these things a lot easier to use, but there isn't really anything out there like this that I know of (Pocket PC interfaces don't count - they're an ugly hack). Maybe the problem is that designing and manufacturing electronic components is costly compared to software development. Or maybe the skill sets required for it is so different to the skill sets these companies have that significant investment is needed. Or maybe no one else seems to think 10-foot interfaces in their current incarnation are a bad idea.

    I wish I had a few million dollars, a team of software engineers, a team of designers, a team of electrical engineers and a manufacturing plant handy sometimes...

     
  • It's Chumby time!

    For the last year or so, my HTPC has been laying dormant, only occasionally waking up. As cool as it was, it wasn't really practical - the screen was too small watch anything, and I had no room to put a bigger screen in my room. Plus it was just too fiddly and slow to navigate through my content with a remote. So for the last year, it has been working as a ridiculously overpowered alarm clock.

    It just became silly, and wasted a large amount of power doing nothing (yeh, I'm being green), so I looked around for something to replace it. Unfortunately, for some silly reason, cool, practical and alarm clocks just don't seem to mix, unless you went for an iPod alarm clock dock (e.g. JBL's OnTime) or a mini stereo system (e.g. Bose Wave II). The nicest one I could find was the Philips AJL308, which was good in concept, but had buggy and very basic software, plus the screen looked washed out and colours were uneven.

    Then I remembered the Chumby. It's hard to describe what it is, because it can do a lot of things. Essentially, it's a wifi-enabled alarm clock with a touchscreen. But rather than just syncing the time up with internet clocks, you can setup widgets and it will scroll through the information on your screen, including news, weather, engadget, digg etc. It is available in black, pearl or latte - I got the pearl one.

    At the point in time, it is US only so their store won't ship internationally. However you can use the various forwarding services out there to get one. I used PriceUSA who were awesome - great service, prompt delivery, and kept you in the loop through whole way. It ended up costing me around 250 AUD, which is a bit more than the 180 USD retail cost when converted even including shipping, but the options are few unless you know people in the US. None of the functionality is affected by the US limitation, although obviously most of the content available on it is US content.

    The out of box experience is great. It comes in a bag, not a box (although it was probably shipped in one for protection):

     

    Chumby in a bag

    Plug it in (you'll need to bend the pins or get an adapter to get the US plug working - adapter supports 240V fine though), turn it on, and you'll be prompt with the intro tour:

     

    Chumby intro screen

    The characters are funny, and the tour is actually useful. Alright, so the Chumby doesn't have the Apple 'brushed metal' cool factor to it, but has its own cute kind of cool feel to it. And it permeates through the whole device - it is designed to be like a soft beanbag, with soft leather sides and beans inside the bottom. You get a pack of 3 charms to add some bling to your Chumby, plus you have to give your Chumby a name, reinforcing the notion that it is yours.

    Next you have to setup network connectivity, otherwise the Chumby will be fairly useless. It supports everything up to WPA-PSK (plus hacks to make it support networks with landing pages). It only has wireless connectivity, so connecting a cable is out of the option (without other devices anyway).

    A few more settings have to be done, including timezone, and then its time to activate it with the Chumby Network. Activation isn't compulsory, but without it the Chumby would be fairly useless because all the widgets come from the Chumby Network. Again, its pretty painless, and at times very slick - the Chumby Network knew exactly when I had authenticated my Chumby and proceeded automatically.

    Once activated, a default selection of widgets are available on the device, including New York Times, engadget and chumball. You can pick and choose widgets from the Chumby Network website. Chumball is interesting because it is one of the few widgets that make use of the accelerometer built into the Chumby. Yep - it has an accelerometer built in. The Chumby device is full of unused bits, including the microphone on the front, and the battery connector at the bottom.

     

    NYT widget on Chumby

    It is worth noting that given certain conditions, the Chumby Network will inject ads into your widget stream, called a channel. At the moment, if you have less than 6 widgets in a channel, ads are avoided. This injection of ads isn't made very clear on the website which has disappointed some people. The argument is that it pays for the Chumby Network, and the ad model is similar to what you get on TV; after all, the Chumby is kind of like an internet TV. Most of the ads are videos (currently, there are CBS ads running), although the sound is disabled unless you tap the screen. Because it is a US device, the ads are naturally US oriented. I personally don't mind them, but others might and it isn't very clear in their product material.

    The Chumby can also be used as a fairly flexible music player. Music can be provided via USB, iPod (except the iPod Touch and iPhone as they lack the 'act as a disk' functionality), SlimServer/SqueezeCenter, or a variety of internet radio streams. The downside is that it can only play OGG and MP3 files/streams. That rules out a lot of internet radio streams out there, particularly the commercial ones, which broadcast using WMA. Reason is that WMA has a licence that is too restrictive. RealPlayer streams are also out, probably for a similar reason. Luckily, the Chumby team are working on a USB radio dongle addon to all you to tune into FM radio - the code is already mostly there, so it should be released soon.

     

    Music control on Chumby

    Sound quality is surprisingly good for a device this size. Bass is fairly non-existent, and the sound does get tinny at times, but it doesn't distort, even at high volumes. It is also loud enough to fill a decent sized bedroom - should definitely be loud enough to wake you up if it is sitting on your bedside table.

    Speaking of sitting on your bedside table, the device has a night mode as well, which dims the screen ahd only shows the time, so it isn't shining in your face at night and rotating through widgets for no reason.

    So back to the main use case - the alarm clock. You can set a particular volume, so it isn't blaring at you in the morning, and isn't so soft you can't hear it. You have the option of setting multiple alarms (not sure of the limit). For each alarm, you can set a particular day, weekdays, weekends, or a certain day of the week. The time can be set to the minute. You can choose what it should play from any music source, and for how long (so it won't keep playing continuously if you're not bed that night). There is a snooze function as well, and you can preset the interval (in 5 minute increments). Finally, you can make it do something when it activates, including turning night mode on/off, or changing to a certain channel.

     

    Chumby alarm screen

    It is definitely usable as an alarm clock, and even has a switch on the top for you to whack. But there are some deficiencies. Firstly, it has no battery backup feature, so if the power goes out, it won't wake you up (although the battery connector on the bottom is supposed to provide this functionality in the future). Also you cannot choose the snooze interval when the alarm is ringing - it will always snooze to the preset interval. It doesn't have a sleep function (although you can emulate one). And there is no increasing volume feature - the music just starts. Ok, maybe I am nitpicking a bit.

    From a typical person's perspective, it is a very usable and viable alternative to your boring alarm clock. As a bonus, it only consumes around 4 watts of power, which is probably on par with most alarm clocks even though it does a lot more.

    But that's only half the fun of getting a Chumby. The Chumby is designed to be hackable. It is based on an ARM processor, and runs a stripped-down version of Linux. You can SSH into it by activating the SSH daemon via an easter egg. The Chumby will also execute scripts on startup from an attached USB stick (give it a name of debugchumby and place it in the root folder of the USB stick), and you can override all sorts of things by having certain files on your USB stick. The Chumby wiki is a great source of information.

    The most painful thing when hacking the Chumby is probably cross-compilation. Because the Chumby uses an ARM processor, programs compiled for desktops (typically x86 or IA64) won't work on it. You'll have to set up a cross compilation environment on your Linux machine - the toolchain is available here. Even with the toolchain precompiled, it is still painful, as GCC support for ARM is still iffy in parts, plus the ARM processor has no floating point match coprocessor (only a software implementation) so many things (e.g. video and SETI@Home) are out of the question, unless an optimized fixed point version is available.

    I tried compiling ffmpeg and mplayer for WMA support (the inbuilt BlueTune player source code doesn't include WMA code, but does support it), but gave up after numerous tries (I'm not the most knowledgeable cross-compilation expert obviously).

    If only the Chumby used the new Intel Atom chip instead... then it might get a bit expensive :)

    Luckily, the Chumby devs have made various runtimes available on the Chumby, including Python, Ruby and Java. Stick them on your USB stick, and you're off - no more cross-compilation stuff, at the cost of performance, resources, and possibly functionality. I used it to load the python-based lastfmproxy so I can have last.fm playing on my Chumby - see here for details.

    Might have been more expensive than a typical alarm clock, but I definitely thought it was worthwhile (appeals to the geek in me, and is practical as well!). The major downside for me is the lack of ability to turn into commercial radio, via the internet or FM, but hopefully that will be remedied in the near future.