Diagram focuses on how to create a Flash Application (compiling MXML and Actionscript files using the free Flex SDK) and on what kind of interactions a Flex-made application can perform with external systems.

Some starting (and incomplete) references:

• Protocols

• AMF (Action Message Format) used for serializing objects [link]
• RTMP (Real Time Messaging protocol) used for messaging [link]

• Adobe Flex Data Service (renamed in Adobe Lifecycle Services) [link]
• Open AMF [link]
• Red5 Flash Server [link]

Being geeks we think that we have to create big-complext-technical-things to sell something, instead may be it is simpler……

When you are lazy typing commands, you can use Firefox extension called FastYub! from SystemPuntoOut.

I think that the adoption of a tool/practice is dependent of the project context, the team and project of course. Feel free to tell me if I am missing something important.

(click on image)

You scored as Philosophy. You should be a Philosophy major! Like the Philosopher, you are contemplative and you enjoy thinking about the purpose for humanity's existence. Philosophy 83% Sociology 75% English 75% Engineering 67% Biology 67% Mathematics 67% Linguistics 58% Chemistry 50% Journalism 50% Anthropology 50% Psychology 50% Theater 42% Dance 25% Art 25% What is your Perfect Major? (PLEASE RATE ME!!<3) created with QuizFarm.com

