When building applications, especially those with a document-based model such as the Aviary apps, Odosketch, My Canvas, ZenStudio, the apps on acrobat.com, and many others, you need a file format for the document or project. Or some way to save it.

What Not To Do

You don’t want to save each item into a table in the database. I know a guy…who had a dream…that his friend did this. This guy’s friend in his dream had a table for each item that needed to be stored with foreign keys etc. When a project needed to be loaded, the server-side script did a ton of queries and created a sometimes-quite-large XML structure that it then sent to the Flash app. When saving, this XML was sent back and parsed back into the database with INSERTS and UPDATES.

That does not scale, and none of that data was needed to be pulled up in reports or anything that you might consider useful and require a database for. It was complex, hard to add features, and slow. That is, it would have been had that guy’s dream friend been real.

Warmer, warmer

Saving document/project files to disk is the way to go. You can store metadata about each project or document in a database if you are storing them server-side. If it is an AIR app, give it a unique extension and the user can double-click on the file to open it. If you are AIR only, you can save your file as a SQLite database file. Pretty sweet option, but doesn’t work for the browser ’cause Flash can’t do that. The format could be XML like OpenOffice documents and the new MS Office formats. You would need to parse the files in and out and they could get very large, so you’d want to compress them anyway.

Hot, burning, you’re on fire!

So, XML might be the most portable format, but hey, that’s what Import/Export dialogs are for, right? We’re talking about Save/Save As… :) Enter our new contender, AMF! AMF isn’t really new, however I haven’t heard of many people using it as their file format. The cool thing about using AMF is that after you’ve prepared your objects for it, you could store (in player 10) pieces of your document on the clipboard for copy/paste from one place to another (even after a page refresh or from AIR to browser!). You can do an auto-save of a document or page to the user’s SharedObject store.

Preparation and implementation

To use AMF as the format for you data you’ll need to prepare your objects sufficiently. Here are a few rules:

• No required parameters in your constructors. When AMF unserializes it has to create those objects and assign the public properties to it. You’ll get errors otherwise.
• Register your classes using flash.net.registerClassAlias or [RemoteClass(alias="...")]. This will store the registered alias name to map a class to a string for serializing and unserializing.
• Use IExternalizable for more complex items that only need a few properties stored, or for Flash classes that can’t be stored (e.g. BitmapData). This allows you to get around the constructor parameter issue, but it is more work. :)
• Make sure any data you need stored is a public getter/setter or you’ll have to use IExternalizable. AMF serialization will only store data that is public and read/write. If you think about it, it makes sense.

The way to store your document object or project object (or page, or widget, or whatever) to AMF depends on where you are storing it. There are a lot of Flash APIs that use AMF already. If you are storing it to SharedObject, just assign the item to the data property or one of its properties.

SharedObject.getLocal("_myProject").data.project1 = myProject;

To send it from one app to another over LocalConection is just as easy.

var conn:LocalConnection = new LocalConnection();
conn.send("_connName", "passProject", myProject);

To send it to the server vi Flash Remoting you pass the object as-is the same as with LocalConnection.

If you want to save the project to disk or pass it to the server in a RESTful manner or as a file upload, you’ll need to serialize it to AMF first. But that is pretty easy. Just remember to compress after you write it and uncompress before you read. This will save a lot of room.

var byteArray:ByteArray = new ByteArray();
byteArray.writeObject(myProject);
byteArray.compress();
// write the bytearray to file or send to server
// or we can pull it back out making a clone! (save as...)
byteArray.position = 0;
myProject = byteArray.readObject();

Easy cheesy. I will leave it as an exercise to the reader to figure out how to store it to the clipboard for copy/paste.

XML might be an easier format, though more verbose and prone to errors in the creation and parsing. Though it could allow for greater flexibility and accessibility to other programs to read the file.

Let me know if you use AMF for your document/project file storage. I’d be interested to hear how many people use this method and how well it has worked out for you.

I’ll be presenting “Cloud computing with Flex”. I’ll talk about the services available to scale your application, but I want to focus on how you can build an app with zero server-side code. It’ll be an AIR app that stores its data on the cloud.

Here is my badge of honor

There have been a couple versions, the first was completely web-based using Ajax, the second a mix of Ajax and Flex. Both of these versions were browser based. Both of these versions had limitations and issues because they were browser based. Enter final version.

The final version will be in 2 parts, a server part and a client part. The server part will be a RESTful webservice using Atom Publishing Protocol, the same protocol Google uses for its Google App Data services. This allows other applications to hook into the CMS and export data and make changes with the appropriate permissions. It could even allow for mashups. I’m certainly interested to see what people will do with it.

