Nov 18, 2005 . Comments (0)
I recently began converting an application written in Flex 1.5/Actionscript 2.0 to Flex 2.0/Actionscript 3.0. As with any new language release there are always things I'm am glad to see included and things I am sad to see go. This time it is no different. I have been anxiously awaiting this release for many reasons but most of all to get my hands on Actionscript 3.0. It promised to deliver a similar jump in capability and performance that Flash 8 provided over Flash 7. I am sure as I spend more time working with it, I will get a better handle on just how much it has improved, but based on what I have seen so far, Actionscript 3.0 is a big improvement over Actionscript 2.0.
The leap in complexity terms for the whole suite of products (Flex, Actionscript, Flash) appears to be quite large. It reminds me of the leap from ASP to ASP.net, one day you had a swiss army knife for developing web sites and applications with and the next day you had a large tool chest full of most of the tools you could ever want. Looking at all that AS 3.0, Flex 2.0 and Flash 8 now include, I can not help but wonder what will become of all those coders and developers who have done reasonably well understanding the 'current' incarnation of Macromedia's products. A tutorial there, some hacks here, decompile a swf and presto, a 'web developer'. Not anymore. Actionscript 3.0 has just moved Macromedia's core products into a whole new arena and will force developers to either continually improve or get left behind.
I have always felt that a developer's greatest asset is not the languages they know, the speed they can code, or the level of complexity they can understand, it is their ability to learn. In a field where continual change and improvement is the norm, and it happens at a rapid rate, the ability to learn and learn fast sets certain developers apart from rest. If you can not learn new concepts, languages and terms, you quickly end up on the outside looking in. I have worked with many people who were really good, even great, at a point in time and then they stopped learning, and fell by the wayside, technology passed them and their career opportunities by. Anytime I interview developers one of the first traits I look for is the person's history of learning, and their aptitude for learning new things. If they can not learn, especially on their own, there is no sense in investing time and effort in them, because it will all go to waste in a relatively short period of time.
So where I am going with all this. Two places. First, over next while, I will be posting my discoveries, insights and headaches as I learn more about the new Macromedia releases. Secondly, and more importantly, as I learn, I want to pass on that knowledge to others who want to learn and keep up with the change, so that they can push the boundaries of what is possible with this release from Macromedia, and continue to push the technology forward so that the cycle of changing and learning continues.
Nov 14, 2005 . Comments (3)
Recently came across an really funny post about emerging web development technologies that are coming online and religious fervour that some people follow them with. While very humourous, Scott does hit on some good points. I continually run across techie zealots like the ones he mentions. People who support a specific technology to the end and blissfully ignore all others because "their's IS the best". There is no best, not for all instances. It depends on what the project is, what it needs to do, and ultimately what the client can afford. I used to work for a guy who had a great saying ...
Ford won car of the year with the Escort but do you really want to run a shipping business with Escorts?
Get the right tool for the job, don't ignore better solutions just because it's not your preferred solution.
In the span of a few weeks I have had two very similar discussions with two different developers who are well versed in a certain evil empire's server side technology and not that familiar with another company's slick client side technology.
In the first instance, I was in a meeting discussing the use of Flash to enhance some searching and lookup features in a client's web site and one of their techies spoke up and smugly said "I can do that with .net, style sheets and dhtml". I proceeded to show them how with Flash remoting the screen does not need to refresh to retrieve data, the user can be easily and intuitively guided in following steps, and the entire widget just plain looks nicer than an html based page. He finally conceded, but not without a fight. People just do not get it. I'm not sure if it's ignorance, fear of the unknown, or a combination of the two but, there are way too many people afraid to even consider better technology solutions ..... just because.
In the second instance, I was walking a developer through how Flash remoting works and how it can pass objects and data back and forth between the client and server and either side natively understands what they received from the other. He was initially very hesitant that it would work as advertised and didn't think it was a good solution. We setup some simple tests to send and receive simple data types and then complex data objects. After 30 minutes of 'preaching' he converted. The server side technology they use is perfect for what they need (not my first pick but it does everything they need it to), the client side could be better, and now, based on our simple tests and an open minded client, it is about to become much better.
Click here to read the full post, and keep an open mind.
Nov 07, 2005 . Comments (2)
I recently stumbled across this new take on Design Patters. In case the original version is no longer available I have reproduced it below.
Resign Patterns
Ailments of Unsuitable Project-Disoriented Software
by
Michael Duell
mitework@yercompany.com
Abstract
Anyone familiar with the book of patterns by the Gang of Four [1] knows that the patterns presented in the book represent elegant solutions that have evolved over time. Unfortunately, extracting these patterns from legacy code is impossible, because nobody knew that they were supposed to be using these patterns when they wrote the legacy code. Hence, this work is a catalog of patterns for the masses. The patterns presented here represent abundant solutions that have endured over time. Enjoy reading the patterns, but please don't use them!
1 Cremational Patterns
Below is a list of five cremational patterns.
1.1 Abject Poverty
The Abject Poverty Pattern is evident in software that is so difficult to test and maintain that doing so results in massive budget overruns.
1.2 Blinder
The Blinder Pattern is an expedient solution to a problem without regard for future changes in requirements. It is unclear as to whether the Blinder is named for the blinders worn by the software designer during the coding phase, or the desire to gouge his eyes out during the maintenance phase.
1.3 Fallacy Method
The Fallacy method is evident in handling corner cases. The logic looks correct, but if anyone actually bothers to test it, or if a corner case occurs, the Fallacy of the logic will become known.
1.4 ProtoTry
The ProtoTry Pattern is a quick and dirty attempt to develop a working model of software. The original intent is to rewrite the ProtoTry, using lessons learned, but schedules never permit. The ProtoTry is also known as legacy code.
1.5 Simpleton
The Simpleton Pattern is an extremely complex pattern used for the most trivial of tasks. The Simpleton is an accurate indicator of the skill level of its creator.
2 Destructural Patterns
Below is a list of seven destructural patterns.
2.1 Adopter
The Adopter Pattern provides a home for orphaned functions. The result is a large family of functions that don't look anything alike, whose only relation to one another is through the Adopter.
2.2 Brig
The Brig Pattern is a container class for bad software. Also known as module.
2.3 Compromise
The Compromise Pattern is used to balance the forces of schedule vs. quality. The result is software of inferior quality that is still late.
2.4 Detonator
The Detonator is extremely common, but often undetected. A common example is the calculations based on a 2 digit year field. This bomb is out there, and waiting to explode!
2.5 Fromage
The Fromage Pattern is often full of holes. Fromage consists of cheesy little software tricks that make portability impossible. The older this pattern gets, the riper it smells.
2.6 Flypaper
The Flypaper Pattern is written by one designer and maintained by another. The designer maintaining the Flypaper Pattern finds herself stuck, and will likely perish before getting loose.
2.7 ePoxy
The ePoxy Pattern is evident in tightly coupled software modules. As coupling between modules increases, there appears to be an epoxy bond between them.
3 Misbehavioral Patterns
Below is a list of eleven misbehavioral patterns.
3.1 Chain of Possibilities
The Chain of Possibilities Pattern is evident in big, poorly documented modules. Nobody is sure of the full extent of its functionality, but the possibilities seem endless. Also known as Non-Deterministic.
3.2 Commando
The Commando Pattern is used to get in and out quick, and get the job done. This pattern can break any encapsulation to accomplish its mission. It takes no prisoners.
3.3 Intersperser
The Intersperser Pattern scatters pieces of functionality throughout a system, making a function impossible to test, modify, or understand.
3.4 Instigator
The Instigator Pattern is seemingly benign, but wreaks havoc on other parts of the software system.
3.5 Momentum
The Momentum Pattern grows exponentially, increasing size, memory requirements, complexity, and processing time.
3.6 Medicator
The Medicator Pattern is a real time hog that makes the rest of the system appear to be medicated with strong sedatives.
3.7 Absolver
The Absolver Pattern is evident in problem ridden code developed by former employees. So many historical problems have been traced to this software that current employees can absolve their software of blame by claiming that the absolver is responsible for any problem reported. Also known as It's-not-in-my-code.
3.8 Stake
The Stake Pattern is evident in problem ridden software written by designers who have since chosen the management ladder. Although fraught with problems, the manager's stake in this software is too high to allow anyone to rewrite it, as it represents the pinnacle of the manager's technical achievement.
3.9 Eulogy
The Eulogy Pattern is eventually used on all projects employing the other 22 Resign Patterns. Also known as Post Mortem.
3.10 Tempest Method
The Tempest Method is used in the last few days before software delivery. The Tempest Method is characterized by lack of comments, and introduction of several Detonator Patterns.
3.11 Visitor From Hell
The Visitor From Hell Pattern is coincident with the absence of run time bounds checking on arrays. Inevitably, at least one control loop per system will have a Visitor From Hell Pattern that will overwrite critical data.
4 References
Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
Michael Duell is an Engineer at AG Communication Systems, where his Resign Patterns have been rejected in favor of the Gang of Four Design Patterns. "Resign Patterns: Ailments of Unsuitable Project-Disoriented Software," The Software Practitioner, Vol. 7, No. 3, May-June 1997, p. 14.
Search
About
Archives
Recent Posts
Links
Feeds