Cube

I’ve always been a gamer at heart, be it video games or board games, or my absolute favorite genre, collectible card games. This month marks nearly a year into my refound romance with the card game Magic: the Gathering. A bit of background here: I used to play Magic back in 1995 or so as a teen, in the ‘Revised’ era. After finding some cards at my mom’s house over Thanksgiving last year, I got the itch for it yet again. I’m taking my hobby a bit more seriously nowadays (though it’s still just a hobby – I still try to find some balance in my life!) – I’ve take the opportunity to go to try a few professional tournaments in the area, and I’ve built up a decent collection of cards over the past ten or so months.

The one thing that has been bugging me lately is how to bridge the gap between my friends who know how to play Magic, but aren’t into playing competitively like I am. To some extent, I’m sure I could convince a few friends to get together and draft, but nothing more than that, and even then on rare occasions. As a group, we are far more likely to play a good game of Smallworld, Power Grid, or any other board game than we are to do anything Magic-related. Being the problem-solver I am, I decided fairly recently to create a Cube.

Cube is an informal Magic format that is similar to Draft. Essentially, you create ‘packs’ of fifteen cards out of an available pool of 500 or so cards, and you hold a draft tournament using those cards. I won’t go into the specifics of drafting, but essentially all the cards you need to play are going to be provided to you at the outset, though winning requires a fair amount of skill and familiarity with the rules of Magic.

Creating a cube is a very time consuming effort. I’m currently in the acquisition stage of my cube – I still can’t play with my cube, though it is roughly half-complete. Having a theme for your cube is somewhat essential in creating it – in my case, I’ve decided upon a hybrid of a powerful-game-state cube and a good-limited-cards cube. This means that I want to add to my cube some of the most powerful cards available in Magic, as well as to add cards that are particularly powerful in draft format. I’ve been tracking my progress in a Google Docs spreadsheet. I’ve picked out a good portion of the cards I want in the cube, though I haven’t acquired them all to this point. My one additional caveat to this story is that I want my cube to be primarily foil cards (say 95%+ foil, and almost no non-foil-non-promo cards – if I have to put a non-foil Primeval Titan into my cube I will, but not without some regret).

Normally, a cube is actually surprisingly cheap to put together – were it not for the foil cards restriction I’ve self-imposed, I would be fairly near completion of my cube. I’ve been trading and buying cards at a pretty furious pace in order to get where I am now, which is about 180 cards in, with an additional 100 or so picked out but not yet acquired. Feel free to comment on my pics if you so desire, and by all means, challenge me to a cube draft when I’m complete. I’m very energized to complete this project, so I can play with some of these amazing new cards that I’ve acquired over the preceding few months!

Extending jQuery Selectors: ‘between’

There are a ton of jQuery selectors to get at just about any data imaginable on a page. Between actual selectors (such as ID and attribute selectors) and pseudo-selectors (such as :first and :checked), the bulk of HTML element selection is trivial. There are, however, a few selectors I’ve had a need for but aren’t in jQuery currently – for instance, there is a next adjacent selector, but there is no analogous ‘previous adjacent’ selector baked in. How does one get around this? Let’s find out, after the jump.

Continue reading

Who does a Non-Neutral Internet Benefit?

One of the greatest fights over the past few years has been over net neutrality, the fight over whether it’s okay for broadband providers to charge content providers extra for the fastest lanes on their networks. I’ll not espouse too much about the issue itself – just check Wikipedia for a primer. The question I’m pondering is this: in the event of a non-neutral internet, who stands to win in the long run?

Current broadband providers (Time Warner, Rogers, AT&T, etc.) believe that they can open a revenue stream by effectively charging content providers for access to the fastest pipes – basically, squeezing extra of money out of planned network upgrades by offering the fastest lane exclusively to the websites that will pay for it. This strategy assumes a few things, most notably that there is little interest in new parties entering the market. What if there were someone entering the market that didn’t rely solely on selling broadband as it’s business model?

There is a notable content provider who is beginning to experiment with broadband providership – Google. The Google of today provides boatloads of services that consume massive amounts of bandwidth. Google has the most to lose with a non-neutral internet – that is, unless they can tip the scales in their favor. Google could enter the broadband market very simply – have themselves be their their own best customer. Under a non-neutral internet, Google would have an incentive to provide cheap, high speed networks across the US (and, even more so in the developing world). On top of offering competitive broadband, they could offer the fastest access to Gmail and YouTube, just to name a few. By owning the network that they distribute their content over, Google would be less beholden to ransoming broadband providers, and significantly undermine them at the same time through competition.