Source: [Gamma et all, "Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley, 1995]

• Program an Interface not an Implementation
• Favor Composition Versus Inheritance
• Find what varies and encapsulate it

Source: [R. Martin, “Agile Software Development, Principles, Patterns, and Practices”, Prentice-Hall, 2002]

• Dependency-Inversion Principle
• Liskov Substitution Principle
• Open-Closed Principle
• Interface-Segregation Principle
• Reuse/Release Equivalency Principle
• Common Closure Principle
• Common Reuse Principle
• Acyclic Dependencies Principle
• Stable Dependencies Principle
• Stable Abstraction Principle

Source: [Larman, “Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development”, Prentice-Hall, 2004]

• Design principles are codified in the GRASP Pattern
• GRASP (Pattern of General Principles in Assigning Responsabilities)
• Assign a responsibility to the information expert
• Assign a responsability so that coupling remains low
• Assign a responsability so that cohesion remains high
• Assign responsabilities using polymorphic operations
• Assign a highly cohesive set of responsabilities to an artificial class that does not represent anything in the problem domain (when you want to maintain low coupling and high cohesion)
• Don’t talk to strangers (Law of Demeter)

Source: [Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules", Commununication of ACM, 1972]

• Information Hiding
• Modularity

Source: [Hunt, Thomas, “The Pragmatic Programmer: From Journeyman to Master”, Addison-Wesley, 1999]

• DRY – Don’t Repeat yourself
• Make it easy to reuse
• Design for Orthogonality
• Eliminate effects between unrelated things
• Program close to the problem domain
• Minimize Coupling between Modules
• Design Using Services
• Always Design for Concurrency
• Abstractions Live Longer than details

Source: [Lieberherr,Holland, “Assuring Good Style for Object-Oriented Programs”, IEEE Software, September 1989]

• Law of Demeter

Source: [Raymond, "Art of Unix Programming", Addison-Wesley, 2003]

• Rule of Modularity: Write simple parts connected by clean interfaces
• Rule of Clarity: Clarity is better than cleverness.
• Rule of Composition: Design programs to be connected to other programs.
• Rule of Separation: Separate policy from mechanism; separate interfaces from engines
• Rule of Simplicity: Design for simplicity; add complexity only where you must
• Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do
• Rule of Transparency: Design for visibility to make inspection and debugging easier
• Rule of Robustness: Robustness is the child of transparency and simplicity
• Rule of Representation: Fold knowledge into data so program logic can be stupid and robust
• Rule of Least Surprise: In interface design, always do the least surprising thing
• Rule of Silence: When a program has nothing surprising to say, it should say nothing
• Rule of Repair: When you must fail, fail noisily and as soon as possible
• Rule of Economy: Programmer time is expensive; conserve it in preference to machine time
• Rule of Generation: Avoid hand-hacking; write programs to write programs when you can
• Rule of Optimization: Prototype before polishing. Get it working before you optimize it
• Rule of Diversity: Distrust all claims for “one true way”
• Rule of Extensibility: Design for the future, because it will be here sooner than you think

Source: [Coplein, "Multi-paradigm Design for C++", Addison-Wesley, 1998]

• Commonality/Variability Analysis

Source: [Lidwell et all., "Universal Design Principles", Rockport, 2003]

I report only a subset of principles that according to me apply directly to software design:

• 80/20 Rule
• Consistency
• Cost-Benefit
• Layering
• Modularity
• Ockam’s Razor

Source: [Meyer, "Object Oriented Software Construction", Prentice-Hall, 1997]

• Modularity
• Direct Mapping
• Few Interfaces
• Small Interfaces
• Explicit Interfaces
• Information Hiding
• Linguistic Modular Units
• Self-Documentation Principle
• Uniform-Access Principle
• Open-Closed Principle
• Single-Choice Principle

Source: [Wirs-Brock, McKean, "Object Design", Pearson Education, 2003]

• Design for flexibility and Extension (abstraction, classification, composition, inheritance and parametrization)
• Design for reliability (consistent exception-handling policies)
• Predictable, Consistent and Comprehensible design (there is no recipe here)

Source: [Martin Fowler, Kent Beck, John Brant, Refactoring: improving the design of existing code, Addison-Wesley, 1999]

In this book the idea of code smell was introduced. Code smells can be figure out as guidelines when you design software

• Duplicated Code
• Long Method
• Large Class
• Long Parameter List
• Divergent Change
• Shotgun Surgery
• Data Clumps
• Primitive Obsession
• Switch Statement
• Parallel Inheritance Hierarchy
• Lazy Class
• Eliminate unuseful classes
• Speculative Generality
• Temporary Field
• Message Chains
• Middle Man
• Inappropriate Intimacy
• Alternative Classes with different interfaces
• Incomplete Library Class
• Data Class
• Refused Bequest
• Comments

As Fred Brooks suggests in his book is: “Complexity of software is an essential property, not an accidental one“. In other words software development is about managing complexity and the goal of a team is to build the illusion of simplicity.

I agree with Grady Booch when he writes in his paper that the “difficulty of design lies in disclosing which design and architectural decisions should be used to best balance the technical, economical, business, political and emotional that swirl around every software intensive system”.

To put in other terms as Booch continues: “the problem of design is NP-complete“. An optimal solution that balances forces exists but it is not computable. “So we have to accept a compromise and selecting then a good enough solution for our design problem“.

In aid of software architects that have to select the right decisions come software design principles. As dictionary says, a principle is a a “comprehensive and fundamental law, doctrine, or assumption“. Some of these design principles are quite generic and abstract that rarely help concretely a developer during the process of software design. Some of these design principles are sometimes called “heuristics” which as you can argue means “problem-solving by experimental and especially trial-and-error methods”.

There are a lot of design principles documented in books and in websites. They are important for the designer but they aren’t decisive. So I think that I can write following equation:

good_architect = Desing_Principles + Experience

Experience is the decisive factor in software development. Experience not only deals with technical stuffs but it relates with people (management , team, customer), with economic forces (market goals and pressure). To get experience you have to work on a wide kind of projects, with the right team, with the right technologies. I hope you can do this in your working life. Alas this is not particulary true for most of our careers.

To achieve experience, at least, on the technical side there is an important tool in the architect’s toolchest. The concept of Software Pattern. In general term Patterns can help by trying to identify common solutions to recurring problems. The interesting thing of pattern is that they are captured by experience. They aren’t designed upfront in a speculative way. They emerge from the field, from real software that works, from real teams.

When we speak about pattern we think at the seminal work of Gang of Four. That’s correct but there exists a larger ecosystems of software patterns that can help designers in their daily work. I tried writing a catalog of patterns in literature. The same has done Grady Booch in his Handbook of software architecture.

(pattern catalog – click on image)

Pattern reading is an important activity for every software architect which hasn’t a valuable experience. I think that pattern studying is an important activity in any computer science curricula. Students can learn a lot about software design and architecture without waiting to hurt in the war’s field of a software development job.

In the last few years a lot of software intensive systems have been developed and put in production. Most of them was based on opensource projects. There is a lot of code hidden in opensource projects that claims to teach us design solutions, architectural patterns, idioms or naïve application of existing patterns and a set of principles and practices.

For my Ph.D thesis I don’t want to study theoretical and speculative academic stuffs. Inspired by the great and motivating work of Grady Booch with his handbook of software architecture, I am going to start a study of design solutions applied in several and concrete opensource projects with the goal of recovering architecture and mining new patterns or combination of existing ones.

Solution: mplayer, lame, shell script and cron

1) I wrote a script called record.sh that get an output filename and an url representing the stream to record

#!/bin/sh
# Usage:
#     record.sh <file> <url_to_record>
mplayer -quiet -cache 32 -vc dummy -vo null -ao pcm:file=$1.wav $2 > /dev/null
lame --quiet --preset radio $1.wav $1.mp3
rm $1.wav > /dev/null

2) I wrote a script that grabs my favourite program. Call it for example grab_xyz.sh

