In August I moved from Allentown, Pennsylvania to State College, Pennsylvania to finish my last two years of college at Penn State’s Main Campus. In addition to the move, the last few months I have been launching a new freelance company with a good friend of mine, Jesse Altman (more on that in the coming weeks). So, I have not exactly had the time I normally put into blogging.

While I have not been blogging, I have not let cavemonkey50.com fall apart either. I have still been answering your comments and pushing out updates to my many plugins. I just have not been finding time to actually write.

I want to change that. Hopefully, over the coming weeks my post count will slowly grow as I start getting back into the groove of writing. I’m not sure what I’m going to write about, but I’m hoping I can get back to my roots and pump out some interesting unique content.

I need your help, though. As I get back to writing, give me your feedback. Let me know what you like and what you don’t. I am open to any feedback you can dish out.

Fixing My MT WSSE Authentication Problem

Earlier this week I received a great deal of help from two Movable Type developers, Mark Paschal and Byrne Reese. After finding the source of my issue, Mark took a closer look at the specific problem. His diagnosis: I had a bug in my end of the WSSE authentication.

After spending numerous weeks working with the Atom Protocol Exerciser, I came to rely on it as a crutch. Whenever my Atom retrieval failed, the APE always succeeded. Well, that turned out to be a bad habit. Movable Type’s WSSE authentication was implemented differently than the APE, and thus the APE was useless against it. So, when I ran into a problem with my code and the APE didn’t work either, I assumed the issue was on MT’s end. That was simply not the case.

After Marked looked at my code, he informed me my nonces were repeating. The AtomPub library I had be using did not rebuild the nonce after each sequential request, and therefore failed to authenticate on the second Atom request, the list of posts. After I added a snippet of code Mark suggested, everything started authenticating perfectly.

So, this entire issue came down to one line of code on my end, and it could have been completely avoided had a took a closer look at my end of the code. Had I approached the problem differently, I am confident I would have found the repeating nonces, but I didn’t even look in that direction. I will definitely be taking this programming lesson with me into future projects.

The Status of the Movable Type Importer

Now that everything is authenticating, the MT importer is not far behind. I’m currently putting the finishing touches on some changes I had to make that differed from TypePad. Once those changes have been made, the importer should be working fine. I expect the MT importer to be completed over the next couple of days, and I should finally have everything submitted to WordPress’ Trac.

The WSSE Authentication Problem

I want to preface my findings with this advisory. I do not have a full understanding of Perl, and my statements may be wrong. If anyone can correct me, please do. I would rather be told I’m completely wrong than continue down the wrong path.

Late last night while inspecting MT’s Atom API code, I found the troublesome line of code (/lib/MT/AtomServer.pm, line 168-170):

if ($nonce_record && $nonce_record->id eq $auth->{Nonce}) {
        return $app->auth_failure(403, "Nonce already used");
}

When commenting out this line of code, the authentication passed, and I was finally seeing a list of posts stored in Movable Type’s database. Once I realized this was the problematic line, I started investigating what this line is doing. From my limited understanding of Perl, this line is checking to see if the nonce has been used in the past. If it has, the check fails to authenticate.

Once I realized this, I looked at my nonces being sent. I verified each nonce generated was different from the last one, eliminating the possibility of the problem being on my end. This tells me somehow Movable Type is incorrectly adding the current nonce to the list of previous nonces before performing that check.

Looking at the slightly bigger picture:

my $app = shift;
my $auth = $app->get_auth_info
    or return $app->auth_failure(401, "Unauthorized");
for my $f (qw( Username PasswordDigest Nonce Created )) {
    return $app->auth_failure(400, "X-WSSE requires $f")
        unless $auth->{$f};
}
require MT::Session;
my $nonce_record = MT::Session->load($auth->{Nonce});

if ($nonce_record && $nonce_record->id eq $auth->{Nonce}) {
    return $app->auth_failure(403, "Nonce already used");
}
$nonce_record = new MT::Session();
$nonce_record->set_values({
    id => $auth->{Nonce},
    start => time,
    kind => 'AN'
});
$nonce_record->save();