What would a current broadband provider be able to do to compete against that? They would have to offer some other type of content (on an aging network, probably) – that would be cost prohibitive, amongst other things. The real inequity in the broadband market is that there is a lack of competition, which has significantly contributed to the idea that net neutrality is even remotely a possibility. However, a non-neutral internet could very well backfire on those that want it most. Share your thoughts!

Ech, WordPress Hackery!

WordPress is a great platform – it’s easy to use, fast, reliable, and very popular. Unfortunately, that also makes it a big target for hackers.
A few weeks ago, FerretArmy.com got hacked – essentially, it was serving malicious content from an injected iFrame. In addition, the administrative panel was intentionally broken in an effort to make it harder to fix. The hack directly targeted the WordPress platform – there are millions of WordPress users, so it was likely an automated attack looking for a known vulnerability. I’m still unsure of the attack vector, though I believe it was most likely either through a plugin, or through a (hopefully patched) security hole in the framework itself.

In order to get the site back up and running, I had to physically comb through all the files in my site and remove all the bad code. It’s very apparent that the hack was scripted – it effectively added a single malicious line to every PHP file in the site. It was all reversible damage (with no data loss, thank goodness), but it still left me pretty upset.

In the end, I changed my passwords and made sure that everything was up to date (site and plugins), and the site has not suffered any similar misfortune since. Being hacked really sucks, and I have absolutely no respect for someone that would do such a thing. FerretArmy is a small fish in a big pond, but I try my hardest to deliver worthwhile content to my visitors. Having someone exploit this (for no real gain, let’s be serious here) is inexcusable.

jQuery Image Overlay 1.3 Released

There have been a distinct lack of updates recently on FerretArmy.com – chock it up to having to do a lot of work-induced overtime over the past few months. Either way, in order to usher in some fresher content, I’ve updated my Image Overlay plugin to version 1.3. Changes are that you no longer need to specify image width and height, as well as being able to specify different animation speeds for the ‘in’ and ‘out’ animations. Hope you enjoy!

jQuery 1.4 Released

jQuery 1.4 is officially out now! The jQuery team is in the process of doing a 14-days-of-jQuery-1.4 promotion, which will run through the 28th of January. This is a major release, with much of the jQuery framework being rewritten in addition to a lot of new functionality. The last major release of jQuery was in February 2009, so this has definitely been a long time coming (see my 1.4 preview post here).

There’s a new set of jQuery API documentation, with a new look and some other enhancements. One thing I’m a big fan of is the ability to see when a particular function was added to jQuery – it’s very easy to hone in on the new stuff that way. One thing I feel is still missing is the abilityto jump directly to the function implementation in the library, like how the Google Closure API documentation is setup.

Interestingly, the last day of the 14-days-of-jQuery-1.4 promotion will be the release of jQuery UI 1.8. jQuery UI 1.8 is looking to be a smaller release – a bunch of bugfixes and few somewhat underwhelming plugins, as well as support for jQuery 1.4. There are a ton of great jQuery UI widgets and enhancements that are in the proposal and development stages, but the pace of development has been very slow, which is disappointing. I’d very much like to see jQuery UI development kicked into high gear.

Overall, this is looking to be a great jQuery release. I’m impressed with the performance improvements (addClass is three times as fast now? amazing!), and the new functionality improves the experience dramatically. A lot of functionality that used to have to be gotten through plugins is now in the framework itself, which will be a boon to development. Check it out now!

Musings on SPDY Protocol

So, yet another week, and another fairly large announcement from Google. They’ve been coming pretty fast and furious lately – the open-sourcing of both Closure and Chrome OS are two fairly recent developments. However, the one this post will focus on is the announcement that Google is working on a new application-level protocol, dubbed SPDY.

SPDY (pronounced ‘speedy’) is designed as an adjunct to the http protocol, which has been around for nearly twenty years now. SPDY was designed to run atop of tcp/ip, which is the place in the networking stack that the browser talks to the web server. Hence, to be able to utilize SPDY, both the browser and the web server need to understand the protocol. However, the router need not change at all, which will greatly aid in implementation, if it’s standardized as a protocol.

So what are the features of the SPDY protocol? First, it’s faster than standard HTTP through a number of mechanisms. By default, it gzips it’s headers (and all content), making the packets more lightweight. It only needs one channel for data transfer (it multiplexes requests through the channel, which functions as a stream), so there’s a tremendous amount of connection overhead reduction versus standard-fare HTTP. The connection is designed to remain open as long as the client wants, which means that new content can be pushed from the server to the client. Packet prioritization is built into the protocol as well.

The nicest part of SPDY, in my opinion, is that it requires the use of SSL by default. This means that every packet sent over the wire is encrypted. Deep packet injection and packet sniffing are realities in the world, so a switch to secure communication is long overdue.

