Here’s a simple process to “publish” a local HTML build on a Mac.  This can be useful for quick demos of work to other team members.  Or (this is how I used it yesterday), viewing work in virtual machines for Internet Explorer testing.

1. Add this somewhere in your shell profile.  For me, this is at ~/.profile.  Garrett supplied this tip to us.

alias server='open http://localhost:8000 && python -m SimpleHTTPServer'

2. Open up a new terminal window and change directory to the folder containing the work you want to stage.  Run the following to create a simple web server.

server

3. Now, you can go to http://localhost:8000 in a web browser to view the directory you launched the server from.

4. Install the localtunnel gem following the instructions on their site.  It’s pretty simple.

5. Stage your build using localtunnel by running (assuming you have a public key generated in the standard location) the following.

localtunnel -k ~/.ssh/id_rsa.pub 8000

6. Now you’ll be able to view your work at http://****.localtunnel.com.  Badical.

On a project we have in development now, we’re deploying a site that must work across mobile devices.  Not just iPhone, but Android, Nokia, Blackberry, and Palm.  Rather than purchasing a bunch of test devices, you can install emulators for each platform and then run the phone’s web browser.  Here’s some places to look and some instructions about how to build up your own testing suite.  These are instructions are for Mac.  Except for where they’re not.

On a project we’re working on now, we need to place “pins” on a map. There are some advantages for us not implementing the map with Flash. Namely, the project has a Facebook app component and Facebook requires users to click to activate Flash on profile tabs. I was curious to see how many pins I could instantiate in the DOM before there was noticeable chug. I made a test script that creates a bunch of img elements in the DOM. You can try it out here: DOM Capacity Test.

Through some not very scientific testing, I found that 100-300 DOM elements is my sweet spot (though IE really needs it towards the low end of that range). Any higher and the browser noticeably chugs during rendering. I was surprised that once rendered, the browser didn’t seem to perform any worse during scrolling or resizing. Another thing I noticed was that Firefox visually added each element to the page iteratively (taking much more time), whereas all other browsers immediately showed all of them after the initial CPU churn.

Here’s what I did to get MAMP Pro working so I could test the HTTPS pages of the site I’m working on.

1) Follow these instructions from Rocket Theme to the letter.  I didn’t need to deal with any of the “Possible Issues” section.
2) Go into “/Applications/MAMP/conf/apache/ssl.conf” and add a new vhost within the <IfDefine> blocks at the end of the page.  This vhost will mirror the settings of the vhost you would have already setup in MAMP:

<VirtualHost test.dev:443>
DocumentRoot "/Path/to/document/root"
ServerName test.dev
SSLEngine on
SSLCertificateFile /Applications/MAMP/conf/apache/ssl_crt/server.crt
SSLCertificateKeyFile /Applications/MAMP/conf/apache/ssl_key/server.key
<Directory "/Path/to/document/root">
Options All
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

3) That’s really it.  Restart MAMP and you’re good to go.

Thanks Greg Patterson of ground(ctrl) for putting this together.  Game time in a couple hours!

Update:

BKWLD Wins!  It was a great day and a close game.  Ground(ctrl) led with an early lead that they kept through most of the innings but BKWLD gradually wore away at it, eking out a victory in the last inning thanks to Shelby.

I tried out some of the newly announced Facebook features today, specifically the Open Graph markup and the Like social plugin.  They were both technically simple to deploy, as promised.  You have less control over the appearance of the Like button than I’d like.  For instance, they don’t have an option to ONLY display the like button without a list of total likes.  You can work around this by reducing the width of the iframe, but it was an unexpected restriction.  For us, the goal was to provide a handy way to Like us on Facebook; we don’t care to give screen real estate to showing your friends who have also Liked us (for the majority of visitors, I expect there would be none).

I initially went about including the Like button the wrong way.  In the demos they showed at the F8, it appeared that they would expect each deep linked article page in a blog to have a unique Like button, like how CNN is implemented.  So I did this:

However, when you click Like, it adds a link in your profile section on Facebook for that specific deep link.  For example, check out the article link added here from CNN:

You could imagine that very quickly this area would be cluttered with all the articles a person had liked on news sites and blogs.  Then I noticed this suggestion from the Open Graph Best Practices:

Make only real-life things into objects. Users don’t want news articles and other transient content as objects on their profile.

This advice makes sense, though it’s inconsistent that Facebook would tout their partner (CNN) whose implementation contradicts this.  Thus, I moved the Like button into the footer, making it site wide, and added a Digg link in it’s place.