From what I’m understanding, the code appears to add the nonce to the record after checking, however, the nonce is passed through MT::Session->load before the check is performed, indicating that may the source of the issue. Sure enough, MT::Session->load is the problem. After replacing the passed nonce with a blank string, the nonce is no longer in the list of previous nonces and the check passes.

I have notified Movable Type’s developers of this problem, and I hope to hear back soon. The good news is once this error is resolved in Movable Type, the importer should work wonders. The bad news is it may be a bit until the next version of MT is released or the bug is fixed. I’ll try to keep everyone updated on the status as I hear back from the developers.

Future Branches of the Atom Importer

Beyond working with Movable Type, after talking with Lloyd this week, we have decided to look into the possibility of porting the importer to other platforms; namely Vox and WordPress itself. We talked about Vox as there is currently no importer at all, as Vox lacks export methods and APIs such as XML-RPC. The idea for WordPress came up because we thought it might be a great way to move a blog from location to location without having to deal with export files.

Over the next week I will be looking at creating those branches of the importer. Thankfully, since the Atom API is a standard, I should be able to quickly and easily make the ports. We’ll see how that goes next week.

Bad: Regular Expressions Are Not My Thing

While working towards media importing this week, I had to write a few regex statements. I’ll admit it, I completely suck at regular expressions. They bring me back to my not so fond days of Discrete Mathmatics; days I would rather forget. Regardless, I managed to get through them and ended with some working code.

Good: Faster Response Times From TypePad

I noticed while working on media importing, TypePad’s server have greatly increased in speed this week. I found that importing took roughly half the time it did in the previous week, with no code optimizations on my part. The speed increases managed to stay consistent through the week, so I’m hoping the changes are here to stay.

Bad: Media Importing is Near Impossible

Wednesday came to a grinding halt when I noticed there was no way to reliably import media by parsing images from posts. There are several reasons to this:

• TypePad has two different methods for uploading images.
• The markup TypePad generates for images is unclean and is not standardized. Users have the ability to modify the output code template.
• TypePad puts the full size image on a separate HTML page that is linked to via a URL that tells nothing about the original file. Due to this, it is near impossible to link the full size image with the originating link.

So, media importing is unfortunately looking very glum. I will try to come up with something since importing media is a crucial feature in my book, but I’m not sure what. More on this in the coming weeks.

Good: WordPress 2.6 Released

The new version of WordPress was released this week, and I was happy for several reasons. First off, I was able update my blog and take advantage of the new features, but more importantly, trunk is going bleeding again. Hopefully in the next week or so the TypePad importer should land in trunk. Stay on the lookout!

Good/Bad: Headway Made on Movable Type Authentication Issue

I managed to get in touch with the developer over at Six Apart who originally wrote Movable Type’s Atom API implementation. The good news is he confirmed I’m not crazy and MT is authenticating differently than TypePad. The bad news is he couldn’t remember off hand what is different with the implementation.

From what it sounds like, MT is not following the RFC 5023 spec in regards to WSSE, simply because the specification was not standardized when the original code was written. I’m not sure where this leaves me, because I don’t really know what is different with authentication at the moment. Also, I’m unsure if Movable Type will correct the authentication difference in the near future.

At the moment, it appears I will be brushing up on my Perl skills and looking at the source code for Movable Type next week. With a little luck, this issue will finally be ironed out. Who knows, maybe I’ll even figure out something for media importing next week as well. Right now, I’m just hoping next week is the week of miracles.

While the App Store and applications have been a huge hit, playing around with applications over the past two days has filled me with some worries. Worries that Apple will need to address if they want the iPhone to succeed as a platform.

Application Data

After trying out several applications yesterday, a major flaw in the way application data is stored became apparent. Application data (preferences, files, saved data such as games) are all stored directly linked with the application that created them. Therefore, if an application is uninstalled, everything that application ever created is cleaned up and throw into the ether. Sounds like a great way to make sure the iPhone stays uncluttered, no? Well it is, but keeping the iPhone clutter free brings problems.

Due to the nature of the application / data relationship, if an application is removed from the iPhone unintentionally, everything that application ever stored is removed permanently. Let me give you an example.