The roadmap for SPDY seems pretty straightforward. It’s not finished yet, but being an open source effort, a standard could be developed in a few years. Browsers and web servers can build in protocol support as the standard is still being developed. Browsers and can try to handshake in SPDY with a web server, then default back to HTTP if necessary. There aren’t many competing protocols out there, especially ones that don’t require any router firmware updates (which would take a decade to roll out, at least). Even if the web doesn’t decide to run on SPDY, the only reason for that would be someone came up with an even better idea in the meantime. A new protocol is definitely in store for the future of the web.

Google Closure

Google Closure

Google just open sourced Closure, their robust JavaScript library. Closure is used in a variety of Google products, notably GMail and Google Docs. I had a chance to play with it for a few minutes, and I’m posting my first impressions.

Google Closure is a fairly complete JavaScript framework. In that sense, it duplicates a lot of the functionality of existing JavaScript libraries, such as jQuery and YUI. It contains behaviors, AJAX, event handling, selectors, UI components, and more. The syntax is fairly straightforward, but it’s not the same as other libraries, so there’s a learning curve in getting acquainted with it.

Closure has excellent dependency management through a robust loading mechanism. Basically, if you don’t reference a certain piece of the library, rest assured that it’s not going to load (and slow down your page as a result). In addition, it comes with the Closure Compiler, which will walk your JavaScript, determine what libraries you need, then aggregate and compress all the required files. Being able to deploy one file instead of many is a great way of speeding up your site.

One thing that irks me is that there only way to get Closure is through Subversion access to the trunk. If Google wants Closure to be adopted widely, they’re going to need to start offering discrete, packaged versions of it. Many developers (and novices) will be put off by the current distribution method otherwise.

The API is well documented, and has links to the actual code for each method (something that I’ve not really seen before in API documentation). The API itself is very robust, with a ton of methods and accessors on each object. I’m not sure I’m a big fan of the way things are laid out in the API, but I don’t have enough experience with it to say anything definitively here.

One doesn’t have to stretch the imagination to believe that Closure has amazing potential. This is, after all, what GMail is built from. I’m excited that it’s been open-sourced and I can’t wait to use it a bit more. Google has given a grand gift to the developer community with this release.

jQuery UI ThemeRoller Should be Distributed

I use jQuery UI a lot. I’ve used it at work on internal projects, I’ve used it on some pages in ferretarmy.com, and it’s integral to blaqdesign.com. It’s a great set of rich UI controls and behaviors that work well and are easily integrated into a webpage. I can’t say enough about the toolset.

However, there’s a distinct point of failure of jQuery UI – ThemeRoller. ThemeRoller is the tool that’s used to create a jQuery UI theme – without a theme, there’s a lot less to love about jQuery UI. None of the widgets and CSS styling are available (interactions and effects would still be available, though). This past week, though, ThemeRoller was down. Specifically, it was not outputting custom themes, though the default ones were working. It was down for about three days, to be exact. This was a very big deal to me (amongst others, I’m certain) – I had to delay a production release because I couldn’t get a custom theme that I needed at the time.

There are a lot of reasons that ThemeRoller would be down, and it’s understandable that it will probably break at times as updates are made to it. The bad thing is that if ThemeRoller goes down, for whatever reason, there is no alternative available to create themes with. What I would like to see happen is there be established an alternate home for ThemeRoller. In addition, it should have an archive of all production versions of ThemeRoller. That way, if a bum version gets released for a few days, one can always use the previous version, which should work fine.

With these fairly trivial changes, jQuery UI would eliminate a point of failure. What could possibly be better than that?

jQuery 1.4 Preview

I just found this preview of jQuery 1.4. I read some of this stuff at the jQuery site, but this is a nice explanation of the proposed functionality of the next major version of jQuery.

I think the new ‘live’ event handlers are going to be great. I can’t stress how much the ‘live’ method has helped my JavaScript development – it makes event binding much less of a chore when dynamically creating page content (especially for trivial things, like bindings for button hover behavior). One of the things I’ve disliked, though, is the change event of dropdowns isn’t able to be live captured, which has led me to use Live Query for those purposes. With 1.4, it can be done with jQuery alone.

It will certainly be interesting to see if the Lazy Load code is included, for on-the-fly .css and .js includes. By conditionally loading javascript and css, a lot of bandwidth could be conserved by choosing to defer file retrieval for little-used site features.

Some of the other cool new features will undoubtedly be radio classes and the offset get/set methods – I can see using those to save a few lines of code. I’m betting that there will also be some performance increases with 1.4, so I’m excited about the release, even if it’s release is still a few months off yet.