Author: masnun

কো-রিলেশন (Correlation), কজেশন (Causation) ও ফেইসবুকের গল্প

Post author By masnun
Post date November 7, 2015

স্ট্যাটিস্টিক্স – ১০১ কিংবা বিজনেস রিসার্চ – ১০১ কোর্স গুলোতে একটা প্রশ্ন খুবই কমন – “কো-রিলেশনই কি কজেশন? উদাহরন সহ ব্যখ্যা করো” । কো-রিলেশন থেকে আমরা জানতে পারি দুটো ভ্যারিয়েবল এর মধ্যে কোন “কো-রিলেশনশিপ” আছে কিনা ।

মনে করি num_friends হচ্ছে একজন ব্যক্তির ফেইসবুক ফ্রেন্ডের সংখ্যা আর time_spent হচ্ছে সেই ব্যক্তি দিনে কতটুকু সময় ফেইসবুকে ব্যয় করে । একদিন সময় করে আমি বিজনেস এ্যাডমিনিস্ট্রেশন ডিসিপ্লিনের শিক্ষার্থীদের উপর জরিপ করে এই ডাটা কালেক্ট করি এবং কো-রিলেশন নির্নয় করি । দেখা গেলো এই ভ্যারিয়েবল দুটি পজিটিভলি কো-রিলেটেড । তার মানে যাদের ফেইসবুকে ফ্রেন্ড সংখ্যা বেশী, তারা ফেইসবুকে বেশী সময় কাটায় ।

সমস্যা হলো, এই ঘটনার পিছনে ৩ ধরনের কারন থাকতে পারে:

(১) যাদের ফ্রেন্ড সংখ্যা বেশী, তারা ফ্রেন্ডদের পোস্ট, ছবি, কমেন্ট পড়ার জন্য ফেইসবুকে বেশী সময় ব্যয় করে (“num_friends” causes “time_spent”)

(২) যারা ফেইসবুকে বেশী সময় কাটায় তারা ফটোগ্রাফি গ্রুপ, ফুডিজ গ্রুপ, নিজের ক্লাসের গ্রুপ, ডিসিপ্লিনের গ্রুপ – নানা গ্রুপে মতামত শেয়ার করে । এরফলে সমমনা অনেক মানুষের সাথে বন্ধুত্ব হয় । (“time_spent” causes “num_friends”)

(৩) এরা ফেইসবুকে বেশী সময় কাটান বয়ফ্রেন্ড বা গার্লফ্রেন্ডের সাথে চ্যাট করে আর ফ্রেন্ড এ্যাড করেন ডিসিপ্লিনের সিনিয়র জুনিয়র সবাইকে । (none causes the other)

এখন যেহেতু আমরা নিশ্চিত না এই ৩টি ঘটনার কোনটি ঘটছে । তাই কোরিলেশন মানেই যে কজেশন – এই ধারনা আমাদের নাকচ করে দিতে হয় । এবং এটা আমরা সুন্দর করে পরীক্ষার খাতায় ব্যখ্যা করে নাম্বার পাই । তাই এর বেশী আমাদের চিন্তা করা হয়ে উঠে না ।

অন্যদিকে ফেইসবুকের বেতনভুক্ত ডাটা সায়েন্টিস্টরা কিন্তু এত সহজে পার পান না । তাদের টার্গেট আমাদের স্টুডেন্টদেরকে বেশী সময় ফেইসবুকে আটকে রাখা, এজন্য এটা নিয়ে তাদের বিশাল মাথা ব্যথা । তারা জানতে চায় বিএ ডিসিপ্লিনের এই কো-রিলেশনের পিছনে আসল ঘটনা কি । তারা ডিসিপ্লিনের স্টুডেন্টদের থেকে র‍্যান্ডম সাবসেট নিয়ে তাদের উপর এক্সপেরিমেন্ট চালায় – তাদের নিউজফিড কাস্টোমাইজ করে ফেলে এবং ২ ধরনের টেস্ট চালায় –

(১) কিছু লোকজনকে ব্যাড এর নেটওয়ার্ক থেকে পোস্ট দেখানো কমিয়ে দেয় । কিছু লোকজনকে বেশী পোস্ট দেখানো শুরু করে ।

(২) কিছু লোকজনকে বেশী বেশী ব্যাড এর সিনিয়র, জুনিয়রদের ফ্রেন্ড রিকুয়েস্ট সাজেস্ট করতে থাকে, কিছু লোকজনকে কমিয়ে দেয় ।

যেহেতু এটি একটি কল্পিত ঘটনা সেহেতু এই টেস্টের ফলাফল আমার জানা নেই । তবে প্রথম এবং দ্বিতীয় টেস্ট থেকে কিছুটা “কনফিডেন্স” পাওয়া যেতে পারে । যদি প্রথম টেস্টে দেখা যায় যে বেশী পোস্ট দেখানোর কারনে লোকজন বেশী সময় কাটাচ্ছে, আর পোস্ট কমিয়ে দেওয়ার কারনে কম সময় কাটাচ্ছে তাহলে আমরা কিছুটা আইডিয়া পাই যে আসলে num_friends causes time_spent অন্যদিকে দ্বিতীয় টেস্ট থেকে আমরা এর উল্টোটা জানতে পারি । আর দুটো টেস্টেই যদি নেগেটিভ রেজাল্ট পাই, তাহলে ফেইসবুকের রিসার্চ টীমের কাজ আরও বেড়ে গেলো । ৩য় কি ঘটনা ঘটতে পারে এটা নিয়ে এখন তাদের চুলচেরা বিশ্লেষন করতে হবে ।

