plebeosaur.us

Over the holiday break I finally got around to creating a little something I’ve been wanting for awhile: a calendar of the web community events in Austin. Check it out at austin.geeknite.info (and then come back for the rest of story if you wish).

Austin GeekNite Info actually started as a simple spreadsheet of the local web groups I regularly attended and their typical meeting nights. But since I’d also like to know what’s going on in other communities (and my wife would like to know where I think I’m going) I started looking at ways to automate the process of adding events to a calendar.

As luck would have it, Google Calendar provides the means to add iCal feeds from other sites to your calendar AND share this newly aggregated event calendar with others. Nice. The wife will be happy. By why stop there? Overwhelmed by the spirit of the season, I grabbed the geeknite.info domain and prepared a simple calendar page to share with the rest of Austin.

Initial release

Adding and editing iCal feeds in Google Calendar can get a bit unwieldy so this first version of GeekNite applies Tony Hirst’s Delicious Pipes solution for managing iCal feeds. It’s a pretty slick fix for getting around Google Calendar’s limitations.

Basically, we’re manually collecting iCal feeds from around the Austin tech community on Delicious.com. We then massage the RSS feed from that Delicious list into an iCal feed with Yahoo! Pipes. Google Calendar happily chomps on that iCal feed and spits out a pretty calendar that can be embedded in any HTML page with a snippet of iframe code.

We end up with a decent calendar that can be viewed in a few different ways (weekly, monthly, agenda). Clicking on an event brings up a bubble with more details and a link to add the event to your own calendar. Nothing too fancy, but useful.

Next steps

• I had to manually enter some dates (e.g, Ignite Austin). That’s something that I’d like to get around in future iterations. It’s 2010 folks and time for y’all to add semantic mojo (in the form of iCal or vCalendar microformats) to your sites. Perhaps that’ll be one of my base requirements: iCal or no-cal.
• The whole Delicious Pipes layer is a temporary hack to get this rolling. I’m guessing there’s a way to sniff out all the local web event iCal feeds sans spam/noise but I just haven’t looked into it that much yet.
• As long as I’m at it, I’d like to break from Google Calendar as well. It’s a nice starting point and all, but much too limiting. I’d like to customize the results a bit more to include more information (e.g., group size, number of past meetings) and to format for iPhones and such.

So there it is, Austin.GeekNite.Info. Let me know what you think and how we can improve this little app.

Update

Shortly after I wrote this, Judd Lyon told me about a couple of other Austin web tech calendars already out in the wild: GarysGuide and Door64 (I really need to check with him before embarking on new projects).

Since Apple announced the iPhone OS 3.0 update at WWDC a few weeks ago, I’ve been eagerly anticipating the addition of location services to Safari (Webkit).

Until now, providing an iPhone 3G user with a map and an indicator of their current position required building a native iPhone application in Objective-C and getting approval from Apple to distribute said app via the App Store. Not fun.

Well now that OS 3.0 is out, we can take advantage of Safari’s newly baked-in geolocation services and some other niceness to do the very same thing. (jump to the map)

Native Geolocation

Safari now gives us navigator.geolocation from the W3C Geolocation API Draft Spec and all the magic that goes with it: getCurrentPosition (one time retrieval of location), watchPosition (continuously updated location), and clearWatch (stop watchPosition). (If you’re browsing with iPhone, Android, or Firefox 3.5 right now, take a peak at your raw geolocation info.)

We want the location marker to follow us around, so we’ll choose watchPosition. The following provides the basic format we’ll follow, though the final code will be different as we add the Google Maps juice:

function displayLocation(position){
  var latitude = position.coords.latitude
  var longitude = position.coords.longitude
  // do something with this new information
}
 
function handleError(error){
  switch (error.code){
    case error.PERMISSION_DENIED:
      alert('Sorry. Permission to find your location has been denied.')
      break
    case error.POSITION_UNAVAILABLE:
      alert('Sorry. Position unavailable.')
      break
    default:
      alert(error.code)
  }
}
 
navigator.geolocation.watchPosition(displayLocation, handleError)

When this code is run in an iPhone 3G with OS 3.0, the browser asks for permission to use your location. If permission is granted, the displayLocation function is called; if not, the handleError function is called. Now let’s do something useful with this location information.

Google Maps

