Monthly Archives: October 2004

"Letters" for Central


Here is a Central clone the FlashCom “Fridge Magnets” app by Stephan at flashcomguru.com but the application is powered by SYNC not FlashCom. The server and client were written from scratch in an afternoon. ;)&

Special credit to Stephan for his original work here.

Cheers,

Ted ;)

Python PSYCO and PowerSDK SYNC


I have been testing the PSYCO compiler with PowerSDK SYNC server and the results are pretty amazing. With minimal code changes, SYNC has jumped over 700% in core message processing speed.&

First let me explain PSYCO. PSYCO is a JIT(Just In Time) compiler that can be added to any Python distribution. When you enable PSYCO it caches functions in memory and every N+1 function call is executed in memory rather than within the Python interpreter. When the functions are run from the PSYCO cache the functions are nearly as fast as their C equivalent.

Python

PSYCO

This is a big deal as it makes a high level langauage like Python execute as fast as a compiled language but without all the hassle. The only drawback is that your application uses more memory in the caching of the functions. In tests with SYNC, it adds about 2MB of memory to a server application.

What is SYNC? SYNC is a server framework for real-time Flash applications written in Python. It allows you to design a protocol as a class and execute it within Python as a server.

Here is a sample SYNC server running an echo class on several ports:

import sync

import psyco

psyco.full()

class SyncEcho ( sync.Protocol ):

     def onData( self , data ):

          for c in self.clients:

               c.send( data )

sync.enable( ‘sync.powersdk.com’, 80, SyncEcho )

sync.enable( ‘sync.powersdk.com’, 1568, SyncEcho )

sync.enable( ‘sync.powersdk.com’, 21, SyncEcho )

sync.start()

In the above example, the server runs the same class on 3 ports (80,1568,21) where any client can attach to any port and get identical data from a common server. SYNC makes writing optimized Flash XMLSocket servers from scratch really easy. The server does not use XML on the client or server and uses a similar model to Flash remoting to exchange data. You fire a client function which fires a server class function which fires a local event. Writing Flash clients for SYNC is a snap.

When PSYCO is applied to the server the onData method is cached in memory and run at near C speed in message threads. As message processing is cached in PSYCO, the server internals are dramatically faster. In tests, the server is over 7 times faster when PSYCO is added. Note the only changes to the application are “import psyco” and calling the “psyco.full()” method. That is just amazing to me.

I should have an example application posted today that uses the SYNC server and a fun Central application. I have been testing the server all week and think it is time to add lots of users onto the server to test scalability.

It would be really interesting to see Flash Player 8 add PSYCO-like functionality. If the player only had to interpret bytecode once and would execute functions directly from memory, AS execution would be dramatically (20x) faster and maybe faster than Java. Bye-Bye Processing, hello Flash.

More to come.

Cheers,

Ted ;)

A Central V2 Diet


Here is a simple way to put your Central V2 apps on a diet. I lost 25Kb with XTreeM version 0.941 (posted minute ago).&

Central 1.5 ships with a shared library that contains many V2 components and classes. When you author for Central, you use the Central SDK components which point to the Central V2 shared library. Since the shared library is already in Central, it is ideal to exclude any duplicate classes used in your application.

I used ASV (Thanks Burak!) to obtain all the classes used within the Central V2 shared library and added them to an exclude XML file (made with XTreeM). If you rename the first portion of the exclude file match your Central FLA name and recompile, your application is sure to loose some unwanted size.

Example:

FLA : main.fla

XML: main_exclude.xml

Original: main.swf 77Kb

After Diet: main.swf 52Kb

A side effect of doing this is that your components instantiate quicker and there is no duplication of effort in your swf. By using this standard exclude list with your Central development you apps will be smaller and will execute faster.

Seeing the video of the Flash 8 Player got me excited about Flash / Central as a platform. A performance jump from 15 FPS to 115 FPS using components would make Central apps as fast a desktop equivalent. I view this as a huge opportunity to invest in Flash/Central now. Wow the future of Flash and Central looks very bright indeed.

Cheers,

