The Sweet Spot
On software, engineering leadership, and anything shiny.

Setting up a multi-AP wireless network

A few weeks ago, I couldn’t seem to connect my laptop to the wireless AP in my apartment. Additionally, I’d be getting weak signals from all these weird corners in my apartment. Since I had a spare AP lying around at home, I decided to do some online research to see if I could get it to behave as a second wireless AP on the same network, extending my network range, allowing our network to handle more wireless users and playing nicely with my laptop.

The desired setup:

  • Two wireless routers on the same network: one router acts as the gateway and DHCP server, the other is a simple switch + wireless AP. One router is the Netgear WGR614, the other is the DLink DI-624.

  • Workload: many wired connections, many wireless connections. We have 3 wired computers for me and my roommates’ computers, and up to 10 people connected via wireless at the same time (we tend to have a lot of visitors).

After a bit of research, I found a forum thread online that details how to set it up:

  • The host router (the Netgear in my case) stays the DHCP server and broadband gateway. Settings:

    • Assign a static IP on the MAC address of the secondary router. It’s 192.168.1.3 on my network. That way you’ll always have an IP address to the second router’s admin panel.
  • Run an Ethernet cable from the host router’s LAN port in to the LAN port of the second router (the DLink). (Note: it’s especially important that you plug this wire in to the LAN port instead of the WAN port).

  • With a computer connected on the network, send your browser on over to the D-Link admin panel at 192.168.1.3. Your settings on the DI-624 should be as follows:

    • “WAN Settings” section (Note the 20.2.20.x IP is just a random IP address so the AP doesn’t go off and try to dynamically resolve a IP address)

      • “Static IP Address” radio button selected

      • IP Address: 20.2.20.20

      • Subnet mask: 255.255.255.0

      • ISP Gateway Address: 20.2.20.21

      • Primary DNS address: 20.2.20.22

    • “LAN Settings” section:

      • Static IP: 192.168.1.3

      • Subnet mask: 255.255.255.0

      • DNS Relay: Disabled.

    • “DHCP Settings” section:

      • DHCP Server: Disabled
    • “Wireless” section:

      • Set up your wireless AP settings however you’d like!

Though these instructions are specific to setting up the DI-624, I’m pretty sure you could get your old router to work on an existing network.You can now extend the range of your home’s wireless network without any fancy signal booster tricks or expensive repeater equipment. How cool is that?

First look at SproutCore and Cappuccino

One trend on the Web these days is to move away from traditional full-stack frameworks (like Rails) toward client-side, full-stack Javascript frameworks (among them Dojo, GWT, SproutCore, and Cappuccino). There’s been a lot of buzz about SproutCore and Cappuccino, because of their design elegance, shiny Mac-ness and promises of really rich client experiences. I’ve been checking them out and here’s some of my observations so far:

  • They’re both really young: SproutCore and Cappuccino have emerged only in the last three months. I haven’t heard of any deployed Cappuccino apps asides from the storied 280 Slides app. Same with SproutCore, looks like asides from MobileMe, they’re only beginning to see user-created apps come out (see: OtherInbox).

  • The two frameworks are beautiful. Because they both model on Cocoa, they both take on the same icon set, window chrome, pane behaviors, and so on. Nice work, lifting the good UI work from the Mac and placing it on the Web.

  • Objective-J sounds cool. I just can’t see non-Cocoa programmers just picking it up, though. Even though I picked up Cocoa over the summer and I think it’s pretty awesome, there was no way I would have the energy to pick up Objective-J on my own (unless Cappuccino proves itself to be THAT big of a draw).

  • Okay, but to be fair, the idea of “Cocoa on the Web” is phenomenal. I wonder if we’ll see a surge of ported Cocoa-to-Web apps. Aligning Cappuccino with AppKit is a great idea, and it’s clearly the “Web framework for Cocoa apps moving to the Web” and you’re gonna want to use it for sure if you’re a proven Cocoa hacker. I wonder, however, if it can capture users who aren’t Cocoa programmers.

  • I’m a big sucker for looks. Nothing gets me excited like SproutCore applications do in all their Aqua-like goodness. GWT in comparison looks pretty frumpy. I really like OS X-looking widgets. What can I say, I was brainwashed :)

  • SproutCore and Cappuccino apps are simply not going to be able to out-perform GWT apps: they simply can’t beat the compiler optimizations of compiled and optimized JS in GWT. Then again… we’re going to have crazy fast JS engines in the next year or so. We’ll see if performance is an issue.

Even though these two frameworks are only beginning to gather momentum, I’m excited at the direction they’re moving the Web in. Anybody else want to weigh in?

GWT vs. SproutCore vs. Cappuccino

I’m looking to develop a Web application with a full-stack Javascript framework like GWT, SproutCore or Cappuccino. I’m making the decision to go with a Javascript framework over a traditional full-stack framework (like Rails) because:

  • I get richer, desktop-like functionality in the browser.

  • I can offload much of the work from the server onto the client.

  • There’s less Javascript hand-coding so I don’t reinvent the wheel.

  • I can bring the desktop app programming paradigm straight to the client.

