Pushbutton Native Americans

26 06 2008

The title of this post reflects various workplace transitions. I prefer not to talk about my day job because I Enjoy Not Being Fired For Blogging About My Job(tm), as noted in the past. I shall point out in an obfuscated way that the old issue of “Too many chiefs, not enough native americans” cannot really be solved with pushbutton native americans.

This is the sort of thing bad 50’s B-movies are designed around. The pushbutton native americans have a habit of turning on their chiefs, armed with laser guns and impervious to our radiation weaponry. Soon we are their fleshy slaves, toiling in mines, broken and suppressed.

Our work situation isn’t QUITE that bad, but I confirmed today that when you push the button, the native american goes “ERROR” and falls over, so I’m figuring they’re gonna have to rethink this whole deal.

The 7Seas workfront (because let’s be honest, SL is basically a part time job for me, not just a gamey lark) is looking more complicated, but that’s fine; it’s all problem solving and coding and getting things DONE. Or rather, it will be. Right now it’s pondering how to get them done. We’re cruising at a decent clip, regardless, and I’m satisfied despite annoyances. Last night I got a good picture of the scope of this project… for the 5-7 items not properly delivered each day, we’re shipping out 100,000+ items that are being delivered just fine. Every. Day. Holy smeg. We can’t even fully study our log files because both Excel and OpenOffice go “ERROR” and fall over when presented with only eight hours of 7Seas data.

Things are huge and scary and wonderful and hopefully not prone to collapse and disaster and horror and running and screaming. Time will tell.

Advertisements

Actions

Information

12 responses

26 06 2008
kublaikhan

Better tool for the job?
Perhaps you ought to use something other than Excel or an office product–because, let’s be frank, studying logfiles and looking for trends is a database (SQL or derivative, plzthx, not that Access BS) operation, not a word processing or spreadsheet operation. You could use a basic perl, python, PHP or similar script as a preprocessor to scan through the logfiles and put ’em into a database, then use any number of other products to build your analytics off of.
I’m currently unemployed and looking for a project, so if you wanted to comission something along the lines of a log analyzer, I’d be more’n happy to help. ;-p

26 06 2008
Stefan "Twoflower" Gagne

Re: Better tool for the job?
At the mo’ I was just trying to find out if someone’s item purchase was in the log at all, much less any analysis thereof. If we have more sophisticated report needs later, we’ll consider alternatives.
My goal is to figure out where in the chain of events things are breaking down when items aren’t delivered. So far I’ve ruled the HTTP / PHP / Database end of things out… 95% of the time nondeliveries are reported as processed by the database. That means something in the SL end of things is fouling up the request. If I can trace it all the way to llGiveInventory() then at least I can gave up knowing that it’s a Linden Lab(tm) problem, not my problem. Right now it’s ambiguous, although leaning to LL, since as noted we have 100k+ successful deliveries a day.

26 06 2008
kublaikhan

Re: Better tool for the job?
That shouldn’t be too hard to work out, especially if you know the userID of the problematic user’s purchases.
Zip me the logfiles and I’ll take a quick squint, if you like.

26 06 2008
Stefan "Twoflower" Gagne

Re: Better tool for the job?
Already figured it out. I coded a tool to give me the last eight hours, and did a search on his name. He did buy it, so that wasn’t the culprit.

26 06 2008
kublaikhan

Re: Better tool for the job?
Bah. Oh, well. Remember me for next time, then.

26 06 2008
tozetre

Hey there. Longtime fan of your fiction works, remembered you had a blahg, added you to my flist, hope you don’t mind.
(caveat: I’m a database guy, not a SL guy- in fact, never touched it)
Also, what kublai said about perl/py/MySQL for log files. He’s correct. If you need to do serious logging like that, even for just the last 24 hours, a MySQL db (or another schema on your production db, or whatever) can save you massive amounts of time. With log files that are Hueg Liek Xbox, eyeball mk1 scans are not going to do you any good. Aggregation and reporting systems > notepad. :P
Also, for the future, assuming the system runs on *nix (or you install the package for Win); PROTIP: grep.

26 06 2008
Stefan "Twoflower" Gagne

Yeah, more intricate parsers and reporting is possible. But in this case, really, I just wanted to know “Did this guy get his fishing area kit or not?”. It was to help me track down a different bug. No doubt we’ll need more useful reports later.
And feel free to follow my hideous pile of ramblings at your leisure.

26 06 2008
tozetre

Oh, I shall, sir. I shall.

(uncomfortable stare)
:P

26 06 2008
shadur

Yeah, the summary script I whipped up in five minutes for him to generate .csv files didn’t have much in the way of sublety – it just grabbed *everything* up to midnight of the current day.
A less kludgy job would involve the ability to search for a given user name in the database before outputting the lot, but like I said, five minute perl hack…

26 06 2008
shadur

Re: Better tool for the job?
SL seems to have frequent issues with the payment system in crowded sims. Might be related…

26 06 2008
tozetre

On the other hand though, yay perl. xkcd references and all that.

27 06 2008
Stefan "Twoflower" Gagne

Re: Better tool for the job?
No… if it never took their money (the Money() event never fired) it wouldn’t have made the HTTP database call. This CAN happen and does happen but it’s very rare, moreso than nondeliveries.
I have a tracker running right now, letting me know every time someone has a fishing area kit delivered. If we get someone saying they didn’t get their kit and my tracker says they did, then SL is to blame (llGiveInventory() failed mysteriously and silently). If my tracker doesn’t pick up on it, something’s wrong with my calling routine, or we’re pushing SL’s scripting language too damn far. We’ll see.

Post a comment on this entry! All feedback welcome.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: