Wednesday, June 15, 2011
Torey Pudwill
Drops the best inspirational video of 2011. Back-lip, kick-flip, back-lip. Massive lazerflip. 360 kick-flip over bench. Kick-flip into waist-high back-smith. What?!
Wednesday, January 12, 2011
RTMFP and FMS on AWS
For the folks out there who would benefit from the full RTMFP Groups functionality provided in FMS 4 but who balk at the up-front server licensing fees, there's a new path to potential fame and fortune:
- Grab the developer addition of the FMS 4 server (get the trial) and a client-side dev tool of your choice, with my strong recommendation being Flash Builder.
- Develop your world-changing P2P application.
- Deploy your server-side logic to an FMS 4 instance(s) on AWS:
http://www.adobe.com/products/flashmediaserver/amazonwebservices/
Also, Jozsef has a great new(ish) article up that discusses strategies for fall-back to handle the situation where clients who wish to establish a direct P2P link may fail to due to poorly behaving NATs or firewalls. FMS on AWS will happily support both RTMFP and RTMP/T/S/E clients and is a great place to put Jozsef's strategies into practice!
Sunday, October 31, 2010
Saturday, October 30, 2010
MAX 2010
My colleague Asa Whillock and I presented a session at MAX 2010 this past week. The session was recorded and the video as well as the slide deck is already publicly viewable at the MAX archive site. The session was titled Secure Enterprise Video Streaming with Flash Media Server and P2P and that does a fair job of summing up everything we covered.
If you're curious about the new RTMFP protocol support in FMS 4, how that's allowing us to really take advantage of the beautiful scaling story with IP or P2P (application-level) multicast as well as the fusion of both at the same time, and how we're putting it to work within Adobe right now, watch the session and take the server for a spin.
If you're curious about the new RTMFP protocol support in FMS 4, how that's allowing us to really take advantage of the beautiful scaling story with IP or P2P (application-level) multicast as well as the fusion of both at the same time, and how we're putting it to work within Adobe right now, watch the session and take the server for a spin.
Wednesday, September 9, 2009
D
Wishing I had the free time right now to really play with D2... Andrei Alexandrescu published a nice, reasonably brief, overview at Dr. Dobb's earlier this year, and it's definitely worth the read.
Wednesday, February 4, 2009
Mission One
Maybe it's time to dust off the motorcycle helmet, boots, and gloves languishing in the garage and get that motorcycle license I was planning on two years ago...
Not that I have the spare change, or the spare time, and I do have a young daughter to consider, but wow. The world's fastest all-electric, from Mission Motors of San Francisco.
Not that I have the spare change, or the spare time, and I do have a young daughter to consider, but wow. The world's fastest all-electric, from Mission Motors of San Francisco.
enums
Back in the FDS (Flex Data Services) days we were stuck supporting Java 1.4.x. Hence, no enum support because they weren't available in the language until 1.5. But things changed awhile back when BlazeDS and LCDS up'ed their base supported JVM to 1.5.
However, just because we could now support enums in the JVM at the server didn't mean anything to the AVM (ActionScript Virtual Machine) at the client.
ActionScript (and ECMAScript) doesn't provide a native enum type. To complicate matters futher, the flash.utils.IExternalizable interface doesn't provide the writeReplace() and readResolve() hooks that the java.io.Externalizable interface defines. When you're deserializing a raw byte stream into an object graph, you need a readResolve() in order to handle enums (singletons).
Java enum serialization can't be overridden at the server, which is good! It's good because this means that enums are always serialized and deserialized according to a consistent recipe. When they're serialized in Java-land (ignoring AMF for a moment), their String name value (as returned by the name() method) is all that's written to the byte stream. When they're deserialized, a single String value is read from the byte stream and passed to the enum's valueOf() method. The returned singleton instance is then readReplace()'ed into the resulting object graph.
Based on this behavior, BlazeDS and LCDS send Java enums to your Flex app as Strings. If the client needs to send an "enum" to the server, send the String value for the enum, and it'll be unpacked as the desired Java enum instance at the server.
But some folks want more than a simple String at the client. As I mentioned earlier, lack of native enum types in ActionScript coupled with lack of a readResolve() hook on flash.utils.IExternalizable makes this impossible. On top of that, when the Java enum instance is written to the AMF byte stream at the server, the AMF type prefix is for the native String type. That means the server-side type name for the enum isn't included in the byte stream so attempting to use registerClassAlias() or [RemoteClass(alias="...")] is futile (and you wouldn't want that anyways without a readResolve() hook at the client).
If you're deadset on representing these values as typed singleton instances at the client, you'd have to do something wacky like manually traversing the data returned from the server (i.e.: a RemoteObject result) and replacing your "enum" Strings or some other marker in the result with the corresponding client-side singleton type instance of your own making before anything else got its hands on the data. That's a lot of brittle data munging for very questionable payoff...
Perhaps at some happy point in the future we'll have a native enum type to work with at the client, but until then my recommendation is to take a deep breath, relax, and just work with Strings (along with defining matching String constants that you can use for data validation, assignments, and equality checks where it makes sense).
However, just because we could now support enums in the JVM at the server didn't mean anything to the AVM (ActionScript Virtual Machine) at the client.
ActionScript (and ECMAScript) doesn't provide a native enum type. To complicate matters futher, the flash.utils.IExternalizable interface doesn't provide the writeReplace() and readResolve() hooks that the java.io.Externalizable interface defines. When you're deserializing a raw byte stream into an object graph, you need a readResolve() in order to handle enums (singletons).
Java enum serialization can't be overridden at the server, which is good! It's good because this means that enums are always serialized and deserialized according to a consistent recipe. When they're serialized in Java-land (ignoring AMF for a moment), their String name value (as returned by the name() method) is all that's written to the byte stream. When they're deserialized, a single String value is read from the byte stream and passed to the enum's valueOf() method. The returned singleton instance is then readReplace()'ed into the resulting object graph.
Based on this behavior, BlazeDS and LCDS send Java enums to your Flex app as Strings. If the client needs to send an "enum" to the server, send the String value for the enum, and it'll be unpacked as the desired Java enum instance at the server.
But some folks want more than a simple String at the client. As I mentioned earlier, lack of native enum types in ActionScript coupled with lack of a readResolve() hook on flash.utils.IExternalizable makes this impossible. On top of that, when the Java enum instance is written to the AMF byte stream at the server, the AMF type prefix is for the native String type. That means the server-side type name for the enum isn't included in the byte stream so attempting to use registerClassAlias() or [RemoteClass(alias="...")] is futile (and you wouldn't want that anyways without a readResolve() hook at the client).
If you're deadset on representing these values as typed singleton instances at the client, you'd have to do something wacky like manually traversing the data returned from the server (i.e.: a RemoteObject result) and replacing your "enum" Strings or some other marker in the result with the corresponding client-side singleton type instance of your own making before anything else got its hands on the data. That's a lot of brittle data munging for very questionable payoff...
Perhaps at some happy point in the future we'll have a native enum type to work with at the client, but until then my recommendation is to take a deep breath, relax, and just work with Strings (along with defining matching String constants that you can use for data validation, assignments, and equality checks where it makes sense).
Wednesday, December 17, 2008
Time to test drive
The first public development milestone for the Spring BlazeDS integration is live. Go give it a try, provide feedback via the community forum and Jira system, and keep in mind that further enhancements for the next milestone are already in the works.
Monday, December 8, 2008
And you thought we were heading into Winter...
Some very exciting, and season-defying, news is that the excellent folks at Spring Source will be releasing an open source Spring BlazeDS integration project, with a beta coming available in mid-December :)
I know many of you out there have been hoping for just such an integration, so this is both a heart warming development to complement your regular Holiday cheer as well as a hint of the many interesting things the future holds for BlazeDS and LCDS.
I know many of you out there have been hoping for just such an integration, so this is both a heart warming development to complement your regular Holiday cheer as well as a hint of the many interesting things the future holds for BlazeDS and LCDS.
Sunday, November 23, 2008
But can he kick flip?
Much to my pleasure and surprise, Timothy Geithner, on deck to become our next Treasury Secretary here in the US, is a fellow skateboarder.
Courtesy of The Economist:
Courtesy of The Economist:
"Mr Geithner looks a lot younger than his 47 years (though not as young as he did before the crisis began). He skateboards and snowboards and exudes a sort of hipster-wonkiness, using “way” as a synonym for “very” as in “way consequential” and occasionally underlining his point with the word “f***”."
Post-MAX
As promised, I've shared (as in share.acrobat.com'ed) the two demos I presented during my MAX talk this past week. They're both basically the same app as far as the end user is concerned, with one version built on BlazeDS and the other on LiveCycle Data Services (LCDS), and they're a sketch or starting-point for building a real-time collaborative app using either of these server libraries we provide. The app provides a simple Contact List with Presence so you can watch as your peers come online, go offline and change their status. It also supports persistent threaded point-to-point chat between Contacts, with an option to view full chat history or just the messages for your current interaction. Again, I want to emphasize that these are demos. They're certainly not production-quality, fully realized apps, and are not officially endorsed or supported by Adobe.
By implementing the same basic app on both BlazeDS and LCDS, they serve as a simple illustration of how the up-front design considerations as well as the actual implementation of a real-time collaborative app will vary depending on which server library you're using. The delta isn't too serious for simple examples, but LCDS makes things much easier, and the pay-off is way above linear as the complexity of your application and its data model grows. Take a careful look through the configuration as well as the client and server source code for both samples to get a better sense for how the channels/endpoints and services you'd use differ, as well as how your application's use of service destinations would differ.
I've zipped up each demo as a fully self-contained, exploded web app that you can deploy to the JEE app server or Servlet container of your choice. If you're running Tomcat with HTTP on port 8400, deploying these should be very simple. You should be able to simply drop them into your /webapps directory and then add Context entries for them.
I hard-coded my channel/endpoint URLs to use localhost:8400 for HTTP in the BlazeDS demo and the LCDS demo uses RTMP on the default port of 1935. If you need to be using different IPs/domain names/ports locally, simply open up the corresponding /WEB-INF/flex/services-config.xml file and adjust the channel/endpoint URL values accordingly.
Both demos include the integrated web tier compiler so you can browse to either /bchat/BlazeSimpleChat.mxml or /chat/LCDSSimpleChat.mxml respectively and compile and run the app without having to set up, build and compile the client swf manually or in FlexBuilder. This also means you can tweak things, and recompile easily, as you play with the apps.
The one thing both demos depend on is a MySQL database. If you don't have MySQL running locally, go grab it and install it. Once installed, you'll need to define a database for each demo.
For the BlazeDS demo, create the database from the MySQL command line with:
CREATE DATABASE bchat_db;
For the LCDS demo, do:
CREATE DATABASE chat_db;
We also need to define the account the demos use to connect to and manage the databases:
GRANT ALL PRIVILEGES ON *.* TO 'javauser'@'localhost'
IDENTIFIED BY 'javapass' WITH GRANT OPTION;
That's wide-open, and if you have additional security considerations, you'd need to take them into account by limiting the grants to just these two test databases. The MySQL docs are an excellent resource if you have any questions about these steps.
The demos both use Hibernate to simplify the management of persistent application data, and the hibernate.cfg.xml files for both apps should be updated to drop, recreate and re-init these databases the first time you start your web app(s). To do this, uncomment the following line in these files (the copies under WEB-INF/classes, not /WEB-INF/src):
<property name="hbm2ddl.auto">create</property>
Note: the import.sql file in the same directory is used to initialize the data in your database when you have this hibernate property uncommented.
So, without any further ado, links to download the demo zips:
BlazeDS Simple Chat Demo
LCDS Simple Chat Demo
And a link to download the PowerPoint slide-deck for my talk (don't overlook the notes on each slide - they provide more info and background beyond the high level points):
Building Real-Time and Collaborative Applications with Flex and BlazeDS
PS: The session itself was recorded, and the video as well as the PowerPoint slide deck should be available soon to MAX attendees via the MAX site. The video should end up publicly available at some point but I don't have a hard date for that.
By implementing the same basic app on both BlazeDS and LCDS, they serve as a simple illustration of how the up-front design considerations as well as the actual implementation of a real-time collaborative app will vary depending on which server library you're using. The delta isn't too serious for simple examples, but LCDS makes things much easier, and the pay-off is way above linear as the complexity of your application and its data model grows. Take a careful look through the configuration as well as the client and server source code for both samples to get a better sense for how the channels/endpoints and services you'd use differ, as well as how your application's use of service destinations would differ.
I've zipped up each demo as a fully self-contained, exploded web app that you can deploy to the JEE app server or Servlet container of your choice. If you're running Tomcat with HTTP on port 8400, deploying these should be very simple. You should be able to simply drop them into your /webapps directory and then add Context entries for them.
I hard-coded my channel/endpoint URLs to use localhost:8400 for HTTP in the BlazeDS demo and the LCDS demo uses RTMP on the default port of 1935. If you need to be using different IPs/domain names/ports locally, simply open up the corresponding /WEB-INF/flex/services-config.xml file and adjust the channel/endpoint URL values accordingly.
Both demos include the integrated web tier compiler so you can browse to either /bchat/BlazeSimpleChat.mxml or /chat/LCDSSimpleChat.mxml respectively and compile and run the app without having to set up, build and compile the client swf manually or in FlexBuilder. This also means you can tweak things, and recompile easily, as you play with the apps.
The one thing both demos depend on is a MySQL database. If you don't have MySQL running locally, go grab it and install it. Once installed, you'll need to define a database for each demo.
For the BlazeDS demo, create the database from the MySQL command line with:
CREATE DATABASE bchat_db;
For the LCDS demo, do:
CREATE DATABASE chat_db;
We also need to define the account the demos use to connect to and manage the databases:
GRANT ALL PRIVILEGES ON *.* TO 'javauser'@'localhost'
IDENTIFIED BY 'javapass' WITH GRANT OPTION;
That's wide-open, and if you have additional security considerations, you'd need to take them into account by limiting the grants to just these two test databases. The MySQL docs are an excellent resource if you have any questions about these steps.
The demos both use Hibernate to simplify the management of persistent application data, and the hibernate.cfg.xml files for both apps should be updated to drop, recreate and re-init these databases the first time you start your web app(s). To do this, uncomment the following line in these files (the copies under WEB-INF/classes, not /WEB-INF/src):
<property name="hbm2ddl.auto">create</property>
Note: the import.sql file in the same directory is used to initialize the data in your database when you have this hibernate property uncommented.
So, without any further ado, links to download the demo zips:
BlazeDS Simple Chat Demo
LCDS Simple Chat Demo
And a link to download the PowerPoint slide-deck for my talk (don't overlook the notes on each slide - they provide more info and background beyond the high level points):
Building Real-Time and Collaborative Applications with Flex and BlazeDS
PS: The session itself was recorded, and the video as well as the PowerPoint slide deck should be available soon to MAX attendees via the MAX site. The video should end up publicly available at some point but I don't have a hard date for that.
Wednesday, November 19, 2008
Pop - Flick - Catch
Basil Hosmer, dangerously high on my list of favorite people, pointed me at a video recently that my buddy BOUTROS had turned me on to a few months ago (and which I'd subsequently gc'ed). Embedding it here should save me the search, next time I'm in need of a bit of inspiration.
I can't help but think it was influenced by Fully Flared, which I believe was a sea change and from here on out things will only get better. For those who haven't had the pleasure, every time I watch the opening sequence it's as refreshing as the first time. Followed by Mike Mo's opener, and everything else... words don't do it justice.
I can't help but think it was influenced by Fully Flared, which I believe was a sea change and from here on out things will only get better. For those who haven't had the pleasure, every time I watch the opening sequence it's as refreshing as the first time. Followed by Mike Mo's opener, and everything else... words don't do it justice.
Thursday, November 13, 2008
Pre-MAX
I'm presenting this coming Monday, November 17th, Wednesday, November 19th, at Adobe MAX in San Francisco. My session is entitled 'Building Real-Time and Collaborative Applications with Flex and BlazeDS', and I'm hoping it gives attendees lots to chew on and a nice starting point for building some cool apps. The title is a bit of a mouthfull, but accurate, and I'll also be comparing what's involved using BlazeDS to what's involved using LiveCycle Data Services - it's an interesting delta. Hope to see you there!
Post-MAX, I'll be posting my demo source, etc. here.
Absolutely not to be missed is Jeff Vroom's talk on 'Advanced Declarative Persistence Using JPA and LiveCycle Data Services' on Tuesday, the 18th.
For those working with ColdFusion along with BlazeDS and LiveCycle Data Services, Tom Jordahl's talk, also on Tuesday the 18th should be excellent.
Christophe and Anil Channappa will be running workshops every day to get folks up and running with deploying BlazeDS and LiveCycle Data Services.
And that's just my little corner of the world.
Post-MAX, I'll be posting my demo source, etc. here.
Absolutely not to be missed is Jeff Vroom's talk on 'Advanced Declarative Persistence Using JPA and LiveCycle Data Services' on Tuesday, the 18th.
For those working with ColdFusion along with BlazeDS and LiveCycle Data Services, Tom Jordahl's talk, also on Tuesday the 18th should be excellent.
Christophe and Anil Channappa will be running workshops every day to get folks up and running with deploying BlazeDS and LiveCycle Data Services.
And that's just my little corner of the world.
Monday, November 3, 2008
Zen and the Art of LocalConnection Maintenance
My colleague Jono Spiro hassled me to post this for my own benefit weeks ago, so here it is, fashionably late... This is culled from conversations with my pal, and ex-Player dev, Peter Grandmaison along with my own experiences working with LocalConnections
LocalConnection uses a block of shared memory to exchange messages between player processes. Outgoing messages targeting a LocalConnection are serialized and added to a queue within the sending player process, and these messages are moved into shared memory during idle time if there's room. Similarly, if messages sent to a LocalConnection owned by the player process are resident in shared memory, they're drained from shared memory during this idle time and processed by the player.
If the recipient process goes away without cleanly releasing its ownership of a LocalConnection, this can end up wedging the shared memory for the LocalConnection because messages aren't being removed for processing. Without any draining, there's no room for new messages.
The most common scenario leading to this is a player instance (or Breeze plugin, or AIR, or...) crashing or being force quit. Stopping a debug session in FlexBuilder behaves this way.
So, a fix was implemented where any player process polling shared memory will expunge anything stored there for more than 5 seconds regardless of which LocalConnection the messages are associated with. This reap cycle after 5 seconds prevents shared memory for a LocalConnection from wedging indefinitely - yay!
The implied caution here is to not send messages to a LocalConnection that will take the receiving process longer than a second or two to process. If you do, you run the risk of subsequent messages magically vanishing into the ether if they're reaped due to the 5 second rule.
In addition to the 5 second rule there's a size limit of 40K on the data sent in each message, and that's covered in the LiveDocs for LocalConnection.
So the take away is to keep your LocalConnection interactions short and sweet.
If you're trying to ship a large amount of data from one player process to another, do your best to limit the total amount of data you need to send, and if it's still substantial then slice it up to send in chunks. Make sure each chunk is guaranteed to be processed by the receiver(s) in well under 5 seconds.
The simplest way to handle this sort of chunking is to have the sending player process open its own LocalConnection that the receiving processes can 'ack' back over. This lets you chain the transfer like so, and protects against the sender potentially flooding the receiver:
Player 1 ---- sends data chunk over primary LC ---> Player 2
Player 1 <----- returns ack over secondary LC ------ Player 2
... rinse and repeat ...
Also, if the process that opened a LocalConnection doesn't exit cleanly, other processes will receive a "connection in use" error if they attempt to create a LocalConnection having the same name. You can work around this by implementing a retry on an interval slightly longer than 5 seconds, which gives the current process a chance to clean up the orphaned shared memory at which point it can successfully create the desired LocalConnection.
Subscribe to:
Posts (Atom)