cameronyule.com

After having one of the most frustrating days in recent memory, I’ve had to leave work with a problem (actually, several closely related problems) unresolved as my stress levels were making it impossible to either concentrate or think rationally.

In any job where you’re essentially solving problems for a living you’re going to have issues that take longer than you think they should - that I understand and accept. The hard part for me is trying to stop thinking about it (on the train home I had my notepad and pen out, scribbling notes about the problem in case they come in useful tomorrow).

Let’s hope a movie (Aliens), a cold beer and an early night do the trick.

I read an article recently on the Blue Flavor blog, Who Owns JavaScript?, which was debating where the responsibility for coding JavaScript lies within an agency. The two options they gave were “designer” or “developer” and here’s their descriptions of the two roles;

…“designers” do the client-side things (HTML, CSS, Javascript, Flash, etc.), and “developers” do the server-side things (PHP, Python, Ruby, Java, .NET, etc.). 

After I’d recovered from the shock of imagining a designer being asked to code some nice object–oriented JavaScript or some heavy–duty AS3, I realised they were in fact talking about a web designer. An important distinction for sure.

That in itself still raises further questions for me though. In my experience from the three agencies I’ve worked at so far (one purely digital, one digital/print and now print/digital), a simplified process of building a web site runs as such;

1. Designer gets spec for website, beings planning.
2. Designer produces initial comps for client.
3. Designer incorporates client feedback into design (repeat as required).
4. Designer passes final designs to Developer.
5. Developer looks at final designs, beings planning (may feedback to Designer).
6. Developer creates HTML.
7. Developer creates CSS (may occur simultaneously with 6).
8. Developer creates JS/Flash.
9. Developer cross-browser/QA tests.

Even taking into consideration that this is a very simplified list and one intended to make a point, the dividing line there should be immediately obvious; the designer designs, the developer does the build.

Is it just me, or does this way of working make sense as opposed to blurring the boundaries?

Some great news coming from the Subversion developers recently, announcing that merge tracking will be included in the upcoming 1.5 release. From the announcement;

Merge-tracking is when your version control system keeps track of how lines of development (branches) diverge and re-form together.

…

While Subversion 1.5 doesn’t make merging as easy as a system like Git or Mercurial, it certainly solves common points of pain. 

It’s no surprise that they mention Git, as it’s starting to gain some serious traction (notably within the Ruby/Rails community)  thanks to it’s superior branch handling.

I haven’t been entirely convinced that the switch to Git would make sense for me. Branching an entire project is something I need to do only occasionally (one of those times being this week, coincidentally) and the other benefits Git offers, while appealing, aren’t enough to make me think I can’t live without it.

Now with SVN improving one of the two flaws I think it has (the other being it leaving .svn directories littered throughout your project, something which I believe is also going to be fixed), I think I may well stick with what I know for the time being!