Google Analytics

Like other people I know, I have been testing Google Analytics. There are some good things about it, but overall I am not really impressed.

The Good:

Content Summary. Specifically the percentages that content get for a time range. I love easily seeing how traffic is growing or subsiding for individual (well, the top 5 anyway) articles. Hey! Recently my article traffic was up 50%! Instant, easy to read feedback like that is awesome.

Variable time range. I like being able to see data for time ranges other than a month (which is the standard for things like Webalizer). Google makes this simple to do.

Date Storage. Some free web site statistics programs only keep data for a certain amount of time, and only show you a limited range of that. For example, the free version of StatCounter only tracks 2 weeks. Analytics stores……. probably all information it has ever received, which really ties in with the variable time range above.

It IS powerful. If you have the time and desire, I am sure you can massage the data to give you tons of information (to bad I don’t care about most of it).

The Bad:

Does not integrate with other Google products. Google Sitemaps integration seems like a no-brainer, given that it is for related data. Google Maps for the map overlay would seem to make sense as well, so that I could actually zoom in on an area, rather than seeing a large grouping of dots along the east coast.

All the Ad related stuff. Ok, I understand that a lot of people want to track their ad revenue, $ index, whatever. But what about those who don’t? I personally find all the ad related stuff clutters the interface I am trying to use.

Unintuitive. The breakdown into Executive, Marker, and Webmaster sections makes finding things difficult. For a while, I couldn’t find a simple referring pages list. More recently I found it under Marketing Optimization -> Visitor Segment Performance -> Referring Source. I couldn’t figure out filtering for a while. Clicking a graphic to change it from exclude a filtered item, rather than filter by it didn’t seem obvious.

Flexible in some ways, obtuse in others. A lot of places, you can display up to 500 records. For the content summary, you only have the top 5. Sure, you can get most of the same information under Content Optimization -> Content Performance, but that section is missing the percentage changes over time (you know, what I thought was GOOD) that the summary has. Also, the referrer information only gives me the domain name, not which page the user came from.

The (Possibly) Ugly:

Google stores all this information, and uses it for their own purposes. ome individuals understandably have privacy concerns regarding this. As Ian said, it’s basically a toss up. Decide if its right for you.


For something free, Analytics is better than some packages. I personally feel that I am presented with way more information than I really want. For something more revenue related, your milage may very.

DevEast Slides

Apparently there are requests for slides and demo code from all trhe DevEast speakers. As such, I’ve taken the time to post my own here. I don’t know if anyone will find these useful on their own, but if anyone has any questions, feel free to ask.

“Halifax On Rails Slides”:

DevEast Aftermatch

Yesterday was the first DevEast conference. Kudos to Derek for putting together an interesting panel of speakers in such a short order of time, as well as bringing in at least 40 attendees. There really were some interesting talks. In particular, I enjoyed Mike Mullens talk about Next Generation Web Apps.

As for my own talk, well,  it could have been better. I tried to go for the live “wow” factor of doing some live code. I mean, if I could create a rails app from scratch in a short amount of time, that would be pretty awesome right? Of course, if I made a mistake somewhere, which, of course, is what happened.My fellow speakers later gave me a few tips:

  • Live code is a trade off between something you can depend on (pre-done code) and something more interactive and impressive to the attendees.
  • If you are going to do live code, you have to fill in the time you are coding with speech, otherwise you stop engaging the audience for a period of time, and risk losing them a bit.
  • Practice beforehand. The more comfortable you are, the less likely you are to screw something up.
  • If your live demo goes wrong, use the above practice code to get back on track. Kinda like those cooking shows where they make the batter, and then put it away and pull pre-made cookies out of the oven.

After the conference, a few of the speakers headed down to Rogue’s for some beer and food. We talked some shop, various stories were told, and Derek tried to get some sound bites for his podcast (I wonder how that turned out). I thought those guys were hilarious and was glad to have had the opportunity to meet them all.

All in all, it was a pretty fantastic time. Maybe I will ask to give a talk at next year’s DevEast and have things run a little smoother.

Finally Giving In

Over the last few years I have been asked to present something at various local conferences (mostly just CEOS). This has always ended up with me saying, “sorry, I don’t have the time”. Recently, I have come to the realization that I am likely going to always be “busy” with various other things. So I made a decision.