Ideally, users clicking the Like button would be added to the BKWLD Facebook page (we previously had a group, which we’re deprecating).  So far, I’m not seeing this happen; users who Like our Facebook page and users who Like us on the BKWLD site appear to be dropped into separate buckets.  The Social Graph markup doesn’t have a field to specifically relate the object (our site) with a Facebook Page.  I assume that Facebook uses some black magic to join the references to BKWLD in the Social Graph metas with the BKWLD references in our Facebook Page.  Possibly this isn’t working because our Facebook page is so new.  Or possibly something got confused during my initial implementation that was per blog article.  It also doesn’t appear that the “fb:admins” meta tag is having any effect.  I’m curious to see if this generated page will be automatically merged into the official BKWLD Facebook Page in the next few days.  Or if a person Likes a site on the Facebook site and that site has Open Graph markup on the home page, does Facebook read it and pull that info in?

In sum, I think the social plugin and Open Graph standard are pretty great in terms of functionality for users that can be added with minimal effort by developers.  I hope some clarification comes from Facebook about how (or if) merging works between different pages.

We’re big Gowalla users at BKWLD, thanks to Aaron getting us started on it.  We’re also big on going to lunch together.  And our location right near Pike Place Market gives us a lot of options.  Now you can follow along at home!

One of the goals BKWLD planned for ourselves this year was to attend more events and conferences.  More accurately: to attend events at all.  In previous years we’ve balked at the cost of most conferences and the expected return we’d get on that money and time.  We decided to give it a chance with the SoDA Click New York event last year, to see whether our assumptions had been valid.  It was a good experience, largely because it got us out of the day to day and thinking bigger picture.  Thus this year’s initiative was born.

We went to StackOverflow’s Dev Days earlier this year.  One big plus of it was it’s cost: $100 a head.  The speakers gave us an overview of technologies that we don’t use regularly (there wasn’t a lot of LAMP love) and the FogBuzz keynote made me realize that some of the issues we’ve faced in the growth of ground(ctrl) and Elastic aren’t unique to us.  Which brings us to SXSW, which 6 of us just back from.

We brought a pretty big team to SXSW and it works there since the conference is so multidisciplinary.  During the day we split up often, so that people could meet with other folks who were there or attend panels specific to their interests.  As anyone who is our friend on Gowalla will attest (sorry for all the spam), we “checked in” to let each other know where we were.  Some of the panels I enjoyed the most were on iPhone UI design, new methods of tactile interaction, and the marketing strategy behind the Bing launch.  I was able to meet some the Appcelerator dev’s at the meetup they held, which was a great opportunity for me to ask them questions.  During the night we caroused between the free parties that different companies held (Pure Volume, Gowalla, etc).

So will we go again? I think so.  In talking with our crew, it sounds like we unanimously agreed that the panels lacked enough depth.  Many were overviews or stated the obvious too much.  There wasn’t enough detail and brainy insight.  That being said, there was usually a tidbit or two I picked up from the panels I attended.  And, there was a lot of value in getting time with coworkers in a stress free environment.  As opposed to doing some extracurricular activity (like our snowboard trip in December), the framework of a conference focused our conversation on work themed stuff, spurning creativity and new ideas.  I think this last point is what would have me taking us back again.  While we could plan a fun activity locally for a much lower cost, having a structure based on learning (even if it fell short) is special about going to a conference and led to growth outside of the sessions.

Next up for us is An Event Apart in Seattle.  If your company is thinking of going to industry events and you want to chat about whether it’s worth the cost or not (I’m still chewing on this myself), hit me up in the comments.

WebGrind is a great tool for analyzing your PHP app and finding where slow down is occurring.  As stated on the Google Code site for the project, it is a “ Xdebug profiling web frontend.”  Here’s the steps I took getting it working in MAMP.

Install xdebug (taken from debuggable):

1. Download the latest Xdebug binaries for your OS from Komodo.  They will be labeled as “PHP Remote Debugging” for Mac OS X.  When you unzip it, you’ll see the xedbug.so file.
2. Copy the xdebug.so for your PHP version to your extensions directory (/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so)
3. Find your php.ini file (Applications/MAMP/conf/php5/php.ini)
4. Add the following lines to your php.ini configuration (MAMP):

[xdebug]
zend_extension=/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so

Enable xdebug
Note, you don’t want to do this in a production environment.  Add the following to your php.ini file:

xdebug.profiler_enable = 1

Install webgrind (from the install wiki)

1. Download webgrind
2. Extract to a directory in the web root
3. Browse pages of your site
4. View the directory webgrind lives in.

That’s it!  There is some useful additional ini settings I found in this blog post:

# Set the filenames generated by xdebug to use REQUEST_URI instead
# of the apache process number
# so all requests to the same page end up in the same file.
xdebug.profiler_output_name = cachegrind.out.%R
# Set xdebug to append data to files instead of overwriting,
# this means you can view aggregate
# function calls over multiple requests.
xdebug.profiler_append = TRUE

I’ve already found some major instances of slowdown that can be cleaned up in the application I’m testing.