Ted Patrick > { Events & Community } > Adobe Systems

A conflict has surfaced with Engage 2008 in San Francisco and I cannot be in attendance to give the opening keynote at 360Flex on February 25. Matt Chotin will be giving the opening keynote and it should be a great talk given there will be lots to talk about.

ConflicTED! AAAARRRRGGGG!!!!

Ted :(

The team over at lovelycharts.com is doing some amazing work with Flex. Watching the video below left me speachless as the application is far easier to use than MS Visio. I really like the workflow for creating diagrams and links between elements. Yet another great Flex application!

ScreenShots:






Application Output:




Looks like Adobe Flex is close to being the foundation to a suite of applications!

Cheers,

Ted :)

It seems that FireBrand.com is hosting an Adobe Flex application that will showcase a majority of the upcoming Super Bowl XLII advertisements using Flash Player and HD Video. The site allows you to watch all the videos end to end by brand using a great UI. The application is a great RIA and makes it easy to re-watch any of the commercials that you might miss during Super Bowl.








Looks like a great use of Adobe Flex!

Go Adobe Flex!
Go Adobe Flash Player!

Cheers,

Ted :)

I moved this weekend and as I was boxing up all my stuff, I thought about generic components and services. Tape, cardboard, moving wrap, and a rental truck are all simple things but when you put them together they become something far more valuable. It seems simple to combine tape and cardboard, but when combined, they make another powerful component (box) and make a larger service possible (moving). During this strange line of thinking, I tried to find the characteristics that made the most sense when creating generic components and services, here are a few that came to mind:

Reusable
Can I use this component over and over?

Examples:
Can I use the same box N times? (box has some wear and tear but can be used N times)
Can I use a piece of tape N times? (tape is more single use, it gets unsticky)

Combinable
How easily can this component be combined with itself or another component?

Examples:
Tape + Tape + Cardboard = Box
Ink + Quill = Pen
((Box + stuff) * 35) + Truck + 9 hours = Move across town

Orthogonal
Are there side effects when I combine components? The fewer side effect, the easier things can be combined.

Example: Does the steering wheel (component) affect the gas peddle (component)? Say I turn right, does the car speed up? Say I turn left does the car slow down? Not good.

Malleable
Can I make a component do something it wasn't intended to do. Can I stretch it, bend it to make what I need?
Example: Splice two boxes to hold something unique in size/shape

Multi-purpose
How many different ways can I use a generic components or service?
Example: Tape and cardboard are used for many different things.

Runtime Assembly
Can you assemble new components at runtime? Can you combine components and make new components here and now without a recompile?

Example: HTML has a beautiful set of generic components that can be reassembled into billions of different configurations. Instead of sending down components, you send the recipe assuming all the generic elements are present.



During the move I found the most useful generic component to be moving wrap. This stuff is magic as it adds a little layer of plastic around things and sticks to itself. In packing up the kitchen I wrapped everything breakable in this stuff to protect it and bundle things together. It allowed me to take a stack of glasses and make them virtually unbreakable and one solid element. During the move not a single item broke or scratched and it was largely do to this wrap. It was a simple generic component that really improved my move.

I am looking to build IFBIN 2.0 atop generic components and services that can be reused in other applications. In designing out the component/services it is useful to explore how other applications might use these. As you think about building components and services for use within the applications you build, take a look at what can be made generic and reusable.

I am glad I am all moved!

Ted :)

One of the new features in Flex 3 and Flash Player (MovieStar) is support for framework caching. Framework caching provides 2 things:

1. Separate the Flex framework from application code via Runtime Shared Libraries (RSL).
2. Installing a secure (signed) Flex framework RSL into Flash Player 9 release 3 (MovieStar)

When you separate the Flex framework into an RSL your application then depends on that RSL and it must be loaded when your app starts up. The RSL contains a specific version of the Flex Framework depending on Flex SDK you use. All sub-versions of Flash Player 9 support RSL but in last release (release 3) Adobe added support for caching a signed (.SWZ) version of the Flex framework. The caching logic installs the signed RSL into the player so that it can be used by Flex app on any domain. This basically allows the RSL to extend the Flash Player so that the Flex Framework version is never downloaded again. The first time a Flex application is used, the caching will occur, the N+1 time the user on any domain will only download the application logic.

