I had a fine time at Furry Connection North, held in Novi, Michigan 2 weekends ago.
It was a "regular" working convention for me. I was on security with the Dorsai Irregulars again. I worked several shifts and then got to hang out, attend a few panels, and meet up with friends.
Finally, here are some stats from the convention:
Total attendance: 1179 members
Fursuit Parade count: 230 fursuiters
Total Charity Donations for Mutts and Mutts Rescue: $5000 ($1,214 in cash, $440 from the poker tournament, $1,975 from the Charity Auction, and $1,371 from the con!)
The rest of my set of pictures can be found over here on Flickr.
I had a great time at Furry Connection North, and intend to be back in 2013!
I'm a huge fan of Drupal's Fivestar module. I use it on all of the sites I run. That said, I always wanted to see some reporting and stats features with the module. It would be nice to track voting activity so that I can spot instances of abuse, or see if there are any users who consistently receive low ratings. So I decided to write a separate module which did just that.
Here's what Fivestarstats does:
So where can it be found? On GitHub, naturally:
So I was troubleshooting Anthrocon's website the other night, trying to figure out why pages were taking a few seconds to load, but used to be much quicker. While digging around, I saw that the filecache directory was over a Gigabyte in size. So I cleared the cache, and saw that it was still several megs in size, which struck me as odd.
Looking in the cache/ directory, I saw that the file that held the cached copy of the system variables was over 5 Megabytes in size. Definitely not normal. My next step was to check the variables table, and look what I found:
mysql> SELECT name, LENGTH(value) AS len FROM variable WHERE name LIKE 'captcha_placement%'; +-----------------------------+---------+ | name | len | +-----------------------------+---------+ | captcha_placement_map_cache | 5155086 | +-----------------------------+---------+
It seems that for reasons I don't understand, the "captcha_placement_map_cache" variable from the CATPCHA module grows without bound. In our case, it was well over 5 Megs. This means that on every page load, a 5 Megabyte file was being read into memory and deseralized. While the filesystem cache kept the disk from getting hammered, the CPU still had to do the same work over and over.
The good news is that I could delete that variable with no ill effects, and the entire website suddenly became much more responsive. Here's a CPU graph:
I'm unclear as to what's happening in the captcha module. I think my long-term solution will be to modify my DDT module to just delete that variable once it exceeds 10 K. That will keep this from ever bothering us again.
I'm pleased to announce my module called DDT, which stands for "Doug's Drupal Tools". (Clever, huh?)
I wrote this module to add some auditing and other functionality to the Drupal-powered sites that I run. Here's a list of its main features:
But wait, there's more! Due to some incidents of spam and other network abuse, I added in some anti-abuse tools:
So where can you get a copy? Right now, it's on GitHub:
Share and enjoy!
Just a quick post about Delaware Furbowl 34. I went the other weekend and had fun times. Here are some of the pictures I took:
I wish I had a greater variety of picutres this time around, but the group picture happened earlier in the event, after which point people got out of suit. Lesson learned for the next Furbowl I'll attend.
My full archive of pictures can be found at: http://www.flickr.com/photos/dmuth/sets/72157629166046270/
And on a personal note, I rolled a 202:
I found this in an old LiveJournal post of mine and thought I'd share it here.
Chontamenti was a member of the abuse team at Erols Internet many years ago along with Afterburner, Neurotoxin, and others. The observant will note that each member's name was 4 syllables long. This was intentional.
CHONTAMENTI(1) User Commands CHONTAMENTI(1) NAME chontamenti - compress spammers SYNOPSIS chontamenti [ -acfhLqv19 ] [ spammer ... ] DESCRIPTION Chontamenti compresses spammers or parts of spammers using Size-Eighteen Boot compaction coding (S16-18). Whenever possible, each spammer is replaced by one without the .nads extension, while changing the ownership of the compressed body parts to group "erols". Chontamenti will only attempt to compress spammers and other net-abusers. In particular, he will ignore joe-jobs and lame forgeries. The amount of compression obtained depends on the original size of the spammer's genitalia, head, and colon. Typically, an average chickenboner can be compressed by 20-30%, with a
It's that time of the year again, to clean out Anthrocon's ride share and room share forums.
I dislike deleting old content, because that just causes lots of bad links from Google (and possibly other sites). Not to mention that my logs fill up with 404s unnecessarily. Instead, this SQL will do the job nicely.
CREATE TABLE temp_nids ( nid INT(10) UNSIGNED, term_name VARCHAR(255), title VARCHAR(255) ); INSERT INTO temp_nids ( SELECT DISTINCT term_node.nid, node.title FROM term_node LEFT JOIN node ON term_node.nid = node.nid LEFT JOIN term_data ON term_node.tid=term_data.tid WHERE term_node.nid IN ( SELECT n.nid FROM node AS n LEFT JOIN term_node AS tn ON n.nid=tn.nid LEFT JOIN term_data AS td ON tn.tid=td.tid WHERE ( td.name LIKE '%Room Share%' OR td.name LIKE '%Ride Share%' ) AND n.status = 1 AND FROM_UNIXTIME(n.created) <= '2013-07%' ) ); DELETE FROM term_node WHERE nid IN ( SELECT nid FROM temp_nids );
The innermost SELECT statement will return the posts made from those forums before last year's convention. The NIDs are then matched to their forum names and post titles and written to the temp_nids table. The reason for the forum names and post titles is to allow for manual inspection of the temp_nids table.
The temp_nids table is then used by the DELETE statement at the end to remove all terms from those nodes, effectively "detaching" those posts from the forums they were originally made in.
End result: the posts aren't removed from the site, just from the forums they were originally in.
As folks noticed on Thursday morning when we opened hotels, the website displayed errors for 5-10 minutes starting at 9 AM EST due to the rush of traffic that came in. This was due to a few factors, which I'd like to go into in technical detail below.
First, some raw stats:
Peak bandwidth: approx 3.6 Megabits/sec
Peak connections: 1,060 concurrent connections
Number of users logged into the site: 100+
Here are some graphs that show just how big those numbers are, compared to normal traffic levels:
For those who saw last year's post about the load on the webserver when we opened up hotels, this year's traffic was about twice what last year's traffic was. I didn't see that coming.
As is plainly visible in the traffic graph, the machine that this website runs on is capabale of much higher bandwidth throughput. So, what happened?
In a word: caching. Or rather, the lack thereof in certain cases.
I finally did it. I bit the bullet and upgraded my site to Drupal 6. Yes, 6.
I had been meaning to upgrade the website YEARS ago, but a number of factors conspired against me, including:
- Waiting on a Drupal 6 port of Acidfree
- Real life $WORK-related things
Be that as it may, the upgrade is finally complete, and my website is now running something just a little more modern. I'll roll out more features to the website in the future, including a brand new commenting system. In the meantime, be sure to subscribe to my RSS feed and/or reach out to me on any of the social networks I'm on.
I'll see you out there.
So I watched Forks Over Knives last night. It's a documentry that talks about the dangers in... not fat, but animal proteins and processed food. It links them to happy fun things such as type 2 diabetes, obesity, and high cholesterol.
The takeaways from this:
- It's not fat that's an issue as much as it is eating protein that comes from animals. That's been shown to cause the above mentioned conditions.
- Protein from plants is not a problem.