ChetOS.net

Analytics software allows you to instrument your code.  This instrumentation can allow you to see what features are being used, generate timing information, monitor exceptions, and send information.  Homegrown instrumentation solutions can be written quickly and do some of the basics, but they lack the functionality of a commercial product.

A commercial product will provide a clean API, have the ability to send the data over the internet (rather than store it in a log which must be retrieved), and have a wide range of reporting capabilities (which homegrown solutions almost never have).

I have been using EQATEC Analytics for the past few weeks and it has all the features you would expect and more.  The dashboard provides excellent reporting capabilities which let you see, over time, how your features are being used and if you have any timing problems.  In addition, it logs all of your exceptions and allows you to track and close them as you fix the underlying issue.

In addition, since it is an enterprise-level solution it allows you to track multiple products and provide all the developers in your organization with their own access credentials.  You can even partition the products so that developers only have access to the products they care about.

Check it out, http://www.eqatec.com/analytics/

I *hate* that there isn't a "bucket" to store information this control.  Lets say that the CheckBox is associated with a row in a table.  Each row is associated with an entry in the database, and they all have a primary key.

I should be able to stuff this primary key into the CheckBox somehow so that I can retrieve it easily later.

OAuth essentially lets you issue a shared-secret to a client application (even if is written by us).  The shared-secret is tied to a key.  When a request is made, the payload is "signed" by hashing the secret with the payload.  Then the payload, the signature, and the key is sent to the server.

The server looks up the secret in the database using the key.  It then hashs the incoming payload with the secret.  If the signature matches, then you know that the client had the correct secret.

This lets you lock down *what* can access your web services.  Meaning, third party developers can't use are services without our permission, even if they have valid user credentials.

Another aspect is *who* can access the web service.  This is handled by issuing another shared-secret which is dependent on the user AND the client application.  Then the payload is hashed with the user shared-secret and the client shared-secret.

This allows third parties to "log in" as the user, even though the user didn't give the application his password.  We haven't implemented this part yet.

My remote control lanwmower project is pretty much done.  All that is left are some nice-to-have features like remote kill-switch, putting larger caster wheels on the front, mouting the electronics.

I have posted two videos on youtube.  They are scenes of my testing when my wife happened to have the camera, so they are not the most impressive demonstrations.

Trial run of just the frame
Lawn mower installed and cutting some grass

I think it goes 10-15 mph, but that is way to fast to cut the grass.