While messing with iTunes’ settings yesterday, I changed my iPod touch’s Application syncing preference to selective applications only. I forgot to select a few applications, and they were removed from my iPod touch the second I clicked apply. No big deal, right? I reselected the applications, and they appeared on my iPod touch with one exception - they were reset to their default settings and no longer contained my saved data. Thankfully, I only lost my Facebook login settings, my Flickr login settings, and my level 8 save game of Enigmo, but the results could have been much worse.

Looking at the list of applications currently available in the App Store, I would say 95% of applications would be fine with their data reset. Users would only lose some display settings, maybe a login or two, and that would be all. However, as the platform matures, more applications (and their users) will become reliant on stored data. Imagine finding out a year’s worth of mileage logs disappeared during your last iPhone’s restore. That could be a disaster.

Syncing

Part of this problem is due to the application / data relationship, but the bigger issue is the lack of a standardized syncing method in the iPhone OS. I would have no problem loosing data after a restore if that data could easily be added back, but at the moment there is no way to restore application data (yes, I’m aware iTunes currently stores a backup, but that is only of the most reason sync, and is no help if a single application looses its data).

Currently all of the native iPhone applications, with the exception of Notes and SMS, sync through an application that manages the iPhone’s stored data. Calendar items sync with iCal, addresses sync with Address Book, and so on. However, third-party applications are left to fend for themselves. Some application developers have cleverly worked around this by utilizing “the cloud” (great example is OmniFocus’ WebDAV sync), but applications without desktop counterparts are left stranded.

How to Trust the iPhone Platform

If Apple wants the iPhone platform to be trusted among businesses and consumers, they need to address these issues. Start backing up application data separate from the application itself. So, when the application is reinstalled, the data can be restored as well. With simple changes such as this, the iPhone will not only be the most innovate mobile platform today, the iPhone can become the most trusted mobile platform as well.

Why Import Media?

The first question I asked myself this week is why should TypePad’s media be imported into WordPress. This was a relatively easy question to answer. TypePad, being a paid service, will delete and remove all content when canceled. This includes images uploaded and stored in TypePad’s cloud. So, importing images and the like is important if a TypePad switcher does not want to see broken images all over the place.

Can TypePad Media Be Imported?

After determining media importing is essential, I explored my options for getting media into WordPress. Thankfully, TypePad has an AtomAPI for their web galleries. Unfortunately, from my testing this Atom API does not include single image uploads. So, the Atom API may be out of the question for media importing.

Since Atom API media importing appears out of the question, I started looking at their XML-RPC documentation. To no surprise, they do not have a method for retrieving media through XML-RPC. Therefore, I’m left with one option: finding media through URLs during the import process.

Sadly, this option is not ideal. For one, it will add time to the already slow import process. Also, this option will force media to be imported at the time of the initial import, since the content can only easily be traversed during the post import. So, I’m not too pleased with my options.

Next Week

Next week I plan on starting to code the media importing during the import process. I plan on making this optional, since it will most likely add significant time to the import process. However, before I do that, I will go through my options one more time. If anyone thinks of any alternatives from now until then, I’d love to hear them.

This Week

This week saw the addition of Atom URI detection based on the straight blog URL. To detect the Atom URI, I have to parse the HTML page for the RSD page, then parse the RSD page for the Atom URI. It’s a multi-step process, but the most reliable should TypePad ever change the Atom URI on me. In fact, I’d like to mention that every single URI (comments, paging, etc) is automatically detecting within the importer, so the importer should be URI future proof.

In addition to AtomPub URI detection, I added a progress bar this week. I thought this would be a huge process, but thankfully the coding was relatively simple. I learned some techniques to force PHP to dump the output buffer, essentially updating the page. Paired with some simple Javascript, I was able to create a fairly responsive progress bar. I chose this method over a completely Javascript method since the Javascript method would require additional time to run (I can explain this technically if anyone wants to know why).

Overall Status

Since we’re at the midway point, I thought now would be a great time to look back at the overall status. As I mentioned earlier in the post, I choose this date as the ready for core inclusion date. Since the release cycle for WordPress 2.6 has been pushed up, core inclusion will most likely be pushed back since the AtomPub importer will not be ready for 2.6. Regardless of the actual core inclusion, the deadlines have not changed in my mind.

