I’ve spent the past few months working heavily with Drupal, rebuilding my company’s primary site on it. While doing this, I came to an interesting issue that involved creating a module that I think the Drupal community at large could use – a new form item type for choose a state, with a full country list as well. To solve this issue, I created the statepicker module, which is currently hosted on Drupal.org as a sandbox project, but I hope to have it upgraded to full project status shortly.

Statepicker creates a new field type, called ‘statepicker’, that creates a pair of dropdown menus in the form – a state dropdown and a country dropdown. When the country dropdown is changed, an AJAX call refreshes the state list to show the states from the current country. I’ve also created an administration panel that lets an admin edit the state list.

You can download the module from the Drupal.org site, currently only through the repository viewer.

http://drupal.org/sandbox/visual77/1258930

Lately I’ve been thinking about writing a browser extension for my beloved teamliquid.net, which is my main source for all things StarCraft. I’ve already created a set of Greasemonkey scripts specifically for Team Liquid,  but that was before I learned how to write a proper browser extension. After writing Zearch for Firefox and Chrome, I feel a lot more confident in cutting Greasemonkey out of the equation and going straight for a proper Team Liquid extension.

As far as desired functionality goes, it’s a given that the two existing scripts will be integrated. Although, I really should fix the banned user script first… that only seems to work for me about half of the time. In addition to the sidebar updater and banned user linking, I will add some functionality for the stream list, at the recommendation of my dear friend Will. I will allow customizing of the featured streams list, and sorting by race.

In order to do this, however, I need to figure out how to set and retrieve configuration options in both Chrome and Firefox. Unlike Zearch, this tool will need some long term data storage. Not only will I need to save user preferences for featured streams, but I’d also like to allow for some configuration, like which features to enable / disable and other miscellaneous settings.

I posted a few days ago on my entry to the Zappos API Developer Challenge, and that was my first post in 6 months. I haven’t been as consistent with my updates as I once was, but it’s certainly not for lack of things to ramble on about. I’ve actually been very busy. I’ve spent a lot of time reading books about some cool concepts that are doing wonders for advancing myself. In particular, I’ve been reading Design Patterns: Elements of Reusable Object-Oriented Software, JavaScript Patterns and Refactoring: Improving the Design of Existing Code. So I guess I haven’t been writing much because everything I’ve been thinking about has already been documented by someone else who explained it far better than I could at the moment.

I’ve also been spending a lot of building my new robot, Lil’ Lady Murderpants, and working on my Zearch browser extension. Even though the Zappos API Developer Challenge is complete and my entry has already been submitted, I still want to keep working on it and making it even more amazing. There are some features to be implemented, some refactoring to be done and some styling to pretty it up. I’ll end up doing a more thorough article on the direction that Zearch will be taking in comings months, so I won’t go into too much details here.

As far as Lil’ Lady Murderpants, that will also be elaborated upon further down the road. For starters, though, she’s an adorable little ball of joy that I made with my girlfriend over the weekend. We began by following the great tutorial over on Let’s Make Robots. Right now, there are issues with her eyes. The range finding sensors are not reporting data back properly. Once we get that resolved, we can have her run some meaningful software. It’s all programmed in BASIC, so i’m having to learn a new language as part of this project, but learning new things is one of my favorite things to do.

I just finished work on Zearch, a browser extension that currently works for Firefox and Chrome. This project is my entry to the first Zappos API Developer Challenge. To say it’s been a learning experience is an understatement. This is my first time writing an extension for either Firefox or Chrome, so I went into this possibly too careful in some ways, maybe not careful enough in ways I have yet to realize.

I started on the Firefox extension, but from the very beginning I knew I wanted to have this work on multiple browsers. In retrospect, I don’t really know why I went for Firefox first. I prefer Chrome as both a web browser and a development platform. Regardless, I paid careful attention to making sure my code was split up properly.

My strategy ended up with splitting the files into a few key areas. I really had no previous experience to base these splits on, it was more just a feeling that this would allow me the greatest flexibility for porting to another browser.

zearch.js is the core JavaScript file. This file would ideally remain the same on every browser. It contains the guts of the operation and is in control of the majority of the functionality.

utils.js is browser specific actions. This file can change from browser to browser, although some commands may not. This is a set of utilities that zearch.js will use to turn on and off elements, create menus and other functions that are likely to differ significantly in their implementation.

bindings.js binds page elements to Zearch functions. This also will change from browser to browser. I could have integrated it in with utils for that reason, but while writing the code, there seemed to be such a sharp disconnect between utils.js and bindings.js that I felt it necessary to clearly separate the two.

zearch.html / zearch.xul define the page elements. Each browser had a very different way to define what shows up on the page, but that’s okay. I expected some things to vary wildly, and the structure of bindings.js and zearch.js made this very easy to adapt to.

When it came time to porting from Firefox to Chrome, this structure seemed to work out quite well. I’d like to end up porting it over to another browser (Opera is probably next on the list), and hopefully I can still use the same structure.

This is my first extension, but won’t be my last. I had a lot of fun writing it. I’m curious as to how long this structure will hold up before issues are brought to my attention regarding either flaws with this or better ways to do it.

