I have decided that I will not be migrating my site, but instead am going to start fresh on my Drupal build, which is now hosted at my new site stevephillips.me. All future posts will go there, and this site will slowly fade away.
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.
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’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.
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.
In a quick followup to yesterday’s building and releasing autoasset, I’ve created another module to do something simple and portable for Kohana 2.x. This module, kotidy, uses the PHP Tidy library to clean up the HTML output immediately prior to display. Even though the HTML is not seen by the end user, I find myself OCD about this kind of stuff and want to know that my source code is clean, even if most people will never see it.
Just like autoasset, kotidy uses the Event system to hook a basic function in place to use the tidy library to clean up the output. Other than adding this module to your module list in the main config file, no work is required on your part, unless you want to customize the config data being sent to Tidy::parseString(), of course.