Slingshot around the sun would be faster

by Thomas Aylott Tue, 10 Apr 2007 03:17:00 GMT

Ok, so you all now know that I’m in on the Slingshot beta now. They have asked me to be candid and blog about my experiences with developing for Slingshot, good or bad, in “real time.” So that is what I am doing…

Joyent Sleeping?

I finally had the conference call with one of the developers at Magnetk and David Young founder and CEO of Joyent last Thursday. He originally confirmed the call for Wednesday. I emailed a number of times but didn’t hear anything until Thursday morning when they called. Five minutes early or 1,435 minutes late, you decide ;)

And then I was promised that I’d “revieve the code” by today (monday) and be able to start hacking around with Slingshot. Shockingly enough, I haven’t heard a peep from them.

Sofar, I’d say we’re off to a somewhat shakey start. Three weeks before the official launch of Slingshot and I don’t have access to the code or documentation.


I forget, is PST 3 hours or 27 hours behind EST?

I’m not an impatient person by any stretch. I’m just used to people doing what they say. Why would you voluntarilly commit to a time unless you’re absolutely certain that you can exceed it?

Slingshot is a real risk on their part. If they don’t handle this properly they run the risk of alienating their developers. And if there aren’t any people developing on their platform then it will shrivel up and die.

Obviously I don’t think that being a wee bit late a few times in a row is going to jinx you from the get go, but it is starting them out in the red. They’re already behind in my book. Time is money, baby! If you’re going to waste my time then I might think twice about setting myself up for it again.

You expect more from a for-profit business

I’ve been spending more and more of my time on open-source or open-standard1 software over the last few years. In that environment you come to expect things to be late and have vast expanses of no forward development, bad communication with the development team, etc… It’s just the nature of the beast.

But when you try and make a closed-source for-profit business, I’m going to expect a little more out of you. You should provide your customers with some way to contact you. You should respond when they do contact you. You should be all in all a bit more professional.

Lately I’ve actually seen the exact opposite to be true.

Open souce developers all seem to be hanging out in IRC and in mailing lists and blogs and on IM and actually reading and responding to their email. Not to mention that if you ever have any problems with their code or desperately need to know how something is implemented you just have to pop open their source code and read or edit the stuff directly, skipping out the middle-man altogether.

Ok, now I’m just ranting like a maniac

Ok, that’s all extremely unfair to the poor Joyent Slingshot peoples here. They aren’t exactly Adobe or anything. And Slingshot isn’t exactly Adobe Apollo.

I’m sure they’ll get something to me tomorrow. And I’m sure it’ll be way less than 2000 minutes late. To be completely fair, it’ll still be Monday for another few hours. The last thing they need is my abuse :P They did have me agree to blog in “real time” though, so it’s their own fault.

Oi, i need some sleep.

Please forgive the rant my friendly internet peoples. Everything is all smiles and joy and the raindrops shall skitter away as does the dew when once it falls upon the stillness of the pond, or something like that…

UPDATE

It’s now 10:45pm EST Tuesday night… I haven’t hard a peep out of them since last Thursday. But I’m sure they’ll email me, any minute… now ... or not.

Apollo, here I come!

UPDATE2

Wednesday at ~1:30pm EST they emailed me back…

We found a big bug in unsync. We should have it fixed today.

Well, that’s probly good. Don’t want to have buggy stuff. I just wish they’d emailed me on monday to let me know I wasn’t going to get it that day.

UPDATE3

I finally got access to Slingshot today, Friday April 13 2007. The Windows version isn’t ready yet.

1 TextMate bundles are an “open-standard.” While the primary application that uses the bundles is for-profit and closed-source, the bundle file formats themselves are open and anyone can use them. See, for example The Power of Textmate on Windows

Posted in Rant, Slingshot, Work | 1 comment

Web Development Environment and Workflow

by Thomas Aylott Fri, 30 Mar 2007 16:51:00 GMT

