Building Analytics

A key part of any build is figuring out what colleagues want to track and how to effectively manage that data. In this case, there is a lot of stuff to track. I recently finished building a hefty analytics components to the app and wanted to share my approach and some things that drove me crazy.

First, I had to really think through which analytics were important. The initial ask was for about 30 different types of analytics, but then, when adding in timeframes, and additional category components, we were talking about close to 400 queries… not super useful for an early launch. Additionally, through my experience with Neighborsations, I could look at these requests and know which ones were most important for raising funds, for identifying user paths, and which ones wouldn’t really be useful until we had a larger critical mass using the application. I also made sure to ask my team what the most important success factors were to them (ie- if this number isn’t what we want it to be, then the business is not successful and we need to make some hard choices, quickly… that’s actually a vital part to determining core metrics and something I learned from Steve Wendel who’s awesome at pushing you on those hard questions.)

The easiest way to do the queries was through writing DB queries, putting them into a model with methods and then creating a view. The app is an ember-appkit-rails app which kinda mushes the rails api and ember together but I decided to keep this simple and just run everything outside of the ember piece and just keep it as typical rails.

There were also a couple of options for running the number… we could have done a rake task or set up a chronjob. Right now, the approach is just to have the business folks hit that page whenever they want new numbers (with the understanding that they shouldn’t hit it too often because it kicks off a bunch of queries that hit the database).

To seed the data, I was originally leaning towards factory girl but decided to start with just creating the data I needed in the tests. What I didn’t realize is that the app automatically pulls in fixture data, so everytime I had a to eq it would fail because the number would be incorrect. That taught me… after spending probably too much time trying to figure out how to not have the test pull in the fixtures, I realized I should just embrace them, learn how to set up the fixtures for my tests correctly and use them to generate the data I needed.

Then I created a model with the class AdminAnalytics. Each analytic was a separate method. I think if I wanted to go back and continue to refactor further, then I could easily break the model into separate classes. For example, instead of having one overarching AdminAnalytics class, it would probably make more sense to have a Users class, a Posts class, and Ingredients class, etc.

Then it was down to the queries. I didn’t have much SQL experience and some of these queries were pretty complicated so it helped me to first write out all of the steps that I was looking for before translating it into an actual query. Once I did that, I could take those queries and use ActiveRecord to give me the rails magic that made the queries a little easier. For example, when joining tables in queries, you don’t have to note the join table… you can just note the two tables and activerecord will figure out the relationship between the two tables on its own. Then, because a lot of the queries involved profile type names or time parameters, I refactored by making those things arguments on the method that could be put in place in the view.

Then I created a controller which was literally one line and was able to create a view that just called the instance variable @analytics and the method with whatever arguments I needed. Bam! Analytics.

Now, once this was all done, we actually decided to pull the analytics out of the app. Instead of bundling these things together, we made it a separate app entirely that talks to the primary app in order to get the numbers needed. When we pulled it out, we used sequel which made it easier to pull those queries in (although still more difficult than just doing it right in the app). The nice part about the app was being able to use ActiveRecord but it also made the analytic piece dependent on a bunch of different models. For example, to get the total number of users, you just do User.count or to get the total number of posts, Post.count. You’re already depending on two different models here, User and Post. So, part of pulling this piece into a separate app was so that we were no longer relying on multiple models in order to get these numbers.

The other thing I really wanted to do was set up a simple dashboard using Dashing. I’d seen people whip these dashboards up in no time flat, so I figured I’d take a stab at it… boy was I mistaken. I think my journey to a dark place started with the decision to use dashing-rails instead of dashing. See, I figured, if I used dashing then I would have to create the connections to the database in order to get the information for the queries I was running. If I used dashing-rails, then the dashboard would be a part of the app and this part would be easier. (If you’re thinking about the paragraph above and thinking, wait a second, you pulled the whole thing into it’s own app anyway in the end, yes. I realize this and boy is hindsight 20/20). Dashing-Rails involves a bit more setup. You’ve gotta set up concurrency, you have to use a database that has lots of threads like puma, etc. The issues started there and just didn’t stop. First, I had an issue with puma and so I upp’ed the number of threads possible and that seemed to fix it. Then, there was a database connection issue. The DB connection would time out almost immediately. We got this working as well, but it still times out. After a certain number of rounds, the thing just kicks the bucket. Then, I had an issue where all my dashboard widget boxes would show up but nothing would show up in them. Sometimes, if I commented things out and then reimplemented them one at a time, they would work again. And there was no rhyme or reason about when the dashboard would start up and kick off, versus when it wouldn’t.