Google Maps released a welcome upgrade to their mapping API this past spring. With the still developing API v3, they tossed out the API key, rewrote the code, improved the namespacing, and much more. In the interest of playing with all things new, we’ll use this version of Google Maps. And in the interesting of keeping the focus on the new geolocation shizzle, we’ll skip the in-depth Google Maps discussion and just cover some abstract goals.

Initially we’ll center the map somewhere in downtown Austin, Texas. Then, when our previously mentioned displayLocation function gets called, we’ll add a marker and re-center the map on that marker—just like the big kids do with their fancy native apps.

Inside displayLocation, we’ll create the marker just once and then update its position on subsequent calls. Every time the iPhone changes location, the marker moves to follow. (extra credit: if you want to create a breadcrumb trail, take out the if/else stuff to create a trail of new markers on each iteration)

Lastly, we add an onload attribute to the body element to invoke our geolocation and Google Maps magic after the page loads. We now have a cool mobile map that tracks your position as you’re moving.

CSS3 Animation

We could certainly stop here and pat ourselves on the back, but let’s apply one last bit of polish. If you look at the native iPhone Map app, you’ll notice that the blue location icon pulses in and out to keep your attention. Hmmm. Our current location marker is lovely PNG image with alpha transparency that smoothly overlays the background map but it doesn’t pulse. Unfortunately, we can’t animate PNGs. We could fade the image in and out with some more JavaScript coding, but let’s take a look at a better solution, compliments of the new Safari.

When the CSS animation draft was announced, it sounded rather odd to add behaviors (JavaScript’s forté) to a styling spec (CSS). But given our current problem, we start to see the wisdom. We can select and animate the location marker with CSS3.

As demonstrated by Surfin Safari, first we describe the effect with @-webkit-keyframes, then we select the marker element from the DOM and apply the animation with -webkit-animation:

@-webkit-keyframes pulse {
  0% {
    opacity: 1.0;
  }
  40% {
    opacity: 0.25;
  }
  100% {
    opacity: 1.0;
  }
}
#map_canvas div[style*="blue_dot_circle.png"] {
  -webkit-animation-name: pulse;
  -webkit-animation-duration: 2s;
  -webkit-animation-iteration-count: infinite;
  -webkit-animation-timing-function: ease-in-out;
}

It’s a simple solution that provides the effect we need without the added overhead of JavaScript.

Feel free to view this map with your normal browser, you’ll get a plain old map of Austin—not much more. For the real show, open it in iPhone 3G and find your current location. Then start moving.

When you get back to the desk, crack open the source code to see how it was all brought together.

Next

So there it is: a breezy introduction to what is possible with the iPhone’s new Safari geolocation powers and Google Maps. We certainly don’t have to stop here. We haven’t even mentioned that other mobile devices have or will have these very same powers. That web developers now have direct access to these powers means that we can expect a torrent of location-aware innovation.

See you at the mall.

Reference Links

• our map
• The Google Maps API V3
• W3C Geolocation API Specification (Draft)
• Safari CSS Reference

After taking a peek beneath the covers of the beautiful WordPress 2.7 admin interface and reading John Allsopp’s Shiny Happy Buttons article on 24ways.org, it’s become abundantly clear that the next great web design era isn’t going to wait around for Internet Explorer. The future is going to be a bit more rounded and IE will be, well, square.

For far too long, web designers have had to deal with a lack of real-world design tools in CSS. In their place, we’ve used kludgy HTML, images, and even JavaScript to accomplish basic visual treatments such as transparency, shadows, gradients, and, yes, rounded corners. Every solution using this old toolset calls for an uneasy compromise of appearance vs. semantic markup vs. development time vs. file count/size.

Why can’t we just ask the browser to provide a 5px radius in CSS in whatever color/width/shape we want and get on with our day? We can.

Welcome Border Radius

Firefox has supported a border radius property for some time now (-moz-border-radius) and Safari recently came out with their own experimental syntax (-webkit-border-radius). Furthermore, the CSS Working Group recently announced some pretty robust support for the border-radius property which means the usually standards-leading Opera should be getting around to roundness soon as well.

Using border-radius today provides nice, rounded corners and shaves a ton of development time (no more round-trips to the image editor or nesting HTML for flexible dimension boxes).

The problem, of course, is that 70% gorilla in the corner. So, what about IE? The yet-to-be-released IE8 is finally getting things right with CSS2.1 (a good thing) and moving their proprietary properties into -ms- vendor specific extensions (also a worthy effort). Yet it doesn’t look as though the IE team will be tackling border-radius until IE9 (2 years?).

Progressive Visual Enhancement