Here are two example projects:

Framework cache disabled (default)
Properties/Flex Build Path/Library Path/Framework Linkage/ Merged into code

AC_OETags.js - ( JS Player detection )
playerProductInstall.swf ( Player upgrade SWF )
SampleProject.html ( Base HTML )
SampleProject.swf ( Application SWF file )

Framework cache enabled
Properties/Flex Build Path/Library Path/Framework Linkage/Runtime Shared Library (RSL)

AC_OETags.js - ( JS Player detection )
playerProductInstall.swf ( Player upgrade SWF )
SampleProject.html ( Base HTML )
SampleProject.swf ( Application SWF file )
framework_3.0.189825.swf ( Flex Framework RSL - Loaded for FP9r1 & FP9r2 players )
framework_3.0.189825.swz ( Signed Flex Framework RSL - Loaded for FP9r3+ )

Q: How will this work when a new SDK is released?

The key is that your app is dependent on a specific version of the Flex framework and the caching mechanism supports this. If you run into 2 apps built with different version of the Flex framework, say release and hotfix 1, both frameworks will get cached. This avoids the DLL hell issue typically in deploying windows applications. As the runtime manages caching and supports multiple version of the framework, it just works.

Q: How much smaller?

The signed Flex framework RSL (.SWZ) is 535KB and includes all base components and libraries in Flex. Even if your app uses just a button, the same SDK will get cached. A simple hello world application is 50KB vs the typical 350Kb. Size of your base application will vary depending on the components used as all skinning, style, assets, and custom code will be compiled into this base SWF file.

Q: Does this work with all Flash Players?

YES! Applications where framework caching are turned on will work in all release versions of Flash Player independent of the caching feature. Caching will occur automatically if Flash Player 9 release 3 or higher is installed.

Q: Can I cache custom code in the framework cache?

NO. Only signed Adobe components can be added into the Flex caching feature at this time due to data security. As the cached code is cross-domain enabled, anything in the RSL is added into the security domain of the running application.

Take a deeper look at Flex framework caching it is a great new feature in Flex 3. It will make your applications smaller and they will instantiate faster.

Regards,

Ted :)

When I create software that runs on Flash Player I take a minimalist approach during development. Flash Player has a limited amount of code execution capacity, rendering capacity, and memory storage capacity at any moment in time. Ideally your application never pushes the player to its limits at any single moment in time and thus will run as fast as possible. Should you hit these limits, the player will simply slow down until all the work you are asking it to do is complete. Over time these facts have forced me to think in terms of programming in a minimalist fashion.

The Flash Player uses a logical unit of work called a frame which consists of 2 phases which occur one after another in a loop:

1. Process ActionScript
2. Render Graphics
3. GOTO 1

After each of these phases is a buffer to handle delays ( say you render to much or loop over a ton of data ). When both of these phases have completed we call that a frame. Each SWF file you create has a framerate (frames/second) which represents the fastest rate that the Flash Player will loop over these phases. When Flash Player encounters delays in processing either phase it will elongate the time to process the frame and thus your framerate will slow but will never exceed the framerate set in the SWF file.

Ideally your application never renders or executes too much at a single moment in time. There are several ways to handle this:

1. Minimalism - Never attempt to do too much at one time.
2. Process data across frames ( callLater() ).
3. Time Animation - Use time to animate/render ( flash.utils.getTimer() ).
4. Frameworks optimized for Flash Player (Flex).

Flex was built to handle application behavior in a minimalist fashion if used properly. I continue to see developers execute to much ActionScript on a single event and not think in terms of processing data across frames. Using events properly is a great place to start. Make sure you know how long and how often methods are being called from events. I had a case recently where a developer was using the flash.utils.Timer class and firing tick events every millisecond. Even with the simplest of methods subscribed to this event, it would bring Flash Player to its knees. To help visualize how your application works take a look at the memory and performance profiling in Flex Builder 3 Professional. This toolset was built to let you see what your application is doing at runtime and easily locate performance areas within your application. Better still the profiler allows you to locate performance issues late so you can avoid early optimization and save a ton of development time. I prefer to take a more balanced approach and architect things taking advantage of processing over time and using events carefully. Another big issue is the use of bindings as these generate events when data changes. As they are so easy to create, you can force the player to be processing nearly non-stop with the smallest of data changes. They are very powerful but it is easy to abuse.

