September 2008 Archives

I like to keep a pretty efficient development environment.  I have several projects I manage at work, and I have these projects all to myself for the most part.  Regardless of whether you are working in a huge IT consulting firm or in a basement by yourself, it's a great idea to automate as many mundane processes as possible.

One of the tasks that annoys me most is moving my code to our production web servers.  It's a royal pain the ass to fire up SmartFTP/FileZilla/whatever, navigate your folders, connect, and so on, especially if you are frequently publishing.  On top of this, manual FTP uploading can also be error prone.  I'd like a nickel for every time I've overwritten production-specific config files with development copies.

The easiest way I could think to publish changes is to simply push a freaking button.  So, a month or two back I found a simply FTP upload script.  The script (I can't remember where I got it) often worked, but once my projects started growing in size, it would often time out and only a portion of my code would make it up.  I figured the best solution would be to write my upload script that cycled through my project files and used a remote script to upload them one by one rather than in one big session.  Sure, it's slower, but hey, it works and all I ever have to do is click one freaking button.

Below are the spoils of my endeavor and some commenting:

Grab the code here.

ftp_tools.php: Utility functions.  Nothing to change here.  echo_jsarray() recursively browses a directory and prints a Javascript object containing information about the files in it.
ftp_upload.php: The script that actually handles uploading a file passed to it.  Here you want to change the $ACCOUNTS variable to hold the FTP login info for your various projects.  Also change the $FTPADDR string to hold your server's address.
SampleProject.migrate.php: The script that handles uploading your files, one by one.  There are some variables up at the top you'll want to change such as file exceptions and the directory you want to upload from.  In UploadFile() you'll also want to define the account you want to use.

Setup:  On our production FTP server, I have an account for each project.  The root directory of each of these accounts is the project's root folder.  Thus, I simply upload to the root folder for every project.  Dump all of these files into a folder on your test server or something, grab jQuery 1.2.6 (minified) and add it to the mix, and you should be good to go.

It's a pretty rough, environment-specific way to do this, but it should be no problem to adapt to your own development environment.  Bonus points: Figure out which files have been changed and which have not, and upload only the changed files.  Add some error handling for when files fail to upload mid-stream.

I've been working on an ASP.NET MVC project with a nice and fancy model layer. My models have a nice'n'friendly UpdateFrom(NameValueCollection) method to bind HTTP request parameters to an object. The only problem is that sometimes, I don't want to have every column on a form, and some of the related database columns should remain unchanged.

In HTML forms, this presents a problem: checkboxes that are unchecked don't post anything. How am I to tell if a field has been left off the form or if a field is unchecked? After some aimless wanderings on the inter-tubes, I found this article which documents a solution for Rails.

It's pretty simple, so I figured I would take this idea and wrap it up in a server control. We have a small set of server WebControls that play nice with the rest of our code, so it was just a matter of adding a few lines of code. You could also wrap this up in a helper method like in the rails version.

CheckBox checkbox = new CheckBox();
checkbox.InputAttributes.Add("class", CssClass);
checkbox.InputAttributes.Add("id", (string.IsNullOrEmpty(ID) ? (FieldName + "CheckBox") : ID));
checkbox.InputAttributes.Add("value", "true");
checkbox.InputAttributes.Add("onclick", 
    "document.getElementById(\"" + FieldName + "TextBox\").value = this.checked.toString()");
checkbox.Checked = Checked;
checkbox.RenderControl(writer);

TextBox textbox = new TextBox();
textbox.Attributes.Add("style", "display: none;");
textbox.Attributes.Add("id", FieldName + "TextBox");
textbox.Attributes.Add("name", FieldName);
textbox.Text = Checked ? "true" : "false";
textbox.RenderControl(writer);

Now I can tell if a checkbox field is truly meant to either just not be there or is false.

I finally got tired of typo dying on me.  Sometimes after making a post, the entire app would just blank out and return no html at all.  The cache seemed to act really weird at times as well.
So, after looking around for some new software, I decided on movable type.  Wordpress was another big alternative, but I had used it on my now-defunct guild site (Retaliation-Skullcrusher) and wanted something a little different.

Movable Type is amazing so far.  The preinstalled themes are great, the admin GUI is intuitive, and the whole thing seems rock solid.  Setup was a breeze as well. (I used this walkthrough)  No qualms so far.

Migrating from typo to Movable Type was fairly easy too.  I lost all of my post dates and images, (my fault, though) but re-entering my post content was a breeze.  I just went into my typo database, went through the contents table, and copy/pasted the markup.  Make sure you choose the "Markdown" format in MT's format selector.

Anyway, time to draw up a design comp and stick it on here.

One of my projects needed a wizard form. Being the jQuery fanboy that I am and given that I couldn't find any existing wizard form plugins for jQuery, I made my own! You can check it out here: http://plugins.jquery.com/project/WizardForm

It's not what I would consider finished, but it works if you need a quick form and don't mind dealing with my markup choices. It behaves sort of like the jQuery tabs plugin, so if you have used that, you should be able to get started fairly quickly.

I hate trying to resolve CSS and Javascript conflicts between web browsers. What I hate even worse is going about it in an "unclean" way.

Conditional comments for IE have been around a long time and I haven't really seen too many people (if any) using them for resolving style bugs. Check out what I do on every web site I build.

<link href="/public/css/style.css" rel="stylesheet" type="text/css" />
<!--[if lte IE 7]>
    <link rel="stylesheet" type="text/css" href="/public/css/style-ie.css" />
<![endif]-->
<!--[if lt IE 7]>
    <link rel="stylesheet" type="text/css" href="/public/css/style-ie6.css" />
<![endif]-->

Note that I normally don't bother with IE 5.5, but this could work for that as well. With these CSS links in place, I can simply expect a normal, sane style sheet to be included on well-behaved browsers, a special style sheet for IE7, and an even more "special" style sheet for IE6. Since these are declared in order of insanity, (from least to greatest) I can simply copy style declarations from my original style sheet, override whatever I need to, and keep everything squeaky clean.

There's my solution. If anyone reading still uses CSS hacks, I would love to know why. It may be something I just don't "get."

ALERT! A better, more complete version of this code can be found here: http://www.sagecraft-studios.com/2008/11/google-driving-directions-in-c---update.html

This is something I've been wanting to figure out for a while. What I'll be demonstrating in this post is how to get driving directions, distances, and trip durations from Google's mapping service... without using Javascript! The demonstration code below is just that - a demonstration. It is your job, dear reader, to make a friendly, accessible interface out of the underlying code.

Note: As far as I can tell, this is undocumented. If you're using this in a production environment, I would advise writing some unit tests in case URLs change, parameters change, etc...

You will need JSON.NET referenced to deserialize the data sent from Google.

using Newtonsoft.Json;

namespace xxxx
{
    public class GDirections
    {
        private string _key = "xxxx";
        private string _output = "js";
        private string _requestFormat = "http://maps.google.com/maps/nav?key={0}&output={1}&q={2}";
        private Hashtable _data = new Hashtable();

Our underlying data. Yes, you could certainly use a generic Dictionary rather than a Hashtable. In the code above, make sure to set _key to your Google Maps API key, which can be generated here.

        /// <param name="path">A path in the format "From {a} to {b}".  Example: "From Lexington, KY to Bowling Green, KY"</param>
public GDirections(string path)
        {
            HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(
                string.Format(_requestFormat, _key, _output, Uri.EscapeUriString(path)));
            request.Method = "GET";
            HttpWebResponse response = (HttpWebResponse)request.GetResponse();
            StreamReader reader = new StreamReader(response.GetResponseStream());
            string json = reader.ReadToEnd();

            _data = readJson(new JsonReader(new StringReader(json)));
        }

In our constructor, we basically just grab the response from a web page. (or in this case, JavaScript object) Using Json.NET, we deserialize the object and somehow stick it in a Hashtable.

        private Hashtable readJson(JsonReader jreader)
        {
            Hashtable data = new Hashtable();
            while (jreader.Read() && jreader.TokenType != JsonToken.EndObject)
            {
                string key = null;
                object value = null;

                if (jreader.TokenType == JsonToken.PropertyName)
                {
                    key = (string)jreader.Value;
                    jreader.Read();
                    switch (jreader.TokenType)
                    {
                        case JsonToken.StartArray:
                            value = readJsonArray(jreader);
                            break;
                        case JsonToken.StartObject:
                            value = readJson(jreader);
                            break;
                        case JsonToken.Null:
                        case JsonToken.Undefined:
                            value = null;
                            break;
                        default:
                            value = jreader.Value;
                            break;
                    }
                }

                if (key != null)
                    data.Add(key, value);
            }
            return data;
        }

        private ArrayList readJsonArray(JsonReader jreader)
        {
            ArrayList value = new ArrayList();
            while (jreader.Read() && jreader.TokenType != JsonToken.EndArray)
            {
                switch (jreader.TokenType)
                {
                    case JsonToken.StartArray:
                        value.Add(readJsonArray(jreader));
                        break;
                    case JsonToken.StartObject:
                        value.Add(readJson(jreader));
                        break;
                    case JsonToken.Null:
                    case JsonToken.Undefined:
                        value.Add(null);
                        break;
                    default:
                        value.Add(jreader.Value);
                        break;
                }
            }
            return value;
        }
    }
}

This is the "somehow stick it in a Hashtable" (or Dictionary) part. The code really is pretty simple, but the resulting data structure is a huge mess. We end up with a nested dictionary-style object with arrays thrown in there just to keep things fun and complicated.

IDEALLY, we would want to create classes for each kind of object we get in our response. For example, Placemark, Status, Point, and Direction classes would need to be created. If even this is too much work, (which it shouldn't be if you are serious about implementing and fully using this functionality!) some more friendly accessor methods/properties shouldn't be a huge chore to do. For example, since we're using this thing just for driving time and duration, I implemented the following accessors

        public decimal DrivingMeters
        {
            get { return Convert.ToDecimal(((Hashtable)Directions["Distance"])["meters"]); }
        }

        public TimeSpan DrivingTime
        {
            get { return new TimeSpan(0, 0, Convert.ToInt32(((Hashtable)Directions["Duration"])["seconds"])); }
        }

        public decimal DrivingMiles
        {
            get { return Math.Round(DrivingMeters * (decimal)0.000621371192, 2); } // according to Google.
        }

        private Hashtable Directions
        {
            get { return (Hashtable)_data["Directions"]; }
        }

So yes, I'm basically saying take this foundation and make it your own. Make it friendly and then give it back to me. :)

Hide unnecessary buttons
Practically everything I use is hotkeyed.  The only primary buttons I show are spells with a range or cooldown.  My buttons are set up to turn red when out of range (Bartender) and display a cooldown time. (OmniCC)  Thus, I don't need spells like arcane explosion or flamestrike on my bar.  I also use only 1 button for shared ranges or cooldowns, such as only showing fire ward instead of both fire ward and frost ward.  I also have a tiny, out-of-the-way secondary bar for common tasks like food and portals.  Gems and potions I just open my bag for.  It's not that much trouble, but a macro for using them would also be useful.

Maximize readability
The best way to increase readability is to reduce clutter and strategically place your frames.  Important stuff should be near the middle of the screen.  The developers of Bigwigs figured this out and implemented a way for incoming timers to pop into the middle of the screen.  Blizzard apparently hasn't, though, and put their unit frames way up in the corner of the screen.  Get some unit frames like Pitbull and move that to the center of the screen, or even use a HUD.  If you're a healer, it would be wise to have raid frames somewhere close as well.

Another potential readability block I have found is error text.  By error text, I mean the stuff you get from spamming spells or trying to take a portal while mounted.  After starting from scratch on my UI a month ago, I realized how important ErrorMonster is.  My BigWigs warning text and Blizzard's error text are basically in the same place.  Eliminating error text makes it easier to read whatever crap BigWigs is trying to tell you.

Use "conditional" buttons and frames
There isn't as much room for this since patch 2.0, but it is still possible.  I have a giant empty button for macros I need on certain encounters.  This includes targeting Spitfire Totem, using Tainted Cores, or equipping/using Staff of Disintegration.  Before a fight, I just drag that macro into that hidden button slot and bam, I'm ready to fight.  I also have a focus frame for sheeping.  Combined with a /focus-ing sheep macro.  This frame is basically just a big 3D portrait to monitor the status of my sheep.

Avoid obstructing your view
<p>There are mods out there that intentionally do this and I have no idea why.  Putting a giant frame behind huge blocks of addons does absolutely nothing.  It doesn't even look good.  If there is little margin, fine, but often addon package authors will overdo framing.  Viewport modifiers are another horrible idea.  Why INTENTIONALLY reduce your visibility?  Having your game look "cinematic" benefits nothing.  Unless one of those viewport mods increases your horizontal field of vision, you are simply losing visibility.  Photek was famous for this back in the day. (the package looks like it has gotten much more sensible since)  It looked pretty when you zoomed in, but overall the loss wasn't worth it.

edit: Since changing blog software, I have lost the screenshots for my old interface.  Sorry.