Framework 0.4.0

Thanks to Southwest delaying my 1.5 hour flight to Portland by 2 hours I’ve finally gotten time to package up the latest release of Framework. I jumped ahead to 0.4.0 from the 0.2.x series due to the fact that 0.4.0 isn’t really 100% backwards compatible and because I felt it was a major enough release to skip ahead a number. Lots of bug fixes, features, etc.

The biggest enhancements are that I switched to a pure exception model for error handling. I even went so far to switch the default PEAR_Error handler to throw Framework_Exception’s. Also, as asked by a ton of people I’ve created the ability to change your DB abstraction layers or not use one at all.

Off to Thailand tomorrow

I’ve spent the last five days running around like a crazy man attempting to get everything in order for my forthcoming epic adventure. Tying up loose ends, wrapping up Digg Images, and purchasing last minute items. I’ve spent more time planning for this trip than I have any other trip in my life. The following is a list of things I’m taking with me.

  • My Chrome bag loaded up with my Canon Rebel XTi, Canon 50mm f/1.4 lens, Canon 28mm-135 f/3.5-5.6 IS USM lens, a mono pod, a few books, a change of clothes, medications, 80GB portable hard drive that accepts CF cards for backing up my pictures and my iPhone for checking email, watching TV and listening to music.
  • I bought a REI Mars multi-day pack and loaded it up with clothes, more books, etc.

I’m not sure what else to pack. I’ve got a copy of all of the necessary documents, double checked that I have all the cables and chargers I need, notified all the necessary people where I’m going, etc. So, with that I’m going to take Crash to a friend’s house and get plenty of rest.

Thailand trip all fleshed out

So I spent a few hours in the Detroit Metro Airport fleshing out my trip to Thailand. I’ll be flying into Bangkok on the 14th of November. I actually arrive on the 15th and plan on spending four nights in the city at the Le Fenix Sukhumvit. Everyone I’ve talked to has told me to spend as little time in Bangkok as possible. I think four days should be plenty of time to see a few sites and get a feel for the city before leaving for the south.

On the 19th of November I board a plane for Ko Samui with a final destination of Had Rin Nok. I’ll be staying in a modest beach bungalow at the Sarikantang resort, which is located across the island on the  Had Leela beach. The reviews appear to be spectacular and it’s hard to argue with $30USD a night, which is actually on the high end for beach bungalows in the area. On the 24th I’ll be joining 10,000 travelers for the Full Moon Beach Party.

I’m really looking forward to this trip now that it’s more fleshed out. I plan on spending a lot of time relaxing and I hope to stay unplugged for most, if not all, of the trip. It’s also my first trip solo to another country, which is exciting.

If you’re going to be in any of the areas above at the same time as me feel free to contact me.

Better late than never

So in 2005 I said I’d travel to two different continents that year. Well, in 2007, just one year late; I’ll be visiting Europe and Asia. Earlier today I booked a ticket to London. I’ll be attending the Future of Web Apps conference and speaking about various Web 2.0’isms at The London Knowledge Lab.

I leave October 1st and come back on the 7th. If you’re going to be in the area and are so interested please do contact me and we’ll get a pint (or ten).

iPhone Tech Talk, San Francisco