So, here’s the really annoying part. I FINALLY got the issues fixed (with the help of lots of pairing with a few different, very patient people) and pushed the dashboard to production, where everything promptly broke and nothing rendered correctly. Then we got it rendering correctly, but the queries still aren’t running correctly. All the while, I’m kicking myself because I was the one who said, “oh, and I’ll build this awesome dashboard to go along with the simple analytics view. It’ll be fun and shouldn’t take too long.” I think the dashboard was mostly a lesson in when to give up. I should have scrapped it after the first week and a half, but I was a little too stubborn and a little too determined to get it done.

So, that’s how I built the analytics. For my final thoughts, I think the moral of this story is to always keep it simple. Start small, get that shipped and continue to add and improve.

Interesting reads from the week 4/19 - 4/25

Just three short interesting reads for this week... I imagine/hope there will be more next week with some good blog posts coming out of Railsconf so enjoy these and look forward to some more next week.


Design for good and interesting thoughts

Interesting read on TDD

    In response to this initial post

Snappy Means Happy

Matthew Beale gave us a lot to think about and showed me a bunch of tools I had no idea existed in this talk about performance. He started by giving us some good things to think about… mainly, what does fast mean to you? He showed different speeds and what that would mean in terms of actually viewing an app (ie- animations, etc.). You can use that “fastness” scale to then look at your code and see what piece is taking the longest. Is it the network? The javascript? Or the render? Thinking about each of these and looking at times for each part help you narrow down what tools to use and what part needs to be made snappier.

When you’re ready to dive into performance and have pinpointed what part needs working on, then you can move on to the recommended methodology. This is 1) gather the facts and isolate the problem. 2) analyze and theorize about what’s going on. 3) change a single thing… if you change a bunch of stuff and performance is better then you don’t actually know what made the difference. And 4) confirm the theory. The example Matthew used was loading the ember.js website on your phone.

So, first you need to reproduce the immobile latency reliability… in this case you can use slowyapp, Charles, or network line conditioner. You then create a clean browser (this was also a new concept to me) which means you have no extensions, a private window and therefore nothing interfering with the site you’re working on. Then you measure and analyze in the network inspector. In that inspector you can check out the timings tab which gives you a bunch of information.

Part of that information shows us that if you look at the timeline, you can see the load order of things and how long each element is taking. Here, you end up being able to move a script tag which makes the page’s load time much faster.

Next, we looked at “janky” animation. To solve this issue, you first need to understand browsers, then you measure with the timeline tool (another one of the inspector tabs). You can highlight a specific section to get more information about it. You can look at frames which show how long something takes to get to the screen. Green = paint, yellow = javascript, clear = upload to GPU, compositing. AND THEN, render console has a bunch of additional tools you can use to record and generate the data.

If you’re a little lost on where all these tools are and how to access them, the slides show it all pretty clearly.

Also, at this point in my notes I had written “OMG, so many tools!” which I thought was worth sharing here.

In this case, the solution to the issue is a webkit transform that keeps it on the GPU and then uploads the whole thing to the graphics card. By adding a Z translation to the animation, it forces the GPU to say this is 3D and should be put on the graphics card.

Finally, we talked about ember.js property change notifications. For this methodology, first you need to understand observers and then look at the profiler. Observers are synchronous and fire when a set thing occurs. There are two options .setProperties or Ember.run.once. Then you look at the profiler. The profiler has processing and memory. You run a profile and get back information in form of a flame chart. A flame chart allows you to see the stack that is being run. In the list view you can use the profiler to pinpoint the issue. Here, you refactor to create a buffer instead of pushing items into an array which fires 1 change notification instead of many.

The important thing to remember here is to have a methodology to solve issues, to remember that web performance does not equal ember performance and that there are a heck of a lot of awesome tools you can use to help you out.

The Unofficial, official Ember Testing Guide

