Archive for February, 2009

Teams, Chad Fuller, and Business Investments

CHOOSING A TEAM

Owning and running a business, the most important elements to your company are your image and the people working with you. This is even more important when you are a smaller business. If you are surrounding by the best of the best, that becomes the perception of what your company is. A small agile company composed of experts is a lot different than a large company with a few experts and a lot of worker bees. Both are valid models and neither is right or wrong. I opt for the quality over quantity approach, regardless of the income difference.

Therefore, when looking for folks to work on projects or to join the team, I look for people that are:
a) smarter than I am
b) completely devoted
c) care

It’s a decision that I don’t take lightly since I’m essentially asking someone to join a “family of friends”. That’s how I view work. It is part of your life, the people around you are part of your life, and you should surround yourself with those that bring out the best in you and themselves.

CHAD FULLER

Last June, Mr. Chad Fuller sent me a note mentioning that he was moving to Atlanta. I knew Chad well, knew how smart he was, but also knew that he didn’t have any work experience. Point blank, experience is huge for us. Due to the positioning of Dreamsocket, we typically receive jobs I would refer to as high experience work. Thus, we can’t have people work on the projects who don’t know the technologies better than they know their own name. It is our position and what we’ve built the business on it. So Chad was in a way a gamble. Obviously there is risk with any gamble. You either win or lose. However, I took a pretty calculated gamble and came out ahead…. way ahead. If I were in Vegas, I would probably be the owner of the Wynn right now ;) .

How did I win? Instead of throwing projects at Chad he would tear his hair out with, I decided to invest in him and the company. Chad’s first project was dreamsocket.com. If you haven’t looked at the site yet I highly advise that you do. Not out of self promotion, but to see what he accomplished. Before the project, Chad had never touched HTML or built a website. After the project he could boast a site that included a store front, live docs, bug tracker, and more all under one dynamic system. Needless to say, I’m more than impressed. Being able to own and shape it himself, Chad really was able to take value in his creation and learn a lot (at least I think he did ;) ).

INVESTMENTS

Since the site was an internal project, it was an investment. We invested in defining our image more concretely, creating a way to extend our business, and developing ole Chad. Personally, I know what its like to run in his shoes. Developers that care want to learn as much as they possibly can, to work on great things, and just enjoy what they do. It felt really good to give him a project that he could call his own, mold it, and learn from. That is really what being a business owner can do for you, it can help you help others.

As much as the business will let me, that is what I intend to do. Invest in the folks around me. If your folks have passion, let them run with it as much as you are able to afford. Your workers will grow in strength, which will in turn mean that you get an experience level you couldn’t get any other way. On that note, Chad got the IPhone bug and I’m letting him get all over it. It means diversification and it means he continues dealing with things he is really excited about. Wait and see what he’s got running ;) .

Look for big things on Chad’s blog and our site

No Comments


Presenting Dreamsocket Media Framework Tomorrow Night

I will presenting our media framework tomorrow night at the Flash Platform meeting.

The general outline of the presentation is to talk about our client work history, run through the framework, talk about what we are working on, and basically field questions and get input from folks.

Anyone that is interested please come out. The presentation will hopefully give you insight on what we have done and the field in general.

The meeting is being held at 7pm over at Round Box (King Plow)
981 Joseph E Lowery Blvd NW
Suite 100
Atlanta, GA 30318

You can get all the details at Meetup.com

I look forward to seeing everyone tomorrow night.

No Comments


Tonight: “Extending Flex 3 Components” and “Concurrency Approaches in Flex and Air”

“Extending Flex 3 Components” and “Concurrency Approaches in Flex and Air” are the two topics for tonight’s Atlanta Flash/Flex User group meeting. From reading the description, it looks like the presentations are going to be winners. I’m definitely planning on making it out and you should to ;) . If you want to chat, feel free to introduce yourself. I’m sure to talk your head off about programming!

Below are the details

Feb 18, 2009 Meeting Details
Date: Web., Feb 18, 2009
Pizza & Schmoozing: 6:00 PM
Meeting Time: 6:30 PM to 9:00 PM
Location: EchoEleven Offices
Dress: Anywhere from casual to business formal
Price: FREE!
RSVP

Extending Flex 3 Components
Presented by Matt Boles

Start your learning of how to customize both functionality and appearance of built-in components through this session. You will see now to manually add objects to the display list, as well as how to override built in methods to alter component functionality.

Concurrency Approaches in Flex and Air
Presented by Charlie Hubbard

