Simple And Stupid Software Implementation Examples
Greetings all,
As we speak I am sitting at the 360Flex conference keynote. Seeing previews of some very interesting Flex based applications and technologies. 
Will hope to have more for you in the future…
- Saj
PS - if you have any Flex questions, feel free to email me and I’ll see if I can find the answers at 360Flex for you.
UPDATE: I’ve got some great little Flex Builder tips for all of you when I return!
ENVIRONMENT: Flash CS3, ActionScript 3.0/2.0
TOPIC: packages & classes
“There are 10 types of people in this world. Those who understand binary, and those who do not.”
This is one of those little insightful jokes that truly express many of the struggles in the programming world. Most people will be confused by the above statement wondering who the other 8 people are. A few, who speak binary, will have read it naturally as dealing with two individuals. And a fair number of us geeks will have deduced from the context the twist in the words. An equally fair number of us geeks are probably still clueless. Doesn’t mean you’re stupid - just means you probably don’t deal with binary code that often.
For those entering the world of classes and packages, you might feel very akin to those wondering who the other 8 people are. If you’ve never dealt with classes (not uncommon for many web designers and programmers of older non-classed based languages - or both as the case may be for Flash developers who haven’t worked with the newer ActionScript methodologies).
Trying to understand new concepts while at the same time trying to deduce proper syntax can result in a great amount of frustration. You can have the concept understood and be unable to implement it because of a syntax issue.
A good case in point is the different implementations of packages and classes in ActionScript 2.0 versus 3.0.
For Comparison, the following defines a class in a package in AS2, where the pathname defines the package the class is a part of:
class path.classname{}
Where as in AS3, the package is designated separately from the class as shown below:
package path{
public class classname{}
}This doesn’t even address the systems end of having your Flash application configured to look in the proper location of your computing platform to access the classes.
What is likely second nature and seemingly intuitive to one who has been working with packages and classes for years can in fact be a frustrating stumbling block for one entering this world for the first time. Many examples out there, and most of the official documentation, make the assumption that you already have all your pieces together. If this is not the case, (and it’s often not for someone who is new to this and thus in need of documentation), then the provided examples fail to run - breaking and leaving the programmer with little insight into the error of his or her ways.
I have attempted to provide an example from start to finish of creating and using a class in a package. Addressing both the syntactical differences between AS3 & AS2 as well as instructing the user how to configure Flash to properly look for the the classes. It is my hope that these examples will provide some useful insight to those trying to get the ball rolling.
Example 1:
http://www.easternstorm.net/sassie/example1/sassie_example1.zip(NOTE: These examples require Adobe Flash CS3)
S.A.S.S.I.E. = “Simple And Stupid Software Implementation Examples”
For years now I’ve found myself struggling with documentation and examples which often skip steps, fail to address the basics or are in fact don’t even work. It gets very frustrating and quite stressful as office deadlines approach and you find yourself hung-up on some bit of code for no apparent reason.
Most of us in the programming world have encountered this. The web blog’s goal is to simply offer bits and solutions (even questions) while endeavoring to keep things very simple.
I ask that all readers please be polite and set aside egos. Please be helpful and not downcasting. (And most programmers out there are helpful but there is nothing more frustrating when struggling with a problem then someone to give a pop-off answer with an exclamation of generalization how every programmer should be able to do what you’re presently struggling to do. More often than not the responder hasn’t even understood your problem.)
In truth, many of us programmer’s are simply trying to do our jobs; so we can pay our bills. We have families and we try to have lives away from our computers. There’s no need to look down on a fellow programmer because they have a lack of knowledge - rather, look at it as an opportunity to help fill that lack.
Often the case we programmers become very specialized in the work we do. What may seem general common knowledge and usage to some may never come up in our office environment. For example, a programmer who has spent most of their time interacting with databases coding form submissions and queries to those databases may find themselves clueless when asked to generate an email submission. This does not mean the programmer is stupid, just that he is in unfamiliar waters.
One doesn’t ridicule someone for being lost and call them stupid - one gives them directions!
THAT IS ESSENTIALLY MY GOAL WITH THIS BLOG - TO SIMPLY HELP OTHERS WHEN THEY SAIL THROUGH WATERS I’VE ALREADY SAILED IN…
