constellex

Do you remember when vending machines used to work? Yea, me neither. I had a run-in with a vending machine the other day and then realized every time I use a vending machine, I’m always a little bit frightened it’s going to either not drop the goods, not allow me to get change back, or steal my money entirely. Usually this happens when I put in the last of my change. Why is this a problem that plagues the vending machine industry? Are vending machines extremely hard to maintain, have a high failure rate, or just terribly designed in general?

So when did it suddenly become acceptable for software to be released in a similarly poor quality. Is the software industry utilizing the broken vending machine effect? You can usually see this software tagged with a beta stamp, to protect the producer’s credibility. I’m not going to spend this blog post discussing specific instances of poor software, this is more of a piece of advice for any consumers of software: Do NOT accept poor software quality. If the software stinks, don’t support it.

And for the developers out there: The word beta is not reserved for releasing unreliable software. Beta is reserved for released software you’d like to be reviewed in order to determine if it solves the customer’s requirements. You can release it to a limited number of users with a limited feature set and call it beta, but only introduce new features once they are extensively tested internally.

If you can think of quality software in your life, you’ll probably realize you think it is quality because it always works the way you expect it to. For you consumers out there, don’t always be afraid to use software from smaller companies, usually those companies are started by people who are actually passionate about software.

Software developed by passionate people is usually of much higher quality than software supported by those who are not passionate.

August 12, 2007 at 12:00AM, we launched our new website. It’s much better than the plain Constellex logo.

Everything went smoothly during the launch except for some much needed and unwanted testing in Internet Explorer 7. We went to test the site in IE7 and found it wouldn’t render at all, but no errors were being thrown. After further investigation, the problem was with this line:

<script src="javascripts/main.js" type="text/javascript"/>

So what’s wrong with that? Turns out, not surprisingly, nothing. Here’s what IE7 wanted:

<script src="javascripts/main.js" type="text/javascript"></script>

That seems perfectly valid right? There is no difference, technically speaking, with those XHTML lines. Since XHTML is based on XML, and the script tag contains no body, you should be able to use the shortened version of the tag, and it should be recommended, as it reduces bytes to transfer over the wire. Safari and Firefox had no problem parsing the XHTML though.

In any case, we hope you enjoy the new site and welcome any feedback.

AJAX is all the rage over the Internet now, with various advantages and disadvantages. I won’t discuss those here, you’ve most likely read about them, and if not, there’s plenty of resources available. I want to talk about a problem that comes up often with people trying to develop applications using AJAX.

A lot of applications benefit from AJAX, but some are suffering as well. Some applications want to exist on the web, but break the rules. The HTTP 1.1 protocol spec states that “A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.” This is typically fine with AJAX, since you make a request and let the connection go. The same goes for a typical web request. As we’ll see later on with COMET, this is not the case.

HTTP requests and AJAX requests are both pull technologies. What I mean by that is the client makes the request and server simply responds. No connection is kept alive and the server is unable to contact the client at any point other than as a response to a request. But what if we want push technology through our browser? Well, HTTP wasn’t designed to do that. So most developers would stop there, which is probably a smart idea. It is impossible to create true push technology applications on the web without using third-party browser plugins. But you can fake it.

COMET is this elusive idea of being able to provide push technology through the browser. Most people would seem skeptical at first, but if you look further into the implementation, it’s almost a form of synchronous AJAX. That sounds strange… Synchronous Asynchronous JavaScript And XML (I understand AJAX, or Ajax, no longer has to stand for that acronym, but work with me here ). How can that be? Well let’s look at the strategy used to accomplish the COMET concept:

In essence, COMET acts a lot like typical threading, the client (browser) is the thread which blocks for a certain timeout period, until the server notifies it or the timeout occurs, and then repeat. This allows the end user to see instantaneous changes from the server, which is pretty awesome, because with AJAX, this can only be accomplished by using a polling technique, where the browser makes a call to the server checking for updates in very short intervals. That technique is a perfectly fine solution if you don’t mind scaling and performance issues as well as a large bandwidth bill. COMET will help reduce that.

Sound too good to be true? Well it is. Remember how I mentioned the HTTP 1.1 spec states we should only maintain a maximum of 2 connections at a time? Surprisingly almost all browsers follow this specification, which means while your COMET application is holding open those AJAX requests for that specified timeout period, the browser is now one less connection until you close the COMET application.