According my requirements for core inclusion, by now the importer should be converting AtomPub data in to actual WordPress data. That’s occurring, so I’m definitely still on track.

The Second Half

So, where’s the importer going from here? Well, I plan to start working on the media importing portion of the importer next week. I’m figuring that may take at least two weeks. By then, WordPress 2.6 should be near release, so core inclusion can be considered once trunk goes bleeding again. After the importer is included in core, I can start getting real feedback from users. That should allow me to find and fix bugs, in addition to working on speed enhancements on a much larger scale.

The Importer In Action

I thought I would leave you this week with a look at the importer action. A few notes for the video:

1. The first item takes a while to display since the first 20 posts need to be requested, plus two requests for comments, in additional to the standard trackback and draft checks.
2. I would like to add a throbber to the in progress page to make the wait for the first post less painful.
3. You’ll notice the importer semi-stall after 20 posts. This is because it needs to request another group of 20 posts.
4. By the time the average WordPress user sees this, I would really love to see the importer work ever faster than this, and will strive the second half to make that happen.

New Issues Found

Additional testing early in the week by my mentor Lloyd brought forth some coding challenges. First off, Lloyd found a few error messages on import. Those were quickly resolved, but once Lloyd made it past the error messages, he found the performance of the importing to be subpar.

After adding some performance measurements to the importer, the source of the problem was revealed. The multiple requests of different feeds of data adds up over time. Essentially, for every post the importer needs to ping the post URL to check for a 404 (draft status), request the comments feed, and request the trackbacks XML-RPC data. Each post was taking over a second, quickly adding up over time.

Progress, Progress, Progress

Unfortunately, nothing can be done at this time to lower the request time; the feed requests are at the mercy of the internet. However, the notifications can be enhanced so a user is not wondering why the importer has not finished.

So, after discussing the issue with Lloyd, I think a progress bar is needed in this situation. Unfortunately, due to the nature of PHP applications, I can’t just add a progress bar out of nowhere. I will need to modularize the importer into a more AJAXy interface, so an AJAX progress bar can be updated with the import status. I will begin looking at solutions for this later in the upcoming week.

Even More Issues

The performance issues was not my only problem this week. Lloyd found that when importing from a blog with 3,000 entries, the importer ran out of memory. Surprisingly, it ran out of memory around 130MB, which would be crazy under a normal web server, given PHP is typically limited to 16MB of RAM.

Once this issue was pointed out to me, I quickly found the problem. I had been putting all entries in a massive array before looping through them to import. So, to correct this I limited the importer to batches of 20 posts at a time, freeing the memory between each set of posts. This appears to have corrected the problem.

In addition to the memory leak, I found out that the comments feed has the same 20 comments as time restriction that the main feed had. Already familiar with the issue for the main feed, I corrected that issue and all comments started to be imported.

Outlook Looks Good

Despite the massive amounts of issues discovered this week, I think the future of the importer is looking better than ever. Some major hurdles were overcome this week, and because of that, this week ends with a more memory efficient, error-free version of the importer.

With the new discoveries, obviously the plan has been changed a bit. Currently, I’m looking at finally (and yes, I mean finally) writing the code to automatically detect the Atom API feed at the beginning of next week. From there, I will begin working on updating the interface to be more AJAXy, providing notifications along the way.

Trackbacks Are Go

If you remember last week, I had some difficulties getting trackbacks working. Well, thankfully that is no longer the case. Earlier this week Joseph Scott helped me figure out the code needed for accessing TypePad’s XML-RPC API. With this addition, all standard blog data is now being imported.

Importing is Go

After solving the trackback dilemma, I started working on actually importing the array’s retrieved from the AtomPub server. Since much of the import code is shared between other WordPress importers, this process went fairly quickly. I only needed to make a few minor adjustments on some code, and by Thursday arrays were becoming rows in WordPress’ database.

Notifications Are Go