Ted ;)

XTreeM XML Editor Version 0.938


The XTreeM editor made another big leap this weekend as I added input filters to several controls and fixed several bugs. XTreeM just passed 300 installs in only 7 days!&

The goal of XTreeM is to provide an editor for rapid/valid XML editing. If you author XML within XTreeM, it should be very difficult to create invalid XML. Any case where invalid XML can be created in XTreeM is a bug and needs to be reported. If you find one, simply paste the invalid XML into the bug form. Special thanks to all the people who have reported bugs in the editor.

I am also working on open XML editing in the textPane. Currently you can only edit TextNodes, CDATA, and Comments but soon you will be able to edit the XML directly. When the XML is edited directly the node will be reparsed prior to adding it into the model. Should there be an error in the edited XML, an error dialog will occur allowing you to fix the error prior to model modification. This will be in the editor before 0.950. Thanks to Peter Hall for this suggestion.

I am also almost done with a new XML subclass called XMLCache that provides node caching. With node caching a snapshot of formatted XML output is stored in each node as text. When a node is modified all parents are marked as dirty forcing the class to rebuild the dirty nodes when they are viewed. When a parent node is viewed, only the dirty nodes are reparsed making XML output over 20X faster. For larger XML documents this eliminates almost all of the performance problems in using the Flash Player.

0.938 Changes:

1. Element Names are filtered in data input.

2. Attributes are filtered in data input.

3. Controls are disabled when selected node is closed in Tree.

4. Attribute deletion selects the next value.

Several people have asked me why I built XTreeM. Here it is:

1. I wanted a better XML editor as most editors are simply glorified text editors. These editors provide great data editing but XML is 80% structure and 20% data. The XTreeM tree view allows you to see the structure of an XML document and edit documents through this view. It provides a powerful paradigm to edit XML allowing rapid modifications that are just not possible or safe with plain text based editors.

2. Most new data formats are based on XML. XML is the base storage format of many applications including Flex, ITunes, Flash, MS Visual Studio, Office, RSS, Atom, Web Services.

3. New Flash or Central applications can inherit from XTreeM. Almost 100% of the code used in XTreeM is reusable and I plan on using it in company and consulting projects. By focusing on XML 1.0 in Xtreem the quality will cascade into other projects reusing its core.

Happy editing, More to come!

Ted ;)

XTreeM XML Editor Version 0.901


Here is the current release of XTreeM version 0.901. XTreeM is a free XML editor for Central 1.5 based on a tree. The editor has come a long way over the weekend and it is quickly becoming very functional and useful in day to day work.&

I put together this primitive product tour flash movie highlighting all the major features. It shows me building XML from scratch and editing a Flex MXML document.

Product Tour – View the application in action!

Changes:

1. Add/Remove nodes to Tree

2. Dialog Engine and Parse Error dialog

3. Invalid XML Raw Text Editor

4. Add/Remove attributes

5. Fixed some major bugs in the tree with Drag and Drop editing

6. Context menu is fully functional and changes depending on selected node

7. Contributions dialog

ToDo:

1. Caching to XML text nodes to speed rendering

2. Pretty printing options (WhiteSpace Restructuring and eliminate WhiteSpace)

3. Text options

Special thanks to Isaac Rivera, Peter Hall, and Phillip Kerman for some invaluable comments and bug reports. Thanks guys. If you find bugs please send a bug to me from within XTreeM.

Cheers,

Ted ;)

XTreeM XML Editor for Central 1.5


I need some user feedback on an XML editor I wrote in Central. It provides a simple structured XML editor oriented around a tree. Simply drag and drop nodes to restructure an XML document.&

Release: 0.8

Changes:

1. XML support for Comments, CDATA Nodes, Processing Instructions.

2. Restructure nodes by drag and drop.

3. Edit Text Nodes, CDATA, Comments, Attributes, Processing Instructions.

4. Pretty printing (XML heirarchy tabs and newlines)

5. File Open and Save Locally

ToDo:

1. Add/Remove nodes to Tree

2. Parse error dialog