So there’s of course some advantages and disadvantages, just like any technology. COMET is useful for certain circumstances, most notably AJAX-y chat rooms. But tread lightly, you may be causing your end users headaches, which we all know is the last thing a company wants to do.

Maybe it’s just me, but I think most programmers would agree: some languages are just more beautiful than others. Beautiful is of course a relative term, but many programmers would probably agree it’s due to some complement between structure and simplicity. From a personal standpoint, I find Java to be well-structured, yet still beautiful. I also find Ruby to be simple from a verbosity point of view, which probably attributes to its beauty.

ActionScript looks very similar to Java. In fact, almost exactly like Java. I would probably compare it more closely to C#, but apples to apples, am I right? Either way, there is something inherently bad looking about it…something we all hate to love. It looks a lot like JavaScript. Here’s some examples:

public var myVar:String = "My string";

public function myFunction(o:Object):int{}

What irks me is that with a few changes the language would look just like Java/C#, providing two benefits: No unnecessary syntax and ease of learning for developers who already know those languages. Let’s pick apart the examples.

In the first example there’s two problems. For one, what is the point of specifying “var”? It seems pretty obvious to me that we’re creating a variable as there’s no syntax for parameters or a function block, so we’re definitely not creating a function or class. You might say they are trying to keep consistency with declarations, but with a variable, we aren’t defining structure, we’re defining an instance of something that has already been defined. Why not change the syntax to something a bit more understandable in my opinion:

public String myStr = "My string";


We’ve simplified the ActionScript code greatly. For one, it is more obvious that this object is a string. We’ve also removed the whole var nonsense. By mixing the variable name with its type, it makes for a little bit harder to read code: “myStr:String”. It’s hard to explain, but it seems unnatural to me to say: “I’m creating a variable named myStr. It is a String. It has this value.” It may look fine at its surface, but as a programmer, I would prefer to start generic and get into more details as I go: “I have a String. Its name is myStr. Its value is ‘My string’.”

Let’s tackle the second line of code. It has the same problems as the first essentially. What is the point of saying “function”? If it is to keep the pattern of stating what things are when defining their structure (Classes, packages, etc.), then I’ll allow it. Again, I would prefer to switch the entire function prototype around to something like this:

public int myFunction(Object o) {}


We’ve removed the unnecessary function declaration and also made it more clear what this function returns, as well as what types it accepts as its parameters. Why do I like having the return declaration to the left of the function name as opposed to the right? Well, let’s think logically and apply how we generally call functions. When you call a function, you tend to set its returning value to a variable, and just like in math and most programming languages using infix notation you have the variable on the left side and equation on the write. We can think of a function as the equation being solved and the result being stored on the left side of the equation. It just seems natural.

Maybe it’s just me, maybe I’m just picky about the look of my code. Ask Chris, I’ll have a fit if people put their curly braces on the next line after a function declaration, or if they don’t use curly braces after block statements that contain only one line of code after it, or if they don’t comment. Will Adobe ever change ActionScript to look more like how I’d like? Probably not. But this post goes out to those who find ActionScript a bit unnatural.

Well, that’s it for the roast of ActionScript. I could post about how it has no collections framework, but that’s outside the scope of the language in my opinion. Overall, ActionScript 3.0 is an improvement over its older versions (Except for the removal of private constructors), and it will only lead to more powerful Flash applications. Of which, we hope to show you in the near future.

One of the most important components to running a successful business is just that, running a business. It is sometimes hard to do so, but you have to leave your personal life out of it. A perfect example of this is including friends in your business ventures. If you can honestly analyze the situation and see that friend as a great contribution to the team, then bring them on. On the other hand, don’t just include them because they want to help and you don’t want to be mean. A person could be your best friend, but your worst business partner. Those two jobs do not include the same laundry list of qualifications and I think a lot of people don’t realize that.

Ok, so you decided to make your friend a business partner. Here comes a possibly awkward situation… contracts. Being good friends doesn’t mean they won’t try to screw you if given the chance. It’s human nature and you have to realize they will choose themselves over you any day. Therefore, put some checks and balances in place to avoid possible trouble. Things like a partnership agreement and restrictions on the bank account are a good start.

As I had mentioned in a previous post, Sally was removed as a partner in our company. In our agreement, we had planned how to handle that type of situation so it was simple and easy. Here is a list of some ideas to include in a partnership agreement:

