Entries this day: first-try-at-a-scoring-mechanism lawnchair-to-solve-a-different-thing-at-work yesterday-at-work

first try at a scoring mechanism

##06:57 Wednesday 08 May 2013

6:43am Wednesday 8 May 2013

This morning I added a score calculator that takes into consideration the number of cards remaining. I figure if only a few cards remain, then it's easier to find the correct one.

It also makes use of prime numbers and floats in an attempt to ensure people do not often get the same high score.

/* prime numbers:
2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71,
73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151,
157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233,
239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317,
331, 337, 347, 349, 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419,
421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499 */

NSTimeInterval timeElapsed = [[NSDate date] timeIntervalSinceDate:self.roundStartedDate];
double bestScoreTime = self.numCardsRemain * 0.1 + 0.3;
double goodScoreTime = self.numCardsRemain * 0.21 + 0.69;

if(timeElapsed < bestScoreTime) {
     self.scoreMultiplier = 337;
     self.score += self.scoreMultiplier * (bestScoreTime - timeElapsed);
}
if(timeElapsed < goodScoreTime) {
     self.scoreMultiplier = 113;
     self.score += self.scoreMultiplier * (goodScoreTime - timeElapsed);
}
self.scoreMultiplier = 10;
self.score += self.scoreMultiplier;

NSLog(@"%d cards %f seconds %d",self.numCardsRemain,timeElapsed,self.score);

lawnchair to solve a different thing at work

##19:27 Wednesday 08 May 2013

7:10pm Wednesday 8 May 2013

I was thinking recently how I didn't use lawnchair to keep track of which items were on a page when coming back to it.

But today I did use lawnchair for a different thing, mostly because I was already using lawnchair for a similar issue. There's a page which uses Datatables to display lists of units in the system. When clicking to view a particular unit, there are previous and next buttons on the page. Lawnchair keeps a big-ass list of all the unit ids so it knows which is the previous and which is the next. I know there's some optimation optimization to be done here, but haven't figured out how yet.

A long time ago, a request was made by the client to select all the records in the list. This needed to be backed by the database (users_2_selections) and I couldn't figure a good way to "re-search" the units according to what search parameters were just done. I told them "it's a really hard problem" and put it off for months.

THEN, today, when looking at a different request, I realized that selecting all the records in the list could solve it (more easily than another way to solve it). So I re-visited this problem and realized "derp! I have all the unit ids in Lawnchair!"

When they click on the thing (what's the word for a span that's not a link and not a button but responds to a click event?), it says "hey lawnchair, give me that list of ids!" and then ajaxes "hey server, they wanna select all these ids!" and the server is like "cool" and slaps them into the users_2_selections table and all is good.

EXCEPT for one detail: it seems that if there's more than 1000 unit ids, the server doesn't get them all. I'll have to look at that one later, possibly tomorrow.

dinner time now!

yesterday at work

##06:43 Wednesday 08 May 2013

6:38am Wednesday 8 May 2013

Yesterday at work I got the pagination to be ajax driven if javascript is enabled and GET driven if javascript is not enabled.

I've started to cut a couple corners as the project is a bit overdue.  For example, instead of figure out how to redisplay the same units when clicking back to the map page (I'd probably use Lawnchair), I just open units in a new tab.