This was one of the sessions I was anxiously awaiting and it did not disappoint. First, a big hand of applause for Eric Berry for giving an excellent talk (his first one!). The slides were excellent and I can’t wait to continue looking into the new ember-qunit.

Testing looks at assertions. Assertions test the state of your code and QUnit is the default assertion library. In ember tests, there are always two parts, the setup and the teardown (those are callbacks). Now, there are assertions that are already provided (see the slide for those). One thing that Eric noted was that mocha and jasmine are not excluded in ember… you can use either of those for testing as well, but qunit is the happy path (a phrase I’ve come to know and love since working with ember).

Helpers help us guide our app to the state we want to test in our assertions. Looking at the callbacks, the setupForTesting sets up the router, etc. then you call injectTestHelpers which sets up the helpers so then, in your actual test, you write your helpers and then your assertions. Ember.test runs the helpers and qunit runs the assertions. Additionally, there are a bunch of different types of helpers starting with asynchronous helpers, synchronous helpers, and wait helpers. Asynchronous helpers wait for the proceeding helps to finish before they run. These are visit(), fillIn(), click(), and keyEvent(). Synchronous helpers run instantly. An example is find() and finally wait helpers wait for asynchronous helpers to complete before running. An example is andThen().

Then there are custom helpers. Use registerHelper() to create an asynchronous helper. Use registerAsyncHelper() to create a new async helper. A final reminder at the end of this part was that you still have to call injectTestHelpers to make sure you run the helpers regardless of whether they’re custom or not.

So now, the new things that will be in Ember 1.5. There will be new integration helpers. For example, triggerEvent() which takes three arguments: selector, event, and anything additional you need to add. Others are currentRouteName(), currentPath(), and currentURL().

At this point, there was an awesome example of testing search, so if you’ve got search in your app, check it out.

The next part looked at how to test in isolation. So instead of having to test all the pieces all the time, you want to test specific aspects. This is where ember-qunit was introduced. Ember-qunit is a library that lets you perform unit tests without loading the whole container. Ember-qunit was inspired by rspec. You start by setting up the globals is emq.globalize() and then you need to set up the resolver (described as the thing that can find anything… ie- mom). It also provides module helpers. These are moduleFor(), moduleForComponent(), and moduleForModel() . For the example moduleFor(“route:index”), it’s basically saying “hey resolver, I need you to pull this (the route:index in this case) from the container. moduleForModel() is specifically for testing Ember-data. There are super descriptive, awesome slides for each of these module helpers.

The last piece I noted was in controllers. In those tests, you’ll notice a “needs” field. Needs is used to bring in the dependency that the test need to bring in, in order to run… in the case on the slide, the controller for application.

To get going with ember-qunit, you just need to do bower install ember-qunit. It’s in ember-appkit and ember-cli already.

Finally, the last big announcement was that the team is redoing the testing guide on the ember.js site.

Happy Testing!!

Because it's been a little while... Here's another Euler!

Project Eulers 7 and 8

Just a few more Euler’s left and I realized the other day how long it had been since I’d posted some answers! I’m also posting both 7 and 8 because really, problem 7 uses the prime library again, so the answer is really short and sweet.

So, first, here is the problem:
By listing the first six prime numbers: 2, 3, 5, 7, 11, and 13, we can see that the 6th prime is 13.

What is the 10 001st prime number?

First, here are the tests:

require 'problem7/problem7'

describe 'Prime number positions' do 
  
  it "is the 6th prime number" do 
    expect(Problem7.prime_place(6)).to eq 13
  end

  it "is the 10001st prime number" do
    expect(Problem7.prime_place(10001)).to eq 104743
  end

end

The tests and the code are pretty simple. You’re just using the resources in the prime library and then use the library to list (take) the numbers up until a certain position (ie- the 10,001st position) and then put the last number which is the answer to the question. So, here’s the code:

require 'prime'

module Problem7

        def self.prime_place(position)
          prime_place = Prime.take(position).last
        end

  puts Prime.take(10001).last

end

And now for Euler 8. This problem was actually really tough for me for two reasons… first, it seemed different than most of the others I had done up until now and second, how the heck do you test this thing?!

