• Getting started with StageVideo is fairly simple. The article on getting started spells things out well, and while the StageVideo object is quite different from the regular Video object, it's not hard at all to use.
• Things can get tricky when using StageVideo with a complicated player given the fact that StageVideo sits below all objects on the display list. If you had your Video object added on top of a complicated display, you'll need rework this.
• You can use StageVideo in a player that doesn't require Flash Player 10.2 Try loading the Brightcove player page in a browser using an older version of the Flash Player to see this- it can even be loaded with Flash Player 9. This isn't done too easily but can be managed with loading the StageVideo code in its own SWF as needed.
• The StageVideo numbers are impressive, as shown in the link above. I heard more than one person surprised at how much it knocked down the processing power needed on their machine.

I'm more than happy to answer questions- email me at bdeitte at brightcove dot com for anything you'd like to know.

I wrote another "come work at Brightcove" post nearly four years ago. How time flies... most of that post is no longer relevant, but the view is the same.

Tickets are still available for the two-day conference that has a lot of exceptional speakers from the Flash community. It also includes a night of geeking out at the MIT museum.

And a welcome back to any blog readers! I've had one month absences from this blog of five years, but this is my first six month absence. I don't expect to keep up very well in the short term, but the blog ain't dead yet. You can also hear from me on Twitter or at brian at deitte dot com.

To anybody reading this who wasn't at the conference- I talked a lot about each slide and don't have any of those notes in the presentation. I'd be happy to explain anything more in the comments.

How RIA Advertising Works And a Little Bit About Brightcove

I've been building advertising SDKs for more than a year at Brightcove, and I want to share the things that I've learned about how advertising works- we'll go over the basics of advertising (CPMs, Mad Men, ad networks), the life of an ad (ad policies, ad delivery, impressions), and the emerging standards (VAST, VPAID). It will be a very technical dive into an area that many of us make our living off but which not a lot of people understand. A coworker of mine, Melissa Gregory, will also be giving a ten-minute introduction to Brightcove at the beginning of the talk.

The presentation I'll be giving is a sponsored presentation for Brightcove. I don't want this to dissuade those who just want to hear about RIA advertising, as my goal is to make this a talk that's the same as the non-sponsored talks at the conference. Being a former speaker at 360Flex in Seattle, I know I can make this happen, no matter if you use a different video platform or none at all.

I'm happy that Brightcove is a Bronze sponsor at the event. We'll have a booth there, which I'll be manning at points and where you can learn more about what we do (and pick up some schwag).

Not signed up for 360Flex? If you can get to San Jose in two weeks, you should sign up now. This is the original Flex conference, and the people who attend make it a one-of-a-kind event. I went to the first 360Flex in San Jose as well as 360Flex in Seattle three years ago. I met so many incredible people at both events, and I'm sure it will be the same at this one.

As a hopefully-obvious cavaet, these are just my reasons and have nothing to do with Brightcove. We have plenty of excellent people focused on the JavaScript side as well here, and I'd read Jeremy Allaire's post on TechCrunch if you're looking for a more Brightcove-centric response.

November 4th at 7pm
One Cambridge Center, 12th Floor
Cambridge, MA

EventDispatcher should expose list of attached listeners went from 4 votes to 16 votes.
Include FlexPMD went from 3 votes to 9 votes.
Expose more of "additional compiler options" in the UI went from 3 votes to 12 votes.

If you haven't seen them yet, there's plenty more voting suggestions in another post on mine (although two of them have already been fixed in 10.1).

My logs show that the blog post was viewed 840 times. I'll take off more than half of that number to account for crawler visits, people who didn't read the article, etc. So that leaves us with 400 people who could have voted on a bug.

Keeping 400 people in mind, here's what I see for the bugs that I entered in the list:

EventDispatcher should expose list of attached listeners. 4 votes
Include FlexPMD. 3 votes
Expose more of "additional compiler options" in the UI. 3 votes

That's a depressing voting percentage. There are a lot more bugs in the original post, and they don't look to have changed much in numbers either.

So why didn't people vote for these bugs? Here are my guesses:

1. You find it too much effort to vote for bugs

This is probably because you don't want to spend the time to register for an account. To show how easy this is, I just signed up for another account (which I will use to double vote for everything*). It took me less than 3 minutes, and most of that time was waiting for the email registration. The total time in which I was really doing something was less than a minute.

After you have an account, you can vote by clicking on a link in the left-hand column of the bug report.

It does take a bit more effort to create new bugs for things that are bothering you, and I know I haven't been very good at this. But I've been getting better as I've been thinking more about point #2.

2. You don't think voting for bugs matters

You voted for a bug that got deferred without explanation, or an enhancement that feels like it's being ignored. Or you've read stories about this, or you just don't believe anybody pays attention to a few votes on here.

I can understand why a lot of people would think this, but I think they're wrong. Unless things have changed dramatically since I was on the Flex team, opinions like this matter a lot to the team and future planning. The thing that's hard to see from our outside-the-team perspective, however, is all the other inputs going into the decision of what gets done or not. There's corporate goals, other internal team requests, what will make money, what people on the team want to work on, etc. So it isn't the only "vote" on the matter, but I think it's a very important vote.

3. You didn't like the bugs I entered

Now this is a reason that I can completely understand. Maybe you're focused on the Gumbo components, or better data services, or you just want more cowbell. In any case, if you didn't like the bugs I pointed to, I hope you're finding or entering the issues that concern you.

4. You don't have to vote to get something fixed... you have other ways

I think this only works if you're Doug McCune or work at Adobe.