The client part will be created using Adobe Integrated Runtime (AIR). This multi-platform (i.e. runs on Windows, Mac, and Linux) will give people the benefits of a browser-based admin along with the benefits of the desktop. I’ll have one browser to deal with and will be able to easily allow in-page editing. The javascript used will be much smaller and easier to deal with since I’m not worrying about cross-browser compatibility. And I’ll be able to add features such as drag-and-drop or client-side caching of the data in a local database.

I’ve almost got the server component done. It will be called Layered Content Server. Layered Content Client will run off of a server instance and together they’ll make Layered Content, a usable — as in easy to use while not limiting functionality and features — CMS.

You can learn more about the architectural decisions behind Layered Content which will allow it to be easier to use and still quite functional at the wiki. I’ll be asking for help once I get a pre-alpha version out so keep an eye out for it.

About 49% of the people I talk to about it aren’t sure what the difference is between Dreamweaver and a web CMS. They’re the non-web developer people like my family and some of my friends. Another 49% (the web guys) aren’t sure why I would choose such an established market to make a product for and even after I explain my marketing strategy still scratch their heads over it. They are still nice about it and wish me good luck. They’ll all see why here soon!
So, I’ve been sort of waiting around for Cascade (my CMS) to be done and then continue blogging, but that’s taking too long, so I’ll keep writing until it’s done. Then I’ll be moving my site over to withincode.com and using Cascade to manage it all.

I was contracted by my company for awhile to one of their clients. While I was there I started making my own JavaScript tree menu in my spare time. The developers I worked with asked why I would do something like that. There are already a handful of tree menus free for download on the web. I was doing it because, one, I thought it would be fun (they thought I was crazy), and two, none of the tree menus gave the functionality I sought. I ended up making a tree menu that is really nice, has a context menu, and works well with Ajax. I have used it in several projects.

I also started building a PHP framework around that time. Pherret was created in my spare time (another “painful” project my coworkers said) because I thought it would be fun and because I didn’t like what was already out there? Arras Template, which became part of Pherret, is a unique and fun templating system. And finally I put together my own JavaScript Ajax library, borrowing some from others like Prototype.

Not being content to use others’ code, others’ frameworks, and others’ hard work is my downfall.

Or is it? I am now the expert at my company in JavaScript. I know the inner workings of what a framework needs to deal with. I know what a template system needs to be able to do, and some of how to do it. I have gone from knowing very little about programming (just 2 years ago) to being a well-versed and well-rounded developer. The drive that has me writing things that have already been done, or even just the drive that has me developing in my spare time instead of just in the workplace is what has made me valuable as a developer. I suppose we call the type a “hacker”. The person who loves to get their hands into code as a hobby.

I’m glad I’m a hacker. I program in a way that my code becomes better and better, day after day. My applications become better layed out. Better organized. Easier to maintain.

Why did we remove the beta label? Because Jason Fried said we shouldn’t. First was a blog post from 37 Signals. They noticed how many new Ajax applications were releasing with the “beta” label. Then in TechCrunch’s article “Don’t Blow Your Beta” he left this comment:

“There’s a better way not to blow your beta: don’t launch one at all. Public betas are rediculous. If your product is public, it’s not a beta, it’s a release. Take responsibility for your product. “Beta” only passes the buck to your customers — outsourcing your pain to them.

“Get over Beta already.”

And then Ajaxian released the article “The Importance of a Good Beta” and added to the above quote from Jason.

What’s wrong with beta? Nothing. Might not be a good idea to charge for a beta product. I don’t think 37 Signals should release BaseCamp or other commercial products with a beta label and charge their customers for it. But that doesn’t mean a free public beta is a bad thing. It is actually a very good thing to be able to get customer feedback early, have users test accross a large variety of platforms, OS’s, and machines, and rethink the goals of the product before all the cleanup work has been done.

If there is nothing wrong with a free beta, why did we change it? We didn’t want people to think we were not taking responsibility for it. We wanted MyStickies to be successful, and we thought people would listen to Jason and not use it if it said “Beta” on it. Were we right? Don’t know. People seem to use Gmail even though it has Beta on it’s logo.

It all comes down to the power of writing. The 37 Signals team has some very good writers and even emphasize that you need good writers to be successful. They have a massive following of people who read their blog and swear by what they write. I would bet most of their products successes are because of their great writing. Marketing themselves on the web. In order to be a have read blog, to generate a hype, to drive a web-application to be successful, good writing is important, maybe essential. My writing needs improvement for sure.

So, I made a project timer. It actually is built in Macromedia Flash, and made into a nice executable using mProjector. I have yet to start using it for my projects, but it seems to be working pretty well. I thought I would share it in case anyone else needed something like this. It only works on Windows right now, but mProjector can make executables for Mac, so I’ll look at doing a Mac version soon.