• Name of the partnership and its members
• Contributions of each member
• Profit and loss allocation
• Authority and management responsibilities
• Adding or removing a partner
• How to resolve disputes
• Amending the partnership agreement

So when a friend asks you to be part of the business and you don’t think it’s a good idea, either try explaining it in a logical manner or use the infamous “it’s not you, it’s me…”

The correct answer is one, but he should be able to hop on one foot and rub his belly at the same time… The point to take from that probably not too humorous statement is that you should not have a business partner who specializes in changing a light bulb, unless of course your business is in changing light bulbs.

This topic, like most business-related ones, is filled with gray areas that depend on your situation. I plan to talk about a lot of business ideas as time goes on and am simply sharing my thoughts and our situation, so don’t take anything as absolute.

Overspecialization is a problem that I have seen in corporations, but it is also something that the little guy should really watch out for. A waste of space in a corporation most likely won’t cause any terrible effects, but if you’re starting a small business then it could really hold you back. A fun little fact about our company is that we started out with three partners. Marc and I have technical backgrounds, so we wanted someone else to handle the business side of things. Sally, in case he wants to remain nameless, is our very smart friend who came on-board to do just that.

There were other attractive aspects to having a third partner that included more capital and some good contacts, so we signed him up. Sally handled our taxes for the most part, which was nice, and also did some other administrative things. However, there just wasn’t enough work for Sally to remain a contributing member of our team. The amount of business tasks were few enough that Marc and I could handle them without a problem, so we had to let Sally go.

Since we are using this business as our source of income, we couldn’t have Sally taking a third of our profits if he wasn’t doing much. We fell victim to overspecialization because Sally handled business tasks, but couldn’t contribute in other areas. If Sally was also a programmer, then there most likely wouldn’t have been a problem. Since we are a small company, there just wasn’t enough activity for Sally at this point in the game. Sally, being the great guy that he is, completely understood the situation and accepted a check for his share of the company on his way out. Marc and I are still great friends with Sally because he understood that business is nothing personal, it’s just business… but I will get more into that next time.

Overloading methods, or functions, is an extremely powerful technique available to programmers in many object-oriented languages (Including Java, C++, etc.). Adobe, however, decided to leave this functionality out, which was a cause for many unexpected design changes to my recent ActionScript project. As a brief review, or introduction for programmers new to object-oriented programming, overloading methods allows for various different strategies. For example, we could have a method with the following prototype:

public boolean parse(String myStr);

As well as another method in the same class with the following prototype:

public boolean parse(int myInt);

There are a couple benefits we gain by being able to use this technique. For one, we could use this technique to simply allow a programmer using the class to be able to pass either a String or int to the parse method. A sample implementation in Java might be:

public boolean parse(String myStr) {

	// perform parsing algorithm on myStr

}

public boolean parse(int myInt) {

	return parse(String.valueOf(myInt));

}

Sure, the programmer that needs to use this class could simply cast/convert the integer to a String first and then call parse, but this makes things a little bit simpler for them. Overloading, however, gives us even more flexiblity. What if the parsing algorithm needed to change based on the object passed in? You couldn’t accomplish this with ActionScript 3.0 since it does not support method or constructor overloading. The rules are simple. You cannot have a method named the same as another method, regardless of differing return types or parameter lists.To the advanced programmer, you can see how limiting this is. How do we solve it? Well, to be honest, some of the cases I’ve pointed out can’t be solved in ActionScript 3.0. If you want to provide different algorithms based on the passed in object(s) via the same method name, you can’t, you need to make different methods with different names.If it is absolutely necessary that you support multiple algorithms based on the parameter passed in, you need to look into implementing the Strategy pattern. If you don’t need all of the overhead of an interface with concrete algorithm classes from the strategy pattern, you can hack this functionality in like so:

public function parse(o:Object):Boolean {

	var retVal:Boolean = false;

	if ( o is String ) {

		retVal = parseStr(o as String);

	} else if ( o is int ) {

		retVal = parseInt(o as int);

	}

	return retVal;

}

public function parseStr(myStr:String):Boolean {

	// Algorithm for strings here

}

public function parseInt(myInt:int):Boolean {

	// Algorithm for integers here

}

