Spam Attack?

Blogspirit introduced a new anti-spam feature today which allows blogger to ban specific IPs. This is pretty nifty, but it coincides with an enormous increase in traffic spam. I wonder if this is either a weakness in the new system, or the revenge of some blogger who suddenly finds that his old methods of vandalism do not work.

A full list of Internet Protocol addresses (IPs) I’ve banned so far are below, but it appear that most spam comes from only a few sites:

212.158.16?.*
212.24.3?.*
217.23.13?.*
62.213.6?.*

While (edited) examples of the trackback spam are:

hockey Sabres hockey club Sabres
point Four point bed Four
screen Hot screen names Hot
sonia Lady sonia photo Lady

That the spam is coming from the same pattern (Word1 Word2 Word1 Word3 Word2) means that (a) the spam is coming from the same source and (b) the spammer is a poet.

Weird, no?


Full list of IPs banned so far:

91.76.101.115
211.167.248.2
211.43.222.21
212.158.163.210
212.158.163.26
212.158.164.194
212.158.165.149
212.158.169.67
212.158.169.68
212.158.169.70
212.158.169.74
212.24.32.228
212.24.37.125
212.24.37.126
212.24.37.127
217.23.131.216
217.23.132.117
217.23.132.118
217.23.132.127
217.23.132.225
217.23.136.206
217.23.136.212
217.23.136.214
217.23.136.216
217.23.136.217
217.23.136.218
217.23.136.220
217.23.136.221
217.23.136.227
217.23.136.228
217.23.136.229
217.23.136.25
217.23.136.26
217.23.136.6
217.23.136.85
217.23.143.18
217.23.143.19
217.23.143.225
217.23.143.225
217.23.151.133
217.23.151.228
62.213.66.200
62.213.66.201
62.213.66.204
62.213.66.74
62.213.66.78
62.213.68.194
62.213.68.196
62.213.68.64
69.92.179.101

Glad to be appreciated

Apparently the “Notes on Rails” project is going well — after the wedding day presentation to my adviser, I now have a contract position to continue developing it through the summer (on top of the doctoral credits for doing the same), plus my school-year-assistantship has been bumped up to a research assistantship in a related area.

Timewise, next semester will be busy but productive. I have only about three hours a week of pre-structured time in the fall, the rest being for research and work. I really like an environment such as this. I’ve never been one for make-work, and the longer I’m in it the more grad school lets you focus on getting things done.

Finishing the Question and Question-List Interfaces

After creating the QuestionList and Question controllers, the next step is to update both of them so that defaults are returned when the user edits the extended fields (which conditions the QuqestionList belongs to, and what options a Question has). Because these are stored in other tables, this information is not presented as-saved to the user, but rather the “defaults” are blank.


Populating forms with defaults from the database

With the help of wiki.rubyonrails.org, the process is pretty simple…


… add a new function to question_list_condition.rb (The QuestionListCondition model)

def self.return_checked_by_condition_id_question_list_id(condition_id,question_list_id)
to_find = find_by_condition_id_question_list_id(condition_id,question_list_id)

“checked” if to_find
end

And replace the current checkbox line in views/manage_question_lists/_form.rhtml with:

<br /><%= check_box :selected_condition, condition.id,:checked => QuestionListCondition.return_checked_by_condition_id_question_list_id(condition.id,@question_list.id) %>

to QuestionOption controller will be modified in much the same way

in question_option.rb:

def self.find_display_text_by_question_id_option_id(question_id,option_id)
to_return = find(
:first,
:conditions => {
:question_id => question_id,
:option_id => option_id
}
)

return to_return.display_text if to_return
end

And in app/views/manage_questions/_form.rhtml, just one line needs to be changed:

<%= text_field :question_options, iterator, :value => QuestionOption.find_display_text_by_question_id_option_id(@question.id,iterator) %>

Next up: Display a question list