I used to have a screenshot of the app here. However, it’s flash, so why don’t I just put the swf up? Pretty small, unobtrusive, and hopefully usable.

To use, click on the world icon, enter in a new project, hit enter, and then click the green play button to start timing. You can add as many projects as needed and choose them from the drop down that appears when you click the world icon. The timer also minimizes to the system tray. You can make it stay on top of all applications from the right click menu, as well as close it down from there. It doesn’t use the registry or create any files of it’s own. It only uses the Flash SharedObject (which is basically a cookie for Flash). Also, if it works the way it should, you can look at a projects total time, the time for the current day, current week, current month, or even a custom time period. When you click custom, it will ask you for a start day. You can also put in an end day by adding a dash and another full date (e.g. “14/11/2005-18/11/2005″).

You may download the following:
flash_timer-mac-0.1.zip
flash_timer-win-0.1.zip

Hope it helps!

The Project

Going back to my roots, I learned to program by hacking on osCommerce code. I wanted to make my own ecommerce site and run my own buisness. It was then that I discovered how enjoyable programming was and stuck with that instead. The problem with osCommerce is, however, that it is very procedural. It has SQL queries inline with the HTML on it’s pages. It uses functions to output pixel images. It requires a lot of hacking to modify. It is an adequate example of what you might call “spaghetti code.”

ooCommerce

We will be starting a new open source project that will implement all the features of osCommerce, but in a better way. And hopefully, since this will be more extensable, we can add many new features. We can call this project ooCommerce for object oriented ecommerce. I have already purchased the domains oocomerce.com, .net, and .org so that we may, eventually, have our own site for it. And I have submitted it to Sourceforge for pending approval. The benchmark of features we will be aiming for is listed on osCommerce’s site. And, because we are going full out object oriented, we will be using PHP 5. I am sorry if you were hoping for PHP 4, but in order to teach better OOP principles, and because PHP 4 is such a hack in terms of OOP, that’s what we need to use.

I hope ooCommerce will be, if nothing else, a great learning experience. Instead of a little pointless tutorial on saying “hello world” in an object oriented manner, we will actually create a full-featured system as our tutorial, implementing all that we’ve learned previously. We will look at planning this project out next week, so stay tuned.

I am currently using StatCounter.com to track the traffic to my site. It is really useful when you use their paid service which keeps track of more than the last 100 visits to your site (the free version cap). It lets you view all the regular stats as well as “drill down” to see the actual path a single visitor took through your site. But, it is a monthly subscription service, which means potenially hundreds of dollars a year, even though it’s not much each month.

Mint is a one-time site liscence fee of $30. So I felt it would be a good investment over the monthly fees of StatCounter. What sums up my thoughts upon using Mint is this: a regular stat tracker was given a great design and some cool javascript effects to make things easier to use. It looks wonderful, but it lacks much. Things such as tracking return visitors, displaying charts and graphs of the data, and being able to drill down to see individual users and their paths are things that really make a web stat tracker useful. A good user interface is important as well.

One bonus to Mint is it can be extendable with plugins or “pepper” as it’s called for marketing. Although, I’m not sure if extras will be sold by other developers, release for free even though the original is a paid product, or both. I should make it easier for the maker of mint to deploy new features anyway.

Overall, I enjoy Mint, and it’s price is much more favorable than the recurring price of StatCounter. I will stick with it and create some nice graphs of the data for my personal use (whenever I get spare time). Perhaps sell it as a plugin or something.

mediaRAIN, my employer, uses Macromedia Studio because we specialize in Flash products. However, we do many HTML/PHP projects as well. Dreamweaver has always been a favorite of mine with it’s HTML highlighting, code completion, and easy-to-use interface. I find myself more productive with Dreamweaver than with notepad. However, it would be really nice to use the WYSIWYG (Design View) to see my CSS styling as I create it rather than saving and viewing in the browser. There is no point in a WYSIWYG if what you see isn’t really what you get.

To be fair, there are some really nice features with the new edition of Dreamweaver. There is code collapsing (which can collapse a selected section of code as well as an element). They’ve fixed the built in FTP client to work in the background. There is a more usable CSS panel which will show you all the styles applied to the currently selected element, even inherited ones. Their code completion is reworked and is a bit nicer. And you can turn on and off the underlining of invalid code (which actually doesn’t seem to work).

My hope would be, in the future (near future would be nice), that Dreamweaver would add the ability of changing the WYSIWYG rendering engine to one of the three or four major browsers so that you can accuratly see what your CSS looks like in that browser. Either that, or fix their current renderer to properly display floating elements, absolutly positioned elements, and the correct box model.