As the Flex platform matures, our ability to write more complex programs increases. As complexity increases, so does the need for long running computations. Technologies like Air force us to solve these problems without the aid of a server. While Flash, on the surface, seems to be missing things like threads to solve running concurrent jobs there are techniques for handling this. In this talk we’ll explore those techniques for handling long running computations on the Flash platform. We’ll look at classic computational problems such as fractals, and more common place problems like parsing large XML and JSON data in Actionscript. We’ll also talk about the future possibilities for Actionscript in this area.

About the Speakers:

Matt Boles is the Technical Lead for the Adobe Partner Enablement group and has been developing and teaching courses on Flex since the 1.0 release. Matt has a diverse background in web development, computer networking, and teaching in both professional computer classes and the public schools. He coauthored the Flex Training from the Source books for both Flex 2 and Flex 3, and was also a coauthor on the Certified ColdFusion Developer Study Guide. He has also developed official Allaire/Macromedia/Adobe curricula in the Flex, ColdFusion and Flash development content areas.

Charlie Hubbard is a 10+ year veteran of the software industry, blogger, open source project contributor and project creator. His days are filled as a Senior Software Engineer at Nexidia working on a grid based approach for searching audio. In his free time he enjoys working with Ruby, Java, Flex, Javascript, and has been known to make a film every once in a while. Charlie and his wife live and work in Atlanta.

No Comments


Event type naming: qualifying vs simple

I have put a lot of thought into event naming recently. In my research, I've seen a few developers fully qualifying their event type names. This is something I actually debated myself when writing our Media Framework, but opted not to do. The subject is debatable, so let me describe what I mean by fully qualified names and why I decided not to use them. Based on the points I outline you can make your own decision of whether to use them yourself.

What is a fully qualified event type name?
ActionScript 3 has a formal event framework where objects dispatch events and others subscribe to them and react accordingly. Each event dispatched is represented by an event object. All of the native AS3 event objects follow a formal convention of defining the types of events they can be dispatched as. This convention places a static constant representing the type name directly on their class to allow for strict typing. For example, Event.RESIZE denotes an event type of "resize" for the flash.events.Event object. The property value itself equates to a simple string. In all native AS3 objects these strings are simple and only represent the action (ex: "resize").

Some programmers are actually fully qualifying these strings. Instead of Event.RESIZE representing the string "resize", it is equal to "flash.events.Event.RESIZE". Now why do this? Well say you had another event ComponentEvent which had a resize event. If you fully qualified it as well, you would have ComponentEvent.RESIZE equating to "com.dreamsocket.events.ComponentEvent.RESIZE". Notice that now both events could be thrown from the same object and subscribed to distinctly. If they both represented the string "resize" then you would run into cases where you thought you subscribed to one event but would potentially receive both.

Why I chose not to use full qualifed names
Even though fully qualifying the string that represents the event type resolves subscription conflicts, for the most part you can resolve them just by prepending your event's name to the type. ComponentEvent.RESIZE could be "componentResize". In a sense this allows you to qualifying it without having a very long unique string. This is what I opted to do. One of the reasons I did this was for less advanced users and for code spiking. Simply, if you want to do things fast, it is easier just to type in a short magic string when listening to an event vs actually importing in the class and typing it out statically.

Actionscript:
  1. foo.addEventListener("componentResize", this.onEvent);

vs

Actionscript:
  1. import com.dreamsocket.events.ComponentEvent.RESIZE;
  2. foo.addEventListener(ComponentEvent.RESIZE, this.onEvent);

Yes, this is kind of the lazy approach and one might also say its bad practice since without strict typing it could result in a "magic error". However, I do it when I'm trying to spike an idea real fast, and I know others do it as well. I'd even venture to say designer/developer hybrids are especially prone to use it since it serves as a comfort concept they brought over from ActionScript 2. It is a practice that exists and I can't say whether it is right or wrong.

Summary
In summary, fully qualified event types have a purpose and serve their purpose well. In our case, we wanted to take into account developers who were used to exploiting existing conventions. I feel even bad habits have advantages if it creates productivity, so the coin toss resulted in a choice not to take them away.

What are your thoughts?

3 Comments


MediaFramework FlashAS2 1.57, FlashAS3 1.67, FlexAS3 1.52 released

We released a minor update to the Dreamsocket Media Framework that addresses issues with streaming video and mp3s. The release is an update to all 3 versions (Flash AS2, Flash AS3, and Flex AS3) and is available for download in customer accounts.

