I’ve been using Google Analytics for quite some time. I do love it. It’s easy, it’s pretty, it’s addicting to look at the charts and graphs. Lately I’ve been trying out an alternative to Google Analytics, Piwik.

I’m not going to list a bunch of bullet points with features of both compared. I am, however, going to tell you my experiences with both. I started with Google Analytics. The setup and install is so easy, a blind ape could do it. Once tracking, the graphs, maps, numbers are all easy to understand. You can compare your site to others like it, and you can set up different segments of visitors and display the graphs according to your segments.

Google Analytics has been fun and easy. I do have some hangups about it. Although there is no cost, Google owns your data. They are giving you a service, you are selling them your data in return. They know about your visitors and can track them based on their interest in various pages of yours. They can do whatever they want with this information. For some people, this is fine. I personally don’t give much of a rat’s ass what Google thinks they know about me. For others, this is a privacy issue.

I also ran into some limitations with Google Analytics. It doesn’t track downloads very easily, and getting any sort of report that it doesn’t already give you is impossible because you only get what you see.

I decided to try Piwik. It’s open source, they advertise themselves as an alternative to GA, and you own all of your data. I threw up a new site on NearlyFreeSpeech.net, installed Piwik (literally a 5 min. install, just as they say), and started playing with it. A lot of the graphs are the same, the dashboard is completely customizable and is not jenky at all. After tracking some sites with it, I’m convinced it’s actually more accurate than Google. It picks up more visitors and keywords from search engines.

So I’ve been using Piwik regularly for about 3 or 4 months. There are some things I miss. Goals in Piwik do not have the awesome funnel that GA does. Not even close. The goals are pretty stupid, honestly, and all the ones I track are done manually through javascript. It’s nice to be able to track them, but it’s something I can get through any of my apps anyway. So from what I’ve noticed, Piwik is missing the funnel view (although they are working on it), and it’s missing an IP filter: half the visits are from me sometimes, and it’d be nice to be able to browse my own apps without having to worry about messing up the analytics.

Aside from those two points, Piwik is the winner for me. I really never actually check Google Analytics anymore. Piwik really has stepped up and provided a service that’s comparable in features to GA, but free as free for me to use it without having to give away info about my awesome users. I would definitely urge anyone who likes Google Analytics to check out Piwik. The best part is, they’re actively developing it and there more and more features to look forward to as new releases come out.

This is a response to a previous post I made about how HTTP authentication is the reason why I’m not building a REST API. After doing a bit more research, I’ve decided that REST is many times better than RPC. Reviewing a lot more information on REST revealed that HTTP authentication is not at all required…but instead a suggested method of authentication only because it’s already built. In fact, any authentication scheme could be cooked up and used. I’ve currently got my eye on OAuth.

That being said, our internal framework is now being updated to support routing different requests to different controllers/actions based on the request method. For instance, I can now route a “POST /events” to /events/add_event, or “GET /events” to /events/get_events. That just about seals the deal on RESTifying the framework, except that I’ll also have to come up with a scheme to implement status headers in the response, either automatically or semi-manually.

There will be no need to do a sort-of REST implementation on the www site. All information needed can be gathered through the API. Gnar, duude.

In conclusion, I’ve decided to go with REST after all. It’s a great architecture, and the best part is that it’s already built for me. Wicked.

UPDATE: please read my followup

So I’ve been in the process of converting beeets.com, which is currently a “website” with integrated back-end code, to a front-end with a back-end API. It’s been an interesting journey, and has spawned a lot of thought recently about how to implement the API.

Obviously, whenever someone says web API, REST is the first this that comes to mind. “Let’s make it a REST API!” From what I’ve been reading about REST (I tend not to use terminology without knowing what the hell it means) many “REST” services aren’t very RESTful (“How I Explained REST to My Wife” – great intro to REST). In fact, the way I’ve implemented the beeets API happens to be closer to RPC. After doing my fair share of research, I’m ok with this.