After testing importing several times, a logical enhancement occurred to me. Occasionally the AtomPub server can take a while to respond and feed the data into WordPress. During this time, a user would be sitting at the initial page with no notification of activity other than the browser’s loading notification. This event could have raised suspicions that the page was not loading, when in fact everything was working perfectly. So, I added a small throbber and message text while the importing occurs. The enhancement is small, but it should bring a piece of mind to those getting antsy.

Bugs Are Go

What would a coding project be without bugs. Today, my mentor Lloyd notified me of several small bugs. It turns out the importer has been generating warning messages left and right. I’ve been oblivious to this since apparently MAMP had PHP error reporting disabled. I have since enabled error reporting, and will start fixing the small bugs early next week.

Unfortunately, a major bug was also discovered. Lloyd found that only 20 entries will import. Since I’ve been working with only a few entries at a time, I had not run into this problem yet. I suspect the issue is with the AtomPub server, and an additional request will be needed for each set entries over 20. I’ll know more next week when I take a closer look at the issue.

Ronald is coding …and he has a plan.

I hope someone gets the above reference. Anyway, as you may have guessed, the early part of next week will focus solely on tackling the bugs found today. Hopefully the issues will not be problematic so I can begin the next task: allowing users to select an author to import all entries under. Once the author override code is committed, the next step on my coding agenda is to finally write the code to automatically the detect the AtomPub URL based on the website’s blog address. Those three items should keep me busy next week, and as always, I’ll let you know next week how the coding went.

Advantages of Safari

• Operating system dictionary integration. Supporting shortcuts like dictionary lookup (command+shift+D).
• iPod touch bookmark syncing.
• Launches fairly fast and browses pretty quickly.
• Has an amazing search plugin.
• Interface is completely “Mac-like”.

Disadvantages of Safari

• Flash currently chokes in Safari. Safari won’t crash, but can easily freeze for over a minute when viewing Flash content.
• After three operating system updates, the vanishing cookie bug remains.
• Some websites still won’t let you use Safari to fill out forms, etc.

Advantages of Firefox

• Lightning fast. Has not crashed or froze on me once since install.
• The amazing awesome bar.
• The bookmark “star” system works wonders. Very easy for temporarily bookmarking websites for later reference.
• When multiple tabs are open, the tab bar scrolls.
• Supports Google Gears.
• Extensions can fill any feature void.

Disadvantages of Firefox

• Interface is only partially Mac-like, even with GrApple.
• Spell checking is not as nice as Safari.
• Firefox 3 occasionally renders some pages strangly, due to the new text rendering.

Looking over the lists, Safari’s advantages are mostly in the interface, while the disadvantages can quickly become show stoppers. For Firefox, the advantages are in the features, while the disadvantages are only minor quibbles. When you enumerate the features, Firefox wins hands down - at least for me.

So, my final ruling is Firefox wins this browser round. If Safari 4 can manage to fix the Flash freezes and remember cookies, Safari has a good chance of winning round 4. Until then, Firefox will remain my browser of choice.

Advertisement: Advertise Your Site in This Space

The XML Parser

I started the week off by writing the custom XML parser I talked about last week. To do this, I researched several different methods for utilizing PHP’s xml_parse function. Since the parsing occured on an established standard where the tag names will not change on me, I decided to parse the tags based on a tag name switch. This worked well until I started running into nested tags. Although, that problem was quickly resolved with the use of a few class variables.

Missing Data

Once the XML was in a parsed array, I began looking over the array and envisioned how this data would import into WordPress. During this process, I realized the AtomPub feed was missing two bits of key data: the draft status of posts and a list of trackbacks. I immediately began looking into possible workarounds.

While I investigated solutions, my mentor Lloyd discussed the missing data with Six Apart. We were assured support for app:draft was on their todo list, but they did not commit to any date for availability. So, Lloyd gave me the go ahead for workarounds.

To solve the draft problem, I ended up creating a 404 checker. Assuming that drafts will not be published, the URL for the post should result in a 404. Knowing this, while posts are imported I loop through the URLs and check the HTTP status codes. The workaround certainly isn’t the best as it’s resource intensive, but for the time being it works.

After fixing the draft problem, I looked into solutions for the missing trackbacks. I found this function on TypePad’s XML-RPC developer site, however, attempts to implement the function call have failed me. So, I continued to search for alternatives.