Today I’m at the iPhone Tech Talk in San Francisco, CA today. The goal of the iPhone Tech Talk is to teach developers the differences and quirks of developing web applications for the iPhone version of Safari.

  • iPhone ignores all CSS screen types besides @media (e.g. @media { { text-weight: bold; } }). Sorry, that’s referred to as a “media query”, which appears to be CSS namespaces.
  • 10MB limit for text (HTML, JavaScript and CSS). 8MB for TIFF, PNG and GIF, 32MB for JPEG and 2MB for animated GIF’s.
  • 5 second limit on JavaScript execution.
  • and target="_new" open new windows with an 8 window max. Interestingly, you can open 8 windows, but they might get paged out of memory, which means that when the user switches back Safari will need to refresh this screen.
  • alert(), confirm() and prompt() all work fine (and look quite nice)
  • iPhone doesn’t support showModalDialog() or print()
  • Natively supports Excel spreadsheets, PDF’s, Word documens (YMMV), TXT and QuickTime audio and video. Does not support Java, SVG or Flash. Interestingly enough, it does support the <canvas> element.
  • Obviously, it doesn’t support a file system so people can’t download files to the phone.
  • Window sized to 980 x 1091 and then scaled to fit 320 (I assume 480 if in landscape). They treat .mobi domains differently; they’re not scaled. They scale it down immediately to fit 320/480.
  • Use <meta name="viewport" content="width=320" /> if you want fine grained control. Other options include initial-scale (1 is the default), minimum-scale, maximum-scale (which limits zooming in and out) and user-scalable (yes/no allows/prevents zooming).
  • Override text scaling with -webkit-text-size-adjust:none (other values include auto, which is the default and percentages).
  • You don’t get hover styles, but do get mouse events (click, etc.). Remember to leave room for a finger (Daniel Burka mentioned this in his notes about designing the Digg iPhone application).
  • Remember to box content for fingers. They look at the box text is in when doing intelligent zooming. For instance do <div><p>some text</p><p>some more text</p></div> will double tap nicely.
  • They send click, mousedown, mouseup, mousewheel (and one I just missed). Also, blur, focus, load, unload, reset, submit, change, and abor. You can’t call blur or focus, but they are called when it happens. You just can’t explicitly blur or focus because they don’t want a lot of jumping around going on when you’re working on a small device.
  • EDGE 70-135 Kbit/sec and bursts up to 200Kbit/sec, while WiFi is 802.11b/g and goes up to 54 Mbit/sec. YMMV will vary of course.
    • Send compressed content as the iPhone supports it.
    • Match image size to <img> height and width and minimize image use altogether if possible (e.g. use CSS and <canvas> if possible). Use CSS border, border-radius or Cavnas.
    • Use QuickTime reference movies (e.g. pull one move for WiFi and another movie for EDGE).
  • Do not redirect automatically to an iPhone specific site.
  • When creating applications use familiar layouts. They have familiar patterns on the developer website.
  • Use familiar animations.
  • Leverage existing libraries; iUi (by Joe Hewitt, which we used the prototype of for the Digg iPhone application), YUI, dojo and prototype.
  • Integrate with the built-in apps when possible.
    • Any URL loads the built-in Maps application.
    • You can explicitly use href="tel:+1 (800) 555-1212" to launch the telephone application.
    • Of course the Also supports “cc”.
  • Use -webkit-border-radius: 8px to get the native rounded record border listings you see elsewhere.
  • Interesting that they use onclick events on the li‘s (which have that -webkit-border-radius on them) instead of an anchor tag.
  • Hide the address bar with window.scrollTo(0,1).
  • Go to to report iPhone bugs. Do you guys provide any information on when you’ll fix a bug or add a feature? “Um, no.” (Duh)
  • Interaction design tips
    • The mouse does not equal the finger. You don’t have multiple buttons, scroll wheels, etc. There’s no hover, rollover, scroll bars, etc.
    • Avoid an entirely interactive website; minimize animation, avoid distracting the user from the primary task, avoid hiding functionality behind rollovers.
    • Don’t require users to enter information; before something useful happens or something valuable happens.
    • Prevent zooming and constrain to vertical scrolling only.
    • Minimize text entry; use lists, pickers and use cookies for user information and where users where the last time they used the application.
  • Optimize for bandwidth; design light-weight pages, minimize the use of large graphics.
  • Optimize for user’s time; keep things clean, use standard iPhone paradigms, get users to primary content as quickly as possible.
  • Oohhhh “Managing Content and Synced Data for iPhone”. My interest? It be piqued. Leveraging current content on iPhone, producing iPhone friendly video and managing portable user data.
    • *sigh* This hs pretty much nothing to do with managing any kind of data as one might expect. I was hoping for something about Google Gears maybe or accesing content on the phone? No idea, but something more interesting than this. Instead I’ve been reading about a guy who got 10 years for selling grow lamps.

EMU loses a beloved faculty member

I’m saddened and dismayed to hear that Jim Vick, VP of Student Affairs at Eastern Michigan University (my alma mater), was fired today along with the President and the Department of Public Safety’s Chief.