Here’s the problem:

 Find the greatest product of five consecutive digits in the 1000-digit number.

 73167176531330624919225119674426574742355349194934
 96983520312774506326239578318016984801869478851843
 85861560789112949495459501737958331952853208805511
 12540698747158523863050715693290963295227443043557
 66896648950445244523161731856403098711121722383113
 62229893423380308135336276614282806444486645238749
 30358907296290491560440772390713810515859307960866
 70172427121883998797908792274921901699720888093776
 65727333001053367881220235421809751254540594752243
 52584907711670556013604839586446706324415722155397
 53697817977846174064955149290862569321978468622482
 83972241375657056057490261407972968652414535100474
 82166370484403199890008895243450658541227588666881
 16427171479924442928230863465674813919123162824586
 17866458359124566529476545682848912883142607690042
 24219022671055626321111109370544217506941658960408
 07198403850962455444362981230987879927244284909188
 84580156166097919133875499200524063689912560717606
 05886116467109405077541002256983155200055935729725 
 71636269561882670428252483600823257530420752963450

So, first for the test. After asking around a bit, the best suggestion I got for testing was to break down the string and take 10 or 15 characters and figure out the largest product from that string and then do the same with the larger number.

Here are the tests:

require 'problem8/problem8'

describe 'largest products of consecutive numbers' do 
  it "is the largest product of 5 consective numbers" do 
    expect(Problem8.product(7316717653)).to eq 1764
  end

  it "is the largest product of 5 consecutive numbers" do 
    expect(Problem8.product(7316717653133062491922511967442657474235534919493496983520312774506326239578318016984801869478851843858615607891129494954595017379583319528532088055111254069874715852386305071569329096329522744304355766896648950445244523161731856403098711121722383113622298934233803081353362766142828064444866452387493035890729629049156044077239071381051585930796086670172427121883998797908792274921901699720888093776657273330010533678812202354218097512545405947522435258490771167055601360483958644670632441572215539753697817977846174064955149290862569321978468622482839722413756570560574902614079729686524145351004748216637048440319989000889524345065854122758866688116427171479924442928230863465674813919123162824586178664583591245665294765456828489128831426076900422421902267105562632111110937054421750694165896040807198403850962455444362981230987879927244284909188845801561660979191338754992005240636899125607176060588611646710940507754100225698315520005593572972571636269561882670428252483600823257530420752963450)).to eq 40824
  end
end

And so, here’s the solution. First, I created an empty array. Then I wanted to use .each_cons which takes every set of consecutive numbers based on the number of characters you ask for (in this case, it would be 5 because I’m looking for the largest product of 5 consecutive numbers) but .each_cons wouldn’t work because you can’t call .each_cons on a string. So, first, I had to separate the string into individual characters by using each_char. Once the string was separated into each_char (each character) I used the map method to make each of the string characters into an array of integers. Then, I used each_cons(5) which separated the array of integers into arrays of every five characters. The I took the product of each of those integers and pushed it into an array. Finally, the max is called on that array which gives the largest number needed for the answer.

module Problem8
  
  def self.product
    arr = []

    "731671765313306249192251196744265747423553491949349698352"\
    "0312774506326239578318016984801869478851843858615607891129"\
    "4949545950173795833195285320880551112540698747158523863050"\
    "7156932909632952274430435576689664895044524452316173185640"\
    "3098711121722383113622298934233803081353362766142828064444"\
    "8664523874930358907296290491560440772390713810515859307960"\
    "8667017242712188399879790879227492190169972088809377665727"\
    "3330010533678812202354218097512545405947522435258490771167"\
    "0556013604839586446706324415722155397536978179778461740649"\
    "5514929086256932197846862248283972241375657056057490261407"\
    "9729686524145351004748216637048440319989000889524345065854"\
    "1227588666881164271714799244429282308634656748139191231628"\
    "2458617866458359124566529476545682848912883142607690042242"\
    "1902267105562632111110937054421750694165896040807198403850"\
    "9624554443629812309878799272442849091888458015616609791913"\
    "3875499200524063689912560717606058861164671094050775410022"\
    "5698315520005593572972571636269561882670428252483600823257"\
    "530420752963450".each_char.map(&:to_i).each_cons(5) { |a| p arr << a.reduce(:*) }     
    puts arr.max 
  end
end

Phew! Look forward to the last two Eulers, 9 and 10, which I’ll hopefully get to post soon.