Most of my work for Automattic is done on a remote sandbox machine, somewhere in Texas. I’ll often jump in and make smaller edits over SSH via vi, but when I’m doing something bigger I much prefer to work locally, using TextMate (I’m on a Mac, obviously). To do that, I need to be able to access files as if they were local, which means either duplicating them to my machine (lame, annoying) or mounting them directly.

I’ve been doing that via one of the following options, and I’m wondering if anyone out there has a better solution.

• Mount locally using Transmit 4, via SFTP or
• Mount locally using Macfusion (which uses MacFUSE), via SSH

I’ve tried both for a while now. They both work. Except for when they don’t. Here’s what I’d found:

• Transmit seems more responsive, when it’s working
• Macfusion often crashes Finder the first time I access a newly connected filesystem (and is then reasonably stable)
• Transmit much more randomly just stops working and gives no indication, I just can’t browse any more and have to disconnect/reconnect
• Macfusion allows you to easily customize a neat icon for each filesystem
• Transmit seems to have more aggressive caching (or a longer TTL on it) of filesystem details (part of what makes it feel more responsive)

So, have you used one of the following methods? Is there a configuration option I’m missing? How do you go about solving this problem?

UPDATE: I should have mentioned that I need to be able to do this over the open internet (securely), where I’m not connected directly to the same network as the server.

Jetpack is a new plugin that delivers a bunch of popular features from WordPress.com (the hosted site, which Automattic runs) to self-hosted installs of WordPress (such as the one that runs Dented Reality). Once you install Jetpack, you get some of the cooler things available on WordPress.com, automatically enabled on your own WordPress site. The modules you get today are just the beginning though, there are a lot more planned for future releases. We’re going to be targeting some of the biggest features that are easier for us to do on our massive grid/cloud infrastructure, but harder for folks to do on their own shared-hosting accounts.

We also managed to partner with a bunch of leading web hosts, so if you’re doing a one-click install on Bluehost, DreamHost, Go Daddy, HostGator, Media Temple, or Network Solutions, you’ll get Jetpack as part of your install. This is huge for people installing their own WordPress.

This has been the coolest thing I’ve worked on at Automattic so far, and it’s been awesome to be involved in a project that has seen so many contributions internally (over 40 people were involved in everything from UX to design to internationalization to testing and debugging) and so many iterations since its inception. I’m really proud of what we’ve created, and hope that it sets a new bar for the design of WordPress plugins (I really think Jetpack is beautiful, amazing work Joen, Hugo and MT!).

So – check out Jetpack if you’re running WordPress on your own server, and let us know what you think!

Which features would you most like to see in Jetpack? Let me know in the comments and I’ll see what I can do

PS: This post proudly proof-read by After The Deadline, as delivered via Jetpack

Here’s a little bit about how that happened and what it means to me:

In 1999, I got what I consider my first job in the web industry. I was hired as an “HTML Engineer” at InsuranceMyWay.com.au (now defunct), a company that allowed users to compare different insurance policies online and then complete their purchase via the web. It was pretty cutting-edge stuff back then, especially in little old Western Australia. At that job, I started playing with PHP and MySQL and both technologies just clicked for me. Since then, I’ve worked with the LAMP stack pretty much exclusively and have never looked back.

Fast-forward to around 4 or 5 years ago, when I installed and themed my first copy of WordPress at the job I had at the time. I was in charge of making most technology-related decisions there and chose WordPress as the ideal platform for our company to launch a customized blog with a unique theme, integration with a specialized search system and a basic categories implementation (tags were only available as a plugin at the time!). I had seen and heard a lot about WordPress, but I’d never worked with it directly until that point.

After that initial project, I was involved in a few smaller projects here and there with WordPress for friends and some smaller clients (I’ve always done consulting work on the side), but never anything too serious. In amongst all of this, I had read up on WordPress MU — the multi-user/blog-network version of WordPress. When I quit my last full time job, I used WPMU as the backbone of MyBabyOurBaby.com, which at the time was probably one of the most customized installations of WPMU around. That gave me about 7 months of doing nothing but looking at WPMU code, figuring out the internals, integrating with bbPress and just generally becoming a bit of a WordPress Pro.

With the publicity from MyBabyOurBaby, I spent the next year working on WordPress projects of one variety or another pretty much exclusively. I did everything from small one-off plugins to do some custom RSS feed work, to working with sites like Mashable.com to help them tune, optimize and scale their very large installations.

I got very used to the freedom and flexibility of the freelance life, but somewhere in amongst all of this, a little over a year ago, I sat down in Huntington Square Park and asked myself “if I were to go and work for a company, full time, which one would it be?” I wrote a list of names down on a card in order of preference. The first name on that list was Automattic.

And so – 3 days before Christmas last year (normal calendars start to blur and not mean much when you’re not on a normal schedule), I finally got around to officially applying for the “Code Wrangler” position listed on the Automattic Jobs page. I didn’t hear anything back, and figured I wasn’t up to scratch. Chance was on my side though, because Matt was speaking at an upcoming MySQL meetup being held at CNet. I accosted him there and asked if he’d seen my application, which he apparently hadn’t. A few days later he got in touch with me and we worked out a contract agreement to do some test projects so that we could both see if I was a good fit for Automattic and vice versa.

That was in January. A few weeks ago I signed my full time contract, so now here I am, starting my first Monday as an official Automattician, and I couldn’t be happier. I’ve met a bunch of the people at the company and so far they are an incredibly smart, passionate and dedicated group of people. All of them.

Today I start with the customary 3 weeks of user support for WordPress.com that all employees start with. I’m guessing that by the end of the 3 weeks, I’ll  know the WP.com platform pretty intimately After that, I’ll probably continue working with the IntenseDebate guys on their impressive comment/reputation system and then we’ll see where things go from there.

You could say I’m excited.

In the “old days” (or in a lot of big corporates today), those support cases would have been handled behind a corporate “veil of secrecy”, tucked in a back end system somewhere, responded to by anonymous “Customer Service Representatives” via a generic email account like “support@intensedebate.com”. While we’re also making use of a generic email address, the similarities between our approach and that of big corporates ends there. End to end, the differences are pretty stark.

Plugin Release

Previously, companies may have tried to encode their plugins, or released them as some sort of binary so that they could control access to them and avoid people modifying them. When we released the 2.1 version of our plugin, we “checked it in” to a public-readable Subversion repository which then publishes to the WordPress Plugin Directory. That code (and all other code in the Plugin Directory) is GPL licensed and available for re-use/hacking/modification. People are welcome to read the code and see what we’re doing, point out where we could do things better, and ideally improve upon it themselves.

After we’ve uploaded the code, people will start getting notifications in their WordPress admin panel that there’s a new version available. To help explain what’s going on, we published a blog post announcing the new version, the new features etc.

Comment Support

Not that it’s a recommended channel for receiving support, but this is where we start really differing. People have posted a number of issues and questions about the plugin right there on the announcement post. We could moderate and remove those comments (or not allow them in the first place); instead, we work with our customers and try to address their problems right there an then. Michael and I have been bouncing around on that post answering questions and finding out more information from people so that we could fix some problems and get to 2.1.1. With email notifications coming in every time someone commented on that post, we’re able to quickly respond to people and help work out any issues they’re having.

Seeking Satisfaction

If people aren’t commenting on that post directly, they’re often over at the Intense Debate Get Satisfaction forum, a community-powered support system where a number of people are contributing. Again, this is a very public way of supporting users, and puts us out there in the limelight, warts n’ all. We answer what we can, assure people that we’re still working on things and that we’re making progress (which we are, a lot of it) and that we’ll get back to them as soon as there’s something to report. When there are updates, or when we need more information for troubleshooting, we post another message and get a stack of responses from eager users, hoping to have their problems solved. This is very real and very connected, and I truly believe that being open and transparent about problems that people are having and the way that we’re working with them helps not just that user, but others who may have similar problems.

Late-night Tweeting

For real-time feedback and almost-instant-messaging-immediacy, there’s Twitter. I know, with Oprah getting in on it now Twitter will probably implode soon, but in the meantime, I’ve found myself providing support direct to people via Twitter as well. One user wanted to use IntenseDebate, but found the comment importer wasn’t working. I replied that we were about to release a fix, and that user was then able to get up and running. This all happened, asynchronously, within about 4 hours of his first tweet.