To more fully understand this approach I would encourage you to explore and experiment with Flash Player and the Flex 3 Profiler. Once you understand how the player internals work and can see the effect of the code you write, you will understand the benefits of being being a minimalist. Just remember, I am not asking you to give up your worldly possessions but rather think in terms of doing the least to achieve your goals with Flash Player or AIR.

Cheers,

Ted :)

Mike Chambers posted on using Command Proxy with AIR for .NET integration but having actually deployed a rich client solution cross-platform with IFBIN using this same pattern, I thought I would chime in. First off it works and by works I mean that I successfully built and deployed IFBIN 1.0 on MAC and PC using Flash Player, Flex 1.5, and Python. Here is the architecture atop Mike's diagram.



The reason I chose Python is that it ran cross-platform so porting between operating systems was not as hard ( can't say trivial but 90% of the code worked ) and leveraging Flash Player allowed for a rich UI. When IFBIN 1.0 shipped in 2005, we had no AIR runtime and using Central 1.5 was problematic given the lack of a really solid FileIO feature set. The IFBIN architecture ran a local http/socket server and launched a browser when started. The browser then loaded a SWF file created with Flex 1.5 and opened an XMLSocket connection to the locally running Python server. The Python server in this case handled all DRM, FileIO, Downloading, and Licensing of the files on a per installed basis and the local server had a simple API for executing any feature that Flash Player did not support.

In regards to security, the architecture in IFBIN 1.0 limited client/API access via a secure token and only clients with that token could connect to the locally running service and call the API itself. It also helped because the local connection from ClientUI to local server was a persistant TCP/IP Socket so once authenticated all commands over the socket were denoted as secure. I also made some security enhancements to limit the FileIO to a single directory and thus writing and deleting files was limited to the service and managed.

I personally would avoid building an local .NET dependency into your application as this just limits compatibility. When we write software we want to reach the largest market possible without having to do unique things on a per platform basis. With IFBIN 2.0 (yes it is in development) I am using AIR 1.0 with no external dependencies. This choice makes development cross-platform ideal as I get 3 platforms for free without any additional work.

My take is that the key value of AIR is writing software for 3 platforms (MAC/WIN/LIN) with a single codebase. Anything that forces me to do something unique per platform and fork the codebase is a really bad thing.

To Mike's defense the Command Proxy architecture works well but I would personally never do it again with IFBIN. AIR 1.0 handles all the requirements to deliver IFBIN without a local server/service running.

My 2 cents,

Ted :)

Hats off to Eric Cancil for putting together a great new container control called FlowLayout extending Flex. The new container takes any children (UIComponents) and lays them out handling variable sizes and resizing behavior. What I find interesting is just how useful this component it from an application development perspective. Assuming you get data in via XML you can create component instances and render them into this control at runtime, dynamic forms, dynamic text with images can all be handled within this container.

I will be showing a demo of the new container at the Flex/AIR Pre-Release Tour at Ebay tonight.

Thanks Eric for extending Flex!

Cheers,

Ted :)

I have been running an experiment using XML/XSL/Flex and attempting to get search engines to spider the model of the application. This morning Google listed the "Flex Directory" under searches containing the body text of the model data. From what I am seeing the spiders have ignored the attribute data as expected. The lesson is to expose the most important elements of the model data and hide data in attributes that would otherwise hinder the results.

So the next step is to reorganize the data so that the directory gets far broader listings and add in the elements of cross-linking using <a href="http://www.blogger.com/url">COMPANY</a>. This will force the spiders to spider the resulting sites via cross-link and reinforce the network relationship via domains.

Proof: SEO and RIA work seamlessly together!

Here are some links for review:
Farata effectiveUI flex
iChameleon ASI
Cynergy Memorphic
Cynergy Flex Sanative

More to come!

Woot,

Ted :)