I found out today that Movable Type has a hidden RSS feed for trackbacks. I tested this and indeed is it true. Unfortunately, TypePad does not seem to have this feed. My guess is this is because of their premium pricing model, removing support for additional and custom templates in the lower tiers. If anyone happens to know the super-secret URL for a post’s trackbacks on TypePad, I would love to know, but I truly believe that feed does not exist.

Therefore, the search for a trackback solution continues. For the time being this is being put on the back-burner. When I get some free time over the next couple of weeks or during the second half of the Summer of Code I will revisit this problem, but at the moment trackback support is being forgone.

Next Week’s Plan

So, what’s up for next week? Early next week I plan on working on the actual importing of data into WordPress. All the arrays are prepped and the functions are ready, so the importing process should go fairly quickly. I’m actually anticipating finishing up the import code by the middle of next week, but if things don’t go to plan I have until the end of the following week. Should I finish early, I will revisit some of the priority two items accumulated over the past few weeks. With a little luck, next week will bring a functioning importer with some additional fixes.

Movable Type Hates Me

Almost immediately, I was retrieving the RAW XML of TypePad’s AtomPub feed. Unfortunately, I could not say the same for Movable Type. Due to some server configuration issues on my end or possibly a bug in Movable Type, I am unable to retrieve Movable Type AtomPub feeds at the moment. I’ve tried various methods of parsing the feed and each method returns the same cryptographic error message. I’ve called in the experts (my mentor, Lloyd) to help me, but if anyone has any clue as to why Movable Type hates me, I would appreciate the feedback.

Parsing the Feed

Regardless of the error, I kept on trucking with the TypePad AtomPub feed, knowing that Movable Type will fall in line once I can figure out my retrieval problems. Working with TypePad’s feed, I started trying different methods of Atom parsing. I first tried WordPress’ built in Magpie parser, but due to Magpie not supporting Atom 1.0, that was little help. I then tried some code snippets on php.net, but unfortunately none of the snippets parsed in the manner I required. So, I started writing my own basic XML parser.

That’s where I stand today. This coming week I will continue writing my custom XML parser, completing the parser by the end of next week. The goal is to have all AtomPub data in array, so I certainly have my work cut out for me.

Since the AtomPub spec (RFC 5023) is so new, this should prove to be an interesting summer. I will be one of the first to implement a real world use of AtomPub, and I suspect documentation will be scarce. Regardless, I am up for the challenge and can’t wait to see how the end product turns out.

If you’re interested in the progress of this project, just stayed tuned to this blog. I will be blogging weekly updates on my progress, so you will always know where I stand.

Microsoft Corp. has warned users updating to Windows XP Service Pack 3 (SP3) that they won’t be able to downgrade from Internet Explorer 7 to the older IE6 without uninstalling the service pack.

As a web designer, this article hit close to home. While I think forcing Internet Explorer 7 down XP users’ throats is great (eliminating the horrible non-standard compliant IE6), this only further complicates the IE6 / web designer relationship.

If I choose to upgrade to XP Service Pack 3, which includes multiple important bug fixes and speed increases, I remove my ability to test in Internet Explorer 6. I could care less for my own personal projects, but I am sure not having the ability to test in IE6 would upset my clients. Then again, this change may remove the remaining IE6 users off the net, thus making IE6 testing obsolete.

Just for kicks, I checked my own website statistics. Currently 20% of my traffic comes from Internet Explorer, with 6% of my total traffic being IE6 users. Do you think this number will dwindle over the coming weeks and months or will the remaining IE6 users remain strong (most likely spyware-infested computers with automatic updates disabled)? When do you think disregarding IE6 users is fair as a web designer?

On a side note, I realize my last post is extremely ironic considering I have not posted since publishing that post. The second my finals are over you’ll see some great content, I promise.

I solved these problems by starting to write my rough drafts on paper, away from my normal work area. I write while I’m waiting for class, or even in class when the professor is boring. When I am on my computer, I have started using an excellent application, WriteRoom, which removes the normal background noise. This combination has allowed me to resume a regular post schedule without much difficulty.