I first met Jim Vick through my fraternity, Sigma Tau Gamma. He had served as the faculty advisor before being promoted to VP of Student Affairs and continued to maintain close ties with the fraternity. I even had the distinct pleasure of initiating him as an honorary brother while serving as my fraternity’s President.

In my last year at college I served as IFC President and, along with that, came a seat on the Student Leader Group, which reported directly to Jim Vick. For the entire year I had weekly meetings with him. Depending on what was going on I’d see him 2 or 3 times a week and it was always a pleasure.

Throughout my years at EMU Jim Vick was a friend and a confidant. Someone I looked up to and  respected. After spending somewhere on the order of three decades he was fired in what many see as a classic case of a fall guy for some bad PR.

Let’s not gloss over the facts; the university knew about this poor girls rape and murder and didn’t tell anyone. What Jim’s role in that was is hard to say, but I find it exceptionally hard to believe he played a key role. I’ll be interested to see where this goes and I wish him the best.

A sad day indeed.

Yet Another iPhone Review

I won’t spend a lot of time covering the things I like about the iPhone as they’re echoed just about everywhere else on the internet. I’ll briefly cover what I like, cover what I don’t like in a bit more detail and sum up my feelings at the end.

  • The screen is jaw droppingly gorgeous.
  • This is hands down the best iPod Apple has produced yet.
  • The multi-touch screen is absolutely a revolutionary input device that cannot be described, but must be experienced.
  • The mail application and web browser are fully functional and work great. For example, my designer sent me a PDF mockup via email, which I opened on my iPhone without issue (multi-touch zooming worked on the large PDF, which was sweet).
  • Clicking on a link to a YouTube video launches the YouTube application and starts playing the video.
  • EDGE isn’t as slow as people make it out to be. Stocks, weather, maps and iPhone optimized websites load up in a respectable manner. Forget about watching a YouTube video though.
  • When moving the text cursor around it zooms in just above your finger because you’d never be able to see where the text cursor is otherwise. Additionally, it auto-capitalizes after punctuation.

There are quite a few things that I don’t like about the phone, which is typical for first generation Apple hardware. It’s clear that the operating system was rushed and that there are bugs, but I fully expect updates to be pushed out in short order.

  • My biggest complaint is that the keyboard is corrective rather than predictive. In other words if I type “tomo” it might suggest “tomb”, but wouldn’t predict I was typing “tomorrow”. I can’t stress how annoying this was coming from a predictive text phone.
  • The software is buggy. I’ve had to even go so far as to reboot it to get things back on track. Again, this will be fixed soon I’m sure.
  • No landscape keyboard sucks for people with big meaty fingers like me.
  • No IM application is jaw droppingly retarded. Another thing I expect to be pushed in an update in short order.
  • EDGE is slow. I know I just said it was acceptable, but it’s only acceptable for some things. I’ll upgrade immediately after a 3G version is available.
  • I dearly miss my scroll wheel from the regular iPod. Sure flicking stuff is fun to look at, but the navigation aspect of the scroll wheel blows the gestures away. For instance, I flick down to an artist, click play and then have to hit a tiny little arrow to go back.
  • Navigation to commonly used tasks is tedius. Just getting to the phone’s keypad takes 3-4 taps. I have no idea what they could do to fix this, but it seems cumbersome to switch around between apps. What would be hot (maybe) is to have a Alt+Tab type feature similar to switching windows in Safari on the iPhone.
  • You can’t open links in new windows in Safari.
  • If Safari is this great platform for developing iPhone applications why the hell didn’t they include some sort of basic JavaScript framework, CSS, images, etc. as an SDK for creating said applications to look, feel and act like regular iPhone applications? Either release it publicly or, better yet, build it directly into the version of Safari on the iPhone.
  • No games. Seriously? This will be best user interface for solitair anyone has ever seen.
  • The SMS utility isn’t very snappy to load.

I think that just about covers it. Overall, it’s better than any phone I’ve ever used. I fully expect the software kinks to be fixed periodically over the coming months and 3G phones within a year. Post any questions in the comments and I’ll besure to reply.

New iPhone version of Digg

Like many other interesting projects the Digg iPhone project started with a conversation over a few beers and a challenge: code it in 48 hours and Kevin would give me a free iPhone. Being the unabashed Apple fanboy I am and, also, being a self-respecting coder I set out to create Digg for the iPhone.  After spending a short time white boarding the application, Daniel mocked up the design and I set off to code it.