* Of course I'm kidding about double-voting. Unless FP-444 doesn't really get fixed.

I'm missing MAX to keep my wife company as we expect our first child when it gets a bit more cold out. So if you don't hear me blogging for a few months, this is the reason. :)

Below are my top requests for the Flash platform. Most of the links are to associated bugs. I created a bug if I couldn't find an existing one and the request wasn't too generic, and of course I voted for all of the ones I found. Please vote for them yourself if you'd like to see them get worked on.

As a hopefully-uneeded cavaet, especially to all the members of the Flex team that I used to work with, this list doesn't mean I don't continue to go all googly-eyed for the Flash platform. Also, I mention Brightcove a few times below, but this is just my personal wants- I don't mention anything about FMS, video encodings, or the other possibilities for others at Brightcove.

Now on to the good stuff, in no particular order.

Flash Player and AS3 improvements

More compiler optimizations for smaller SWFs. Some of this covered by a bug, although its title is harsh. Some can be found in the new and very intriguing project called TAAS.

Mobile versions of the standard Flash Player. I know there's been announcements about this, I know multiple ways I'd want to use this at work and for play, and I don't think I need to say anything more on this one.

Get all classes in the player. I've needed this more than once, but I don't remember the scenarios anymore. It'd definitely be helpful for frameworks.

Private/protected constructors. Ted's post mentions that this is in the works, but I'm still noting it since it's marked as Open.

Abstract classes.

Ability to catch all uncaught errors. The bug is Under Investigation so this may not need any more votes. I could use this in multiple scenarios, both for testing and general error logging.

Include flexcover or create a new code coverage tool. And after this is done, I'd love to see support for this in Flex Builder, something at the same level as the profiler support.

EventDispatcher should expose list of attached listeners.

Headless player for unit tests. I heard at MAX last year that it's possible that the Ichabod player that's being used for search could be repurposed for this, which also has some tricks in it for not waiting as long for code to run. Having a headless player that could also run unit tests faster would be fantastic.

Flex SDK improvements

I want to first note the absense of Spark bugs and improvements in here. I've spent most of the last year working in straight ActionScript rather than the Flex framework, and so while I've read a lot about them, I haven't had much time to play with Spark components and Catalyst. They look interesting and helpful, but until I start building things with them, I can't add anything it to my requests. And I'm not sure many of my requests would be higher than the other items on this list.

Even faster compiles. A lot of work went into Flex 4 for this, but an even faster compiler would make me even happier. This isn't necessarily a Flex SDK thing, and there is a Flex Builder bug open for this. Since that's the top-level, with possible work needed at the Flex SDK and AS3 level as well, I'll put my vote there.

Binding improvements. What improvements are needed would just be based on what would most help out the performance of an application that uses bindings thousands and thousands of times. One-time binding and Support delayed evaluation of MXML bindings are good possibilities.

Allow compilation in the SDK using FlexBuilder project files.

Flash Builder improvements

Flash Builder on Linux. We use xen boxes with Linux at Brightcove and not being able to use Flash Builder there makes me sad. I assume that design view is the problem for this, and having Flash Builder without design view on Linux is is completely fine with me.

Support QuickFix for developer productivity.

Include a code formatter. The third-party plug-in for this that's mentioned in the bug is great, but having built-in support (hopefully leveraging the existing project) is much better.

Include FlexPMD. See the previous comment about built-in support being
better.

Generate Handler in ActionScript.

Expose more of "additional compiler options" in the UI.

Better refacoring support. I've noticed the name of a coworker of mine as the submitter of a couple of the bugs I've mentioned in here, and his name comes up on all but one of the bugs below. Adam Brod entered a lot of much-needed bugs for refactoring, and I think it's good to call out all of the ones I'd like to see below individually to recognize that these can be a very large bucket of things to do (and every one would be appreciated):
Move refactoring
Pull Up/Push Down/Change Method Signature Refactoring
Extract Method Refactoring
Extract Local Variable Refactoring
Extract Constant Refactoring
Inline Refactoring
Convert Local Variable to Field
Extract Superclass
Extract Interface
Use Supertype Where Possible
Introduce Indirection
Introduce Factory
Introduce Parameter Object
Introduce Parameter (not Parameter Object)
Encapsulate Field
Create Script (refactoring scripts)

Other Requests?

If you find yourself agreeing to a lot of the bugs above and have other bugs and features that you'd like to see done, please link to them in the comments so that I can vote for them. Thanks!

I'm very interested to see the extensions that come out of this. Here's some possibilities:

• custom metadata processing that's similar to Java's annotation processing, which someone is already working on
• a better-integrated version of flexcover
• different databinding solutions
• conversion of more media types for embedding
• SWF size reduction with new compiler optimizations
]]> http://www.deitte.com/archives/2009/08/flex_compiler_e.htm http://www.deitte.com/archives/2009/08/flex_compiler_e.htm Flex Sun, 02 Aug 2009 23:05:57 -0500 I'm a week late in my posting on this, but as I've been horribly behind in my posting lately, I'll just ignore that fact. And I still wanted to be able to point out the Flash multi-touch goodness. I can't wait to see the finished APIs and play around with them.

Relatedly, while Brightcove has had an iPhone integration for awhile, I didn't realize that other people were watching video through Skyfire, which will soon be making its way to Blackberry devices.


]]> http://www.deitte.com/archives/2009/07/flash_on_phones.htm http://www.deitte.com/archives/2009/07/flash_on_phones.htm Flex Sun, 26 Jul 2009 21:43:00 -0500