I have wanted to cover this basic question for a really long time but it is a very hard question to answer. Flex is many things but I wanted to put a definition out there to help everyone see what it is, where we are headed, and why we created it. With all my presentations I start with "What is Flex?" and it is about time my blog had the same information. So here is my definition:

What is Flex?

Flex is a way to make SWF files!

At the heart of Flex is the ability to create SWF files that run in Adobe Flash Player. Distill all the features down and really it is a development paradigm that compiles to SWF. It really is that simple but often we make the definition much harder. Just like Flash can create SWF files, so can Flex but the way you develop is completely different.

Flex is for developers.

Flex was not built for animators, writers, accountants; it was written for software developers and the paradigm matches the development methodology you already know. If you know Java, C, C++, C#, Delphi, VB, PHP, ColdFusion, Python, Ruby, you can learn Flex with little effort. The goal when Flex was created was to make a development paradigm that developers could learn easily matching the methodology they already know yet create SWF files for Flash Player (and now AIR). Flex has classes, components, a compiler, a debugger, class libraries, and uses XML (MXML) for declarative markup of components. The ActionScript programming language is based on ECMAScript 4 (the language standard behind JavaScript) and has full support for the ECMA XML scripting standard E4X. It also has most of the UI components that you already use ( like button, list, datagrid, combobox, and tree) but it also supports containers like HBox, VBox, TabNavigator, TitleWindow and many others. If you have written software before you can learn Flex easily. Better still is that Flex is compatible with all HTTP servers, version control systems, and any server side programming language, so the knowledge you have of servlets, php, ASP.net, or JSP is really handy. Flex just lets you program the client side in a paradigm you already know and understand.

Flex is for making applications...

Flex was built for making rich client side application behavior. It wasn't built for making web pages, banner ads, or server side logic it was built for creating client-side applications that run over the Internet talking to remote servers. Flex has been used to make some really great apps like Buzzword (Document Editor like Microsoft Word but in the web) or Picnik (Photo Editor/Manager for touching up your best snapshots) or SlideRocket (Presentation software like Apple Keynote but in the web) or Oracle Sales Prospector (An enterprise ERP application. Yes Oracle uses Adobe Flex! ) or many other applications you can see at Flex.org. The real key is that all these examples provide an application experience just like desktop software.

that run on the web (Adobe Flash Player)...

Flash Player 9 is installed on more than 95% of computers that use the Internet and has been installed more than 3,500,000,000 times at a rate of over 10,000,000 times per day. When you develop software, you want it to run compatibly in as many places as possible. Adobe Flash Player provides a solid foundation to build these experiences without the need to install or update anything on the end users computer. If you were running a store you would want that store available to as many customers as possible and choosing Flash Player allows you to provide a great experience (rich) to 95% of the web (reach). Make sure to look at the reach of the technology you select, if you choose something not widely installed or incompatible, you are simply turning away customers and business.


Adobe AIR is a new runtime in development by Adobe and we are very close to releasing Adobe AIR 1.0. AIR allows you to write desktop software that runs on 3 operating systems (MAC,WIN,LINUX) with the same file. This allows your application to be a true desktop application rather then just a website and allows you to do much more than the web allows today. AIR applications are real native desktop applications and provide APIs for writing files, drag-drop, system notifications, network detection, and more. AIR empowers developers to write desktop software that leverages the Internet.


We are working to enable Flex to build applications for mobile platforms and support a wide range of devices. Just as Flex can be used to write a web based application or desktop application, it can be used to write software for mobile devices. The fact is that devices are becoming ever more powerful and more plentiful. It is just a matter of time before we enable developers to leverage Flex to deliver mobile applications on Flash Lite or AIR on mobile.

In summary, Flex is a development paradigm that allows you to write software for the web and desktop that many people can use compatibly today. It leverages the tools, servers, and development models that you already know and allows you to write the next generation of software compatibly. At Adobe we are working around the clock to make this ecosystem of software better and provide you with the best tools and platforms to make your projects a success.

I encourage you to take a fresh look at Adobe Flex and discover the opportunity in learning a new language and ecosystem. Developers around the world are embracing it to create all sorts of new applications and I think you should jump in too.