So at this point we have two options when it comes to going all CSS on rounded corners: we can whine and cry about how IE sucks (been done already) and wait for IE to get around to border-radius or we can take progressive enhancement to the next level.

Let’s take the latter route. Starting today, let’s throw out all the crappy, nested HTML; the countless, un-scalable images; and the overly-complicated JavaScript work-arounds. Let’s start fresh…

1. Lay a foundation of basic borders—square, un-adorned, solid borders. Every browser shall see squared edges by default. No problemo.
2. Then throw in some rounded corners for Firefox and Safari and anyone else that’d like to join the party. Kewl.
3. Lastly, add a dash of gradient to Safari as prescribed in Shiny Happy Buttons. Brilliant!

Sweet. No one gets hurt, the cool kids get the nicest looking stuff, and those squares that want to join the cool kids just have to download a free browser. What could be better?

It’s been a couple weeks since I traded in Firefox 2 for Firefox 3 and I’ve rarely glanced back. Most of my critical extensions have been ported and work fabulously. And what few annoyances that did arise were quickly cleared up with a few hacks to trick FF3 into accepting older extensions. Muzzling the AwesomeBar with oldbar also made things more tolerable.

One irritation defied all my attempts to resolve: disabling CSS via the Web Developer Extension’s long-standing keyboard shortcut CMD-SHIFT-S. Apparently the Mozilla team decided to Shanghai that shortcut for their History Sidebar. Why?

No matter. Today I found my solution in Keyconfig for Firefox 3. Now I can create, edit, or disable existing any FF3 shortcut I wish. Buhbye, History Sidebar!

Web development on a Mac is pure joy. There are so many tools that just that make building websites simple and even fun. From the dead-simple MAMP web server setup to the deceptively powerful TextMate editor to the game-changing Firefox browser-cum-editor/tester (with the essential Web Developer, FireBug, and ySlow extensions), it’s all good in Mac land.

And since Mac went Intel, we can develop like crazed bunnies and test our work in each nasty little flavor of Internet Explorer running in separate virtual Windows environments. Granted, it took a bit of Googling on my part to find out how to point Windows browsers to MAMP. But the two primary solutions are fairly straight forward and work in most cases:

1. use the Mac’s IP address (e.g., 192.168.2.2:8888)
2. create and use a hostname
   1. open the C:\WINDOWS\system32\drivers\etc\hosts file (in Notepad)
   2. add a line to the bottom with the Mac’s IP address and desired hostname (e.g., 192.168.2.2 mamp) and save
   3. use that hostname (e.g., http://mamp:8888)

In most cases? Yep. Everything runs fine so long as your apps don’t reference MAMP’s default webserver name, localhost:8888. Of course, the popular apps such as ExpressionEngine and WordPress do need a base URI—and localhost:8888 is it.

Bugger. Windows has it’s own localhost quite separate from Mac’s and neither the two shall meet. Accessing MAMP’s localhost just isn’t going to happen with Windows’ localhost listening in and intercepting. The only solution is to set up a hostname other than localhost on the Mac side and enter that same name in the Windows host config file.

The gritty, command-line way of changing MAMP’s hostname from localhost is to make some changes to its httpd.conf file and to muck with dscl (Apple’s NetInfo replacement). Feel free to Google the specifics, but I personally don’t want to have to fire up Terminal every time I want to change to another site. Thank goodness for VirtualHostX.

My new pal, VirtualHostX, allows me to create different virtual host names for all my projects. So rather than using the localhost URI, I can create meaningful URI’s such as newproject.dev and anotherproject.dev with impunity (which makes it superior to the Headdress method of merely assigning new port numbers to localhost). VirtualHostX makes all the changes behind the scenes and even backs up the default settings before making those changes. Sweet!

We’ve almost achieved web developer inner-peace… but we need to make one more stop. Let’s remove that crufty port 8888 bizness (e.g., localhost:8888, myproject.dev:8888). By default, MAMP uses port 8888 to avoid conflicts with OS X’s built-in web server (which listens to the http default port 80). Since I have no immediate intentions of using OS X’s built-in server, I immediately changed MAMP’s default port setting to good ole port 80. From here on out, just enter myproject.dev in any Mac browser and go. Yay. Nirvana.

Now, back to the Windows side. After adding myproject.dev to the Windows host file (e.g., 192.168.2.2 myproject.dev), fire up your Windows browser of choice, point it to myproject.dev, and Shazam! Everything works.