Over the years I have worked with a bunch of teams and solo. I usually go with the flow as far as the group workflow. I have had to roll my own subversion workflow in the dark days before it was a normal and expected thing to do.

Here is a rundown of the major types of workflows I have used…

My Ideal Web Development Environment

  • Subversion Repository:
    • Accessible via https
    • Trunk branch for new features
    • Stable branch for production and quick patches
  • Development:
    1. Local testing/development environment
      • Local working copy of trunk and stable
      • Local server, database, etc…
        • for both your trunk and stable checkouts
      • A complete local environment for development and testing
        • It should also have no internet dependancies so that you can still keep working if you lose internet or on your laptop on the road, etc…
    2. Edit locally
    3. Test locally
    4. Commit changes to trunk
  • Deploy:
    1. Merge trunk to stable
    2. Deploy stable to staging server
      • Commit any necessary changes to stable from your local
    3. Deploy stable to production
  • Bug fixes:
    1. Make minor tweaks to stable checkout
    2. Test locally
    3. Commit changes to stable
    4. Deploy stable to production

For environments where you can’t test locally and are the only person with access to the testing server

  • Subversion Repository
    • Trunk
    • Stable
  • Development:
    1. Local working copy
      • A local checkout of trunk
    2. Edit locally
    3. Upload changes to testing server and test
    4. Commit from local working copy
  • Deploy:
    1. Merge trunk to stable
    2. Deploy stable to testing server for final test
    3. Deploy stable to production
  • This is a slow and annoying way to work!

UPDATE: Rob McBroom has come up with what looks like a really handy way to use TextMate to work with remote projects.

The two commands are “Get Remote Project” and “Upload Project Changes”. ... They essentially save all files and call rsync - au on your directory in different directions.

For environments where you can’t test locally and share a single testing server with other developers.

  • Subversion Repository
    • Trunk
    • Stable
  • Development:
    1. Local working copy
    2. Edit local working copy
    3. Can’t test before committing
    4. Commit from local working copy
    5. SVN update testing server and test
  • Deploy:
    1. Merge trunk to stable
    2. Deploy stable to testing server for final test
    3. Deploy stable to production
  • This is a horrible way to have to work!

With this workflow you have to commit extremely minor changes before you can even test them.

It’s a massive waste of time to commit every single minor change before you can even test it. But if you don’t have your own dedicated testing environment then you just have to commit all changes before you can test them. Avoid this setup!

Personally, I’d really rather not work on a project unless I can test all my changes quickly and easily. My time and my Clients money is valuable.

In the past, I have worked remotely on projects that couldn’t be tested locally, but I had my own dedicated testing environment on the staging server. I would prefer not to have to ever do that again. Uploading changes before you can test them is just hideously slow.

I will make extremely minor changes remotely if the cost of setting up the local environment is higher than the potential that making a bad edit will trash the production server. But, usually those changes are just HTML, JavaScript and CSS. And all that stuff is really easy to test before committing.

The CrazyEgg Development Environment

  • Both developers work remotely.
  • This is all Rails stuff with some secret sauce.
  • We use Capistrano to deploy.
  • We have a bunch of custom scripts and stuff
    to check server status and stuff like that.
  1. Local developers each have a complete local testing environment.
  2. We make changes locally, test locally and commit changes to the trunk branch of our subversion.
  3. When we have made all of the changes necessary to make a deploy,
    we then merge trunk to stable and deploy to our staging server.
  4. We test the changes on the staging server
    and then make any changes necessary and commit to stable.
  5. We then deploy the stable checkout to our production servers.

Quick bug fixes are handled on the stable branch. This helps keep the unstable feature development and the quick fix development as separate workflows.

I do occasionally skip the whole staging and deploying thing for very small changes that don’t require a full deploy or restarting any processes or anything. Mostly just CSS and JavaScript changes. Then you can just scp them to production and restart your processes if necessary.

John Butler created a system that allows us to deploy without having to shut down the system now, so that helps.

The sixteenColors Development Environment

  1. Developers have local testing environments
  2. When we make enough good changes we
  3. commit to trunk from our local and
  4. deploy trunk to production

This is the secret alpha version I’m talking about. The current version of the website was developed by lordscarlet a long time ago in ASP.NET. The alpha is juts a super-tiny webapp at the moment. There’s no need to waste the few hours a month we have to work on it with a verbose and tedious workflow.

My old offsite totalTrak.net Development Environment

Since this is an ASP.NET application and I was developing it on a PPC PowerBook, I had no easy way to setup a local testing server. I was also the only person working on the project.

  1. I had a local mirror of production
    • A checkout of the trunk working copy
      • You should always have separate stable and trunk branches.
      • I didn’t bother with it on this project since the app was extremely stable (therefore no need to make quick patches on stable) and I was the only developer working on it.
        Excuses excuses…
  2. All changes made locally
  3. Tested HTML, CSS & JavaScript locally
  4. Tested T-SQL in TextMate locally
    • I hacked together a crazy system to connect to their SQL Server
      • It involved some crazy unixy shell stuff with an SSH Tunnel to their SQL Server ports via their MacMini blog server
  5. Upload the changes to the testing server for testing
    • I used Transmit to manage the mirroring.
    • I also used the TextMate Transmit bundle to upload files from my working copy to the testing server
  6. Commit changes from local
  7. SVN update testing server for final test before deploy
    • SSH tunneling to mount their SMB shares locally
      • This was slow, but it worked for subversion operations.
      • TextMate totally chokes on a mounted share normally,
        but over an SSH tunnel? Way too slow.
  8. SVN update production via SSH
    • We made sure that the .svn folders weren’t served.
    • Normally, you should always make your production server use a checkout rather than a working copy.
      • This was all very pre-Capistrano

My really old onsite Development Environment

  1. Local machine had no project files
  2. Shared development server
    • Each developer had a separate set of working files
      on a single shared development box
    • We all shared a single development SQL Server
      • We occasionally made duplicates of tables to test out some crazy operations.
  3. I made changes to the files over a SMB share
  4. I committed changes to trunk from the share
  5. deployed by svn upping the production working copy

Way way way way back in the day…

Back in the dark Dreamweaver days
before I discovered subversion.

  1. We all shared a single development server
  2. We made changes to the files over a SMB share
  3. We then deployed by replacing the files on production with the development files
  4. Then we franticly checked everything to make sure it all still worked

I sure am glad we have some better workflows today. Yeesh

What is your workflow?

How do you guys work? What kind of development do you do? There are LaTeX guys and Ruby guys and ASP guys out there. What kinds of workflows are standard for your environments? Will you put up with having to upload to a testing server to test every single minor change? Or do you demand to have a local development environment that is just like your production environment?

Posted in TextMate, Work, Tip, Workflow | 4 comments

Announcing CrazyEgg 1.0

by Thomas Aylott Wed, 23 Aug 2006 16:26:00 GMT

This is the secret-ish project I’ve been working on for quite a while now.

As you can see from the CrazyEgg about page, the original prototype was developed by John Carlin. After that there have only been two developers. Me and John Butler.

I must say, John Butler is about the greatest developer I’ve ever met. But, I managed to get a lot of good stuff into CrazyEgg too. ;)

Basically it tracks how people use your website and then you can view reports about it.

Go check out the DEMO

Specific reporting features are currently:

  1. Overlay mode
    1. Overlay mode shows little markers, panels and outlines next to every clicked thing with the number of clicks and the percentage of total clicks that represents.
  2. List mode
    1. List mode show a list of clicked items, whether they could be found in the report or not. Align with the number of clicks, percentage and type of element.
  3. Heatmap mode
    1. Heatmap mode shows an overlay on top of your page with hot spots for where people clicked.

Yes, those screenshots are from WordPress.com

We have a whole bunch of stuff up our sleeves. If you have any ideas of what you’d want us to add, post a comment.

Welp, back to working on the crazy updates. :D

Posted in Work, Ruby on Rails | 67 comments | no trackbacks