Flex: A development platform that is revolutionizing how the world writes and deploys software!

Cheers,

Ted :)

I decided in November to learn Erlang as a new programming language and over the recent holidays I got 3 weeks to play around with it. In my 2008 RIA trends post I listed Erlang as a language trend and thought it would be good to shed some light on the matter.

Erlang - a general-purpose concurrent programming language and runtime system.

The language is very different from any programming language I have worked with and was created by Ericsson to write highly scalable mission critical telecom server products. There are several advantages to Erlang as a language that make it optimal for writing server based applications:

1. Concurrent Processes - Erlang can spawn many processes, like 250,000 processes and these run concurrently in the VM. Each process can receive messages and send messages to other processes. The VM automatically handles executing processes across multiple processors so having more processes generally runs N times faster on N core machines. In a world where cpu cores are multiplying, Erlang has a huge advantage in leveraging additional CPUs without any programming effort.

2. Message Based - Erlang processes communicate by sending messages and the language syntax is optimized to make handling messages easy. The arrity and type of data passed to a function determine which version of the function is called so message handling is done at the interface of the process not in some if/then/else/case statement. The message either matches a function or it is ignored. The way messages and processes are handled is much like the real world, we do not have shared state, rather we send messages to one another by honking, blinking, speaking or waving.

3. No shared state and Variables that do not vary - The strangest truth in Erlang is that variables do not vary. This allows apps to avoid shared state and read/write contention and locks. The rule is that where there are locks, there are keys to loose so Erlang has neither. It seems annoying but in fact it only takes a little while to get used to. In avoiding shared state, processes are much more scalable and issues of thread contention, race conditions, and collisions essentially fall onto the floor.

4. Bit Masking and Pattern Matching - The feature I like most is pattern matching and the bit masking syntax. It is trivial to parse extremely complex binary data and set variables from input data. Here is a little snippet:

<<?Header:4, Chan:4, Note:8, _:8>> = InBytes.

6. RPC and Distributed Computing - Running processes in local and remote Erlange VM's could not be easier. Once the machines are physically allocated by IP you can spawn processes on remote VMs and call remote processes as if they were local. It makes writing a cluster of servers really simple and once the different VMs are trusted on a network exchanging messages is nearly identical to local messaging between processes.

Learning Erlang has already been one of the more interesting explorations in my software career and it is similar to my first experience with Python back in 1999. If you are interested in exploring large scale distributed computing, Erlang is the language and VM in use at both Google and Amazon in a large scale. I think we will see much more from this programming language in 2008 as the services market heats up. I will also be releasing some services written in Erlang for Flex later this year.

Cheers,

Ted :)

I just posted a new build of the Flex Directory here. I made changes to test an SEO theory in regard to attributes vs element values. When a spider looks at the XML of the Flex Directory they see an XML file but I changed the nodes to <div/> elements and moved the company names into the element as the value. If the theory holds here, the search engines will be exposed to the company data and search results should return when company names are searched. This change is a test and we will have to wait and see if the search engines grab ahold of the new schema and parse the data correctly. My hunch is that spiders typically are programmed to ignore attributes since they are 100% used for markup and never contain textual data relavant to SEO.

Special thanks to Doug McCune and Eric at Space150.com for helping with the SEO optimization their comments on the last few posts has been invaluable. Ideally if this test works then we have a really solid SEO model for Flash based UI. I chose to use DIV elements to hold the various company data but this could prove to be the real test. What elements the spiders like to work with is quite the mystery. Sure I could target microformats or xhtml but this test is designed to be incremental so we can measure the change. I will be testing other schemas too.

Flex Directory Build 003

Test, Test, Test, Optimize, Test, Test, Test! Fingers crossed! Loaded and Launched!

Cheers,

Ted :)

There is a very important security distinction between using Loader.loadBytes and Loader.load that EVERYONE needs to understand.

Loader.load loads content (PNG,GIF,JPG,SWF) into the security context of the url being loaded.

Loader.loadBytes injects bytes (PNG, GIF, JPG, SWF) into the security context of your application!!!

Loader.loadBytes is much like eval() and if used improperly it can inject a security hole into your application. Much like eval() it is very useful and allows you to do all sorts of great stuff but it can also cut your arm off and melt your tennis shoes.