3. Add/Remove/Order attributes

4. Pretty printing options (WhiteSpace Restructuring and eliminate WhiteSpace)

5. Text options

If you find bugs please forward them to me. I have been working with the WC3 compliance XML tests and only a few documents show parse errors now.

The editor will remain free.

Cheers,

Ted ;)

iconFunction and labelFunction in V2 (Repost)


If you learn these simple functions, what is possible with V2 components grows exponentially.&

In the V2 framework there two functions that can dramatically alter how you use components and dramatically expand your options. In most of the V2 components there are 2 optional callbacks that allow data to be modified as the component is writing data into the component. These two callbacks are iconFunction and labelFunction.

How they work:

When a component is processing data in a dataProvider (source of data) into the component itself, before the data is written to the component, these two callbacks are executed if they exist.

Lets assume I have a Tree and I want to customize the tree based on data within an XML document. Using iconFunction I will modify the icons in the tree and using labelFunction I will modify the label just before the tree is rendered.

Source Code

1. Drop a tree on stage, name the instance “myTree”, and position it.

2. Add this code to the keyframe. The code retrieves an XML document from the internet and sets the “myTree” dataProvider. Pretty simple so far.

dx = new XML()

dx.ignoreWhite = true

dx.load(“http://www.powersdk.com/sample/treedata.xml?”+Math.random()*10000)

dx.onLoad = function(){

myTree.dataProvider = this.firstChild

}

3. We are going to create 2 functions to modify the tree. When the dataProvider is read and elements in the tree are created, these methods will be called allowing us to change the data at the last second before it is rendered.

Watch carefully this is really difficult. ;)

// whatever you return in this function

// is LinkageID MovieClip the tree will use for the Icon.

myTree.iconFunction = function(node){

return node.attributes.icon

}

// whatever you return in this function

// will be the value of the Label in the Tree.

myTree.labelFunction = function(node){

if(node.attributes.title == undefined){

return node.attributes.name + ” (Division)”

}else{

return node.attributes.name + ” (” + node.attributes.title + “)”

}

}

4. Done

Basically these two functions allow you to modify how a dataProvider is rendered in the component. With these simple functions you can merge dataProviders and make your view very powerful while your data remains un-fooled-around-with.

Another great technique is swapping these functions to allow for a completely different view with the same dataprovider. Simply swap the functions and execute the refresh() method on the component.

Hopefully it will help you keep your model and view nicely separated. ;)

Result SWF:

Cheers,

Ted ;)

"Good Enough" vs "Ideal"


I often get stuck in development on how to make something work. I keep finding that if I design targeting “Good Enough” rather than “Ideal”, development is more productive and the results are much better.

First off let me clarify “Good Enough” and “Ideal”:

“Good Enough” – Designing software to fully satisfy the current requirements and nothing more.

“Ideal” – Designing software to exceed the current requirements of the project.

Developing for “Good Enough” doesn’t mean cutting quality but rather being practical in regard to meeting requirements, rather than exceeding them. I occasionally find myself diving into a single aspect more than is necessary. When I look back on my time spent, the single aspect coded to “Ideal” standards wasted allot of time and effort. If I had spent the wasted “Ideal” time on making things “Good Enough”, the overall project would have benefited.

I guess the “Ideal” mentality emanates from attempting to defensively protect a project from changing requirements. Everyone has had a project where mid-development, the manager says in passing:

“Oh, by the way we need to support this too. Is that a problem?”

On occasion, coding for “Ideal” has saved me in these situations and falsely bolstered my confidence in the practice. Instead of remembering all the wasted effort in coding to “Ideal”, I remember the rare victories where it saved me.

So from now on I am focused on coding to “Good Enough” rather than “Ideal”. Hopefully I will ship more software and better meet current requirements. I can’t predict or preempt change, it is a wasted effort planning for the unknown and unseen.

Note to self:

– Re-read “Pragmatic Programmer” Chapter 4 – “Good-Enough Software”

“Striving to better, oft we mar what’s well.” – King Lear 1.4

Cheers,

Ted ;)