As of 2016-02-26, there will be no more posts for this blog. s/blog/pba/
Showing posts with label human. Show all posts

Even with all these systems and people working to stop bad ads, there still can be times when an ad slips through that we don’t want. There are many malicious players who are very persistent—they seek to abuse Google’s advertising system in order to take advantage of our users. When we shut down a thousand accounts, they create two thousand more using different patterns. It’s a never-ending game of cat and mouse.

This summarizes up how worse those bad and abusive people are on the Internet, even Google confirmed it and has to deal with them with much efforts in order to keep them away. I recommend that you read the post, just to know how serious the situation is and what steps Google are taking to fight against scammers, though I don't feel Google is the one winning, but it's trying.

I read it because I need to read something, I am forcing myself to read everyday. Not I was interested in this topic, but I was glad that I read it with patience. Google has a system which involves three different aspects to decide and co-judge whether a subject is bad or good, do they (machine or human) need to take further steps or just block, and so on.

You will find that human truly is the last defense in all three aspects, they make the final call when machine can't tell. Like other modern system, decision isn't made by fixed rules, they can evolve and learn from mistakes (errors, which human points out), still, human is the most crucial component.

If I recall correctly, I only reported once on a Google ads. That ads tricked me to click on a text saying "Close," and I did click on it. It was instinctive reaction when that ads kept flashing strong colors like between red and yellow. It was so annoying, although I rarely saw such kind of trash ads via Google's advertisement system, but I did that time.

Out of natural instinct, I clicked on that "Close," however that would never got you to close that ads. Instead, I was brought to the ads' website. I was fooled, clearly.

That was only time I saw a bad ads via Google, I think Google does a good job on protecting their profitable advertisement system. There might be more, only I hardly pay much attention to ads, and my eyes and brain are well-trained ad-filter, but some slip through. I care more about email spam since it's main source I would see a spam or phishing email.

I would believe that Google has actually brought those scammers to court, they had done so to spammers. They have all information of all advertisers, so there should have no problem to file a lawsuit against a scammer. Name, address, phone number, credit card, everything they need is already in Google's database. Some could be fake, but it can't be all. Identity thief, come on, this is not a drama.

Anyways, I am looking forward to more posts like this.

Recently, I upgraded SDK to 1.4.2 from 1.4.1 and added new stuff to lil.btn. I was trying to read the Django 0.96 template documentation on Django’s website, then I found out the page has been removed. Actually, I recalled I have known the removal of the page for some time.

1   Django 1.2.5 Template

Anyway, I decided to use Django 1.2.5 Template since it’s shipped with SDK. Amazingly, it’s so easy to switch to another version from the default version 0.96. This is what I only added before the template import, suggested by the doc,


# os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

from google.appengine.dist import use_library
use_library('django', '1.2')

from google.appengine.ext.webapp import template

I only use template. I don’t know if i18n will be this easy as well, I might do a follow-up later. I need to mention I didn’t want to switch at first and still don’t. But it seems that I have to.

1.1   autoescape

One thing about Django 1.2.5 I like is it automatically enables escaping for preventing code injection on client-side. You know developers sometimes are lazy or careless, because we think will review our codes once everything is settled. But one might be missed or even intentionally skipping reviewing some codes and forget there is always a risk.

When I was using 0.96, I often did {{ varname|striptags|escape }} or just {{ varname|escape }}. I didn’t know if there is one I forgot to filter, now I need to worry less. If you are sure some don’t need, you just {{ varname|safe }} so Django won’t escape it.

I don’t know which version it was started with, but it was commited into code three years ago.

1.2   Loading humanize

Probably two years ago, I wanted to add thousands separator to some statistic integer numbers. You can always do that in your Python code1.

I know there is a set of template filters called humanize in Django, why re-invent? I tried to include it into of my GAE app. I got the code from SDK and removed unwanted filters and put it in the top level of my source.

But I found out there is a really quick and easy way and it works for both 0.96 and 1.2 (1.2.5),


def main():

webapp.template.register_template_library('django.contrib.humanize.templatetags.humanize')
run_wsgi_app(application)

That’s it. You just use that register and there is no need for {% load humanize %} in your template, you just add the filters wherever you want, e.g. {{ varname|intcomma }}. I believe this also works on other contributed Django templating code sitting in /contrib.

When I firstly tried, I even added a Django setting file, but I couldn’t get it to work. Few days ago, I read this question. It gave me an idea, though I can’t just use import to get it work. I use that register function with full module path, that works.

[1]Coding by yourself or using Python 2.7+, but this isn’t the case for Google App Engine. But may be some day, supporting 2.7 is listed in roadmap.

2   Capability name of datastore for CapabilitySet

I read the documentation about the supported capabilities and I had these


CapabilitySet('datastore').is_enabled()
CapabilitySet('datastore_write').is_enabled()
CapabilitySet('memcache').is_enabled()

They run fine on development server, however, after I deployed the code, I got:


Traceback (most recent call last):
File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 515, in __call__
handler.get(*groups)
File "/base/data/home/apps/lilbtn/1.348320236448169656/itchape.py", line 205, in get
if CapabilitySet('datastore').is_enabled():
File "/base/python_runtime/python_lib/versions/1/google/appengine/api/capabilities/__init__.py", line 98, in is_enabled
config = self._get_status()
File "/base/python_runtime/python_lib/versions/1/google/appengine/api/capabilities/__init__.py", line 170, in _get_status
raise UnknownCapabilityError()
UnknownCapabilityError

The memory cache part is fine. I don’t know why that name of capability didn’t work, but I found an alternates,


db.READ_CAPABILITY
db.WRITE_CAPABILITY

But I use these later,


CapabilitySet('datastore_v3', capabilities=['read']).is_enabled()
CapabilitySet('datastore_v3', capabilities=['write']).is_enabled()

I found the second line on Handling downtime: The capabilities API and testing, which I had skimmed when it was published.