So how harmful can it be, lets look at a simple example:

Load a PNG file from domain.com into your Flex app:

GOOD: Do this with Loader.load and you are safe as can be.

BAD: Do this with Loader.loadBytes and the injected image bytes will be processed like they were native code. If someone renames a .SWF file into .PNG, they have successfully injected data directly into your application running in AIR or Flash Player. If this SWF file were in AIR, it would have the ability to use any AIR apis and would create problems.

Note: The AIR team is looking at a minor API change for Loader to default loadBytes content into a security sandbox with an optional to override the new default behavior.

There are a few nice use cases for loadBytes in AIR:

- Obsfucate a SWF file - Load a binary file and reorganize the bytes into a functional SWF before loading into your application. You could use TEA encryption or a simple bit shifting pattern across the ByteArray.

- Provide try/buy functionality - Create 2 SWF files one trial and one purchased (encrypted) and provide the encryption key during software licensing.

Be careful when you use loadBytes, it can inject a security issue into your application if you do not know what you are loading. I will be updating my post on Progressive Image Loading as this methodology uses loadBytes and has risk.

Keep loading!

Ted :)

One of my projects for Q1/2008 is a very large expansion of the Flex Directory. Today I updated the directory and added 85 new firms developing with Flex. The Flex Directory now lists over 250 companies who can build Flex applications. Before we take a look at what is next, lets take a look back at what worked and what did not.

What worked:

• Flex over XML - XML + XSL + SWF
• SEO Compatible - #1 Listing in Google for "Flex Directory"
• Simple and easy to update XML file
• Sortable/Filterable
• Easy to sign-up

What didn't work:

• No Database, just 1 XML file. It worked but it needs a backend. :)
  
• Updating a listing required submitting a listing again. This needs to be self-maintained and easy.
• Management tools - Currently the site lacks any management tools other than TextMate editing XML.
• Company detail: ScreenShots, Logo, Description, Contact Details, Location Details
• No support for developer listings or alternate types.
• Just Flex - No support for Flash, AIR, or other.

FXD 2.0 - Architecture
To start, the new architecture is a Structured XML/Flex WIKI. Basically there is a simple API for updating the URL listings and all XML stored is rendered through a Flex template. In this case I can update 1 SWF file and change the look and feel of the entire site while supporting variable schemas for all types of listings. The model is quite powerful and allows for clean SEO support, an XML API , clean urls, and compatibility with 95%+ of browsers. This architecture is something I have been working on quietly for over a year and this will be the first large scale use of it outside of the internal demo apps.

My favorite feature is that the UI is completely separate from the data and this creates some powerful side effects for managing the site. This allows me to add features to the template and have them optionally shown based on the model data. If a developer adds a <screenshot src="ImageURL" title="App Screen Shot"/> tags to their profile, the template will add a screenshot tab to the profile and load the image url in the UI. Allowing this sort of feature extensibility is really great and it makes the whole system really easy to maintain and extend. If you like someone elses profile, you can simple view source on the XML to find out the template's capabilities.

This solution is also very scalable, allowing the Flex Directory to support a larger number of page types and millions of pages. In the first edition I only listed companies and had to reject individual developers due to scale. With the new architecture the site will support many different types and allow cross-linking between the pages with clean URLs.

FXD 2.0 types:

• Companies
• Developers
• Projects
• Components
• Services
• Jobs

The cross-linking is key to allowing visitors to see relationships visually and navigate the site across the networks within.

Here are some example relationships that can be shown:

Developer "at" Company
Developer "recommends" Developer
Project "by" Company/Developer
Company "has" Projects/Component/Service/Jobs
Jobs "at" Company
Components/Services "by" Company/Developer
And more...

The cross-linking is one directional, optional within the profile, and tied into the URLs. Ideally it adds a ton of value and allows the developer network to become visible creating more value for everyone. For the market to grow we need this level of transparency. Ideally it will drive a lot of business to companies, raise leading developer rates, and allow projects to find the resources they need to become successful.