I’ve been taking a look at GWT (Google Web Toolkit), SproutCore and Cappuccino, and here’s some of my observations so far:

  • GWT is the most mature framework out of the three at 2 years. SproutCore and Cappuccino have emerged only in the last three months.

  • SproutCore is really, really, beautiful. Just look at MobileMe. I’m sure Cappuccino looks much the same. It’s probably because both emulate Cocoa, and so take on the same icon set, window chrome, pane behaviors, and so on.

  • Objective-J sounds cool. I picked up Cocoa over the summer, and to have it on a Web browser is going to be phenomenal.

  • Cappuccino is so new that there aren’t that many apps out there (asides from the storied 280 Slides app). I’m worried that it could be buggy and docs are too sparse.

  • Something about Java in GWT makes me cringe. Maybe it’s just because I’m not used to that extra compilation step. Maybe it’s because I’ve been mucking in dynamic languages for too long of a time.

  • I’m a big sucker for looks. GWT looks pretty frumpy. Honestly, it doesn’t get me excited like SproutCore applications do in all their Aqua-like goodness.

  • The Ext widgets from Ext-GWT are only slightly better. I guess I shouldn’t complain… but gosh, I really like OS X-looking widgets. What can I say, I was brainwashed :)

  • SproutCore and Cappuccino are slower: they simply can’t beat the compiler optimizations of compiled and optimized JS in GWT. Then again… we’re going to have crazy fast JS engines in the next year or so.

  • I considered Dojo. Sort of. I like it because it’s more mature than SC, but it’s slower than GWT and doesn’t have as many widgets as Ext.

Honestly, even though my “ooh-shiny” sense wants to use SproutCore, my objective reasoning tells me to go for GWT for its stronger support, more maturity, better performance and a fuller set of widgets. Anybody else want to weigh in?

Updated portfolio... sort of.

Since I’m in the process of doing some housekeeping around the blog, I’ve begun moving my old design portfolio over to Flickr.

This is sort of an intermediary step to another intermediary step of overhauling my portfolio (yeah, I’ve been meaning to do this for the past five years). Watch this space for updated project briefs to come trickling in.

A layman's guide to the OAI-ORE data aggregation protocol

In Spring 2008, I took an information architecture course in the UC Berkeley School of Information, taught by Erik Wilde (disclaimer: I dropped the course after a month because of schedule conflicts). An interesting part of my research for that class involved investigating the nascent Object Reuse and Exchange (OAI-ORE) protocol, a way of organizing groups of resources across the Web. I’m going to try to describe in laymen’s terms what I learned from my research and explain why it’s significant.

Group things together on the Web

Let’s say you’re looking for a book online. You’ll hit up JStor or Google Books and browse through the pages of that book you found. Easy enough, right?

In reality, the physical, electronic representation of the book online is actually more than just “that book on JStor” or “http://www.jstor.com/book”. It’s actually a collection of images on a Web server. We need a uniform way to descibe that jStor’ specific online version of “War and Peace” is actually comprised of “page1.jpg”, “page2.jpg”, et cetera.

As another example, let’s say that the local public library wants to create a digital representation of its materials on Jimi Hendrix. Well, the library’s got Jimi Hendrix CDs, Jimi Hendrix books, Jimi Hendrix magazine articles, and so on. With the OAI-ORE protocol, we can create a digital “Jimi Hendrix @ Your Local Public Library” object that lists out each CD, book and magazine article contained in the library.

Let’s say on top of that, a certain Jimi Hendrix biography references “Little Wing” on pages 12, 141 and 254. This “Jimi Hendrix” object is capable of encoding that reference from those pages to “Little Wing” on the “Axis: Bold as Love” album in the library.

Why even have a description framework?

As the Web gets more connected and as we’re seeing the rise of interoperable Web services, it becomes increasingly important to have a standard resource description language. Various protocols (such as RDF) have built a foundation on which to describe relationships between electronic resources.

Think of OAI-ORE as a way of organizing information for re-use by others. If every library created its own “Jimi Hendrix” resource object and made them accessible to others, we could potentially create programs and Web services to collect all “Jimi Hendrix” objects from across the globe and reconstruct the ultimate, canonical Jimi Hendrix electronic resource library. We could note which books made references to “Little Wing.” We could view “Little Wing” as an WMA file, an MP3 file, or as lyrics.

The key is that by standardizing a description language, we enable programmatic ways to collect and synthesize data that can potentially add to the value of the world’s sum knowledge.

Resource maps & implementation formats

OAI-ORE is a specification that defines relationships between resources through an object called the resource map. The resource map is a resource file enumerating a collection of resources and describing the relationships between each resource. Each resource map has its own URI, so it can be discoverable and accessible.

There is no standard file format to encode resource maps. Currently, the OAI-ORE working group has suggested the following description formats (HT: Univ. of Queensland):

  • RDF (Resource Description Framework)
  • Atom syndication format
  • YADS
  • TriX (RDF triples in XML)

The recommended method of describing a resource map is in RDF/XML. I’m not very familiar with the RDF syntax, however, and the TriX format, which affords us RDF triples that can easiliy express relationships between objects and resources, seems to make more sense to me.. However, there is a complete Atom implementation of the protocol, used when syndication is preferred.

I’d definitely refer the reader to the Univ. of Queensland’s OAI-ORE PDF overview for a broader overview of the protocol and its potential implementations.

The nitty-gritty

Collections: Multiple resources can be grouped together, but only via an “aggregate object” or a “collection”, which maintains pointers to each object in a collection.

Links: Links describe relationships between objects in a resource map, such as “has-part” (“War & Peace “-has-part-“page 2”) or “derived-from” (“Radiohead - 15 Step Remix”-derived-from-“Radiohead - 15 Step”). Actual relationships depend on selected vocabularies and namespaces (meaning you can change the link relationships to be whatever you need them to be). There is a list of default namespaces on the spec.

In conclusion

I took a high-level and somewhat abstract tack in describing the protocol, and would direct you to the OAI-ORE Primer for more implementation specifics. Apologies to those of you who were completely lost in this discussion.

I’m excited about developing standards like these because resource mapping protocols such as OAI-ORE are an instrumental step in connecting resources, services and information on the Web. They’ll help us “connect the tubes” and create the infrastructure needed to link the world’s information together. Now that’s pretty cool.