#!/bin/sh
RECORD=/home/pc/bin/record.sh
filename=/data/shared/P2PDownload/toListen/$(date +%y%m%d)_xyz
$RECORD $filename rtsp://url/xyz.rm

3) Finally I edited a cron job (cfr: crontab -e)

# Record 'XYZ from Live Stream' (from 13.30 to 14.30)
30 13 * * *     $HOME/bin/grab_xyz.sh
30 14 * * *     /bin/killall mplayer

4) At end I’ll find (in toListen directory)

060118_xyz.mp3
060117_xyz.mp3
060116_xyz.mp3
..................

Ok it’s a small and simple hack but it works and it avoids to buy dedicated shareware.

I am planning to analyze systems built with recent and exciting technologies such as Jini, JXTA and Peer to peer in a broad sense. I am in search of opensource systems to study. Alas most of the works with these niche technologies are commercial systems and so it is difficult to analyze and study source code and the related architecture.

So if you know any opensource system related to this field which is worth of study, please drop me a mail.

I solved synchronization issues using a Home Linux Server and Internet. Server acts as data centralizer and collector for all these systems. I started also experimenting Web2.0 services which can solve easily annoying problems.

My Home Server is equipped with a Gentoo Linux distribution and it performs usual services: file & print server, vnc, subversion and ssh. Synchronization of data files is done using Unison file synchronizer which allows replicas of a collection of files and directories to be stored on different hosts, modified separately, and then brought up to date by propagating the changes in each replica to the other. Unison is truly multiplatform: I can easily synch linux, windows and osx without problems. It works very well in low bandwidth condition too.

Programming projects and source code instead are synchronized with the popular version control tool called Subversion. Any time I switch machines I synch my data (or commit in the case of subversion) and do another synch (or an update in the case of subversion) on my new machine. Everything keeps nicely synced, and I get full version control too.

Unison and subversion are good for documents and source files. Other kinds of data need to keep synchronized and previous tools are not enough. So here is a summary of my strategies for treating all ubiquitous data:

Documents: Unison
Projects and sourcecode: Subversion
Mail: IMAP Server (I purchased a Fastmail.fm account which is very good)
Bookmark: Delicious
RSS: Bloglines
Memos: Writely
Addressbook: Palm PDA (not synch’ed)
Calendar: Palm PDA (not synch’ed)

I know it’s not perfect and from some point of view it can be hard to understand. But I think that benefits of working regularly with different environments are grater.