In Your Facebook

Then for one that I really wasn’t expecting, someone contacted me through Facebook to try to sort out a problem. A user spotted me providing support via Get Satisfaction and other methods, and tracked me down on Facebook. In this case, it was someone that we were already working on a fix for, but it demonstrates just another way that people have been able to get in touch with us.

Better for Customers, Better for Us?

I guess the big question (or 2 questions really) this all poses is: Is this new way of providing support better for our customers? Is it better for us (as the company providing support)? Could it be better for everyone still?

The biggest problem I have (as someone providing support) is just trying to keep track of all these different “vectors”. I’ve identified 4 different support vectors above, and that’s not even including our normal support email/form, official Facebook group or VIP support channels. That makes at least 7 different vectors through which we might be providing support. It can get messy trying to keep up to date with them all and ensuring that you’ve replied to people where they’ve contacted you and in a timely fashion. Perhaps there’s an argument for traditional, centralized systems after all

There’s a new website online as of yesterday and it’s looking pretty spiffy. I’m looking forward to seeing Tim Ferriss and Tara Hunt speak in particular.

Oh, and I’m going to be helping out on the “Genius Bar” for a bit as well, so drop by and get some questions answered!

This will probably be a bit of a different experience for me than previous years because I’ve been doing some consulting work with Automattic, so I’ve met a lot of the crew now, and it’ll be good to see a lot of them again here.

It was specifically written for/tested on the as-yet-unreleased Prologue Projects theme from Automattic, so when that comes out, it’ll be ready to go. Check out all the details about Sparkplug.

As it turns out, it’s been quite a project. LiveJournal’s API is, shall we say, “challenging” to work with, and the sheer size of Guav’s journal (over 3,700 posts and nearly 200,000 comments) meant that I kept running into time, memory and database limits that would crash the importer. After a lot of back and forth with Guav though, I’m happy to present the new importer (find it under Tools > Import > LiveJournal), sporting the following features:

• Just enter your LiveJournal username and password and you’re ready to go
• Via the API, it connects directly to LiveJournal and imports all of your posts,
  • Posts marked as “Friends Only” are assigned a password within WordPress,
  • Posts marked as “Private (you only)” are marked as Private within WordPress, which means that only authors on your new blog can read them,
  • lj-cut tags are converted to the WordPress equivalent, the <! — more — > tag,
  • lj-user tags are converted to normal links, and have class=”lj-user” attached to them to make it easier to style them if you like,
  • Tags are imported properly,
  • If you closed the comments on a post in LiveJournal, then they’ll be closed in WordPress as well,
  • Lots of the “meta” information related to posts is also imported using WordPress’ Custom Fields feature. You could then use these values to reproduce some of LiveJournal’s functionality within your new theme if you like. The fields imported are:
    • If your post contains adult content (lj_adult_content),
    • Your current co-ordinates and location (lj_current_coords and lj_current_location),
    • Your current mood (lj_current_mood),
    • Current music (lj_current_music),
    • Your userpic keyword (lj_picture_keyword)
• Next up, all of your comments are also imported,
  • Threading is preserved, so replies to other comments show up successfully (provided you enable that feature in WordPress),
  • The “subject” of each comment is included as the first line of the comment itself, because WordPress doesn’t have a comment title/subject value,
  • LiveJournal users get links back to their LiveJournals,
  • Your own comments are linked to your WordPress account, and are linked back to your new WordPress blog,
  • Anonymous users are labeled as “Anonymous”,
  • “Screened” comments on LiveJournal are imported as “Unapproved” within WordPress, so you can decide what to do with them

So there you have it, a brand new, shiny LiveJournal importer. This should be bundled with the 2.8 release of WordPress (it’s available right now on WordPress.com), and will be available for everyone. As I mentioned, it’s been tested with one single, very large blog (and a few smaller test ones), but if you find anything wrong with it, please file a bug on the WordPress Trac!

Huge thanks again to Guav for helping with the testing of this thing (maybe now he can migrate over to WordPress as well)!