What is cool is that all these various types of information can be listed without a single change to the backend. As this is done WIKI style using just an XML model, the view can be wildly different atop the same model. A regular WIKI would embed markup with the model and result in an inconstant UI, this is not the case with a Structure Wiki. The system can display wildly different views of the same information and extend features of the UI should certain model information be present. From my initial tests the architecture supports the rapid creation of a large number of accounts supporting millions of entries. What is interesting is that this methodology is also very bandwidth efficient. As the UI is a single SWF file, it is downloaded and cached once per site visit and the base XML page data is really small (5K or less). This results in creating millions of pages where the UI is 100% cached after the first page and contray to popular belief it actually is far faster and more interactive than an HTML/JS/AJAX based methodology.

The goal of the FXD 2.0 is to make the market for Flex/Flash/AIR much more transparent. Currently many developers and firms build great projects but have no visibility in the larger marketplace. Components and Services for Flex/Flash are also not very visible. Ideally FXD 2.0 will make the market much more visible, help developers find projects, projects find the right developers, and developers find components and services to build their applications upon. It will be a great big social experiment atop the Adobe technology platform and should be a blast to build. If you have been following my blog for the past year you have seen slices of this in development (FXT, Flex Search, FX over XML, URL Matters ) but this will put the whole picture together.

I will also be building this transparently online and all work will be released open source and including the WIKI backend and all SWF/Flex projects within. Hopefully the architecture can be reused for your own projects.

Flex Directory

More to come!

Ted :)

I find out about some killer jobs using Flex. From time to time I will be posting these jobs to my blog. I will only be posting the best of the best of the best here. This week the job is from SurePeak in Palo Alto, CA.

---

Company: SurePeak is an angel funded software company that is developing Web 2.0 Advertising solutions. SurePeak is a team-oriented company where you will play a key role in all stages of product development. You will participate in architecting, designing, developing, and releasing advertising solutions for the Web and Mobile networks. We are looking for highly motivated and talented engineers to join us. If you are looking to work somewhere fun and challenging, then we would like to hear from you.

Position Type: Full Time

Location: Palo Alto, CA

Responsibilities:

• Participate with engineering team in defining, architecting, and developing our next generation Advertising solution.
• Design & develop Software components for SurePeak’s web presence. The GUI components will be based on Adobe Flex.
• Create SDK for releasing Software components to customers and 3rd parties
• Integrate SurePeak’s web components into Social Networks such as Facebook, and MySpace.

Education & Experience:

• B.S. / M.S. in computer science, or equivalent work experience.
• 5+ years in software development
• Strong experience working with Adobe Flex is REQUIRED.
• Experience designing web-based GUI applications for complex tasks is REQUIRED.
• Strong experience building Web solutions with Java/J2EE is REQUIRED; experience with Java frameworks is desirable.
• Strong Tomcat, Apache, and MySQL configuration and setup.
• Ability to quickly understand how a variety of technologies work and are used.
• Self-learning. Need to be able to work independently with the software to understand, validate and explain product functions.
• Ability to manage schedule, resources, etc. to deliver a quality solution on time.

Aptitude and Attitude:

• Careful, reliable, and efficient
• Have passion to work with team to drive toward successful product launch
• Are able to stay calm during stressful periods
• Love to learn new technologies and techniques
• Are a self-starter and team player

Contact: info.surepeak@surepeak.com

---

Cheers,

Ted :)

From Jan 21 - Jan 24 I am traveling the California coast talking about the upcoming release of Flex and AIR. It should be a great week of MXML and ActionScript down HWY 1 from San Francisco to San Diego. I will be hitting all the user groups this week and showcasing the release features in detail. Make sure to check out all the tour dates worldwide!




January 21, 2008 6:30 PM - 9:30 PM - Adobe San Francisco - Bay Area ColdFusion User Group

January 22, 2008 5:30 PM to 9:30 PM - eBay Town Hall San Jose - Silicon Valley Adobe Flex User Group

January 23, 2008 7:00 PM - 9:00 PM- Yahoo! Los Angeles, CA - Los Angeles Adobe Flex User Group

January 24, 2008 6:00PM - 9:00PM - Adobe San Diego - San Diego ColdFusion User Group

See you on the tour!

Ted :)