The newest iteration in my StarCraft II Build Order Calculator is a minimalistic approach, in comparison to the previous builds. Unlike the last few ambitious builds that attempted time and resource calculation, this is an attempt at the absolute basics. It is also my first build calculator that is somewhat usable right at the moment, as opposed to merely offering a glimpse at where I want to go with this system.

This calculator contains all units for all 3 races and allows for race changing and resetting the build. It also begins to toy with styles and the UI, although I didn’t spend much time other than getting elements in the rough position that I would like them to be.

I dropped back to a more minimal approach because I felt like the more advanced approaches I was working on were going in the wrong direction. I’d ultimately like a more advanced system, but I want to rewind a bit and go back to basics and consider alternative approaches to the other systems, that relied heavily on large data structures to store data, at times storing it repeatedly for different purposes.

I completed the third JavaScript iteration of the StarCraft II Build Order Calculator this morning and put it online. It took a few days longer than I expected, but I also drastically changed how the data is being stored for the build order. In my previous builds, I stored the data with the time as the lowest level element, whereas this build stores the unit as the lowest level element. This makes it easier to see what the unit is doing (and thus, what it is allowed to do), but makes it harder to display the timeline.

I also stored unit actions (such as build Probe, warp in Pylon, etc.) as functions within each unit. As I wrote the functions, it quickly became apparent that a huge number of functions are identical and should only be written in one place.

This build shows me the viability of storing unit actions within the function and keeping track of unit timelines within the unit, but also shows the weaknesses of displaying the timeline when I have to scan every unit for every second to see what has been done. It still does not take into account that you need a Gateway before you can make a Zealot, but I chose to not pursue that in this build when all of the flaws of this build became apparent. It does, however, take into account queuing and will not let you build more than 1 Probe from a Nexus at any one time.

I will begin my next iteration very soon and hope to have that online within the next few days. Each iteration definitely teaches me a lot about what will and will not work. I am still very far from a final build, but I still think it is possible to get the final build online before the game launches on Jul 27, 2010.

In my last update on the StarCraft II Build Order Calculator, I said that I was going to have this next version work on building queues, but I decided to work on the URL sharing instead. The newest version of the S2BOC still doesn’t account for queues, but you can now send someone the URL to share build orders.

This URL sharing is one of the most critical requirements of this system. This calculator is designed to aid strategy discussions and a key part of that is showing a friend your strategy. As you update your build order, the URL will be modified, so you can send the build order at any time and anyone going to that URL will see what you see.

This calculator also allows you to switch between Terran, Protoss and Zerg, albeit in a clunky way that will be addressed before the final build. In order to change race, change the URL to start the build order string (from # to the end of the URL) with T, P or Z. In both FireFox and Chrome, I had to refresh the page after changing the URL before the new race properly appeared.

StarCraft II Build Order Calculator

Sample Build (9 Pylon / 12 Gateway Protoss build)

I have finished the first interactive prototype of the StarCraft 2 Build Order Calculator and placed it online with the rest of my iterative development tests. This JavaScript prototype is just a proof of concept and is missing many required features, but it does show the possibilities of the system.

This build is the first JavaScript prototype of the S2BOC. I decided at the very start that I would be building this in a client side language to reduce server strain, and so doing tests in PHP is very impractical. It uses the jQuery library and contains a custom extension to generate the build order. It shows off the abilities of the system to add units and calculate the amount of minerals available at any given time, as well as calculate the earliest moment that a unit can be built.

My next iteration should be online and viewable this weekend. This iteration will contain features not shown in this version, like taking queues into account and building requirements. I estimate there will be another 10-12 iterations before I consider writing the final version.

I’ve recently begun work on a new project that should see the light of day in time for StarCraft II to launch on July 27. The project, being hosted over at http://sc2build.com, is the StarCraft II Build Order Calculator. The project aims to take the ease of use and share-friendly nature of World of Warcraft talent calculators and apply it to StarCraft II build orders.

The project is just beginning the iterative development phase, with some small scale tests of single aspects of the system. I began writing my notes on the site in plain text, but it quickly became apparent that I will have enough notes to require a full fledged blog.

Expect to see a flood of posts in the coming days as I think aloud on how to build this system and test various methods of implementation. I will be building it through iterative development, and as such there will be many micro tests in the coming weeks of single aspects of the system.

The first test that has already been pondered upon and attempted once is how to store the build order data in a URI without that URI becoming ungainly in length. You can see my notes on that test and see a sample of this one attempt in the iterative development section of that site.

Anyone who has used phpmyadmin‘s query window knows how frustratingly small the textarea is, and how difficult editing SQL query blocks can be. I wrote a Greasemonkey script to de-suck this query window. As of now, Greased PMA is version 0.1 and has the following features:

• Automatic resizing of the textarea to make best use of the window size
• Ctrl+Enter submits the query
• Tab inserts 4 spaces into the query

Click here to download Greased PMA version 0.1.

Update: While messing around at home on Vista / Chrome, I noticed that Greased PMA partially works on Chrome. I wasn’t expecting this to work outside of Firefox / Greasemonkey, but Chrome has a similar extension feature, it seems. The textarea resizing works, but the Ctrl+Enter submitting query and tab modification do not work. Perhaps this weekend I will debug those two functions on Chrome.