Toronto Ruby on Rails nite - not what you expect

15 January, 2009

So last night was the first Rails project night of the year and you know what ? I don't think I talked to one person about Rails itself other than the cursory "what do you do?" type conversations. What *was* interesting is I had no less than 4 different conversations with people about their professional development, be it their ideas or their careers - challenges they're facing, how to tackle things etc. It was kinda amazing, and made me realise just how important these project/pub/*camp evenings are. Being in a startup, or freelancer you don't have access to people to bounce ideas off, nor have access to professional development or HR teams. Last night really hammered this home. So if you're a team leader, a seasoned development vet, have built a business or two, etc and have a passing interest in Rails, you could do much worse than head out to one of the RoR related events, or any tech events, in Toronto. Ask someone what they do and you never know what kind of conversation you might have..

Read More

RubyFringe a new brand of awesomeness

20 July, 2008

Opening night and day 1 are over. Just about to go pick Krispy and head down for day two. Truly, my mate mates down at Unspace have done an AWESOME job. The vibe is amazing. A lot of "best conference ever" comments going round. Yes.. those are laptops waving in the air, and yes that is Zed on stage. Just look out for the mp3..

Read More

If there's one piece of advice I could give ..

16 July, 2008

So I've been thinking about things, thinking about the state of web development. What could I write about to could help out some new recruits and budding developers. (Note this is a long one, so get some coffee, sit back, read, and I'd love to see your thoughts and opinions at the end ...). In a nutshell: I have a rather entrepreneurial friend back in New Zealand, he consulted at a Software company I worked for once. Over time we became good friends.. One day him and his business partner came up with a widget. And sold a few, and then needed to sell some more. Then one day he gave me a call. You can imagine as a web developer the conversation "Yeah some some company wants [insert horrendous figure here] to build us an e-commerce site" pffwaaaattt (coffee all over desk)... And so began a new relationship. Realising the scope of work was BIG, I actually called up one of my dev mates. "Oi, I've got some work for us, keen?" Gave him the specifics. We agreed to do it 50/50 (side note, later on I ended up taking it on 100%). We struck a deal. I drew up a contract and we got underway. It's one thing sitting at a desk job, saying something will work, and then meh, it doesn't, this happened or that happened, whatever the reason, your thing doesn't work. There's a kazillion reasons why something won't work, or can't be done, or is late etc. Depending on your character this will bother you, or not (hopefully the former!). It doesn't *really* teach you responsibility. Now, taking someones money personally, and promising delivery of something, with nobody else to shoulder the workload. Now that's responsibility. There's only you and your Mac/PC. So long as the two of you are both in working condition, and you haven't bitten off more than you can chew well there's no excuses. Everyone reading this should be familiar with the actual mechanics of building something, but most often you're shielded from the business elements. Why are you building what you're building ? Is some Business Analyst telling you chinese whispers. Do you really know ? It's all about the vision. This isn't some contrived management tactic, there's a reason people put it on the top of briefing/requirements docs, if you buy into the ultimate business goal, then you will be far better at doing what you need to do. There is a famous saying in New Zealand - "Make the boat go faster" an entire army of engineers, yachtsman, craftsman, tacticians were all about one single minded goal - making the boat go faster (and they did, Black Magic won the Americas Cup). In our case it was all about selling the widgets. By being both a friend, and supplier, you realise you're taking money from this company, your friend, to build something. They're going to have to make that money up by selling product. So, you'd better do what you can to help them sell that product. By keeping the vision at the forefront of your mind you're not going to use technology for technology's sake. You're not going to waste time spending 10 hours getting some little bit working when it doesn't matter. You are going to learn how to prioritise - especially if you're doing this in your hometime. Once you've wasted 3 evenings in a row and not gotten any further along the path to completing your objective you'll quickly learn what's important! This WILL make you a better developer. Too often I read posts about the top x number of things looking for when hiring a developer. Technical brilliance is IMNHO focused on WAY too much. By doing the process from start to finish, you'll realise, the minor technical bits are quite small in the overall scheme of things (unless of course you need to build some ninja fast product requiring complex calculations) Note as I've been writing this Ilya put up a great post mentioning the jelly jar, another way of looking at this issue You will hear and see a lot people who are singularly focused on one technology, one piece of the puzzle, they're specialists. That's great. But a piece of code, or a sql call, or a config file does not a web app make. If you have to do everything from ordering a server to getting the finished app up and ready to login, you'll realise there are a lot of pieces of the puzzle. By doing everything yourself you'll begin to realise the other side of the fence is not as nearly black magic as you thought it was. Gaining experience in all aspects, from server config, mysql setup, dns setup, playing with cron will make you a lot more well rounded. By becoming more experienced in different aspects, you'll realise you can do a lot more. [As a side note, this is also why I think working in a startup, is a damned good thing. Every dev should do it at least once!] Along the way, your client is going to ask you for things, lots of things. And you're going to have to manage that feature request cycle. Now who knows better - you or the customer ? The just say no philosophy that is becoming pervasive in web app development school of thought is scaring me. My client loves it when stuff gets implemented. I don't just say no every request. Where stuff doesn't make sense, or can be done better, I talk through it with them. But if I just said no everytime. Well the relationship not likely go far. Don't get me wrong, I see it's place, but you have to use judgement, and know where it applies. Don't take it literally. When you're close to the customer, you'll realise their daily pain. Walk through the system with them, understand every support request - what lead to it, why, what can you do better ? Now, why did I say in my opening statement maintaining an app. Long term there is no greater thing than maintaining what you wrote. In our day jobs, we move on, client's move on, the code moves on. But invariably the business doesn't - it stays there and so does the site. By maintaining something yourself you get an appreciation for the movement in technology(when we first wrote this app, the nearest thing to a published framework were the PEAR libraries, nobody had yet come up with a solid stack). Now 3-4 years later I'm rolling in Rails into the mix. You'll understand the value of commenting the tricky bits. it always comes up as a reminder, just last week I was all over some code questioning "WTF did I do here?" especially when the business decision hadn't been written down beside the code. Along with gaining a much fuller appreciation of clean, modular, readable and reusable code. Also you'll get the chance to refactor and it makes you (well at least it does for me) feel good. Some crufty bit of code you haven't touched for 6 months, and you get to make it look better and work better. Nice ! This might seem counter to what I've been saying. But I think this is how a lot of new technologies get adopted. People are playing on pet projects and attempt to use a new technology. Doing your own app, you get to make the choice. It's either going to work or it's not. And you have to live with the win's or losses. Whereas in your day job there might not be anyway on gods green earth you're going to implement technology x as the impact on a large team is huge, but on your own time - it's your choice. You get to play with jQuery for instance (whichs rock extremely hard by the way), or mix and match Rails and PHP. Can you imagine what a system architect is going to say when you propose that in your day job? No f-cking way. Of course, you have to pick your moments and rationalise why you're choosing that technology. What is it really doing better for you... This is where doing a project for yourself shines. I saw a great clip by Tony Robbins the other day, must say I've never seen him before, and not likely to buy his products, however he did say something that that resonated with me loudly - too many people blame the lack of resources time,money etc but ultimately their failures are not about lack of resources, but the lack of THEM being RESOURCEFUL. This is what I'm talking about with this post. Maybe it's a really long winded way of putting it, but by building and maintaining your own app, in order to do it successfully you'll have to be resourceful. You'll have to learn, prioritise, be accountable, responsible, problem solve, etc and it will all matter because.. You'll get this at the end of the day. That's what I appreciate in developers. People who when faced with a challenge won't back down. They will find different approaches to a problem. They will try and try to get something running, they'll go away, rethink the problem and have another crack at it. Once done, they'll polish it, make it look work better/faster/ etc to acheive the end goal/vision. Having done that they'll take pride in it and say "I did that, I think it's cool and it rocks, and here's why ... ". Going back to my original opening statement, doing a project yourself gives you the opportunity to do so, virtually unrestrained. You'll get a tonne of challenges from technical, emotional, financial, time, the whole gamut. But by taking on the responsibility to do it yourself, (or be responsible for delivery yourself - you could farm the whole lot out, then you've got a whole new set of problems!), it means you have to meet and break through each one of those challenges. The only constraints in general, are your time and motivation. A number of years down the track you can look back on it, and go 'damn that feels good' When I get the chance to interview people one of my questions is always Feel free to answer it here, I'd like to see what makes other people tick..

Read More

Toronto Rails Night - Merb Presentation

11 June, 2008

Last night was yet another successful Toronto Ruby on Rails Nite put on by Corina Newby. The Toronto ruby community is rocking, evidenced by the large turnouts and fresh faces we see everytime. I'd guess 40-50 of Toronto's best and brightest Rails developers filled out the room. The unspace guys put on some much appreciated beer and made sure we're all informed about the upcoming RubyFringe (can't wait, I'm really hoping Zed's presentation is as exciting as his blog rants posts). Along with the other presenters of the night Mike and Libin/Wes/Carsten (up on TorontoRB.ca sometime in the next day or so). I did a presentation on Merb - The pocket rocket framework. Slides are are here (you may have to click through to the blog post to view if you're reading this in a reader/aggregator). Resource links are at the end of this post, and some discussion notes follow.. Presentation background Intended for people who are interested in looking at Merb, collating key points from blog posts, irc dicussions, mailing lists, and own experiences getting an app running with Merb (well the opposite way round, trying to get an app running and finding out those answers!). Hopefully the presentation collected a fair few hours worth of investigation into 20 or so minutes to help other people out Sports Bikes vs Sports Cars Useful analogy between Sports Bikes (Merb) and Sports Cars (Rails). Said cars have all the bells and whistles, everything is packaged up nicely, and it's pretty hard to hurt yourself, however given the nice packaging it's pretty hard to modify things. Sports bikes (Merb) on the other hand, are much more open to tuning, playing with, go faster, but need a bit more care Same same but different Rails and Merb apps are very much of the same likeness, but there are differences. Don't expect to be able to port code over 1:1 (especially if you've got a big reliance on plugins), and don't pepper the merb mailing lists/irc channel for "please make xyx behave like it is in rails merb-core & merb-more Two gems you need to get started (technically you only need merb-core). -Core is the stripped down bare minimum to get merb running. -more contains all the nice packaged goods to help you along the way merb-gen is your friend throw out script/* you're now doing everything in merb gen for generating your app, models, resources etc Key code differences refer to slides, but the code used is difference Agnostic in a very good way Merb is agnostic when it comes to ORM, test framework, js framework, rack adapator. merb-gen behaviour changes based on component used so if you're using rpsec, then stories get created vs unit tests. This is one of the reasons I'm very much into the idea of Merb Cool features part controllers, action args, router, covered off in the slides. Full apps, flat apps, very flat apps and thin servers and large grains of salt For performance stats (which are to be taken with a very large grain of salt). Hello world action on a single controller, rails would be about 300 req/s full merb app would be round 500 req/s flat merb app 500-550 req/s, a very flat app marginally quicker again, front a very flat app with thin (merb -I veryflatapp.rb -p 3000 -e production -a thin) and woah hold on, 1000 req/s ! Question was asked about benchmark figures and I made the point, they're going to be all over the place - it's easy enough to benchmark for yourself, that's the only thing that's really relevant. We know Merb is quick, just how quick will depend on your own application and uses. Merb, Rails and you The inevitable discussion at the end around, should you use Merb and how does it relate to Rails. Some of the goodness in Merb looks to be slowly being backported to Rails, so over time Rails will benefit from all of the wizardry going on in Merb (hopefully!). For those that like Merb's approach, and willing to forsake the vast library of rails plugins, and/or have very specific performance requirements and/or need to hack a framework around to do what they want. Merb looks to be killer. Ultimately it's upto you, so evaluate carefully. Resources Lots of link goodness..... http://merbivore.com http://wiki.merbivore.com http://merbunity.com http://merborials.com/ http://groups.google.com/group/merb http://github.com/search?q=merb http://mwrc2008.confreaks.com/ http://www.slideshare.net/search/slideshow?q=merb http://www.slideshare.net/search/slideshow?q=datamapper

Read More

Minor gotcha and shout out to Passenger crew

06 May, 2008

Okay so yesterday I found a behavior problem with passenger (1.04) in that

request.env['PATH_INFO']

was nil, whereas under Mongrel it was being set as we were expecting to the current path. Within less than I guess 2 hours of reporting it on #passenger, code was put in place and committed to github. Now how's that for amazing work ? You've got to hand it to the boys over at the Passenger team. I sat back in my chair at that point and thought about the days before dealing with open source. I recall a dev team I was working with found a bug in number handling with .NET, what could they do ? For all the money paid in licensing fees etc ? Nothing. Just code around it. Days like yesterday I really enjoy the open source community, it certainly has some major advantages. I still have a lot of testing to do before I'd happily switch a production app over to Passenger, but looking forward to the promise of better deployment that's for sure!

Read More

Rails + PHP sharing the same session

10 April, 2008

Ya know there's times in your life you do things that feel 'wrong'. This somehow feels that way, but one of my buddies wanted to know how it's done, so here it is: I've got an application I maintain in PHP which has been in production for a good number of years. It's stable, works really well, however like any application I need to keep putting in enhancements, the pain curve of doing this is exponential with the time I've been using Rails, so over a couple of years you can imagine the pain is pretty high. Last week I thought to myself, enough is enough. I'm sick of writing PHP, I could do this so much faster in Rails. I've been churning away on a rewrite in the background, in Rails as and where I have time but I wanted a 'fix it now' kind of solution. So, why not have the same virtual host serve out both Rails & PHP, so long as the Rails app can find out if a user is currently logged in, then I can piece by piece enhance/replace the PHP app. Turns out it was pretty damned simple. Here's a quick guide assuming 1- Both apps are sharing the same database 2- In the session you're storing a user_id of the logged in user 3- App uses cookies So here we go...

1. Virtual Host Config

The first thing we need to do is get Rails to run under the same vhost as the PHP scripts are run. This is easy, just adding a ProxyPass directive into the Apache vhost for the site back to your mongrel(cluster), so lets say we had a REST resource "some_resource", you'd add in the ProxyPass line below

    ...
    DocumentRoot "/path/to/your/php/app/html"
    ProxyPass /some_resource http://127.0.0.1:3000/some_resource
    ...

Note that in production this would pass through to a balancer of course. The unintended consequence of this is that you also can share all of your assets served from your existing app without having to duplicate them in your Rails app.

2. Sessions - PHP

The next thing for this to work is we need to know for the Rails app that the PHP app has logged a user in - we need to share the sessions. There's not too much black magic here. When you start your session in the PHP app (well at least mine!) PHP was storing in a named cookie eg "myappname" a hash value via

session_name( 'myappname' );

. This hash value is used to look up the session tmp files stored on the server, inside those session files are the serialized objects that PHP stores in $_SESSION global. So you have three options. 1. The "read from file system and unserialize the session" route 2. Store the session in memcached and have both PHP/Rails connect to memcached 3. Use the db to store sessions and logged in user_id's, then load the user on each page load. Note there is a page on this on the rails wiki, devoted to approaches 1 & 2. However if you're not storing a tonne of variables in the $_SESSION then approach number 3 - the path of least resistance - will likely be just dandy for you... In my database I created a shared_sessions table - using a rails migration (detailed in step 3 below) This stored a unique key "session_hash", as well as other fairly understandable columns "user_id", "updated_at". As we're logging in and out from the PHP app, this will mostly maintain the sessions table. So I added a quick couple of functions Application_SetSession() and Application_ClearSession(). Application_SetSession() simply writes into the shared_sessions table the hash value from the cookie $_COOKIE['myappname'], the corresponding user_id, as well as the time of update, it looks something like this:

function Application_SetSharedSession($user_id)
{
    global $DB;
    $session_hash = $DB->real_escape_string($_COOKIE['myappname']);
    $qry = "REPLACE INTO shared_sessions SET `session_hash` = '{$session_hash}', 
                      `user_id` = '{$user_id}', `updated_at` = NOW()";
    if ( !$DB->query($qry) ) throw new DBException($qry);
}

ClearSession() clears out the appropriate shared_session record. As you can well imagine ClearSession() is called when the user logs out, SetSession() when they login as well as every page load. Your PHP app will now be setting/clearing the shared_session records as appropriate.

3. Sessions - Rails

  rails myphphack
  cd myphphack
  script/generate model SharedSession
  script/generate model User
  script/generate scaffold SomeResource name:string ... 

Right now you need to fill out the SharedSession model's migration, and delete the user model migration (it's already in the database!). In the SharedSession migration, make sure you're setting the unique index on session_hash, otherwise REPLACE INTO won't work. So, first we need to load the user on the Rails side. To do this we need look up the SharedSession model for the session hash, from the cookie that was set by PHP. It's available of course, doesn't care who set it we have access to it.

class ApplicationController < ActionController::Base
  before_filter :restore_user
  ...
  protected
  def restore_user
    unless @user = User.restore_from_php(cookies[:myappname])
      redirect_to '/login.php'
    end
  end
  ...
end

On the user model, we now need a method to find the user from the session_hash:

class User < ActiveRecord::Base
  has_many :shared_sessions
  def self.restore_from_php(session_hash)
    find(:first, :include => :shared_sessions, 
          :conditions => ["shared_sessions.session_hash = ?", session_hash])
  end
end

Easy peasy.

4. Testing time

Run the migration, fire up a mongrel instance on 3000, hit the appropriate vhost, login to your PHP app and go to /some_resource. With any luck you'll be able to hit the /some_resource path with a logged in user.

Now then, it's not quite that simple

The astute ones will notice "Hey what happens if I login from PHP, see /some_resource, then come back directly to /some_resource in future - I could do this at any point in the future, it won't log me out". Exactly, you can handle this one of two ways. Either some nasty cron job thing to clear out the SharedSessions table, or do it as part of the load_user filter in the rails app - ie before restoring the user, SharedSession.delete_all("updated_at < DATE_ADD(NOW(), INTERVAL -15 MINUTES)") or whatever matches your current PHP session timeout settings. You also probably want to do some hash of the user agent, ip address etc and store this away in the shared_session table, then check against it whenever you're finding if a user exists, to try to eliminate cookie theft.

The fine print

It's pretty simple and it works in testing... YMMV. Test the hell out of it in your own application.

Read More

Rails vs Merb & ActiveRecord/Datamapper

19 February, 2008

If you're getting to this page from searching "Rails vs Merb" I suggest you read/view this presentation I did http://work.rowanhick.com/2008/06/11/toronto-rails-night-merb-presentation/ Following on from my presentation last week, I had someone mention I should look at Merb+Datamapper if I'm looking for something awesomely fast. So I decided to put it to the test. This is a *completely* contrived - I've done enough benchmarking to know this, so take the following figures with an (extremely) large grain of salt, I'm just posting this for interest. The view being rendered is a real world view that I'm using for a rewrite of a PHP/MySQL app, listing out orders by order status, along with their customer and originating country. I've got a database of Orders(770), OrderStatuses(17), Customers(300), Countries(244). I have a find by sql statement I'm using to pull upto 100 orders like so: "SELECT orders.id, orders.created_at, customers.name as customer_name, countries.name as country_name, order_statuses.name as status_name FROM orders LEFT OUTER JOIN `customers` ON `customers`.id = `orders`.customer_id LEFT OUTER JOIN `countries` ON `countries`.id = `customers`.country_id LEFT OUTER JOIN `order_statuses` ON `order_statuses`.id = `orders`.order_status_id WHERE (order_status_id < 100) ORDER BY order_statuses.sort_order ASC,order_statuses.id ASC, orders.id DESC LIMIT 100" The same statement is used in all 3 applications, along with the same generated html. All 3 apps were run daemonized in production mode using mongrel. The resulting page is comprised of a layout + js + css files, that each app is serving identically. Using Rails: 42.16 req/s (baseline) Using Merb + ActiveRecord: 57.80 req/s (1.37x) Using Merb + Datamapper: 72.98 req/s (1.73x) So lets up the order count to 11550. As the volumes of data goes up (and therefore database tuning becomes more important) these are the following figures... Using Rails: 22.82 req/s (baseline) Using Merb + ActiveRecord: 29.85 req/s (1.30x) Using Merb + Datamapper: 33.91 req/s (1.48x) Merb+Datamapper still outshines the competition, but the difference in performance isn't quite as significant, however once the DB is tuned, I bet life gets more interesting.... Again before I get lambasted, take the figures with a grain of salt, the times do vary quite significantly as there are variables aplenty, just look at the general trends.

Read More

require, RMagick, and case sensitivity

19 December, 2007

(At least on Leopard with Ruby 1.8.6) Ruby will try to reload rmagick if you get the case of rmagick different from the original require. And when that happens it all goes up the whop. We were using attachment_fu's image magick processor, then doing a require 'rmagick' seperately which resulted in tonnes of errors like this

/usr/local/lib/ruby/gems/1.8/gems/rmagick-1.15.10/lib/rmagick.rb:32:
  warning: already initialized constant PercentGeometry

Keep your case's of require's consistent. Even if this is file system dependent behaviour in mixed development environments you can imagine how weird problems could get!

Read More

Gotta love *those* recruiters

01 November, 2007

From a blanket spam email I (and probably a good portion of the rails community just received) "I have a direct client who is seeking a strong Programmer who posses experience with Rudy on Rails. If you are qualified and interested, please send me your most current resume in a word.doc format to.." Yes, Rudy was actually put in bold, just to place even more emphasis on the spelling error.

Read More

Using Rails with Flex to manage long running tasks

31 July, 2007

UPDATE Jul 2008 - The API for BackgroundRB has changed and docs improved significantly since this blog post. Read the latest API calls over here http://backgroundrb.rubyforge.org/rails/. Don't reference the Rails code below if using latest BackgroundRB As soon as you start doing anything with photos sooner or later someone says "It would be really nice to upload these in a zip file", which then leads into a whole rabbit warren of issues, one of which you will inevitably come across is how to deal with a long running task on the server, in terms of a) getting it to actually complete and b) telling the user what's going on. There are various hacks for doing these, like running a shell script and writing out tmp files all over the place. Just plain ugly. Enter Backgroundrb, probably one of the greatest little inventions for Rails. It lets you kick off a background process, outside of the main rails app process, with the option to interact with the rails models or not. The beauty of this plugin is a little thing called MiddleMan, as the name implies it lets you interact with your background processes (Workers) from your Rails app. So, this gives us the ability, from your Flex app to invoke a Worker on the server side, then monitor that Worker until it's finished, and/or kill off the worker if need be (for slacking on the job?). What do we need. 1. First off install BackgroundRB from here. 2. Next we need to create our worker in your Rails app dir 'script/generate worker ResizerWorker . Here's a simple chunk of worker code.

class ResizerWorker < BackgrounDRb::Rails
  def do_work(args)
    @total_images = 50
    @current_image = 1
    50.times do
      @current_image += 1
      sleep(1)
    end
  end

  def get_progress
    @current_image < 50 ? status = 'In progress' :  status = 'Finished'
    info = { :status => status, :current_image => @current_image, :total_images => @total_images}
    return info
  end
end

As you can see we have a do_work method which is generated by default, this is called whenever the worker is instantiated so it kicks off our work to be done. Then I added a get_progress method to return a hash of the worker's current status. 3. Great so now we need to kick it off, there's some options to do this automatically at timed intervals, but I'm not going to go into that here, all we're doing is getting our rails app, by a web request to start/stop and monitor the progress (the web request is then called from Flex) . So we create a watcher controller, with actions 'start_task', 'status' and 'stop_task' as below which is all pretty self explanatory:

class WatcherController < ApplicationController

  def start_task
    session[:worker_key] = MiddleMan.new_worker(:class => :resizer_worker)
    info = {:message => 'job_started', :key => session[:worker_key]}
    render :xml => info.to_xml(:dasherize => false)
  end

  def status
    @worker = MiddleMan.get_worker(session[:worker_key])
    if @worker
      info = @worker.get_progress
      if info[:status] == 'Finished'
        MiddleMan.kill_worker(session[:worker_key])
      end
    else
      info = { :status => 'Finished' }
    end
    render :xml => info.to_xml(:dasherize => false)
  end

  def stop_task
    @worker = MiddleMan.kill_worker(session[:worker_key])
    info = { :status => 'Task Stopped' }
    render :xml => info.to_xml(:dasherize => false)
  end

end

Gotcha! I found out the method names in the Documentation, on MiddleMan, were wrong compared to the version I had installed. I needed to use .new_worker, .get_worker and .kill_worker. 4. Fantastic, so go into console, do "rake backgroundrb:start" in your rails directory, then fire up a rails server. You should now be able to hit http://localhost:3000/watcher/start_task, http://localhost:3000/watcher/status, http://localhost:3000/watcher/stop_task and see the appropriate results. 5. Now you can fire HTTPService requests on the Flex side and consume the results as required. For example : (for the sake of berevity I haven't put in any timer function to recheck the status, just a manual click event)

	
		import mx.rpc.events.ResultEvent;
		import mx.controls.Alert;

		private function onSvcWatchTaskResult(event:ResultEvent):void
		{
			trace(event.result.valueOf());
			var info:XML = XML(event.result);
			pbProgress.setProgress( info.current_image, info.total_images );
		}

		private function onSvcStartTaskResult(event:ResultEvent):void
		{
			Alert.show('Task Started');
		}
	





	
		
		
			
			
			
		
	


And there you go. A few seemingly simple lines of code has knocked off one of the age old problems of dealing with long running tasks. I heart Rails (and Flex).

(As always with code examples, don't copy and paste, rewrite it yourself. You'll understand it better and won't copy in any errors I've made whilst cutting it down for blogging)

Read More