More recently, I have been asked to give a talk at DevEast. Rather than my traditional “sorry I don’t have time”, I decided to give in and accept. I am now going to be giving a talk about Ruby on Rails that will encompass a lot of the basics, as well as sharing some of my own experiences with it over the last year.

Win, lose, or draw, at least in a few days I will be able to say I’ve tried.

Moving On

So, I recently left my job at v1Labs. There are a number or reasons for my decision to move on, but in the end it boiled down to a feeling. I just didn’t feel that I was where I wanted/was supposed to be at this point in time. While the money WAS good, I am currently debt free and so decided to take a risk and go elsewhere. ’Elsewhere’, in this circumstance, ended up being Sampling Technologies, Inc., a position I was referred to by my old boss at Satlantic. They are a local startup that does marketing and data presentation for pharmaceutical companies. I think the work they are doing is fairly interesting, and the people here feel… passionate is how I would put it. People are here because they believe in what the company was doing, rather than just putting in the 9-5 and picking up their paycheck.

Right now, I am doing more general IT and the automation of backend tasks, along with some DB work (biggest DB I have worked with by far). The plan is for me to eventually move into more actual development (Java) as more and more background tasks become automated. Sure, I might be starting out at the bottom, but I am fairly confident that I will be able to work my way up.

A month and a half in, and I am not regretting it (though I do miss some of my coworkers from v1 at times). There is a lot of stuff to learn and do, and more importantly, a lot of DIFFERENT things to learn and do. I interact with more than just developers on a regular basis. I actually get to interact with customers. I love interacting with both of them, and at the end of the day I feel like I have solved problems for real people.

Behaviour Driven Development And rSpec

Last week, Dave Astels came into Halifax and gave a talk on Behaviour Driven Development (BDD) and rSpec (a BDD framework for Ruby). I thought it was quite the interesting talk, and that a lot of things seemed to make sense.

I took some rough notes, and thought I would write a bit about what I managed to take away from the talk.The premise behind BDD (as I understand it) is that many users are only getting part way up the Test Driven Development ladder and then getting stuck and not being able to leverage the full set of tools and techniques they have at their disposal. Some of this has to do with terminology (ala the Sapir-Whorf hypothesis) and not being able to grasp the concepts as they are presented. For example, TDD has unit tests, but what exactly is a unit? What exactly are tests supposed to test?

TDD emphasizes checking state at various points in execution. BDD, as the name would imply, defines tests in terms of behaviour.

The part of the talk that I enjoyed most was the fact that BDD focuses on human readability. So instead of something like:

def test_truth

assert_kind_of Group, @group


you get:

specify “is really a group” do

@group.should_be_an_instance_of Group


Note: the above examples are identical in functionality (in fact, Dave pointed out that they made a point to provide all the same functionality as the Ruby TDD framework, so people that preferred BDD would have a clear migration path) but differ in how they are presented.

If you are interested in a more in depth description, you can check out an earlier version of the talk on Google Video or check out Dave’s site

Formats, Microformats, and Exporting, Oh My!

The other day, I came across this Microformat Bookmarklet, designed to extract hCard and hCalendar markup from a website and into a format that people can use. ‘Hey’, I though, ‘that’s pretty cool, why don’t I use those in places’.

It was the motivator that finally got me to fix a long open feature request for TigerEvents. Now, the event view has hCalendar markup for those who care.

Once that was done, I thought, since I had already done hCal, why not figure out iCal export? Easier than I would have thought, thanks to the iCalendar gem and the send_data method. Now people can grab iCalender export by individual event, group, or category. People should even be able to subscribe to iCal files and have events automatically shown in their calendar app (if said app has this feature). Only future events are shown, however, in order to cut down on file size.

Finally, while I was working on the above, a friend stopped by, saw what I was doing and commented, ‘you know… it would be awesome if I could click on a link and have the event loaded into my google calendar’. So, quickly scouring the web came up with Google Calendar event publishing guide and after a few minutes, I managed to add that functionality as well.

Now for RSS feeds…

Back At It