সহজ কথায়, কোরিলেশন নিশ্চিতভাবে কজেশন মিন করে না, তবে টোটাল পপুলেশনের র‍্যান্ডম সাবসেট নিয়ে কিছু টেস্ট করে কোরিলেশনের পাশাপাশি কজেশনও আছে কিনা সে ব্যাপারে আইডিয়া পাওয়া যেতে পারে ।

পুনশ্চ: আমার এই উদাহরন সম্পূর্ন বানোয়াট হলেও ফেইসবুক তার নিউজফিড নিয়ে এক্সেপেরিমেন্ট করেছে এবং সেটার ইথিক্যাল দিক নিয়ে আলোচনা সমালোচনাও হয়েছে অনেক ।

রেফারেন্স: http://www.nytimes.com/2014/06/30/technology/facebook-tinkers-with-users-emotions-in-news-feed-experiment-stirring-outcry.html?_r=1

Django Python

Django REST Framework: Custom Exception Handler

Post author By masnun
Post date November 6, 2015
7 Comments on Django REST Framework: Custom Exception Handler

While using DRF, do you need to handle the exceptions yourselves? Here’s how to do it. First, we need to create an exception handler function like this:

from rest_framework.views import exception_handler


def custom_exception_handler(exc, context):
    # Call REST framework's default exception handler first,
    # to get the standard error response.
    response = exception_handler(exc, context)

    if response is not None:
        data = response.data
        response.data = {}
        errors = []
        for field, value in data.items():
            errors.append("{} : {}".format(field, " ".join(value)))

        response.data['errors'] = errors
        response.data['status'] = False

        response.data['exception'] = str(exc)

    return response

from rest_framework.views import exception_handler

def custom_exception_handler(exc, context):

# Call REST framework's default exception handler first,

# to get the standard error response.

response = exception_handler(exc, context)

if response is not None:

data = response.data

response.data = {}

errors = []

for field, value in data.items():

errors.append("{} : {}".format(field, " ".join(value)))

response.data['errors'] = errors

response.data['status'] = False

response.data['exception'] = str(exc)

return response

In the exception handler, we get exc which is the exception raised and the context contains the context of the request. However, we didn’t do anything fancy with these. We just called the default exception handler and joined the errors in a flat string. We also added the exception to our response.

Now, we need to tell DRF to call our custom exception handler when it comes across an exception. That is easy:

Open up your settings.py and look for the REST_FRAMEWORK dictionary. Here you need to add the exception handler to the EXCEPTION_HANDLER key. So it should look something like this:

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework.authentication.BasicAuthentication',
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.TokenAuthentication',
    ),


    'EXCEPTION_HANDLER': 'api.utils.custom_exception_handler'
}

REST_FRAMEWORK = {

'DEFAULT_AUTHENTICATION_CLASSES': (

'rest_framework.authentication.BasicAuthentication',

'rest_framework.authentication.SessionAuthentication',

'rest_framework.authentication.TokenAuthentication',

'EXCEPTION_HANDLER': 'api.utils.custom_exception_handler'

}

Django Python

Django: Handling broken migrations

Post author By masnun
Post date November 6, 2015
1 Comment on Django: Handling broken migrations

Often for one reason or another, migrations don’t apply properly and we have to fix them manually. If there’s a faulty migration that throws errors when run, we first have to identify what went wrong. Very often on MySQL, we see half applied migrations (probably because MySQL doesn’t have transactions?). In this case we need to do the other half ourselves.

We can easily connect to the database prompt by typing the dbshell command.

python manage.py dbshell

1	python manage.py dbshell

The command opens the shell for the respective database engine using the configurations provided in the settings file. That is you don’t have to remember the username or password for the database connection.

Now you have to fix the issues and then you can try running the migration again. In case it fails again, you should alter the database to match the state the migration would have created. For example, if the migration was supposed to alter a column from store_type to store_type_id (from a char field to foreign keys), you have to manually run the query, something like:

ALTER TABLE api_store CHANGE store_type store_type_id INT(11);

1	ALTER TABLE api_store CHANGE store_type store_type_id INT(11);

Then you have to fake the migration. When a migration is run, Django stores the name of the migration in a table. It helps track which migrations have already run and which needs to be run. When we fake a migration, Django stores the faked migration name in that table without actually running it. If we don’t do this, when we next run migrate command, Django will try to run this migration again and fail.

This is how we fake it:

python manage.py migrate --fake

1	python manage.py migrate --fake

You can also specify one particular migration when you have multiple migrations running.

python manage.py migrate --fake <appname> <migration_name>

1	python manage.py migrate --fake <appname> <migration_name>

Recent Posts

Recent Comments

Archives

Categories