I’m curious if other bloggers and writers run into the same problem as me. Do you find your working environment difficult to write in at times? How do you deal with this? Change of scenery? Hit up Panera or Starbucks? I’d love to hear how others deal with this frustration.

Now four weeks later, I am seriously considering developing my first non-web application. The iPhone seems like the perfect platform for such a task, thanks to its powerful SDK and numerous development tools.

The Beginnings of Native Application Development

I know what you’re thinking. Why haven’t I developed a native application yet? Well, while I know C++ and Java, neither of my courses ever entered the realm of graphical user interfaces. Everything I have done thus far with native application development has been strictly confined to the command-line. Not very helpful in today’s GUI-driven world. Also, while C++ is useful on the Windows side, Mac OS X is strictly Objective-C, presenting a minor barrier to my development entrance.

That is all about to change, though. I just scheduled a required course next semester in object-oriented programming. If I am unable to learn Objective-C on my own, IST 311 should help me fill in the gaps.

Although, more importantly, the iPhone SDK offers something I have yet to fully discover in Mac OS X development: an interface builder. The iPhone interface builder looks drop-dead simple, hopefully helping me cross over into GUI development.

Picking an Application to Develop

Now that the technical hurdles have been overcome, the real challenge lies ahead. I need to come up with an application to develop. While I’m learning I will stick to simplistic applications, such as “Hello World” and others, however eventually I would love to develop an application that others will use. That should not be difficult as the iPhone, being a new platform, will have numerous voids to fill.

I will be sure to keep you updated in my crossover into native application development. In the mean time, if anyone has any ideas for applications, I would enjoy hearing them. I am trying to stay unique, as I am certain when the Apple Store is launched there will be a plethora of To Do applications and so on, but do not hold back on your suggestions. Anyway, I hope to see you on the flip-side, a native iPhone application, soon.

I have to agree with John whole-heartily on this issue. Firefox 3 is generic cereal; while it may look like the name-brand cereal, the taste is horribly off. Firefox belongs on Windows, and I don’t think Mozilla can ever hide that fact.

Why Even Use Firefox?

That got me thinking, why should anyone use Firefox on the Mac? I mean, Safari is quite an amazing browser for being the default Mac browser. Safari has a mind-blowing user interface, is completely standards compliant (arguably better than Firefox), loads blazingly fast, and even includes some kick-ass web developer tools. Well, I think I have an answer: no one cares about that stuff.

The Voices in My Head

People have been trained over the years to despise Internet Explorer and embrace Firefox. I don’t think most people even know why they hate Internet Explorer; they’ve just been told by some geek in their life that Firefox is better and they should use that. When they make the switch to Mac, that sub-conscience kicks in and they feel the need to use Firefox.

Yesterday, my brother approached me and told me he hated Macs. Baffled by that statement, I pushed him for some reasoning. It turns out his school Macbooks have a really old version of Firefox (1.5) running on Leopard. There must be some bug in that configuration because the keyboard always freezes up on him. After hearing his reasoning, I simply told him to use Safari. He quickly responded, “Safari sucks”. Again baffled, I pressed him for a response. He couldn’t come up with one; he just assumed that every operating system’s default browser sucks and he should use Firefox.

I look back now, and when I first made the switch to OS X in 2005, I had the same knee-jerk reaction. Of course, back then Safari did kind of suck, especially on pages with heavy Javascript, but still; Safari was no where near the level of crappy-ness as Internet Explorer. I just assumed Firefox was the correct browser to use without ever giving Safari a try.

A Win-Win Situation

So, I’m not really sure what to make of this. Firefox certainly has a purpose on Macs; to offer an alternative, familiar experience to Windows users, while satisfying the power-user. And, Safari certainly has the short end of the stick; with many switchers passing over an amazing browser for a recognizable name.

I guess the true solution to this stalemate is just to be happy. I mean, this is a web geek’s dream. For once, people are using standards compliant browsers in mass numbers. The movement has become so noticeable that Microsoft has been forced to raise the bar on standards in Internet Explorer 8. A Mac user can’t go wrong; either option is a good one, and in the end as long the page displays correctly, that is all that should matter.

Advertisement: Advertise Your Site in This Space