Some people might have noticed that the site has gotten a makeover. This visual overhaul was performed by the talented Andrew Shouldice. This overhaul has garnered a lot of positive feedback so far, and it is my hope that prettier site = more visited site.

Besides some obvious visual enhancements, some long standing backend items have made their way into the release. Notably, tags have replaced categories, meaning that individuals no longer have to scroll through a multitude of categories to select the one wanted. Additionally, there are a few more options for finding events, notably searching, and browsing by group.

There are still a few things that could be done better, notably with how categories are browsed (alphabetical as opposed to by order perhaps), how items are displayed on the front page (a month’s worth of events is hard to scroll through, though that is a sign that it is being used more).

All in all, this transition has made me want to do even more work on it a bit more often. As always, any comments and criticizms are more than welcome.

Testing….. Testing…..

Update: Apparently, despite my usage of FeedBurner, chokes on my site being back up. Apologies to everyone this effects.

So…… a while back, I switched my friend Jon over to Typo, on a new server I am splitting with some friends. It was always my intention to switch my own instance over at some point, but it usually came down to “If it ain’t broke, don’t fix it”.

Well, it turns out that I recently DID break things, since Typo trunk is labeled ‘unstable’ and I didn’t pay attention to this fact when updating it. Ooops. So, I finally had the incentive to move things over and accomplish a number of goals.

  1. Renumbering entries so I could properly redirect my old WordPress URLs to the new Typo entries (I had to hack away at the Typo => WordPress script to not change the IDs)
  2. Write the actual mod_rewrite rule to properly do the above1
  3. Set up proxying using Apache and Mongrel, as opposed to Lighttpd and FastCGI (I haven’t had any complaints so far).

Everything seems ok so far. I might have lost a few comments, and a few other things I have done (I remember trimming down the categories at some point), but hey, those are small items in the grand scheme of things that I can fix up at my leisure.

The rewrite condition, for those interested is:
RewriteCond %{QUERY_STRING} p=([^&;]+)

RewriteRule ^/$ http://yourdomainhere/articles/read/%1? [R=301,L]

Sneaking Ruby Into The System

Many of you may know of my love for the Ruby language. Used for most of my own projects and quick scripts, but have never been able to use it in any of my paid work. Until now.

It started a few weeks ago with a script I wanted to write. As I am the ‘translator guy’ at work, from time to time I need to convert the XML files that store the English text to something that a non-technical translator can easily read (I thought the XML was readable, but apparently I need to hand over Excel spreadsheets). As Ruby has nice XML library included, I just quickly whipped something up, and away I went. Never intending this to be anything more than a tool for myself and knowing my boss wouldn’t care as long as it got done without me having to spend a few hours, it seemed like the thing to do at the time.

Fast forward another two weeks. I overheard a few of my coworkers talking about how they can’t manipulate XML files in Auto-it, which they were using to cover some deficiencies in another build tool we were using called FinalBuilder. They started talking about either writing their own XML parser, or using yet another tool/language to do what they wanted.A few of my coworks obviously didn’t like either idea. I mean, sure it was a solution, but it wasn’t an ideal solution. None of us liked the thought of debugging build/test/release scripts cobbled together from 3 different programs/languages. Some of us thought that if we were going to take the time to do something like write our own XML parser, we might as well spend the time to do something even smarter, like rewrite all our scripts in a single language. This would have several advantages, including things being uniform (1 language vs 3 helps there) and making it easy to track changes in svn (FinalBuilder has binary files, which caused problems when multiple people made enhancements).

So a number of suggestions were made, including batch files (ugh) and php. I obviously suggested Ruby, pointing out its portability (as opposed to Windows only solutions), readability, and the existence of desired functionality (eg. XML Parsing). The individual who was going to write the scripts had never used Ruby before, and so wanted to know more before making a decision. Coincidentally, I had a copy of Enterprise Integration With Ruby sitting on my desk,and was able to toss it over so he could take a look at the syntax (bonus points for its section on XML parsing). I also pointed out the ruby-doc site and pointed out rake.

Now, we have all of our build scripts written in rake format, and I reworked my translation scripts slightly to be rake tasks as well. At the moment we are working out some kinks in another series of scripts a coworker has written for creating packages for our clients, and we won’t have to waste time making small tweaks to packages manually.

« Previous PageNext Page »