Staging and Deployment

[ LiB ]

Long after prototyping but still before your application is ready for prime time, you'll want to stage it. Staging refers to viewing your application in its final form, but not in its target locationthat is, not on the public server or wherever you intend for it to reside. It's like the last step of testing before you go live.

Staging probably sounds easier than it really is. The thing is, you can't always test your application on your hard drive. Many applications use application servers that abide by a different set of restrictions. When you test a Flash SWF on your hard drive, for example, it's allowed to reach out and load data from web services on remote serverssomething that's restricted when you view your movie in the browser from a web server. Every time you test a movie, it will work, but it will fail when you deliver.

In addition to my previous dire warnings, I have a few specific recommendations to make your staging go smoothly:

• Perform reality checks or proof-of-concept test runs throughout the production. That is, do mini-stagings along the way. This way, you're more likely to find (and resolve) problems before you get too deep.

• Use variables as constants for base values. For example, if you're delivering to http://www.phillipkerman.com/realthing/ but want to do your testing at http://www.phillipkerman.com/test/ , store one of those URLs in a variable (for instance, BASE="http://www.phillipkerman. com/test/" ). Then, when you go live, you can just change that variable. Consider if you had written out that URL in multiple places in your codeyou'd have to be sure to fix each instance. (By the way, using all capital letters for variable names , like BASE , is a convention that means you're treating the variable as a constantyou intend to set it once and not change it.)

• Try to come up with scripted solutions. For example, I use the following code to determine whether my file is on a web server or running on the desktop (or inside Flash itself):

  
  

   if(_url.charAt(0)=="f"){ online=true; }else{ online=false; } 

  
  
  

  This works because the _url property begins with an f only when running locally (for example, file:///C /folder/file.swf ). The big clue that you should have either a constant variable or a scripted solution is that you find yourself editing.

• Install a local web server. There are a variety of free web servers you can install to run on your computer. I don't know how long it took me before I really understood that it's totally different to run an HTML page in a browser on the hard drive than to point to a page on a web server. Web servers aren't limited to servers set up to host pages publicly . For example, you can install the free developer version of ColdFusion, and it comes with a web server perfect for testing. To run files, they need to be in the server's wwwroot folder. You launch them by typing http://localhost/... instead of just double-clicking the HTML file. Also, know that if you install ColdFusion to run parallel to another application server on your computer, it uses a different port number. For example, I have a couple of web servers installed locally for testing; so when I need to point to ColdFusion's wwwroot folder, I use http://localhost:8500/... . That's because my installed version of ColdFusion "listens" to port 8500.

• Publish to your stage. Although the Project panel is really your best option here, you also can just set Flash's Publish settings to target a folder (for instance, on your web server). For instance, Figure 10.11 shows how every time I publish, the SWF goes into my test server. The idea is that I can have all the HTML and related files ready and waiting on the local servereven have a bookmark in my browser. So if I make a change, I just republish and then go test. I don't have to meticulously copy files and so forth.

  Figure 10.11. You can direct Flash to publish in any folder you want. (Notice that the folders are now buttons to browse.)

  

  
  

I'm sure there are countless other tips for staging, many of which you'll learn (perhaps the hard way). In any event, I'll say it again: The time spent coming up with production time-saving tricks is usually worth the investment.

Multimode Applications

Although not specifically a staging issue, I think multimode applications fit well here. The idea of having multiple views on a single application is quite common despite multimode being a term I made up. A familiar example is when you want both a public view and an administrator view. The point is that you probably don't want to actually make two different applications (one for the admin and one for everyone else) but rather one application that adapts to perform appropriately depending on who the user is. Multiple files mean more maintenance and so on.

Here's a real example. When you visit my answering machine (www.phillipkerman.com/machine), you can only view messages you left or those left by others who agreed to make them public. However, I wanted a way for me to view all the messages plus a way to change the outgoing message. Instead of creating two different versions of this app, I just made one multimode app. There's a single variable admin and it's set to true or false depending on whether I'm the one viewing the app.

Note

How It Really Works

In case you're wondering, the approach I used on the answering machine is both simple and secure. I placed a different HTML file in a password-protected area of my web site (that is, a folder I protected using my ISP's administration toolsnot unlike traditional .htaccess and .htpasswd files). So the HTML page I use to launch the app is inaccessible to you, and it's slightly different in content. Specifically, is uses the FlashVars tag (covered in Chapter 6, "Basic Data Exchange") to set a variable called username to the secret password that I can't disclose here. Anyway, because I didn't want to store the correct or expected value for that variable in the Flash movie (because SWFs can easily be hacked), what I do is pass that variable to the Flash Communication Server when I connect. If the main.asc file receives the expected value in the onConnect() method, I trigger a function in the SWF that just sets the admin variable to true . Then throughout my app, there are several places where you're taken on a slightly different course if admin is true or if it's false . Okay, so my answering machine isn't used by international spies, but it was a good exercise nevertheless.

It's not that multimode applications have to be super sneaky or secure. You may just have the need to reveal or hide specific buttons that don't apply to the user's interests. That is, you don't have to protect one mode with a password as I did with the answering machine. The thing is, when you design your application so that code and data are well separated, adding a multimode feature becomes much easier. Although I suppose it's best to plan ahead for such a feature, it should be fairly easy to add later in a project.

Incidentally, the reason I put this discussion under staging is that many of the same basic techniques apply to both staging and multimode apps. For example, you may set up your application to run differently while testing locally than when on a server. That's similar to how the app might have to work differently in one mode or the other. You can think of staging/not staging as two modes in your app. Anyway, I don't mean to push the multimode concept on every app you build. When appropriate, however, it can really add some value to your project. Here are just a few examples of multimode features I've built in real projects:

• The live cattle auction I programmed for stampedecattle.com has both an auctioneer view and a bidder view. The bidder view has several modes depending on how you log inspectators are restricted from bidding, whereas registered buyers can bid. Also, if you log in as the second auctioneer, you're able use your microphone to call the bidsthis way the auctioneer can log on from anywhere in the world. For the main administration console, I did create a separate SWF only because the window size had to be larger because there was so much information to present onscreen. It's still a form of multimode because the admin connects to the same Flash Communication Server application.

• The site allsteeloffice.com/number19 includes several linked videos in both Windows Media and QuickTime format. When visitors pick their first video to view, they must choose a format preference. From that point forward, they're in a slightly different mode. (That is, I know their preference.) Anyway, for testing I built it so that if you hold Shift when you click to view a video, it will ask your preference again.

• I built a graphing application that had two modes: data entry and visualization. You could either get in and edit the values to be plotted, or you could view the graphs. In this case, I just built a toggle option for the userit wasn't as if one mode was a secret.

• Whenever I give a presentation, I like to make an online version available. Although I want to make sure the navigation is clear to users, I prefer to keep buttons and such hidden while I give the presentation. That is, I know where the buttons are but I don't want them to remain hidden. Again, I built a multimode feature that will hide the buttons when I'm running it locally but not online. (I also added speaker's notes to many such presentations that are only viewable by those viewing the presentation online.)

• Although Flash has some remote debugging features, your trace() statements become lost forever when you deploy. You'll learn in Chapter 11, "Quality Assurance and Debugging," however, how to use the local connection object to send trace strings from your app to a homemade output window. The idea here is that you can have a "debugging mode" to your app in which you can test things online.

It's not like you'll probably sit down and decide to build a multimode application. Instead, it's just a type of feature that's nice to add. Even if just for testing or your convenience during production, multiple modes are quite useful.

Creating Dummy Data

Chapter 3, "Technology Overview," and Chapter 4, "Working with Complex Data," covered manipulating and presenting data. During production you may not have a supply of data handy, however. What if your app is supposed to display the current standings in a sports event that hasn't taken place yet, for instance? The answer is you're going to have to make up data.

Just like how designers use lorem ipsum to display the layout before they get the actual copy, programmers need to build dummy data before the real thing is available. However, it's probably better if the data you derive is truly representative of the real thing. Herein lies the challenge. In the real app your data will, for the most part, be pretty consistent. (For instance, most people's first names have fewer than 12 letters.) However, you really need to prepare for any possibility (perhaps someone's first name contains 24 letters).

The thing is that you don't need to start by worrying about such outliers (that is, individual cases where values are out of the normal range). Although you will need to come up with a range of data that could possibly break your code, it's fine to start with "nice data." Start by stocking your app with data that fits what you expect. Work out your data structure and parsing routines. Then come back through and try to break it with oddball values. A secondary advantage of fixing the data is that you can readily see whether your code is working correctly. If you're plotting student scores as a percentage of 100, for example, you could start with nice round numbers (100, 90, 80, and so on).

Here's an example of what I call "nice" data (and the code to populate it):

 function init(){ users=[]; users.push({name:"Tom" ,score:100}); users.push({name:"Dick", score:80}); users.push({name:"Harry", score:50}); } 

Notice that, even while the movie plays, you can reset all the values by triggering the init() function.

If you need a ton of data, you could create a loop to do the populating, as this example shows:

 users=[]; for(var i=0;i<1000;i++){ users.push(({name:"username"+i, score:random(100)}); } 

The interesting point here is that basic scripting skills can come in handy when creating sample data. Although it's best to start with "nice data," it's also important to test for a full range of data. Although this is really a debugging step that gets covered in the next chapter, it's worth touching on here. First, realize that all the data doesn't have to try to strain your code, just a few outliers to prove it's still working. In the preceding examples, for instance, you could try adding one oddball user to the beginning or end of the array. For example, above or below the existing "nice" population code, you could add something like this:

 user.push({name:"a_very_very_long_name",score:0}); user.push({name:"s",score:101}); 

Exactly how you fashion data to stress-test your app depends on the nature of the application. In the preceding example, there may be no way for score values to reach beyond 100so the second line of code would be unnecessary. Also, we haven't discussed how you respond to a case where whacked data breaks your app (for instance, if the long name in this example wraps or gets cut off). Generally, you just want to make sure you're testing everything. To begin, you just need something to work with. The idea of dummy data is to get you rolling.

Incidentally, often your app will need to import data from outside sources. So, to fully test your system, store the data in its native format externally. You can still start by creating dummy data internally. Just be sure to fully test with data when it comes from outside, too.

Creating dummy data is a basic production technique. The concept applies to other portions of your work, too. It's impossible to do everything at once, so instead, hard-wire parts of your work and then come back and finish it later. Quite often I write a function that always returns the same value (for instance, true ). In the real project, however, it will have to return a range of values (even if that's just true or false ). The point is that I can keep rolling even though parts of my project are not complete. Without such mock ups, you'd be forced to do everything "in order," and that may not be possible or practical. The good news with these techniques is that you also can apply the skills needed to debugging, as discussed in the next chapter.

[ LiB ]