Technically speaking, it’s no revolutionary application and I didn’t spend the entire 48 hours working on the application. I did, of course, find time to go see Transformers (awesome) over the weekend. The JavaScript was borrowed from Joe Hewitt and adapted a bit using jQuery. The application iteself is based on our API using the Services_Digg PEAR package I maintain. I’ve been talking with the jQuery team about some limitation in the animations and plan on packaging up a more robust iPhone JavaScript library based on jQuery sometime in the near future (hopefully).

Yesterday Kevin announced the iPhone application and Daniel Burka, our designer at Digg, has covered the details about designing for the iPhone. So far the response to the application has been positive. It was fun and I’m glad everyone is enjoying it. I know I did while riding the bus to work today.

And to answer everyone’s questions. I got an 8GB version last night, the keyboard is interesting, it’s breathtakingly gorgeous and I’ll write YAiPR (Yet Another iPhone Review) soon.

Technical Background of Digg's new Comment System

UPDATE: As you might have noticed, we’re having some technical issues rolling out the new comments. Please bare with us as we work out the kinks.

UPDATE: We reworked a few things and the comments are now live again.

Today Digg launched it’s redesign of the comment system, which was programmed by yours truly. Daniel has written up a detailed overview of the design decisions so if you’re interested in the design aspects you’ll definitely want to check that out.

There were a few fairly complex technical changes to the comment systems, which I’ll outline and then go into a little detail about.

  • We’ve been talking about moving towards a services oriented architecture on and off since I started in February. Steve had coded the API and the decision was made that the new comments system would use Digg’s public API.
  • Comment threads would be loaded dynamically using AJAX and JSON.
  • All commenting, editing, etc. would happen via AJAX.

The API ended up making the PHP code behind the scenes relatively painless. Each page loads using two small calls; one to figure out how many comments are on a story and another to fetch the first 50 or so comments (we use a fuzzy limit so it’ll just load all of them if there’s, say, 55 comments on a story). Both our local proxy and the comments code use the Services_Digg package we released via PEAR when the API launched. In fact, the entire permalink page is built using the API now, which is pretty neat.

By far the most complex portion of the comments system was how dynamic it was going to be. Threads would be zipping in and out, we’d be creating 90% of the HTML dynamically in the DOM from JSON, posting and editing over AJAX, etc. It was during design that Micah and I also plotted to remove and replace it with the smaller jQuery library. The entire comment system is, in fact, a series of jQuery plugins.

Probably the coolest, technically speaking, portion of the new comments is the manner in which most of the page is created. No longer do we create static HTML in PHP and send you a huge HTML page. Instead we give you the basics and, via AJAX/JSON, we make requests to the API and dynamically create the DOM using the FlyDOM jQuery plugin. The FlyDOM JSON templates are a stroke of genius if you’re looking at loading JSON dynamically into the DOM. The advantage of this is that initial page loads are much snappier and you can load the threads you wish to read on demand.

I really picked up the whole dynamically created DOM ball and ran with if. If you notice, on the initial page load there aren’t any forms anywhere in the DOM. Those, also, are created dynamically on request. An interesting side effect to this is that there’s about 4x as much JavaScript code on the new comments than there is PHP.

The major technical and design changes of comments should lead to faster load times, less bandwidth being eaten up and, hopefully, a better user experience. I hope you enjoy them and, as always, welcome comments and input.

As Kevin would say, “Digg on!”

Google Developer Day 2007 – Advanced Topics on Google Data APIs

  • GData gives access to Apps, Base, Blogger, Calendar, Code Search, Notebook, Picasa Web Albums, and Spreadsheets. List is growing.
  • A protocol for reading and writing structured data over HTTP based on REST. A lot less complex than SOAP.
  • Atom Publishing Protocol uses HTTP GET to get feed data, HTTP POST to add a new entry, HTTP PUT to edit and HTTP DELETE to delete an entry. Interesting.
  • Authentication works through ClientLogin (highly trusted applications) and AuthSub (for less trusted web applications).
  • AuthSub is works like Flickr’s authentication model as well.