REST seems like an excellent architecture. In fact, one of the world’s largest global networks is built on that architecture. It works well for what it does…but what the hell does it do? From what I’ve been reading, it gives “resources” (pieces of information) a single location to be accessed/updated/created/deleted. At least this is how it works on the web.

RPC is basically a function or method that runs on a remote machine that can be called by a local machine, completely transparent to the local code. Most RPC implementations work on their own conventions, separately from the beautiful architecture which is REST…what is otherwise known as reinventing the wheel.

So why am I okay with using RPC in the beeets API? The main reason is that RESTful authentication is total junk. It’s great for server-server communication, but NOT so great for user interactions. Users are used to seeing pretty login boxes with “forgot your password? reset it, moron!” or “create an account!” links. Popping up an HTTP login screen is not cool. It’s not cool. This is my main problem with REST.

That being said, if you cannot authenticate REST, then using the built-in methods POST, PUT, DELETE are more or less worthless, unless you have a completely public set of information that anybody can add to, change, or remove…in which case, REST would kick ass.

In light of REST lacking in this area, I think the following makes sense. Create an RPC API that authenticated servers can call to get/create/update/delete information. IPhones, Facebook apps, etc can use this RPC for interacting with the actual dataset. Then on the www front-end, create a REST system that only implements GET.

So I could go to beeets.com/events/123-native-american-slaughter-celebration and get an HTML page with links I can click, an awesome layout, etc. I could go to beeets.com/events/123-native-american-slaughter-celebration.json and get a JSON representation of that event, with URLs to other pages which could be JSON-encoded if need be.

In other words, create a read-only RESTful service on top of the www site, and use an RPC for create/update/delete interactions with the dataset. The already-public information is freely accessibly, without any sort of authentication, so any person or system that cares to consume it can do so. This way you’re still mapping a resource to a location, and providing multiple consumption formats for said resource.

If there is any other way to authenticate users against a RESTful system without an HTTP login, and while being able to control the actual login/registration flow and layout, PLEASE let me know!

So after reading a very good comparison between the two frameworks, I have to say I feel good about my decision to use Mootools in pretty much all of the sites I build. This isn’t because of some nebulous reasoning about Mootools being better than jQuery, but the facts are

• They both do different things, and do them very well
• They intersect in some places (mainly DOM parsing)
• They both have their uses, pros, and cons

I was considering looking into switching beeets.com to use jQuery, but wanted to do some research beforehand. I’m glad I did.

It seems that jQuery is popular because it removes the hassle of doing everyday Javascript chores. Quite frankly, I’ve known Javascript for quite some time, and don’t mind getting my hands dirty in it. So using a framework that abstracts that out and creates what seems like (from reading the syntax) a whole new language makes me groan.

Mootools seems to better extend Javascript itself, and provides the tools to extend it even more. So if you already know JS fairly well, you can look at Mootools code and still tell what’s going on even if you only have an extremely limited knowledge of Mootools. It also implements some great features that allow you to reuse code extremely intelligently. So intelligently, in fact, that in much of the code on beeets.com (JS heavy), we’re actually not tapping into the full power of Mootools. Whoops.

That is another point I wanted to bring up, though. When Mootools 1.11 and earlier was around, things were great. The framework was good, the docs were good, the examples were good. Come 1.2, they changed their site (much uglier), castrated the examples, and the documentation is, in my opinion, pretty jenky. There are no good tutorials on their site, and it seems like there are many features I’ve never tapped into because, well, I just never knew about them.

This is half my fault, half Mootools’. I should be doing my research, but educating those using your framework is a must as well. Let’s hope they work on it, and in the meantime I’ve got some reading to do. It doesn’t help that the update from 1.11 to 1.2 changed an assload of conventions, classes, and method names.

All in all, it seems like Mootools is the way to go if you are already great at Javascript…and I am. That being said, it may be worth me learning jQuery to do simpler DOM parsing and AJAX. For larger projects that actually need to reuse big pieces of code and do more than parse the DOM, I’ll gladly stick to Mootools.

Let the flames begin…