Yes, that’s hideous. Each time you want to be able to parse another type of object you need to add another function and modify the original parse one. Oh, and there’s no compile time checking to make sure that users of your class aren’t passing in an instance of Object that isn’t supported. So you’d need to add functionality to throw an exception. Hopefully Adobe adds method overloading in 4.0. Next up for part 3, unnecessary syntax.

ActionScript 3.0 is the new version of the Adobe Flash scripting language. ActionScript 3.0 is supposed to be a better implementation of Object-Oriented paradigms. Through my learning of ActionScript on my latest project (A XML Object-Relational Mapper between web services), I have come across several gotchas and frankly annoying things about ActionScript.

I will be doing a several part series on the various problems I’ve encountered using ActionScript and how to get around them or how Adobe should fix them. Either way, knowledge about these things is important to the typical OO programmer looking to learn ActionScript.

Private constructors. Although not the most commonly used feature of most object-oriented languages, they are essential for one of the most famous, or infamous depending on the programmer, design patterns. The Singleton. For those not in the know, the Singleton pattern is used for enforcing only one instance of a specified class. There are many uses for this, but I’ll leave that discussion to a place with a little more room.

ActionScript 3.0 is missing private constructors. This is intriguing for two reasons. One, private constructors were allowed in ActionScript 2.0. Two, private constructors were removed with what seems to be no reason. I have been unable to find any documentation as to why they were removed. This makes implementing the Singleton pattern rather strange. So how do we do it?

package com.constellex.actionscript {

	import flash.utils.getQualifiedClassName;

	public class Singleton {

		private static var instance:Singleton = null;

		public static function getInstance() : Singleton {
			if (Singleton.instance == null) {
				Singleton.instance = new Singleton();
			}
			return Singleton.instance;
		}

		public function Singleton() {
			if ( getQualifiedClassName(super)
				!= "com.constellex.actionscript::Singleton" )
				throw new ArgumentError();
			} else {
				// Your constructor code here
			}
		}

	}

}

The only difference this ActionScript 3.0 implementation does differently is that instead of checking at compile time whether you are correctly using the Singleton object, it will throw an ArgumentError exception if you attempt to instantiate the Singleton object outside of the Singleton class. The getQualifiedClassName(super) gets the name of the class calling the method, which allows the Singleton to check and make sure only the Singleton class can call the constructor.

Next up in part 2, overloading methods.

Web development is hard. No, it’s not server side applications, web services, HTML, or even *gasp* AJAX. It’s dealing with browser inconsistencies. For any novice web developer you know the drill, you create your web page and test it in your browser of choice. Then about half-way through completion you decide you should probably test it in those other browsers. Doh. Doesn’t work. But you followed all of the web standards and you even pass the W3C Validation test.

So what’s the problem? Well, there could be a number of issues, but one of the biggest contributors is the often forgotten about browser default styles. Yes, even when you build a site without any styles each browser applies its own style sheet at the most base level and unless you override those styles, they may be slightly different from browser to browser.

Solving that problem is actually rather simple and there are some clever solutions available. You need to essentially override all styles that are defined by the major modern browsers in your web page’s stylesheet. One solution that works particularly well available from the site linked above and originally from Left Justified:

* {
     padding:0;
     margin:0;
}
body {
     padding:5px;
}
h1, h2, h3, h4, h5, h6, p, pre, blockquote, form, label, ul, ol, dl,
fieldset, address {
     margin:20px 0;
}
li, dd, blockquote {
     margin-left: 40px;
}
fieldset {
     padding:10px;
}

Essentially you are overriding the margins and padding of all elements and then redefining them for individual elements. This starts you with a nice clean slate across all browsers and hopefully less headaches down the road.

Welcome to the Constellex official company weblog. This will essentially be an open channel of communication between Constellex and our customers, but we have more in mind for this blog. As a software company, we are always tackling new and difficult issues, and we would like to share our solutions from time to time.

Why would we do this? Well, for one we like to contribute back to the software community. We believe in, and use large amounts of, Open Source software, so it is in our best interest to aid that community whenever we feel we can.

At the same time we aren’t really sure what will come of this blog. Keeping our thoughts and decisions open will help us keep track of our history of choices as well as hopefully receive a lot of good input from anyone who comes across this blog.

I’ll keep this brief and get onto more interesting topics, but we wanted to welcome you to our blog and we hope to start some good discussions!