Deploy*

When you don’t hear much from a developer it’s usually because he is hard at work at programming. At this time not everything is finished and tested, but here are some for sure upcoming features for 1.4:

• 2 new built in functions that make it easier for non programmers to add and create files
  • create_empty_file() creates an empty file into the generated deploy. Simply specify the path and file name. E.g. ( create_empty_file(’css/mystyles.css’); )
  • import_file() will copy a file from any directory from the root into the generated deploy. To use simply tell it what file you want to copy and then where. E.g. ( import_file(’files/CSS/mystyles.css’,'css/mystyles.css’); )
• Added the following JavaScript libraries:
  • jQuery UI
  • Prototype
  • script.aculo.us
  • MooTools
  • Dojo
  • SWFOject
  • Yahoo! User Interface Library (YUI)
• Now has a choice of header.php, footer.php, navigation.php, and sidebar.php includes.
• Deploy* now does not use a hard copy of jQuery. It now uses Google’s AJAX method. This is the same as all the generated deploys as well. This way they will stay up to date automatically among many other benefits.
• Fixed a bug that happened ≈0.2% of the time where a file wouldn’t be copied using the exec(cp) function. Instead I use a the custom function called import_file().
• I have updated the reset.css and how it handles resets. It now adds a @import into the main.css file. Some updates to the CSS file are:
  • <b> and <strong> are now bolded by default
  • <i> and <em> are now italicised by default
  • Links in no longer have a dotted outline in some browsers
  • No longer minified for easier editing

There are many more changes and cleaner javascript code that runs the Deploy* form and I’ll make sure to add a changelog.txt file to the Deploy* 1.4 file. I’m also going to include a tarball of Deploy* as well as a zip on code.google.com for the users who want to upload it to their server.

Even if you are not a programmer you might wonder how exactly does Deploy* work? Does it just copy files over? Does it create them on the fly? Is it magic?

As of 1.3.2 and under Deploy* goes through a few processes before making that final zip you get at the end after you push that big red “Deploy!” button.

The very first thing it does is creates a temp directory inside the root of Deploy*. This directory is “deploy_” then it adds the date, in UNIX time, and then a set of random numbers. This way, even if two people create Deploy*s at the exact same time the chance of them overwriting the others Deploy* is extremely slim.

Once the directory is chosen it checks to see if you chose a project name and if so what and what the file extension should be (if you chose the .php extension it would change index.html to index.php at this time). It also adds the DOCTYPE you chose into a variable for later.

If you chose to include a blank css file it creates a CSS file from scratch with PHP. If you choose include the resets it grabs the file from the /files directory. It places either the blank or reset file into your temp directory. It then saves that you chose CSS in a variable for later use.

Next, if you chose jQuery, it looks for the correct type of jQuery file to include such as the packed or uncompressed and then copys it into the temp directory. It then adds this choice to a variable for later.

The plugin part is next and if you chose plugins the process is probably one of the most tricky parts of Deploy*. I wanted to keep it easy for people to download Deploy* and add their own plugins with XML. The XML is basically in a v0.9 stage at this point and needs to have more flexibility to it.

The XML allows multiple images and stylesheets. It allows a space for a developer to put a link to his site and of course name his plugin. projectdeploy.org/plugins.xml Is where the XML that runs this Deploy* is now.

PHP runs through each choice and then runs through and copys all the files it needs into the right locations (e.g. <image>s get put into the /images in your Deploy* and <css> in the /css directory and the actual plugin file in the /js.) Finally it puts all the names of the plugins you chose into a single variable.

After this is all finished it creates that index.php file by putting all the info it needs into the final variable which holds all the previous variables above and creates a brand new file. So, for the DOCTYPE, <head>, <script>s, and everything depend on your previous choices.

The last thing it does creates any extra directories you chose such as flash, images, or includes. Deploy* is smart enough to create the images or css directory if your plugin requires it and you chose not to include those directories.

Now for the fun part, once everything is the way it should be when they unzip it, it copies this directory (deploy_xxxxxx) into the /deploys directory. It then copies itself inside of itself renames it to your project name and then zips that directory. You end up with raw project folder with the name of like deploy_xxxxx with all your files inside of it, a directory named your project name with all your files and a zip of your directory which becomes your final Deploy* which you end up downloading.

It goes through this process every time you visit the deploy.php page. It has gone through this around 12,000+ times at the time of writing this.

Hopefully this will help people when they download this and start developing on it which some have been doing. Not knowing about the temp directory makes it very strange when you are getting mkdir errors in your root directory when you think it supposed to be creating the directories inside of /deploys

The people who don’t like Deploy* usually have one comment, “Why would I use Deploy*? What it does is pretty trivial. I can just make a directory and copy it.” My response is always about the same and it’s basically, “Yes, you can.”

Now with that in mind, why would you use Deploy*? For me it’s a couple reasons:

1. I have never got around the creating a basic structure of a site I like that I end up copying. I should have, but never did. I ended up loosing where I put my code from prior projects and spent time hunting down those plugins.
2. I never had quite the same project. Sometimes I needed files while other I didn’t. I didn’t like having to copy the folder and then add and delete files from it.
3. I hate having to open up Finder in the Mac OS X and looking for a directory (Quicksilver speeds this up a little), but still opening Finder and going through looking for the folder with the different set ups and then looking again for the right one. I like being able to just click a bookmark and having the project instantly.
4. I didn’t like looking up/copy the proper DOCTYPE syntax and I also didn’t like having to link each piece of JavaScript I had. This was just a simple solution.

I guess you could call me lazy, but then again, you are calling the 10,000+ return visitors last week lazy as well.

Another question I get frequently is, why the name Deploy*. When I was thinking of a name, deploy was the perfect word.

The New Oxford Dictionary says deploy(verb) means: “bring into effective action; utilize”.

Deploy* trys to bring your web project into effective action and ready to be utilized to create the project right away without the hassle of creating a template (x)html, css, or download the latest jQuery version and create directories.

The “*” comes from the regexp idea of “all” or “everything”. I wanted a way to say, deploy any web project framework. I wanted to keep it minimal enough for a designer to use, but robust to use for a jQuery plugin developer to start on his lastest idea for a jQuery plugin right away before he looses his train of thought.

I hope this clears up any confusion.

Short answer, it’s both.

Long answer, Project Deploy* is the web site that hosts Deploy*. The reason the site has the logo “deploy*” on this web site and blog is because Deploy* is the web application that runs on projectdeploy.org. When you download Deploy* you are downloading Deploy* from the project’s home, projectdeploy.org.

I know a few of you have had this question, so I thought I’d clear it up.