I’ve been working on my rebuilding of the site on Drupal 7.x quite a bit lately, and have the theme mostly done. The Drupal build, in its current state, can be found in this subfolder. The next step is to migrate the content of my WordPress blog over to the Drupal site, which I’m trying to accomplish with the WordPress Migrate module, but I am having some difficulty. If need be, I might just manually recreate the blog entries I care to retain (that is, not ones related to homebrew or gaming) and attempt to salvage the rest at a later date.

Hopefully I can completely switch over to this Drupal build within the next week. I’ve built the theme as a subtheme of the venerebal Zen theme, and would love to get a working Drupal build to be able to show off some of the stuff I’m working on, like the statepicker module that I recently posted about. I still need to get that working with Drupal 7, however, so I won’t be able to show a demo of it right away.

In the past few weeks, I finally have had the chance to start using Git. I’ve been mildly interested for about a year now, ever since a coworker of mine left the company and began using Git at his new company, but the sheer momentum of my company’s Subversion repositories was a big hurdle to overcome.

I was finally forced to move something onto Git when I put my statepicker module onto drupal.org, and Git was their only available VCS. After making the switch, and learning Git, I definitely agree with the general consensus that Git simply is better than Subversion. Having a DVCS just adds an incredible amount of flexibility to how repositories are set up, maintained and shared.

So on that note, I’ve begun to actually use the github account I set up a few months ago. The first thing I’m putting onto it is the repository for my Drupal rebuild of visual77.com. As far as future projects on it, the only other thing that I still want to do at some point is my Team Liquid Browser Extension. I’ve been unable to touch that since I first mentioned it because I’ve had very little time lately, but that isn’t a stillborn concept.

In the past 6 months, I’ve been using Drupal quite a bit and have made the decision to migrate my site from WordPress to Drupal. I’m more familiar with Drupal 6.x than Drupal 7.x right now, but I can easily change that. The decision to migrate really came to a head when I made my last post about the statepicker module and realized I have no ability to show off this module on my own site. Not only is this site running software that isn’t Drupal, but WordPress is a platform that I don’t foresee myself spending much time in its development community.

My time with Drupal has really changed my opinion of it from ‘meh’ to semi-awestruck. The main point that I keep thinking about is that I have yet needed to hack in any changes to Drupal. Every module I’ve written and every customization I’ve done has been neatly tucked into the sites folder, where custom content is intended to be handled. Unlike the other platforms I’ve used (mostly Kohana and WordPress), I have not needed to go edit things I shouldn’t be editing to reach my desired result.

I’ll be doing the migration over the next month or so. As of right now, I just have a blank Drupal 7.7 install floating in a git repository. I have a lot of work before it’s suitable to replace this WordPress build.

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.

Yesterday, I completed the switch from Bluehost to InmotionHosting. I had been with Bluehost for the past 2 years. They were really good early on, but in the past year, the sites began to slow down significantly and crash several times weekly. I never had data loss or site outages that lasted more than 10 minutes, but it was still extremely obnoxious and unacceptable. I decided to switch to InmotionHosting after having really good experiences with them at work. In particular, their tech support and customer service is amazing.

All pages should be fully operational, but with any hosting switch comes a bit of a risk. I’m still moving over the other domains I had hosted, but none were as significant as visual77.com, so I’m taking my time with the rest. I’m not transferring over all domains, though. There are a few that expire very shortly and I have no interest in renewing.

I just hope no issues pop up during this critical judging phase for the Zappos API Developer Challenge, where my Zearch extension has been entered. It would be a shame to lose points because the Zappos developers were unable to even download Zearch during the downtime.

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.