Here is a brief outline of the changes:
[FIX] ondemand streaming not being canceled out
[FIX] duration not being reset on close for StreamingNS
[FIX] corrected streaming mp3 initialization
[CHG] added autoloading of content if closed and setting a url back to the same one
[CHG] re-added getLength calls for StreamingNS content
[CHG] handling of netconnection status events after connecting
[CHG] added netConnection as a property of AbstractMediaNS

For the full release history for each version please check out our release notes section.

No Comments


How we built Dreamsocket.com

Fellow Dreamsocketeer and partner in crime, Mr. Chad posted a short little article on Dreamsocket briefly outlining how we built the site. He mentions how he put together the store front, live docs, bug tracker and more all under one cohesive roof. If you are interested in how we accomplished it all, then definitely give it a read and post any questions you may have.

No Comments


Dreamsocket Site updates 2-17-09

Based on all the feedback and site analytics, we've updated dreamsocket.com. The quick change list includes media framework demos, live support chat, code highlighting, and extra company info.

Check out our full blog post on the site for more details. We definitely care what you think so post your thoughts and ideas on what we are doing!

No Comments


Blog Facelift

Yesterday I had Dreamsocketeer - Chad give this blog a much needed face lift. Unfortunately, I let it go to long with a dated default look that made it hard to read some entries. Obviously, most people just grab the feeds through a reader, but for those making the trek to the site it made sense to give you something that appealed to the eye. In addition to lovely new "clothes", I threw in some additional social links of mine in the navigation for those wanting more info on who I am, what I do. Enjoy the new lovely!

1 Comment


Atlanta iPhone User Group: February Meetup TONIGHT!

For anyone that isn't aware, Atlanta has a pretty solid IPhone user group that has been meeting frequently. Though, I've only been to one meeting, I was pretty impressed by the turnout and diversity of its participants. Whether you are just getting started or you are a veteran, it seems like a good fit for all. I encourage anyone in the Atlanta community that is interested in developing for the platform to go.

Tonight is February's meeting and below is the agenda
7:00 to 7:20 - Drinks and Introductions
7:20 to 7:30 - Mobile Strategy or User Experience Topic
7:30 to 7:55 - SDK Tutorial Topic
8:00 to 8:30 - Native Applications Show & Tell

If you are interested go sign up now. Unfortunately, I won't be able to attend tonight, but am trying to have a Dreamsocketeer to go in my place.

No Comments


Default Event Constructor Parameters used in Subclasses

The base Event class in Flash has 3 parameters.

Actionscript:
  1. public function Event(type:String, bubbles:Boolean = false, cancelable:Boolean = false)

The first parameter, type, is required. The second two, bubbles and cancelable, default to false. This means that you don't have to pass either of these two parameters and they will incur values.

If you look at any of the native Flash Event subclass constructors, their additional parameters follow the Event base's default parameters and have defaults.

Actionscript:
  1. public function IOErrorEvent(type:String, bubbles:Boolean = false, cancelable:Boolean = false, text:String = "", id:int = 0)

So the questions arise when you subclass an event and you have a new parameter you consider required: Should all additional parameters be required to follow the base parameters to ahere to the base signature? Should a developer have to type in values that almost a 100% of the time will be defaulted in order to type in one that is thought to be required? Obviously, if this is the case then the additional parameters can not be required by the compiler and only enforced by practice. These parameters would have to have defaults.

Actionscript:
  1. // required parameters following default ones is illegal and the compiler will flag it
  2. public function Foo(defaultParam:int = 0, requiredParam:int)

While working on our media framework, I debated on whether it was valid to follow Flash's native Event subclasses and make required parameters only required by practice or whether to change the subclass signature and make them required by nature. I settled on the fact that it's ok to switch up the order of parameters in the constructor's signature and place new required parameters before base default ones.

Actionscript:
  1. // super constructor
  2. public function Event(type:String, bubbles:Boolean = false, cancelable:Boolean = false)
  3.  
  4. // subclass constructor
  5. public function DownloadEvent(type:String, currentProgress:Number, totalProgress:Number, bubbles:Boolean = false, cancelable:Boolean = false)

If the parameters were all defaults, a developer could forget a "required" one and end up having to debug unexpected results. By actually requiring parameters, a developer who forgets to put them in then will get warned by the compiler. This seems better practice and also feels more natural when programming. For example, when creating new instances, you only have to pass in required parameters and can let the base ones default.

Actionscript:
  1. this.dispatchEvent = new DownloadEvent(DownloadEvent.DOWNLOAD_STARTED, .5, .5)

Personally, I don't think signature familiarity is as important as context responsibility. It also doesn't make sense to force yourself into a practice that can actually be less productive and hurt you rather than be beneficial. That's my take.

1 Comment