Understanding a larger application

May 7, 2009 at 8:17 pm (Flex, Java, Ruby, Week 7)

After a couple of hours this morning going through the web, searching for a way to make native OS calls from ActionScript (in Adobe AIR), I’ve come to the conclusion that right now, the only way to do it is to wrap AIR in another application like Shu. Mike Chambers also has a proof of concept for another wrapper called CommandProxy. I’m not sure yet whether we’ll go in that direction or not, but this seems like a big strike against using AIR. The idea is that for this application, we’d need to completely control the desktop, eliminating things like Cmd-Tab (or Alt-Tab on Windows), Alt-Cmd-Esc (Ctrl-Alt-Delete on Windows), etc.

It’s always frustrating to dig around on the internet looking for a way to do something and in the end coming up short. What kills me about it is that there’s always that chance that the solution you’re looking for exists, but it’s difficult to find. I can’t imagine being a programmer before Google; I can see myself getting stuck for days on things. On the other hand, at a company like 8th Light, my best (and quickest) bet is usually just to ask around. But in this case, there are no confessed ActionScript gurus here. At any rate, whether the work I’ve done gets used or not, I’m impressed to realize that I don’t really have to spring for the $249-$699 Flex Builder application to play around with ActionScript and Flex.

The rest of the day, Micah, Doug, and I worked through some story work (even looked briefly at some Objective-C code) and ran into some issues with bundling JRuby gem files in a jar. I’m inspired to try and recreate the problem here at home, so I’m looking forward to a fun evening of learning about java -jar (and JRuby), with the off-chance that I’ll actually figure something out. It was really cool to see the way Micah and Doug reacted to the problems. Basically, after exhausting all of the permutations and possibilities we could think of, we took a step back, evaluating what we were trying to do at a higher level, and realized that while we need a solution for this problem eventually, we were OK for now and didn’t need to bash our heads against a wall. The solution will come, and tomorrow it will be easier than today.


Permalink 2 Comments

Prime factors and the first client project

May 6, 2009 at 6:34 pm (Flex, Java, Limelight, Ruby, Scheme, Week 7) (, , , , , , )

I worked with Doug almost the whole day today, which was great. This morning when I came in, I happened to mention that last night, I’d done the prime factors kata, inspired by tweets from Doug and Caleb, but I used Scheme: the results are in a Gist. It was pretty frustrating trying to do this in a functional style, purposefully avoiding defining anything other than functions, but I sure learned how poorly I understood Scheme’s list-building constructs (cons, cdr, and car). I have a feeling there are clearer ways to do this, and I’ll definitely try again at some point to make it more fluid (I was completely stumped several times).

So, we spent some time in the morning working through the kata in C++, which was awesome. I hadn’t written any C++ since my only CS course in college, around 10 years ago, and what I wrote then was of course very simple. We used CPPUTest as our unit testing framework, but luckily, Doug already had the tests constructed, so we uncommented one at a time and concentrated on the implementation. I’d like to look into testing C++ a bit more at some point, but it may be awhile, considering all the other things I’m learning. We found several variations on the process of solving this problem, and the process of solving it became clearer, slowly but surely, as we worked through it several times. Then Doug said I should “perform” the kata for Caleb, which I did in Java (and in the process learned how much I rely on my IntelliJ Live Templates when I’m writing JUnit test code!) At some point I may try my hand at screencasting and record myself performing it, but I think I need a little more practice first!

Later on, after I struggled through setting up FlexUnit for the small AIR/Flex I’m building, Doug helped me get my bearings in the client project I’m working on now. We were writing Ruby, HTML, and JavaScript code most of the day, though Objective-C is also part of the project, and Flex/ActionScript may be eventually. It was awesome to be working on a bigger project and finding myself able to figure our what’s going on relatively quickly. My Limelight experience with Tic-Tac-Toe definitely paid off – if I hadn’t spent some time with that, there’s no way I would’ve known what was going on today. Of course, the technology itself wasn’t the sole aim of the Limelight Tic-Tac-Toe project – visual design was a big part of that, too.

At any rate, I’ll obviously have to be a bit more vague about project details now, but I’m excited to be getting into some client work, and I know I’m going to learn a lot from seeing Doug and Micah code on a regular basis.

Permalink 2 Comments

Flex, AIR, and ActionScript, oh my!

May 5, 2009 at 6:00 pm (Flex, Week 7) (, , , )

I’ve thought for a long time that I’d like to have at least a cursory knowledge of ActionScript (the scripting language that runs on Adobe’s Flash platform), and once Flex became more well-known I thought of it more often. Today Micah gave me a reason to actually get into it a little bit. My assignment was to investigate AIR, Adobe’s newest platform, which allows you to run Flex applications outside the context of the browser as regular desktop applications. The idea is sort of a kiosk-mode application for a client, and while I encountered (and partially) some technical problems with Flash’s security mechanisms, I also gained some reading knowledge of ActionScript and MXML, the markup language for Flex.

I haven’t done anything really interesting yet as far as layout goes, but it was super-easy to embed basic web browsing capability into the application:

height="100%" width="100%"
location="http://www.google.com" />

I only did some very basic ActionScripting, but it shares some syntax with JavaScript: the var keyword for local variable declarations and the function keyword for, well, you know… On the other hand, ActionScript has classes, which is of course more like Java. The technical issues I ran across forced me to look into a good bit of event and listener code, which is good for me since that’s probably the aspect of JavaScript I understand the least. Luckily, I happen to know an ActionScript master from my Athens days, and he was able to set me straight on a minor limitation of the Flash platform.

There’s a little weirdness in the construction of an AIR application. A lot of the just-starting documentation assumes that you’re using FlexBuilder (Adobe’s expensive IDE), and I’m not. Also, you can do a lot of behavioral programming in Flex either with ActionScript or with MXML. I wasn’t sure how to get started with plain old ActionScript, so I have kind of a bloated MXML file at this point (all my ActionScript is embedded in mx:Script tags). I’m sure there’s a way to extract that to another file, but for now I’m just spiking to see if this is a technology that will work for our client.

The big question marks left have to do with packaging up the AIR runtime (and with it, I suppose, Flash itself, in case that’s not installed) so that the install of our application would include the installs of Flash and AIR. Once I finish tracking down the answers to Micah’s questions on AIR, I’m going to be joining him and Doug on their project. I’m very much looking forward to having more opportunities to see them in action coding, and also to be working in a new domain. Also, their project has one component written in Objective-C, so it will be cool to at least get a bit of reading knowledge in that language.

Permalink Leave a Comment